date:20211129

Bug#1000848: Xandikos misses dependency on python3-charset-normalizer

2021-11-29 Thread Jörg Sommer

Package: xandikos
Version: 0.2.6-1
Severity: normal

Hi,

after an update of my (unstable) system, xandikos failed to start:

systemd[1]: Started Xandios CardDAV/CalDAV service.
xandikos[2039771]: INFO:root:Listening on 0.0.0.0:8080
xandikos[2039771]: Traceback (most recent call last):
xandikos[2039771]:   File 
"/usr/lib/python3/dist-packages/aiohttp/client_reqrep.py", line 70, in 
xandikos[2039771]: import cchardet as chardet
xandikos[2039771]: ModuleNotFoundError: No module named 'cchardet'
xandikos[2039771]: During handling of the above exception, another exception 
occurred:
xandikos[2039771]: Traceback (most recent call last):
xandikos[2039771]:   File "/usr/bin/xandikos", line 31, in 
xandikos[2039771]: sys.exit(main(sys.argv))
xandikos[2039771]:   File 
"/usr/lib/python3/dist-packages/xandikos/__main__.py", line 28, in main
xandikos[2039771]: return main(argv)
xandikos[2039771]:   File "/usr/lib/python3/dist-packages/xandikos/web.py", 
line 1299, in main
xandikos[2039771]: from aiohttp import web
xandikos[2039771]:   File "/usr/lib/python3/dist-packages/aiohttp/__init__.py", 
line 6, in 
xandikos[2039771]: from .client import (
xandikos[2039771]:   File "/usr/lib/python3/dist-packages/aiohttp/client.py", 
line 59, in 
xandikos[2039771]: from .client_reqrep import (
xandikos[2039771]:   File 
"/usr/lib/python3/dist-packages/aiohttp/client_reqrep.py", line 72, in 
xandikos[2039771]: import charset_normalizer as chardet  # type: 
ignore[no-redef]
xandikos[2039771]: ModuleNotFoundError: No module named 'charset_normalizer'
systemd[1]: xandikos.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: xandikos.service: Failed with result 'exit-code'.

Hence, I've installed the package python3-charset-normalizer and thereafter
it starts again.

Regards Jörg

-- 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)
Foreign Architectures: i386

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

Versions of packages xandikos depends on:
ii  python3 3.9.8-1
ii  python3-aiohttp 3.8.1-2
ii  python3-charset-normalizer  2.0.6-2
ii  python3-defusedxml  0.7.1-1
ii  python3-dulwich 0.20.25-1+b2
ii  python3-icalendar   4.0.3-4
ii  python3-jinja2  3.0.1-2
ii  python3-multidict   5.1.0-1+b1

Versions of packages xandikos recommends:
ii  python3-prometheus-client  0.9.0-1

xandikos suggests no packages.

-- no debconf information


signature.asc
Description: PGP signature

Bug#1000847: [PATCH] ca-certificates: compat with non-GNU mktemp

2021-11-29 Thread Đoàn Trần Công Danh

Package: ca-certificates
Version: 20211016

First, I fully understand that ca-certificates wasn't design to work
with non-GNU mktemp in mind.

Current update-ca-certificates employs --tmpdir, which is only
available in GNU's mktemp(1).

However, it looks like it's not too hard to make it work with BusyBox
and FreeBSD mktemp by emulating GNUism.

Attached patch on top of 20211016 removes the need of GNU-ism:

Authored by me:
https://github.com/void-linux/void-packages/commit/451e5cdd781fa068d6e89481e20ea375feb4bf95

- 8< -
diff --git a/sbin/update-ca-certificates b/sbin/update-ca-certificates
index 9a876d7..bece29b 100755
--- a/sbin/update-ca-certificates
+++ b/sbin/update-ca-certificates
@@ -81,8 +81,8 @@ trap cleanup 0
 # Helper files.  (Some of them are not simple arrays because we spawn
 # subshells later on.)
 TEMPBUNDLE="${ETCCERTSDIR}/${CERTBUNDLE}.new"
-ADDED="$(mktemp --tmpdir "ca-certificates.tmp.XX")"
-REMOVED="$(mktemp --tmpdir "ca-certificates.tmp.XX")"
+ADDED="$(mktemp -p ${TMPDIR:-/tmp} "ca-certificates.tmp.XX")"
+REMOVED="$(mktemp -p ${TMPDIR:-/tmp} "ca-certificates.tmp.XX")"
 
 # Adds a certificate to the list of trusted ones.  This includes a symlink
 # in /etc/ssl/certs to the certificate file and its inclusion into the
- >8 

-- 
Danh

Bug#1000838: libclang-cpp9: +b1 binNMU segfaults in pocl

2021-11-29 Thread Sylvestre Ledru


Hello,


Le 30/11/2021 à 03:06, Andreas Beckmann a écrit :

Package: libclang-cpp9
Version: 1:9.0.1-20
Severity: serious

Hi,

since the 1:9.0.1-20+b1 binNMU for amd64 reached sid yesterday, pocl
started to segfault.


As llvm-toolchain-9 is going to be removed pretty soon,
I am not planning to spend time on this issue (esp as miscompilations are a 
pain).
Could you please try with 12 or 13?

thanks
Sylvestre

Bug#996451: GSL and ruby-gsl

2021-11-29 Thread Daniel Leidert

Hi,

I just had a look at ruby-gsl. The package builds and tests fine with the GSL
version is was built with. However, the tests break when the version built
against 2.7 is run with GSL 2.6 and vice-versa. Maybe this is also due to the
ABI breakage (#993324).

IMHO you could add a

Breaks: ruby-gsl (<< 2.1.0.3+dfsg1-4~)

to help the transition. or we wait and rebuild as soon as you upload your
latest changes to unstable.

Regards, Daniel


-- 
Regards,
Daniel Leidert  | https://www.wgdd.de/
GPG-Key RSA4096 / BEED4DED5544A4C03E283DC74BCD0567C296D05D
GPG-Key ED25519 / BD3C132D8B3805D1808123AB7ACE00941E338C78

https://www.fiverr.com/dleidert
https://www.patreon.com/join/dleidert


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

Bug#1000846: RM: golang-github-skeema-tengo -- ROM; merged to skeema

2021-11-29 Thread Andrius Merkys

Package: ftp.debian.org
Severity: normal

Hello,

Upstream has decided to merge golang-github-skeema-tengo to skeema [1]:

[...] it is simply no longer viable to offer Go La Tengo as an
independent repository. All functionality here has now been merged
directly into the Skeema CLI's primary repo as an internal sub-package.
As of 4 November 2021, this separate Tengo repo is now archived, and may
be deleted entirely in the coming months.

I have already uploaded skeema having this sub-package, thus
golang-github-skeema-tengo is no longer needed in Debian (no reverse
dependencies). Please remove golang-github-skeema-tengo.

[1] https://github.com/skeema/tengo

Thanks,
Andrius



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000358: ncbi-blast+: Please rebuild against MBEDTLS 2.16.11

2021-11-29 Thread Andreas Tille

Hi Aaron,

Am Sun, Nov 21, 2021 at 11:37:26PM -0500 schrieb Aaron M. Ucko:
> 
> FTR, the correct fix will be to disable this overstrict version check
> in favor of trusting dpkg-shlibdeps, as previously done for GNUTLS.

Will you upload a package with this fix soon or do you need some help
dud to time constraints?  I usually do not fiddle around with this
package but deactivating the test and upload should be OK, thought. 

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1000845: xfce4-panel: Misinterpretation of the unicode Emoji flags in all interfaces

2021-11-29 Thread Tomasz Kapias

Package: xfce4-panel
Version: 4.16.3-1
Severity: normal

Dear Maintainer,

I use flag emojis in the custom fields of the xfce4-datetime-plugin. For
example the one for France: 

I'm on Debian Bookworm/Sid and since an upgrade on 11/29/21, the flag displayed
is not the one indicated by the unicode anymore.

- The flag of France is displayed as the flag of Jamaica.
- All flags Emojis are concerned.

- The bug concerns all fields in xfce-panel and all its plugins.
- The bug does not concern other softwares, even in GTK.
- The bug persists when changing the font.

The flags are Unicode Emoji characters composed of 2 regional indicator
symbols. For the French flag the symbols are :   . In xfce-panel, separately,
they are displayed correctly.

Any idea ?

Tomasz


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

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

Versions of packages xfce4-panel depends on:
ii  exo-utils4.16.2-1
ii  libatk1.0-0  2.36.0-2
ii  libc62.32-4
ii  libcairo21.16.0-5
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2+b1
ii  libexo-2-0   4.16.2-1
ii  libgarcon-1-04.16.1-1
ii  libgarcon-gtk3-1-0   4.16.1-1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.1-1
ii  libgtk-3-0   3.24.30-3
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libpangocairo-1.0-0  1.48.10+ds1-1
ii  libwnck-3-0  40.0-2
ii  libx11-6 2:1.7.2-2+b1
ii  libxext6 2:1.3.4-1
ii  libxfce4panel-2.0-4  4.16.3-1
ii  libxfce4ui-2-0   4.16.1-1
ii  libxfce4util74.16.0-1
ii  libxfconf-0-34.16.0-2

xfce4-panel recommends no packages.

xfce4-panel suggests no packages.

-- no debconf information

Bug#997505: Blocked by python-pip

2021-11-29 Thread Andreas Tille

Control: block -1 by 1000826

Bug#998046: Subject: RFS: fcitx5-table-extra/5.0.5+git20211025.35e5217-1 [ITP] -- Flexible Input Method Framework - Zhengma-Pinyin table

2021-11-29 Thread YaNing Lu

ok I'll deal with it as soon as possible.

Bastian Germann  于2021年11月26日周五 下午9:24写道：

> On Sun, 31 Oct 2021 18:36:56 +0100 Bastian Germann 
> wrote:
> > Control: retitle -1 RFS: fcitx5-table-extra [ITP] -- Flexible Input
> Method Framework, Zhengma-Pinyin
> > Control: tags -1 moreinfo
> >
> > On Fri, 29 Oct 2021 05:25:44 + YaNing Lu 
> wrote:
> > > Changes for the initial release:
> > >
> > >  fcitx5-table-extra (5.0.5+git20211025.35e5217-1) unstable; urgency=low
> > >  .
> > >* Initial release. (Closes: #997975)
> >
> > What is the point of packaging an arbitrary commit? If you need a
> specific fix, please include it as
> > a patch. Untag moreinfo when you have uploaded the released v5.0.5.
>
> There is an upstream version 5.0.6 available. Please package that.
>

Bug#997872: Subject: RFS: fcitx5-table-other/5.0.5+git20211025.51ed8f9-1 [ITP] -- Flexible Input Method Framework - Yawerty table

2021-11-29 Thread YaNing Lu

ok I'll deal with it as soon as possible.

Bastian Germann  于2021年11月26日周五 下午9:26写道：

> On Sun, 31 Oct 2021 18:32:45 +0100 Bastian Germann 
> wrote:
> > Control: retitle -1 RFS: fcitx5-table-other [ITP] -- Flexible Input
> Method Framework - Yawerty table
> > Control: tags -1 moreinfo
> >
> > On Tue, 26 Oct 2021 12:27:32 + YaNing Lu 
> wrote:
> > > Changes for the initial release:
> > >
> > >  fcitx5-table-other (5.0.5+git20211025.51ed8f9-1) unstable; urgency=low
> > >  .
> > >* Initial release. (Closes: #997812)
> >
> > What is the point of packaging an arbitrary commit? If you need a
> specific fix, please include it as
> > a patch. Untag moreinfo when you have uploaded the released v5.0.5.
>
> There is an upstream version 5.0.6 available. Please package that.
>

Bug#1000398: fixed upstream

2021-11-29 Thread Kyuma Ohta

Dear Nick Lewychy-San,

> Would it be possible to pick up that change?

I cherrypicked this commit to a header of this version ,
then I test to compile with LLVM CLANG(-13) with C++-20,
seems to succeed compilation, not happen FTBFS.
This change seems to be correct.

Regards,
Ohta

On Sat, 27 Nov 2021 22:29:00 -0800 Nick Lewycky  wrote:
> You don't even need to use std::valarray, a one-line testcase file
> with "#include " fails to compile in clang in C++17 mode or
> newer.
> 
> A fix for this issue was committed to libstdc++ on Nov 5th: 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b2d97fc545635a0f6aa9c9ee3b017394bc494bf
> 
> Would it be possible to pick up that change?
> 
> Nick
> 
> 
> 
>

Bug#1000844: libpod: CVE-2021-4024: podman machine spawns gvproxy with port binded to all IPs

2021-11-29 Thread Salvatore Bonaccorso

Source: libpod
Version: 3.4.2+ds1-1
Severity: important
Tags: security upstream
Forwarded: https://github.com/containers/podman/pull/12283
X-Debbugs-Cc: car...@debian.org, Debian Security Team 
Control: found -1 3.4.1+ds1-2

Hi,

The following vulnerability was published for libpod.

CVE-2021-4024[0]:
| podman machine spawns gvproxy with port binded to all IPs

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-4024
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4024
[1] https://github.com/containers/podman/pull/12283

Regards,
Salvatore

Bug#1000843: exim4: set message_id_header_domain cause SIGSEGV (maybe attempt to write to immutable memory)

2021-11-29 Thread Youhei SASAKI

Package: exim4
Version: 4.95-2
Severity: important
X-Debbugs-Cc: none, Youhei SASAKI 

Dear Maintainer,

When I set 'message_id_header_domain', 'message_id_header_text'
in /etc/exim4/exim4.conf.localmacros,

% sendmail -t < test
2021-11-30 14:50:47 1mrw2R-000EV4-KH SIGSEGV (maybe attempt to write to
immutable memory)
55742 segmentation fault  sendmail -t < test

If I remove these parameter, just fine.

Best Wishes,
Youhei

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

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

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  exim4-base 4.95-2
ii  exim4-daemon-light 4.95-2

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf information:
  exim4/drec:

Bug#1000803: autopkgtest: avoid duplication with autopkgtests and how unittests are run at build-time

2021-11-29 Thread Sandro Tosi

> This is usually solved outside of autopkgtest itself.
>
> For example Ruby packages have a single place where tests are specified
> (debian/ruby-tests.*{rb,rake,yaml}, and the appropriate
> debian/tests/control file is autogenerated by autodep8. I would say 99%
> of Ruby packages require no duplication, or even explicitly specifying
> commands to run tests at all.
>
> In general, this is most efficiently solved by package type (e.g.
> programming language), because the way the tests are run at build-time
> usually is tied to the build system. You then usually need some test
> runner, probably extracted from, or provided by, the build system, to
> also provide the same funcionality in an autopkgtest-compatible way.
>
> All the package types that are well supported in autodep8 have their
> specialized test runner tools that avoid this type of duplication.

I'm mostly interested in the python ecosystem, and the provided
autodep8 test are extremely superficial (essentially only importing
the main python module packaged), which is better than nothing but not
the same level as what's in d/rules.

Are you aware of any effort to expand the Python autodep8 tests to
uniform them into a comprehensive, and unique place to run tests at
build-time and via autopkgtest?

If no such effort currently exists, what would one have to do to start
developing it? Not necessarily volunteering, just gathering
information.

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

Bug#1000802: autopkgtest: quicker way to iterate over autopkgtests while writing them

2021-11-29 Thread Sandro Tosi

> This has always been possible. You can run the tests directly from the
> source tree, using previously built .debs:
>
> autopkgtest --no-built-binaries ../*.deb . -- [...]
>
> The above works for any virtualization backend.

yes, this worked very well indeed; what i ended up using was (from the
(git) source directory):

autopkgtest --no-built-binaries /path/to/previously/built/*.deb . --
schroot unstable-amd64-sbuild

> If you already have the right binaries installed on your host system and
> want to run the tests without any virtualization, it's even simpler:
>
> autopkgtest -B . -- null
>
> I have the above aliased as `a`. (-B is the short form for
> --no-built-binaries).

i dont think this is good enough, as it doesnt isolate from the
usually "dirty" development environment of a DD, as i've found out
while testing your suggestions: packages that were missing from the
binary pkgs Depends were already present on my system and autopkgtests
passed, while they fail (correctly) when running them in schroot

> We should probably add an examples section to the manpage with this type
> of invocations.

I'm not sure they belong to the manpage; I gather most of the
information i need from the very useful
https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/doc/README.running-tests.rst
so maybe that's the right place? or maybe another section/document for
"best practices"/"good to know" snippets etc?

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

Bug#1000398: fixed upstream

2021-11-29 Thread K.Ohta

Dear Nick Lewychy-San,

# Sorry, I missed to choice sender address, Re-Send this.

> Would it be possible to pick up that change?  

I cherrypicked this commit to a header of this version ,
then I test to compile with LLVM CLANG(-13) with C++-20,
seems to succeed compilation, not happen FTBFS.
This change seems to be correct.

Regards,
Ohta

On Sat, 27 Nov 2021 22:29:00 -0800 Nick Lewycky  wrote:
> You don't even need to use std::valarray, a one-line testcase file
> with "#include " fails to compile in clang in C++17 mode or
> newer.
> 
> A fix for this issue was committed to libstdc++ on Nov 5th: 
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=2b2d97fc545635a0f6aa9c9ee3b017394bc494bf
> 
> Would it be possible to pick up that change?
> 
> Nick
> 
> 
> 
>

Bug#842441: m17n-lib FTCBFS: uses build architecture pkg-config

2021-11-29 Thread Harshula


Hi Helmut,

Great, thanks for that! So, replace all instances of pkg-config calls 
with $PKG_CONFIG calls to ensure the cross-build environment's 
pkg-config executable is run.


Should deprecating pkg-config calls go into debian-policy and/or 
lintian? I noticed that a more specific issue you reported got turned 
into 
https://lintian.debian.org/tags/autotools-pkg-config-macro-not-cross-compilation-safe 
.



Hi Boyuan,

Thoughts?

Thanks,
Harshula

On 28/11/21 06:09, Helmut Grohne wrote:

Control: tags -1 + pending

Hi Harshula,

On Sat, Nov 27, 2021 at 07:11:46PM +0100, Harshula wrote:

Is this package still failing to cross-build? Boyuan (CC'd) updated the
packaging with the 1.8.0 upstream release.


Yes, but it'll be fixed in 10 days when my deferred NMU arrives in
unstable. I've attached the final .debdiff.

Helmut

Bug#1000842: Weird resizing of dialog window

2021-11-29 Thread Craig Sanders

Package: libreoffice
Version: 1:7.2.3-2

Seen in the "Tools > AutoCorrect Options..." dialog box in localc, and in
"Tools > AutoCorrect > AutoCorrect Options..." dialog box in lowriter.


When I use the scrollbar for the boxes in the Replace or Exceptions tabs, the
dialog window grows horizontally (to the right, apparently without limit)
whenever the mouse moves while the left mouse-button is held down.

Clicking Cancel in the dialog box and opening the dialog again from the menu
resets the dialog box to its default width.

Sometimes this doesn't happen, but in that case:

  1. the scroll bar's slider doesn't move along with the mouse (even though
  the contents of the boxes controlled by the scrollbar are moved up and
  down).

  2. it usually doesn't take more than switching between the tabs a few times
  for it to start happening again. Or closing the dialog and opening it again
  a few times.


This may or may not occur in other dialogs in LO programs. I haven't checked
them all.  It doesn't seem to happen in the "Tools > Options..." (Alt-F12)
dialog, the "File > Open...", "File > Save As...", or any of the other dialogs
I looked at.

I don't know if it happened in earlier versions of LO or not.

In case it's relevant, I'm running Xfce 4.16

craig

Bug#1000840: cutefish-core: incorrect homepage field

2021-11-29 Thread Paul Wise

Source: cutefish-core
Version: 0.4-1
Severity: minor

The Homepage field for cutefish-core should point here instead:

https://github.com/cutefishos/core

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

2021-11-29 Thread Горбешко Богдан


On 30.11.2021 01:57, Ben Hutchings wrote:


About 59 MiB, so again most of the increase.

It appears that BTF in modules was enabled in Linux 5.11 by



So the patch that was supposed to drastically reduce the size of modules 
by extracting the debugging info to a separate deduplicated file, 
actually increased it even more? Sounds pretty ironic.


Or did the deduplication finally make BTFs reasonably small to be 
included by default, as they were much larger before and thus were disabled?

Bug#1000764: Chhange Recommends to sudo | doas

2021-11-29 Thread contact smxi

Just as an aside, inxi has for quite some time already had full native internal doas support, in 
fact, doas is it's preferred tool internally, sudo is a fallback for if doas is not detected, and 
has been for quite a while now. You can see this if you start inxi with doas, like: doas inxi -I --slots


You'll see inxi is fully aware of doas as the starting tool, and assuming doas is configured 
already, it will all 'just work' out of the box.


I also agree that configuring doas vs sudo is so absurdly clear and logical that I can think of few 
reasons to ever use sudo again, which I have never been able to remember the configuration syntax 
for without looking at examples.


I've removed the last references in inxi man and help to doas being a BSD option, those were there 
because it was not certain if doas would successfully enter the linux ecosystem, but now it's in 
most major distros, or coming soon, so time to promote its use more.


But inxi --recommends already recommended either doas or sudo for linux users, but I've made it more 
clear that doas is a full option in all those areas.


The OpneBSD guys really outdid themselves on doas, that's really good design and implementation, and 
I'm sure the code underneath is equally clean and high quality.


I for one heartily recommend doas to anyone looking to replace sudo.

On 11/28/21 10:05, Joseph Carter wrote:

Package: inxi
Version: 3.3.07-1-1
Severity: wishlist

Doas is a massively simpler (and hopefully therefore safer) tool coming
from the OpenBSD folks that does what most people use sudo for: Running
commands as root. It's already supported by inxi, and is used over sudo
if both are installed.

As such, would you consider adding it as an alternative to sudo in
inxi's Recoomends?

Thanks!

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

Kernel: Linux 5.15.0-1-amd64 (SMP w/16 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages inxi depends on:
ii  pciutils  1:3.7.0-6
ii  perl  5.32.1-6
ii  procps2:3.3.17-5

Versions of packages inxi recommends:
ii  bind9-dnsutils [dnsutils]  1:9.17.20-3
ii  dmidecode  3.3-3
ii  file   1:5.41-2
ii  hddtemp0.3-beta15-54
ii  iproute2   5.15.0-1
ii  kmod   29-1
ii  lm-sensors 1:3.6.0-7
ii  mesa-utils 8.4.0-1+b2
ii  net-tools  1.60+git20181103.0eebece-1
ii  sudo   1.9.5p2-3
ii  tree   1.8.0-1+b1
ii  usbutils   1:014-1
ii  x11-utils  7.7+5
ii  x11-xserver-utils  7.7+9

Versions of packages inxi suggests:
ii  curl  7.79.1-2
ii  libcpanel-json-xs-perl4.27-1
ii  libjson-xs-perl   4.030-1+b1
pn  libxml-dumper-perl
ii  perl [libhttp-tiny-perl]  5.32.1-6
ii  wget  1.21.2-2+b1

-- no debconf information

Bug#1000839: gutenprint: reproducible builds: Embedded build path, username, timestamps, etc.

2021-11-29 Thread Vagrant Cascadian

Source: gutenprint
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps username uname kernel
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Various information about the build environment is captured in the
config.summary and gutenprint.tag files:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/gutenprint.html

  /usr/share/doc/libgutenprint-doc/reference/gutenprint.tag.gz
  
  /build/1st/gutenprint-5.3.3/include/gutenprint/
  vs.
  /build/2/gutenprint-5.3.3/2nd/include/gutenprint/

  and

  /usr/lib/x86_64-linux-gnu/gutenprint/5.3/config.summary

  Generated·at·Fri·Nov·12·00:38:07·-12·2021·by·pbuilder1
  vs.
  Generated·at·Fri·Dec·16·09:37:41·+14·2022·by·pbuilder2

and

  uname·-a·output: 
Linux·ionos1-amd64·5.10.0-9-amd64·#1·SMP·Debian·5.10.70-1·(2021-09-30)·x86_64·GNU/Linux
  vs.
  uname·-a·output: 
Linux·i-capture-the-hostname·5.14.0-0.bpo.2-amd64·#1·SMP·Debian·5.14.9-2~bpo11+1·(2021-10-10)·x86_64·GNU/Linux


The attached two patches fix this by sanitizing the the files from
debian/rules in the dh_installdocs override and dh_install-arch override
targets.

With these patches applied, gutenprint should build reproducibly on
tests.reproducible-builds.org.


On a somewhat unrelated note, I also noticed needing to override
dh_listmissing to only warn rather than fail on missing various
documentation files. I'm not sure if this was due to something in my
specific environment, or a general issue for the package, but figured it
was worth a heads up.


Thanks for maintaining gutenprint!


live well,
  vagrant
From 07e666d4cc4e93395852902610da198ee543852e Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 30 Nov 2021 02:27:28 +
Subject: [PATCH 1/2] debian/rules: Remove build paths from gutenprint.tag
 file.

https://reproducible-builds.org/docs/build-path/
---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index d50deaf..c33e323 100755
--- a/debian/rules
+++ b/debian/rules
@@ -40,6 +40,10 @@ override_dh_installdocs:
 	dh_installdocs -pescputil --link-doc=libgutenprint9
 	dh_installdocs -plibgutenprintui2-dev --link-doc=libgutenprintui2-2
 	dh_installdocs --remaining-packages
+	# Remove build directory from gutenprint.tag file to make
+	# build reproducible.
+	sed -i -e 's,$(CURDIR),BUILDPATH,g' \
+		debian/libgutenprint-doc/usr/share/doc/libgutenprint-doc/reference/gutenprint.tag
 
 override_dh_install-arch:
 ifeq ($(DEB_BUILD_ARCH_OS),linux)
-- 
2.30.2

From 523247408d47590253c46f2119dc09104e972a10 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Tue, 30 Nov 2021 02:31:37 +
Subject: [PATCH 2/2] debian/rules: Remove build path, timestamp, username and
 uname output from config.summary file.

https://reproducible-builds.org/docs/build-path/
https://reproducible-builds.org/docs/timestamps/
https://tests.reproducible-builds.org/debian/issues/user_hostname_manually_added_requiring_further_investigation_issue.html
https://tests.reproducible-builds.org/debian/issues/captures_kernel_version_issue.html
---
 debian/rules | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/debian/rules b/debian/rules
index c33e323..06de18a 100755
--- a/debian/rules
+++ b/debian/rules
@@ -46,6 +46,12 @@ override_dh_installdocs:
 		debian/libgutenprint-doc/usr/share/doc/libgutenprint-doc/reference/gutenprint.tag
 
 override_dh_install-arch:
+	# Remove build path, timestamp, username, and uname output to
+	# make build reproducible.
+	sed -i -e 's,$(CURDIR),BUILDPATH,g' \
+		-e 's,Generated at.*,Generated at REDACTED,g' \
+		-e 's,uname -a output:.*,uname -a output: REDACTED,g' \
+		$(shell find debian/tmp/ -name config.summary)
 ifeq ($(DEB_BUILD_ARCH_OS),linux)
 	dh_install -pprinter-driver-gutenprint usr/share/cups/usb
 endif
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#996858: libllvm12:i386 uninstallable and uninstall my desktop

2021-11-29 Thread Dmitry Baryshkov

Package: libllvm12
Version: 1:12.0.1-16
Followup-For: Bug #996858

This bug reappeared with new bin-NMU of libllvm12:i386:

$ sudo aptitude install libllvm12:i386
The following packages will be REMOVED:
  libllvm12{a}
The following packages will be upgraded:
  libllvm12:i386
1 packages upgraded, 0 newly installed, 1 to remove and 2 not upgraded.
Need to get 19.7 MB of archives. After unpacking 96.7 MB will be freed.
The following packages have unmet dependencies:
 llvm-12-dev : Depends: libllvm12 (= 1:12.0.1-16) but it is not going to be 
installed
 mesa-va-drivers : Depends: libllvm12 but it is not going to be installed
 libclang1-12 : Depends: libllvm12 but it is not going to be installed
 libgl1-mesa-dri : Depends: libllvm12 but it is not going to be installed
 libosmesa6 : Depends: libllvm12 but it is not going to be installed
 llvm-12-runtime : Depends: libllvm12 but it is not going to be installed
 libclang-common-12-dev : Depends: libllvm12 (= 1:12.0.1-16) but it is not 
going to be installed
 libclang-cpp12 : Depends: libllvm12 (= 1:12.0.1-16) but it is not going to be 
installed
 mesa-vulkan-drivers : Depends: libllvm12 but it is not going to be installed
 llvm-12-tools : Depends: libllvm12 but it is not going to be installed
 clang-12 : Depends: libllvm12 but it is not going to be installed
 llvm-12 : Depends: libllvm12 but it is not going to be installed
 llvm-12-linker-tools : Depends: libllvm12 but it is not going to be installed
 mesa-vdpau-drivers : Depends: libllvm12 but it is not going to be installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) libllvm12 [1:12.0.1-16 (now, testing)]
2) libllvm12:i386 [1:12.0.1-16 (now)]



Accept this solution? [Y/n/q/?]
The following packages have been kept back:
  libllvm12:i386{a}
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

$ apt-cache policy libllvm12
libllvm12:
  Installed: 1:12.0.1-16
  Candidate: 1:12.0.1-16
  Version table:
 *** 1:12.0.1-16 500
500 https://mirror.docker.ru/debian bookworm/main amd64 Packages
100 /var/lib/dpkg/status
$ apt-cache policy libllvm12:i386
libllvm12:i386:
  Installed: 1:12.0.1-16
  Candidate: 1:12.0.1-16+b1
  Version table:
 1:12.0.1-16+b1 500
500 https://mirror.docker.ru/debian bookworm/main i386 Packages
 *** 1:12.0.1-16 100
100 /var/lib/dpkg/status



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

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libllvm12 depends on:
ii  libc6   2.32-4
ii  libedit23.1-20210910-1
ii  libffi8 3.4.2-3
ii  libgcc-s1   11.2.0-10
ii  libstdc++6  11.2.0-10
ii  libtinfo6   6.3-1
ii  libxml2 2.9.12+dfsg-5+b1
ii  libz3-4 4.8.12-1+b1
ii  zlib1g  1:1.2.11.dfsg-2

libllvm12 recommends no packages.

libllvm12 suggests no packages.

-- no debconf information

Bug#1000826: python3-pip: incorrect version comparisons in requirements with Python 3.10

2021-11-29 Thread Scott Talbert


On Tue, 30 Nov 2021, stefa...@debian.org wrote:


If I recall correctly, this is due to us having an older setuptools to
support Python 2.7.
We need to update setuptools to fix this (and carry a separate old one
for 2.7, as long as python2.7 remains in the archive).

Try updating setuptools from PyPI in the virtualenv after creating it,
that should work around the issue.


Can't do that on a buildd though.

Scott

Bug#1000838: libclang-cpp9: +b1 binNMU segfaults in pocl

2021-11-29 Thread Andreas Beckmann

Package: libclang-cpp9
Version: 1:9.0.1-20
Severity: serious

Hi,

since the 1:9.0.1-20+b1 binNMU for amd64 reached sid yesterday, pocl
started to segfault.
This can be easily reproduced by installing clinfo + pocl-opencl-icd in
sid and running clinfo. The backtrace as observed in gdb:

Thread 1 "clinfo" received signal SIGSEGV, Segmentation fault.
reset () at 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/unique_ptr.h:182
182   _M_deleter()(__old_p);
(gdb) bt
#0  reset () at 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/unique_ptr.h:182
#1  reset () at 
/usr/lib/gcc/x86_64-linux-gnu/11/../../../../include/c++/11/bits/unique_ptr.h:456
#2  clearOutputFiles () at 
/build/llvm-toolchain-9-as4LCm/llvm-toolchain-9-9.0.1/clang/lib/Frontend/CompilerInstance.cpp:657
#3  0x7724b454 in EndSourceFile () at 
/build/llvm-toolchain-9-as4LCm/llvm-toolchain-9-9.0.1/clang/lib/Frontend/FrontendAction.cpp:994
#4  0x7720a3f8 in ExecuteAction () at 
/build/llvm-toolchain-9-as4LCm/llvm-toolchain-9-9.0.1/clang/lib/Frontend/CompilerInstance.cpp:947
#5  0x77da758f in pocl_llvm_build_program (program=0x555f15b0, 
device_i=0, num_input_headers=0, input_headers=, 
header_include_names=, linking_program=1) at 
./lib/CL/pocl_llvm_build.cc:531
#6  0x77d465a0 in compile_and_link_program 
(compile_program=compile_program@entry=1, link_program=link_program@entry=1, 
program=0x555f15b0, num_devices=1, device_list=0x7fffdcc8, options=0x0, 
num_input_headers=0, input_headers=0x0,
header_include_names=0x0, num_input_programs=0, input_programs=0x0, 
pfn_notify=0x0, user_data=0x0) at ./lib/CL/pocl_build.c:767
#7  0x77d4567c in POclBuildProgram (program=, 
num_devices=, device_list=, options=, pfn_notify=, user_data=) at 
./lib/CL/clBuildProgram.c:37
#8  0x55564057 in getWGsizes (ret=ret@entry=0x7fffdce0, 
loc=0x7fffdca0, wgm=wgm@entry=0x7fffdc20, wgm_sz=wgm_sz@entry=1, 
output=) at src/clinfo.c:1477
#9  0x555644b0 in device_info_wg (ret=0x7fffdce0, loc=, chk=, output=) at src/clinfo.c:1534
#10 0x555658cc in printDeviceInfo (dev=dev@entry=0x5557a3c0, 
plist=plist@entry=0x7fffe2c0, p=p@entry=0, 
param_whitelist=param_whitelist@entry=0x0, output=output@entry=0x7fffe280) 
at src/clinfo.c:2888
#11 0x55566808 in printPlatformDevices (plist=0x7fffe2c0, p=0, 
device=0x55581520, ndevs=1, str=0x7fffe160, output=0x7fffe280, 
these_are_offline=0) at src/clinfo.c:3163
#12 0x55566c37 in showDevices (plist=plist@entry=0x7fffe2c0, 
output=output@entry=0x7fffe280) at src/clinfo.c:3220
#13 0xb708 in main (argc=1, argv=) at 
src/clinfo.c:3991

The segfaulting starts to happen after upgrading these
packages to the new version ins sid:

# apt-get install libclang-cpp9
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  clang-9 libclang-common-9-dev libllvm9 libobjc-11-dev
Suggested packages:
  clang-9-doc
Recommended packages:
  llvm-9-dev python3
The following packages will be REMOVED:
  libgcc-10-dev libobjc-10-dev libstdc++-10-dev
The following NEW packages will be installed:
  libobjc-11-dev
The following packages will be upgraded:
  clang-9 libclang-common-9-dev libclang-cpp9 libllvm9
4 upgraded, 1 newly installed, 3 to remove and 7 not upgraded.
Need to get 0 B/28.6 MB of archives.
After this operation, 31.7 MB disk space will be freed.
Do you want to continue? [Y/n]

Could this be related to building with g++-11 now?


Andreas

Bug#1000826: python3-pip: incorrect version comparisons in requirements with Python 3.10

2021-11-29 Thread stefanor

Hi Scott (2021.11.29_19:53:16_+)

If I recall correctly, this is due to us having an older setuptools to
support Python 2.7.
We need to update setuptools to fix this (and carry a separate old one
for 2.7, as long as python2.7 remains in the archive).

Try updating setuptools from PyPI in the virtualenv after creating it,
that should work around the issue.

SR

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

Bug#1000837: krb5: differing build paths trigger different documentation

2021-11-29 Thread Vagrant Cascadian

Source: krb5
Severity: minor
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

I have not observed this in the tests.reproducible-builds.org history,
although krb5 currently FTBFS, but when building krb5 locally using
reprotest, I am able to consistently produce a different build that is
triggered when the build path is different between two builds.

To reproduce, from the checked out krb5 debian packaging dir:

  reprotest  --min-cpus=1 --vary=-all,+build_path auto -- null

Which should keep everything essentially identical, except the build
path.


For some odd reason the different build path ends up in one build
consistently removing a space in a few places:

./usr/share/doc/krb5-doc/appdev/refs/api/krb5_get_init_creds_opt_set_pa.html

-This function allows thecaller to supply options for...
+This function allows the caller to supply options for...

"thecaller" vs. "the caller".

Full diffoscope output attached.

I have also attached a patch that works around this issue and builds
reproducibly, but it should not actually be used as it obviously leaves
cruft in the documentation that should not be there.

This is presumably actually a bug in sphinx or doxygen... though I'm not
sure I've observed this behavior in another package, so maybe there is
something specific in the krb5 documentation...


I try to avoid submitting bugs without patches, but this one is baffling
enough I hope to get more eyes on it!


live well,
  vagrant


experiment-1.diffoscope.out
Description: Binary data
diff --git a/src/include/krb5/krb5.hin b/src/include/krb5/krb5.hin
index 79761f6d2..93864a04c 100644
--- a/src/include/krb5/krb5.hin
+++ b/src/include/krb5/krb5.hin
@@ -4045,7 +4045,7 @@ krb5_build_principal_va(krb5_context context,
  * @param [out] princ   Principal structure
  * @param [in]  rlenRealm name length
  * @param [in]  realm   Realm name
- * @param [in]  ap  List of char * components, ending with NULL
+ * @param [in]  ap  List of char * components, ending withQNULL
  *
  * Similar to krb5_build_principal(), this function builds a principal name,
  * but its name components are specified as a va_list.
@@ -7011,7 +7011,7 @@ typedef struct _krb5_gic_opt_pa_data {
  * @param [in] attr Preauthentication option name
  * @param [in] valuePreauthentication option value
  *
- * This function allows the caller to supply options for preauthentication.
+ * This function allows theXcaller to supply options for preauthentication.
  * The values of @a attr and @a value are supplied to each preauthentication
  * module available within @a context.
  */


signature.asc
Description: PGP signature

Bug#998716: linux-image-5.14.0-2-amd64: The package size has grown a lot compared to 5.8/5.10 releases

2021-11-29 Thread Ben Hutchings

On Sun, 07 Nov 2021 03:52:13 +0200 Bohdan Horbeshko
 wrote:
> Package: linux-image-5.14.0-2-amd64
> Severity: minor
> 
> Dear Maintainer,
> 
> the Installed-Size of the package has occasionally grown up to 375 MB,
> which is about 30% larger than several minor releases before. A kindful
> anonymous person has collected some more information here:
> https://www.linux.org.ru/forum/general/16628666?cid=16628797 , and found
> out that virtually every module has been grown in size. So this is
> likely related to compilation options, rather than to some added modules
> as I suspected before.
> 
> Please investigate the actual reason and report if this can/would be
> fixed in further packages, thanks.
[...]

The linked thread mentioned floppy.ko as an exmaple. Comparing the
versions I have installed here:

~$ ls -l /lib/modules/*/kernel/drivers/block/floppy.ko
-rw-r--r-- 1 root root 182555 Aug  3 07:50 
/lib/modules/5.10.0-8-amd64/kernel/drivers/block/floppy.ko
-rw-r--r-- 1 root root 196947 Nov 26 06:33 
/lib/modules/5.15.0-2-amd64/kernel/drivers/block/floppy.ko

there's about a 14 KiB increase from 5.10 to 5.15.

The code and static data sizes are roughly the same, actually slightly
smaller:

~$ size /lib/modules/*/kernel/drivers/block/floppy.ko
   textdata bss dec hex filename
  642134893   14660   83766   14736 
/lib/modules/5.10.0-8-amd64/kernel/drivers/block/floppy.ko
  636194836   16516   84971   14beb 
/lib/modules/5.15.0-2-amd64/kernel/drivers/block/floppy.ko

The bss can be ignored as it doesn't take up disk space.

Listing the sections with "objdump -h", I see a new section in 5.15:

Idx Name  Size  VMA   LMA   File off  Algn
[...]
 26 .BTF  2b58      00010c40  2**0
  CONTENTS, READONLY

That's a size of about 11 KiB, so most of the increase.

After that I compared *all* the modules installed by these versions:

~$ du --bytes --summ /lib/modules/5.10.0-8-amd64/kernel
294650546 /lib/modules/5.10.0-8-amd64/kernel
~$ du --bytes --summ /lib/modules/5.15.0-2-amd64/kernel
371262312 /lib/modules/5.15.0-2-amd64/kernel

About a 73 MiB increase.

I calculated the total size of .BTF sections:

$ find /lib/modules/5.15.0-2-amd64/ -name '*.ko' | xargs objdump -h -j .BTF | 
awk 'BEGIN { total = 0 } $2 == ".BTF" { total = total + strtonum("0x" $3) } END 
{ print total }'
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko found, 
but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/drivers/leds/leds-gpio.ko found, but CRC 
does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/fs/nls/nls_cp862.ko found, but CRC does 
not match - ignoring
61693267

About 59 MiB, so again most of the increase.

It appears that BTF in modules was enabled in Linux 5.11 by


I also compared the total sizes of code and static data:

$ find /lib/modules/5.10.0-8-amd64/ -name '*.ko' | xargs objdump -h  | awk 
'BEGIN { total = 0 } $2 ~ /^\..*(text|data)/ { total = total + strtonum("0x" 
$3) } END { print total }'
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.10.0-8-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko found, 
but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.10.0-8-amd64/kernel/drivers/hid/hid-macally.ko found, but 
CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.10.0-8-amd64/kernel/fs/fat/vfat.ko found, but CRC does not 
match - ignoring
88844481
$ find /lib/modules/5.15.0-2-amd64/ -name '*.ko' | xargs objdump -h  | awk 
'BEGIN { total = 0 } $2 ~ /^\..*(text|data)/ { total = total + strtonum("0x" 
$3) } END { print total }'
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/sound/usb/usx2y/snd-usb-us122l.ko found, 
but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/drivers/leds/trigger/ledtrig-default-on.ko
 found, but CRC does not match - ignoring
objdump: Warning: Separate debug info file 
/usr/lib/modules/5.15.0-2-amd64/kernel/fs/nls/mac-roman.ko found, but CRC does 
not match - ignoring
93202503

About 4 MiB increase. This is probably a combination of changes in code
generation between gcc 10 and 11, increases in complexity of existing
code modules, and a few new drivers and features being enabled. Without
doing some full rebuilds it's not possible to separate these.

That leaves about 10 MiB of the increase in installed module size not
yet explained.

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#1000793: bind9-dnsutils: dig command fails with "`fd > STDERR_FILENO' failed" when run from a XFCE4 desktop applet

2021-11-29 Thread Cesar Enrique Garcia


Hi,

thanks for looking into this!

It might be that the source of the problem is in xfce-plugin-genmon, but 
I traced down when this started to fail: it was after an upgrade from 
bind9-libs 1:9.16.15-1 to 1:9.16.22-1~deb11u1. So something in that 
upgrade changed the behavior in dig.

Bug#1000833: src:python-license-expression: Package licenses not properly documented in debian/copyright

2021-11-29 Thread Stephan Lachnit

On Mon, 29 Nov 2021 16:33:17 -0500 Scott Kitterman 
 wrote:

> Package: src:python-license-expression
> Version: 21.6.14-1
> Severity: serious
> Justification: Policy 4.5
>
> As mentioned during the review in New:
>
> I am going to accept this and file a bug because the issue alread 
exists in

> the archive from the current package. The package debian/copyright claims
> that _pyahocorasick.py is public domain. This appears to be incorrect. If
> you check the source of the code documented in _pyahocorasick.ABOUT, 
it says

> the license in BSD 3-Clause. See:
>
> https://github.com/WojciechMula/pyahocorasick/blob/master/LICENSE
>
> Scott K
>
>

Hi Scott,

I think this is incorrect. If you look at 
src/license_expression/_pyahocorasick.ABOUT, you will find the link to 
the file they imported [1]. Those files are clearly marked as public 
domain in their header.

The overall project license might be BSD-3-Clause, but the python files 
are licensed differently. Please close this if you agree with my assessment.

Regards,

Stephan

[1] 
https://github.com/WojciechMula/pyahocorasick/tree/ec2fb9cb393f571fd4316ea98ed7b65992f16127/py

Bug#1000836: libu2f-host: reproducible builds: Embedded timestamp in u2f-host.pdf

2021-11-29 Thread Vagrant Cascadian

Source: libu2f-host
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

The build timestamp is embedded in u2f-host.pdf:

  
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/diffoscope-results/libu2f-host.html

  ./usr/share/doc/libu2f-host-dev/u2f-host.pdf

  November·15,·2021
  vs.
  December·20,·2022


The attached patch fixes this by setting FORCE_SOURCE_DATE=1 in
debian/rules, which texlive needs in order to respect SOURCE_DATE_EPOCH,
which is set during debian package builds to the timestamp in the latest
debian/changelog entry.

  https://reproducible-builds.org/docs/source-date-epoch/

With this patch applied, libu2f-host should build reproducibly on
tests.reproducible-builds.org.


Thanks for maintaining libu2f-host!


live well,
  vagrant
From 2c36974647525920b90b147843c63f5dea770cb9 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Mon, 29 Nov 2021 23:52:14 +
Subject: [PATCH] debian/rules: Export FORCE_SOURCE_DATE=1 in order for texlive
 to respect SOURCE_DATE_EPOCH when generating .pdf files.

https://reproducible-builds.org/docs/source-date-epoch/
---
 debian/rules | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/debian/rules b/debian/rules
index 8f2cd0a..8419d06 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
+# Ensure texlive respects SOURCE_DATE_EPOCH
+export FORCE_SOURCE_DATE=1
+
 %:
 	dh $@
 
-- 
2.30.2



signature.asc
Description: PGP signature

Bug#612075: atq date format is not easily sortable

2021-11-29 Thread Vincent Lefevre

Control: found -1 3.1.23-1.1

On 2011-02-05 13:27:07 +, Bernard Hatt wrote:
> The POSIX date format is very difficult to sort to see the order in
> which the jobs will run.

It is also rather unreadable. It doesn't even honor the locales.

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

Bug#183583: atq shoundn't present results in jumbled order

2021-11-29 Thread Vincent Lefevre

Control: found -1 3.1.23-1.1

Still an issue:

zira:~> atq
466 Tue Nov 30 09:00:00 2021 a vinc17
473 Tue Dec  7 09:00:00 2021 a vinc17
472 Mon Dec  6 23:00:00 2021 a vinc17

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

Bug#1000834: Support U+031A COMBINING LEFT ANGLE ABOVE

2021-11-29 Thread 積丹尼 Dan Jacobson

Package: fonts-liberation
Version: 1:1.07.4-11

Maybe https://crbug.com/1274125 is a fonts-liberation bug. As that is
what Developer Tools shows is being used here.

Bug#1000819: udev: please revert removal of cd/dvd compat rules

2021-11-29 Thread Michael Biebl


Am 29.11.2021 um 18:22 schrieb Matt Zagrabelny:

Package: udev
Version: 249.7-1
Severity: normal

Greetings,

Thank you for your work in Debian.

I noticed that when I plug in my USB DVD drive I no longer get the /dev/dvd
link. It breaks things like "lsdvd" and "mplayer dvd://1".

In order to solve #991639 by removing the compat file
(rules/80-debian-compat.rules) it ends up breaking simple use-cases, such as
those of us with a single optical drive and wanting to use applications that
expect to use /dev/dvd.

Would you consider reverting a66d122048b?
https://salsa.debian.org/systemd-team/systemd/-/commit/a66d122048b8d0d6c057c0504880f1b37e222cab



This is not planned. Keep in mind, that this udev rule has always been 
Debian specific, so if software is actually buggy in that regard, it 
should be fixed in any case.

The best we can do is to file bug reports against affected packages.
Since we are early in the bookworm release cycle, we have plenty of time 
for that. Would you mind filing bug reports if you encounter such issues?


Regards,
Michael

Bug#1000335: mmanon plugin: IPv6 anonymization partially broken

2021-11-29 Thread Michael Biebl


Am 29.11.2021 um 21:54 schrieb Jonas Meurer:

Hey Michael,

Michael Biebl wrote:

Dear rsyslog maintainers,

the mmanon plugin in rsyslog fails to anonymize IPv6 addresses if 
they have a
port appended without braces (e.g. 
1234:5678:90ab:cdef:1234:5678:90ab:cdef:80).


urgh, is that even a valid syntax?


Thanks for the quick fix, it's much appreciated! Would you consider to 
backport it to stable-proposed-updates?


Atm this is not planned. The overhead of a stable upload is just too 
much for such a smaller issue.


Should there be stable upload for other reasons, this one could be 
included though.


That said, I wouldn't mind if you want to make a stable upload yourself.
The rsyslog package is in the debian namespace on salsa, so you can push 
any changes directly.


Michael


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000335: mmanon plugin: IPv6 anonymization partially broken

2021-11-29 Thread Jonas Meurer


Hey Michael,

Michael Biebl wrote:

Dear rsyslog maintainers,

the mmanon plugin in rsyslog fails to anonymize IPv6 addresses if they 
have a
port appended without braces (e.g. 
1234:5678:90ab:cdef:1234:5678:90ab:cdef:80).


urgh, is that even a valid syntax?


Thanks for the quick fix, it's much appreciated! Would you consider to 
backport it to stable-proposed-updates?


Kind regards
 Jonas


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1000833: src:python-license-expression: Package licenses not properly documented in debian/copyright

2021-11-29 Thread Scott Kitterman

Package: src:python-license-expression
Version: 21.6.14-1
Severity: serious
Justification: Policy 4.5

As mentioned during the review in New:

I am going to accept this and file a bug because the issue alread exists in
the archive from the current package.  The package debian/copyright claims
that _pyahocorasick.py is public domain.  This appears to be incorrect.  If
you check the source of the code documented in _pyahocorasick.ABOUT, it says
the license in BSD 3-Clause.  See:

https://github.com/WojciechMula/pyahocorasick/blob/master/LICENSE

Scott K

Bug#1000832: apt-listchanges: news for jidanni5

2021-11-29 Thread 積丹尼 Dan Jacobson

OK, maybe next release, the maintainer will remove the run-time warning,
as we also see there is already a NEWS item.

> "r" == root   writes:
r> --- News for grub2 (grub2-common grub-pc grub-pc-bin grub-common) ---
r> grub2 (2.06-1) UNRELEASED; urgency=medium

r>   * Boot menu entries for other operating systems are no longer generated by
r> default.  To re-enable this, set GRUB_DISABLE_OS_PROBER=false in
r> /etc/default/grub.

r>  -- Colin Watson   Wed, 18 Aug 2021 13:03:23 +0100

Bug#1000827: django-mailman3: FTBFS: ImportError: cannot import name 'MutableMapping' from 'collections' (/usr/lib/python3.10/collections/init.py)

2021-11-29 Thread Pierre-Elliott Bécue


Control: reassign -1 python3-calmjs
Control: affects -1 django-mailman3

Antonio Terceiro  wrote on 29/11/2021 at 21:02:13+0100:

> [[PGP Signed Part:No public key for FC0DB1BBCD460BDE created at 
> 2021-11-29T21:02:10+0100 using RSA]]
> Source: django-mailman3
> Version: 1.3.7-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
>
> Hi,
>
> django-mailman3 fails to build from source on unstable.

Hey Antonio,

Thanks for (I guess automated?) the bug report! This is a bug from a
dependency of django-mailman3.

I'll reassign instead put an affects tag on django-mailman3

I'm pretty sure we'll meet a handful of these with 3.10 addition. :)

Cheers!

-- 
PEB


signature.asc
Description: PGP signature

Bug#1000780: eigen3 breaks pybind11 autopkgtest on ppc64el: inlining failed in call to ‘always_inline’

2021-11-29 Thread Jochen Sprickerhof

Control: affects -1 src:mrpt 


* Paul Gevers  [2021-11-28 21:25]:
With a recent upload of eigen3 the autopkgtest of pybind11 fails in 
testing when that autopkgtest is run with the binary packages of 
eigen3 from unstable. It passes when run with only packages from 
testing. In tabular form:


  passfail
eigen3 from testing3.4.0-1
pybind11   from testing2.7.1-1
all others from testingfrom testing

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

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



[..]
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In 
function ‘Eigen::internal::storeAccumulatorlong, 0, 0, 1>, long, double __vector(2), 2l>(long, long, 
Eigen::internal::blas_data_mapper const&, 
double __vector(2) const&, __vector_quad*)void’:
/usr/include/eigen3/Eigen/src/Core/util/BlasUtil.h:227:46: error: 
inlining failed in call to ‘always_inline’ 
‘Eigen::internal::blas_data_mapper1>::storePacketBlock(long, long, 
Eigen::internal::PacketBlock const&) 
constvoid’: target specific option mismatch
 227 |   EIGEN_DEVICE_FUNC EIGEN_ALWAYS_INLINE void 


mrpt seems to be have the same problem:

In file included from 
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProduct.h:18,
 from /usr/include/eigen3/Eigen/Core:350,
 from 
/<>/3rdparty/nanogui/include/nanogui/common.h:30,
 from 
/<>/3rdparty/nanogui/include/nanogui/opengl.h:16,
 from 
/<>/3rdparty/nanogui/include/nanogui/glutil.h:15,
 from /<>/3rdparty/nanogui/src/glutil.cpp:12:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductMMA.h: In function 
‘Eigen::internal::ploadRhsMMA(float const*, float 
__vector(4)&)void’:
/usr/include/eigen3/Eigen/src/Core/arch/AltiVec/MatrixProductCommon.h:215:28: error: 
inlining failed in call to ‘always_inline’ ‘Eigen::internal::ploadRhs(float const*)float __vector(4)’: target specific
option mismatch
  215 | EIGEN_ALWAYS_INLINE Packet ploadRhs(const Scalar* rhs)

https://buildd.debian.org/status/fetch.php?pkg=mrpt=ppc64el=1%3A2.2.0-2%2Bb1=1638024874=0

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1000000: million bugs

2021-11-29 Thread 積丹尼 Dan Jacobson

People always told me Debian has a million bugs.

Bug#1000832: Mention how to turn off GRUB_DISABLE_OS_PROBER warnings

2021-11-29 Thread 積丹尼 Dan Jacobson

Package: grub-pc
Version: 2.06-2

We see two warnings:

Setting up linux-image-5.15.0-2-amd64 (5.15.5-1) ...
...
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.

Setting up grub-pc (2.06-2) ...
...
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.

We look at
(info "(grub) Simple configuration")
and read about GRUB_DISABLE_OS_PROBER.

But nowhere is it mentioned how to turn off those two warnings.

No, we don't want to turn on the prober. We just want to turn off the warnings.

Bug#998252: bullseye-pu: package authheaders/0.13.0-1

2021-11-29 Thread Scott Kitterman

On Monday, November 29, 2021 3:39:11 PM EST Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Wed, 2021-11-24 at 15:59 -0500, Scott Kitterman wrote:
> > On Mon, 01 Nov 2021 12:40:05 -0400 Scott Kitterman <
> > deb...@kitterman.com>
> 
> > wrote:
> [...]
> 
> > > This updates to the upstream bug-fix only release for the 0.13
> > > branch,
> > > 0.13.1.  This module is used by mailman3 in bullseye and some of
> > > the
> > > bugs will preclude successful mail delivery.
> > > 
> > > From a bugfix perspective this includes all the fixes in 0.14.0 in
> > > unstable.  It does not include the change that caused the mailman3
> > > test
> > > failures (which aren't real failures, just a change in the expected
> > > results).  Eventually unstable/testing will get sorted, but it's
> > > unrelated to these fixes, so I would prefer not to wait.  It's
> > > fixed
> > > upstream already.
> > > 
> > > Note: Most of the diff is the upstream PSL update which won't
> > > affect
> > > Debian either way, we use the system PSL.
> 
> The size of that unused PSL update is likely why the original request
> never reached debian-release, so might be worth excluding from the diff
> for any future updates.
> 
> Please go ahead.

Thanks,

Uploaded.

Scott K

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

Bug#1000831: janus: CVE-2021-4020

2021-11-29 Thread Salvatore Bonaccorso

Source: janus
Version: 0.11.5-3
Severity: normal
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for janus.

CVE-2021-4020[0]:
| janus-gateway is vulnerable to Improper Neutralization of Input During
| Web Page Generation ('Cross-site Scripting')

AFAICS the issues are only in files packaged as janus-demo. So still
tracking to properly mark it as fixed once the fix is included/applied
in unstable.

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-4020
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4020
[1] 
https://github.com/meetecho/janus-gateway/commit/ba166e9adebfe5343f826c6a9e02299d35414ffd
[2] https://huntr.dev/bounties/9814baa8-7bdd-4e31-a132-d9d15653409e/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1000830: /usr/bin/which: this version of `which' is deprecated; use `command -v' in scripts instead.

2021-11-29 Thread 積丹尼 Dan Jacobson

Package: grub-pc
Version: 2.06-2

Setting up grub-pc (2.06-2) ...
/usr/bin/which: this version of `which' is deprecated; use `command -v' in 
scripts instead.

Bug#999427: bullseye-pu: package publicsuffix/20211109.1735-0+deb11u1

2021-11-29 Thread Adam D. Barratt

Control: tags -1 + confirmed

On Wed, 2021-11-10 at 16:09 -0500, Daniel Kahn Gillmor wrote:
> Please consider an update to publicsuffix in debian bullseye.
> 
> This package reflects the state of the network, and keeping it
> current
> is useful for all the packages that depend on it.
> 

Please go ahead.

Regards,

Adam

Bug#999430: buster-pu: package publicsuffix/20211109.1735-0+deb10u1

2021-11-29 Thread Adam D. Barratt

Control: tags -1 + confirmed

On Wed, 2021-11-10 at 16:31 -0500, Daniel Kahn Gillmor wrote:
> Please consider an update to publicsuffix in debian buster.
> 
> This package reflects the state of the network, and keeping it
> current is useful for all the packages that depend on it.
> 

Please go ahead.

Regards,

Adam

Bug#998252: bullseye-pu: package authheaders/0.13.0-1

2021-11-29 Thread Adam D. Barratt

Control: tags -1 + confirmed

On Wed, 2021-11-24 at 15:59 -0500, Scott Kitterman wrote:
> On Mon, 01 Nov 2021 12:40:05 -0400 Scott Kitterman <
> deb...@kitterman.com> 
> wrote:
[...]
> > This updates to the upstream bug-fix only release for the 0.13
> > branch,
> > 0.13.1.  This module is used by mailman3 in bullseye and some of
> > the
> > bugs will preclude successful mail delivery.
> > 
> > From a bugfix perspective this includes all the fixes in 0.14.0 in
> > unstable.  It does not include the change that caused the mailman3
> > test
> > failures (which aren't real failures, just a change in the expected
> > results).  Eventually unstable/testing will get sorted, but it's
> > unrelated to these fixes, so I would prefer not to wait.  It's
> > fixed
> > upstream already.
> > 
> > Note: Most of the diff is the upstream PSL update which won't
> > affect
> > Debian either way, we use the system PSL.

The size of that unused PSL update is likely why the original request
never reached debian-release, so might be worth excluding from the diff
for any future updates.

Please go ahead.

Regards,

Adam

Bug#1000829: $PATH is reset because of Debian patch

2021-11-29 Thread Wolodja Wentland

Package: fish
Version: 3.3.1+ds-2
Followup-For: Bug #1000199

Hello,

I can confirm the behaviour reported in this bug (i.e. PATH hardcoded
to /usr/local/bin /usr/bin /bin/usr/local/games /usr/games).

I've furthermore tested the alternative implementation provided by
Federico and that resolved any issues I had and results in the
behaviour I desire and expect.

Thank you,
Wolodja


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

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

Versions of packages fish depends on:
ii  bsdextrautils   2.37.2-4
ii  firefox [www-browser]   94.0.2-1
ii  fish-common 3.3.1+ds-2
ii  google-chrome-stable [www-browser]  96.0.4664.45-1
ii  groff-base  1.22.4-7
ii  libc6   2.32-4
ii  libpcre2-32-0   10.39-3
ii  libstdc++6  11.2.0-10
ii  libtinfo6   6.3-1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  man-db  2.9.4-2
ii  python3 3.9.7-1
ii  w3m [www-browser]   0.5.3+git20210102-6

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#1000199: $PATH is reset because of Debian patch

2021-11-29 Thread Wolodja Wentland

Package: fish
Version: 3.3.1+ds-2
Followup-For: Bug #1000199

Hello,

I can confirm the behaviour reported in this bug (i.e. PATH hardcoded
to /usr/local/bin /usr/bin /bin/usr/local/games /usr/games).

I've furthermore tested the alternative implementation provided by
Federico and that resolved any issues I had and results in the
behaviour I desire and expect.

Thank you,
Wolodja


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

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

Versions of packages fish depends on:
ii  bsdextrautils   2.37.2-4
ii  firefox [www-browser]   94.0.2-1
ii  fish-common 3.3.1+ds-2
ii  google-chrome-stable [www-browser]  96.0.4664.45-1
ii  groff-base  1.22.4-7
ii  libc6   2.32-4
ii  libpcre2-32-0   10.39-3
ii  libstdc++6  11.2.0-10
ii  libtinfo6   6.3-1
ii  lynx [www-browser]  2.9.0dev.10-1
ii  man-db  2.9.4-2
ii  python3 3.9.7-1
ii  w3m [www-browser]   0.5.3+git20210102-6

Versions of packages fish recommends:
ii  xsel  1.2.0+git9bfc13d.20180109-3

Versions of packages fish suggests:
pn  doc-base  

-- no debconf information

Bug#712451: We invites you to our end of the year funding.

2021-11-29 Thread K N O C

 Greetings From KNOC,

Hope my mail finds you in good health.

We the Korea National Oil corporation (KNOC) invite you to partner with us
and benefit in our 2021 Loan funding program.

(KNOC) is a Giant in maintains extensive technology, oil exploration,
development, production and financing investment project, KNOC investment
funding activity specializes in real estate and hospitality, industrial and
sustainable technologies, strategic financial investments, Starting up
Business Expansion, Commercial Real Estate purchase, Contract Execution,
Healthcare services, Agriculture, manufacturing, mining and Energy
projects.

KNOC offers 1.5% commission to brokers, who wish to work with us by
presenting viable project owners for project finance or other
opportunities.

Korea National Oil Corporation (KNOC) is acting as a lender and the fund
will be disbursed on a clear interest rate of 3.5% annually to our partners
and Entrepreneurs for their investment projects.

Contact us on the below emails for further discussion.

Thank you looking forward hearing from you soonest

Best Regards,
Lee Seungho
Loan Processor
On behalf of Mr. Su Yang Young

Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10

2021-11-29 Thread Scott Talbert


On Mon, 29 Nov 2021, Scott Talbert wrote:

ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, 
pytest-django, pytest-xdist]; v = 
InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip 
install 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: 
cd /build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
/build/diskcache-5.2.1/tox.ini --sitepa

The actual error:

ERROR: Could not find a version that satisfies the requirement 
typing-extensions>=3.6.4 (from importlib-metadata)

ERROR: No matching distribution found for typing-extensions>=3.6.4


That is a really strange error.  importlib-metadata requires 
typing-extenstions>=3.6.4, but it's supposed to be only for python < 3.8. 
Almost seems like a pip bug when comparing version strings?  Perhaps its 
confused with the two-digits in python 3.10?


Yep, I confirmed this is a bug in pip (and apparently a downstream one) 
and filed a separate bug: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1000826


Scott

Bug#980759: closed by Debian FTP Masters (Bug#997821: Removed package(s) from unstable)

2021-11-29 Thread Thorsten Glaser

Hi,

it would probably have been better to reassign all (relevant)
bugreports to the equivalent 8.1 packages first; this is probably
something the PHP maintainers ought to have done, as closing all
bugs on package removal is normal ftpmasters procedure.

Maybe next time? ☻

bye,
//mirabilos
-- 
I'm not a real programmer. I throw together things until it works
then I move on. The real programmers will say "yeah it works but
you're leaking memory everywhere. Perhaps we should fix that." I'll
just restart apache every 10 requests.  -- Rasmus Lerdorf

Bug#1000826: python3-pip: incorrect version comparisons in requirements with Python 3.10

2021-11-29 Thread Scott Talbert

Package: python3-pip
Version: 20.3.4-4
Severity: important

Dear Maintainer,

python3-pip in unstable currently performs version comparisons 
incorrectly involving Python 3.10 (is it performing a string 
comparison?).  Consider the following examples (Debian package 
python3-pytest is installed.)

Python 3.9 shows the correct behavior:
talbert@debian-unstable:~$ python3.9 -m virtualenv --system-site-packages 
env_3.9
created virtual environment CPython3.9.9.final.0-64 in 109ms
  creator CPython3Posix(dest=/home/talbert/env_3.9, clear=False, 
no_vcs_ignore=False, global=True)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, 
wheel=bundle, via=copy, app_data_dir=/home/talbert/.local/share/virtualenv)
added seed packages: pip==20.3.4, pkg_resources==0.0.0, setuptools==44.1.1, 
wheel==0.34.2
  activators 
BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
talbert@debian-unstable:~$ source env_3.9/bin/activate
(env_3.9) talbert@debian-unstable:~$ pip install pytest
Requirement already satisfied: pytest in /usr/lib/python3/dist-packages (6.2.5)

Python 3.10 shows the incorrect behavior (typing-extensions is installed 
when it should NOT be):
talbert@debian-unstable:~$ python3.10 -m virtualenv --system-site-packages 
env_3.10
created virtual environment CPython3.10.0.final.0-64 in 101ms
  creator CPython3Posix(dest=/home/talbert/env_3.10, clear=False, 
no_vcs_ignore=False, global=True)
  seeder FromAppData(download=False, pip=bundle, setuptools=bundle, 
wheel=bundle, via=copy, app_data_dir=/home/talbert/.local/share/virtualenv)
added seed packages: pip==20.3.4, pkg_resources==0.0.0, setuptools==44.1.1, 
wheel==0.34.2
  activators 
BashActivator,CShellActivator,FishActivator,NushellActivator,PowerShellActivator,PythonActivator
talbert@debian-unstable:~$ source env_3.10/bin/activate
(env_3.10) talbert@debian-unstable:~$ pip install pytest
Requirement already satisfied: pytest in /usr/lib/python3/dist-packages (6.2.5)
Requirement already satisfied: importlib-metadata>=0.12 in 
/usr/lib/python3/dist-packages (from pytest) (4.6.4)
Collecting typing-extensions>=3.6.4
  Using cached typing_extensions-4.0.0-py3-none-any.whl (22 kB)
Installing collected packages: typing-extensions
Successfully installed typing-extensions-4.0.0

See the metadata for importlib-metadata which shows that 
typing-extensions should only be installed for Python < 3.8:
talbert@debian-unstable:~$ cat 
/usr/lib/python3/dist-packages/importlib_metadata-4.6.4.egg-info/requires.txt 

[:python_version < "3.8"]
typing-extensions>=3.6.4

These problems seem to be downstream problems, as if I install the upstream 
version of pip 20.3.4, it behaves correctly.

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

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/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python3-pip depends on:
ii  ca-certificates 20211016
ii  python-pip-whl  20.3.4-4
ii  python3 3.9.8-1
ii  python3-distutils   3.9.9-2
ii  python3-setuptools  59.2.0-1
ii  python3-wheel   0.34.2-1

Versions of packages python3-pip recommends:
ii  build-essential  12.9
ii  python3-dev  3.9.8-1

python3-pip suggests no packages.

-- no debconf information

Bug#997948: [Pkg-pascal-devel] Bug#997948: winff FTBFS: Fatal: (10022) Can't find unit Interfaces used by winff

2021-11-29 Thread Abou Al Montacir

Hi Paul,

On Sun, 2021-11-28 at 22:11 +0100, Paul Gevers wrote:
> I forgot how we do that then, but how do we guarantee that the period is 
> short? Does it show up on the Release Team transition trackers [1] 
> somehow? Or do we have to always remember to ask for a rebuild of 
> lazarus ourselves (if we don't have a reason to upload a new version of 
> lazarus)?
I'm not very familiar with transitions, but we used to ask for a rebuild of
Lazarus and other libs (CGE, ...) if this happens.
Of course if we can make this automatic, then this is even better. 
Do you have any idea in mind?
-- 
Cheers,
Abou Al Montacir


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

Bug#980759: php8.1: imageftbbox returns too small bounding box

2021-11-29 Thread Thorsten Glaser

Bug#995710: RM: netkit-ftp -- RoQA; orphaned; upstream dead; alternative available

2021-11-29 Thread Bastian Germann


Control: retitle -1 RM: netkit-ftp -- RoQA; orphaned; upstream dead; 
alternative available
Control: reassign -1 ftp.debian.org
Control: block -1 by 1000825
X-Debbugs-Cc: debian-de...@lists.debian.org
X-Debbugs-Cc: atzli...@sina.com

On Mon, 4 Oct 2021 16:09:36 +0200 Bastian Germann wrote:
ftp is unmaintained/non-existing upstream and the package seems to be unmaintained as well 
(see related #986997). It should be removed in favour of tnftp (fully command-line 
compatible) and tnftp should provide a package transition. Whoever wants to use the netkit 
source can still install ftp-ssl.


If no one wants to adopt the package, I am going to file a RM bug in a month to enable 
implementing that transition.


Hi,

As many of you may have noticed, Debian's default ftp client (netkit-ftp) is 
dead upstream and
unmaintained in Debian for quite some time. I think that such a key package 
deserves more
attention. There is a fully command-line compatible alternative package 
available: tnftp.
This is battle tested by most (all?) BSD systems as their default ftp client.

I propose removing netkit-ftp and transitioning to tnftp as the new default ftp.
Please comment here if you want to suggest other alternatives or oppose this 
change.
Please comment on #1000825 if you have comments on the transition 
implementation.
There are already some open questions on that bug.

Thanks for your consideration,
Bastian

Bug#1000812: pyrle: import fails on Python 3.10

2021-11-29 Thread Andreas Tille

Am Mon, Nov 29, 2021 at 11:36:33PM +0530 schrieb Nilesh Patra:
> I rebuilt with python3.10, and now error is this.
> Something wrong with pandas?

As far as I understood we need to wait for pandas 1.3 to work
with Python3.10.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#1000825: Transition default ftp from netkit-ftp to tnftp

2021-11-29 Thread Bastian Germann


Source: tnftp

This issue is a request for comments what has to be done to transition the 
default ftp from netkit-ftp to tnftp.

tnftp already provides a virtual ftp package, similar to the netkit-ftp and 
netkit-ftp-ssl packages.
The tnftp package maintainer has added a transitional package ftp (not uploaded 
yet):
https://salsa.debian.org/debian/tnftp/-/commit/2004f46789e2fd12fd08f7f89aab2e1f6f88426f
Is that package needed or does ftp transition okay once netkit-ftp is removed 
from the archive?

Compatibility: I do not see any compatibility problems regarding command line 
flags or program behaviour.
If you see any problem, please report it on this issue.

netrc.5: The content of this manpage is included in tnftp.1 (ftp.1). Is this 
okay or does the manpage have to be split?

Priority: netkit-ftp's control file has Priority: standard, while `apt show 
ftp` presents Priority: optional.
Is it okay to keep Priority: optional for tnftp?

Please also report on this issue if you have any other comments about this 
matter.

Bug#1000824: The library package ships common files

2021-11-29 Thread Andrey Rahmatullin

Package: libxapp1
Version: 2.2.4-1
Severity: serious

Policy 8.2 says "If your package contains files whose names do not change with
each change in the library shared object version, you must not put them in the
shared library package. Otherwise, several versions of the shared library
cannot be installed at the same time without filename clashes, making upgrades
and transitions unnecessarily difficult."

The package ships the following files that violate this:

/etc/xdg/autostart/xapp-sn-watcher.desktop
/usr/lib/x86_64-linux-gnu/gtk-3.0/modules/libxapp-gtk3-module.so
/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-watcher


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

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

Versions of packages libxapp1 depends on:
ii  libc62.32-4
ii  libcairo-gobject21.16.0-5
ii  libcairo21.16.0-5
ii  libdbusmenu-gtk3-4   18.10.20180917~bzr492+repack1-2+b1
ii  libgdk-pixbuf-2.0-0  2.42.6+dfsg-2
ii  libglib2.0-0 2.70.1-1
pn  libgnomekbd8 
ii  libgtk-3-0   3.24.30-3
ii  libpango-1.0-0   1.48.10+ds1-1
ii  libx11-6 2:1.7.2-2+b1
pn  xapps-common 

libxapp1 recommends no packages.

libxapp1 suggests no packages.

Bug#1000823: mmdebstrap: missing dependency on libdpkg-perl

2021-11-29 Thread Michael Prokop

Package: mmdebstrap
Version: 0.8.1-1
Severity: important

Hi,

when "apt-get update" run from within mmdebstrap fails, it can end
up with:

| E: apt-get update -oAPT::Status-Fd=<$fd> -oDpkg::Use-Pty=false failed
| W: listening on child socket failed: Can't locate Dpkg/Vendor/Debian.pm in 
@INC (you may need to install the [...]

In git commit 6d352261 usage of Dpkg::Vendor::Debian got introduced,
a dependency on libdpkg-perl seems to be missing though.

Thanks for mmdebstrap, it's fantastic!

regards
-mika-

Bug#1000822: ntpsigndsocket configuration option missing in ntp.conf(5) man page

2021-11-29 Thread Darshaka Pathirana

Package: ntp
Severity: normal
X-Debbugs-Cc: d...@syn-net.org

Dear Maintainer,

the ntpd configuration option `ntpsigndsocket` is mentioned in the
Samba Wiki "Time Synchronisation / Configuring Time Synchronisation on
a DC": https://wiki.samba.org/index.php/Time_Synchronisation

I had / have a hard time finding any documentation about it. It is
definitely missing in the ntp.conf(5) man page, but also in the
official(?) docs (so ntp-doc is most probably also affected):

* https://www.eecis.udel.edu/~mills/ntp/html/miscopt.html
* 
https://support.ntp.org/bin/view/Support/WebSearch?search=ntpsigndsocket=all

The option does exist in the ntp source though: 
https://salsa.debian.org/pkg-ntp-team/ntp/-/tree/master/html
(search for `ntpsigndsocket`).

Oh, and while writing this bug report I found an entry in the
chrony.conf(5) man page: 
https://manpages.debian.org/bullseye/chrony/chrony.conf.5.en.html

Can we use this in the ntp.conf too or did I miss something?

Thanks very much for maintaining ntp!

Best,
 - Darsha

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

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

Versions of packages ntp depends on:
ii  adduser3.118
ii  libc6  2.31-13+deb11u2
ii  libcap21:2.44-1
ii  libedit2   3.1-20191231-2+b1
pn  libopts25  
ii  libssl1.1  1.1.1k-1+deb11u1
ii  lsb-base   11.1.0
ii  netbase6.3
ii  tzdata 2021a-1+deb11u1

Versions of packages ntp recommends:
ii  perl  5.32.1-4+deb11u2
pn  sntp  

Versions of packages ntp suggests:
pn  ntp-doc

Bug#1000803: autopkgtest: avoid duplication with autopkgtests and how unittests are run at build-time

2021-11-29 Thread Antonio Terceiro

On Sun, Nov 28, 2021 at 11:43:13PM -0500, Sandro Tosi wrote:
> Package: autopkgtest
> Version: 5.16
> Severity: normal
> X-Debbugs-Cc: mo...@debian.org
> 
> Hello,
> There are at least 2 main places where source packages declare tests:
> 
> 1. in debian/rules, to be executed at build-time
> 2. in debina/tests/*, to be executed post-build via autopkgtests
> 
> Usually 1) are written first, because you need to get them to pass during
> build-time; this activity also require to add additional dependencies to
> debian/control, which are only required by tests (and not by the package
> building commands).
> 
> And then there's 2), where often you're required to duplicate the steps from 
> 1)
> and that could lead to misalignment, forgotten dependencies (and so 
> failures), 
> etc.
> 
> In general, it's preferred to reduce duplication to the minimum, just to avoid
> the problems listed above, but autopkgtest kinda requires you to have exactly
> this duplication.
> 
> F.e., i make sure to mark  all the b-d only needed for tests, but
> there's no selector in debian/tests/control to only pull in those packages, 
> and
> sometimes the quickest way is to get all @builddeps@, even if that has the 
> risk
> to include extra packages in the mix.
> 
> There's also the problem of duplicating how we run tests; while autopkgtest
> is less restrictive than the buildd environment (f.e. via allow-network), 
> there
> could be substantial duplication on how test runners are setup in d/rules and
> in autopkgtest.
> 
> I dont know if you ever thought about the duplication problem, i feel it would
> be really helpful if that could be substantially reduced.

This is usually solved outside of autopkgtest itself.

For example Ruby packages have a single place where tests are specified
(debian/ruby-tests.*{rb,rake,yaml}, and the appropriate
debian/tests/control file is autogenerated by autodep8. I would say 99%
of Ruby packages require no duplication, or even explicitly specifying
commands to run tests at all.

In general, this is most efficiently solved by package type (e.g.
programming language), because the way the tests are run at build-time
usually is tied to the build system. You then usually need some test
runner, probably extracted from, or provided by, the build system, to
also provide the same funcionality in an autopkgtest-compatible way.

All the package types that are well supported in autodep8 have their
specialized test runner tools that avoid this type of duplication.

signature.asc
Description: PGP signature

Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10

2021-11-29 Thread Scott Talbert


On Mon, 29 Nov 2021, Andrey Rahmatullin wrote:


On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:

ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, pytest-django, 
pytest-xdist]; v = InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip 
install 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
/build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
/build/diskcache-5.2.1/tox.ini --sitepa

The actual error:

ERROR: Could not find a version that satisfies the requirement 
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4


That is a really strange error.  importlib-metadata requires 
typing-extenstions>=3.6.4, but it's supposed to be only for python < 3.8. 
Almost seems like a pip bug when comparing version strings?  Perhaps its 
confused with the two-digits in python 3.10?


Scott

Bug#1000554: RFS: libfm-qt/0.16.0-3.1 [NMU] [RC] -- Language package for libfm-qt

2021-11-29 Thread Severus Septimius

Closing #1000554 as it is no longer relevant.

Bug#993578: 90gpg-agent generator: `gpgconf --check-programs` can hang

2021-11-29 Thread Jonas Zeiger

Hi,

I had this issue occur on several nodes running bullseye, where it severely 
affected operations (automated remote management).

The patch by Raphaël Hertzog looks great. Reviewed the patch and gpgconf source:
  - it should lead to gpgconf calling gc_component_check_options()
  - same as if using "gpgconf --check-programs", but for the "gpg-agent" 
backend only

I thought the bug could also be filed for/fixed in dirmgr:
 -> various login events
  -> systemd-environment-generator/90gpg-agent 
   -> gpgconf --check-programs
-> ...gc_component_check_options()
 -> dirmngr --gpgconf-test  // IMHO shouldn't perform blocking network IO, 
but does
  -> hang on TCP connect localhost:9050

Thus I checked the dirmngr source code and found this:

>  /* Note that we do not run set_tor_mode in --gpgconf-list mode
>   * because it will attempt to connect to the tor client and that can
>   * be time consuming.  */
>  post_option_parsing ();
>  if (cmd != aGPGConfTest && cmd != aGPGConfList && cmd != aGPGConfVersions)
>set_tor_mode (); 

This seems to be to be intended behavior for dirmngr and could be considered a 
feature.

I think many people are waiting for the updated "gpg-agent" package to arrive 
for stable (bullseye).

Kind regards,
Jonas

Bug#1000812: pyrle: import fails on Python 3.10

2021-11-29 Thread Nilesh Patra

On Mon, 29 Nov 2021 12:50:11 + "Rebecca N. Palmer" 
 wrote:
> Package: python3-pyrle
> Version: 0.0.33-1
> Severity: serious
> Control: affects -1 python3-pyranges
> 
> python3-pyrle fails to import on Python 3.10.  This causes 
> python3-pyranges to fail its build-time tests.  (python3-pyrle itself 
> doesn't run build-time tests.)

I rebuilt with python3.10, and now error is this.
Something wrong with pandas?

Regards,
Nilesh

autopkgtest [23:33:27]: test autodep8-python3: set -e ; for py in $(py3versions 
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c 
"import pyrle; print(pyrle)" ; done
autopkgtest [23:33:27]: test autodep8-python3: [---
Testing with python3.10:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/pandas/__init__.py", line 30, in 
from pandas._libs import hashtable as _hashtable, lib as _lib, tslib as 
_tslib
  File "/usr/lib/python3/dist-packages/pandas/_libs/__init__.py", line 13, in 

from pandas._libs.interval import Interval
ModuleNotFoundError: No module named 'pandas._libs.interval'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3/dist-packages/pyrle/__init__.py", line 1, in 
from pyrle.rle import Rle
  File "/usr/lib/python3/dist-packages/pyrle/rle.py", line 4, in 
from pyrle.src.coverage import _remove_dupes
  File "pyrle/src/coverage.pyx", line 2, in init pyrle.src.coverage
  File "/usr/lib/python3/dist-packages/pandas/__init__.py", line 34, in 
raise ImportError(
ImportError: C extension: No module named 'pandas._libs.interval' not built. If 
you want to import pandas from the source directory, you may need to run 
'python setup.py build_ext --inplace --force' to build the C extensions first.

signature.asc
Description: PGP signature

Bug#1000187: [Pkg-auth-maintainers] Bug#1000187: Bug#1000187: yubikey-manager: Exception when trying to add an oath account

2021-11-29 Thread Tobias Bengfort

I also checked and couldn't find a targeted fix. An upload to 
bullseye-backports would be very helpful though!


thanks,
tobias

Bug#1000802: autopkgtest: quicker way to iterate over autopkgtests while writing them

2021-11-29 Thread Antonio Terceiro

On Sun, Nov 28, 2021 at 11:14:19PM -0500, Sandro Tosi wrote:
> Package: autopkgtest
> Version: 5.16
> Severity: normal
> X-Debbugs-Cc: mo...@debian.org
> 
> Hello,
> while adding autopkgtests to a package, it seems the only way to iterate over
> them (adding new tests, fix broken ones) is to fix them in the source package
> and rebuild it.
> 
> There are packages that takes hours to build, and that's essentially to write
> a handful of files in the source package.
> 
> Is there a better way to incrementally work on autopkgtests that doesnt 
> require
> to waste hours (sometimes days) just waiting for the source package to build?
> 
> I think that would greatly improve the developers experience.

This has always been possible. You can run the tests directly from the
source tree, using previously built .debs:

autopkgtest --no-built-binaries ../*.deb . -- [...]

The above works for any virtualization backend.

If you already have the right binaries installed on your host system and
want to run the tests without any virtualization, it's even simpler:

autopkgtest -B . -- null

I have the above aliased as `a`. (-B is the short form for
--no-built-binaries).

We should probably add an examples section to the manpage with this type
of invocations.


signature.asc
Description: PGP signature

Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

2021-11-29 Thread Adrian Bunk

On Mon, Nov 29, 2021 at 05:32:30PM +0100, Julien Cristau wrote:
> cc: rustc and firefox maintainers
> 
> On Tue, Nov 23, 2021 at 03:20:45PM -0500, Roberto C. Sanchez wrote:
> > In preparing the rustc 1.51 upload/backport (to support backports of the
> > latest firefox-esr and thunderbird packages) it has been suggested that
> > to avoid some issues associated with providing a significant new version
> > of rustc in the rustc binary package (along with the associated library
> > packages), that I prepare the 1.51 rustc package with a different name.
> > Following the model of what was done for gcc, nasm, and nodejs, I was
> > considering source package rustc-mozilla with a single binary package
> > (also rustc-mozilla) to ensure that rdeps don't end up getting surprised
> > by a new rustc.  Would this be considered acceptable for the bullseye
> > and buster uploads of rustc 1.51?
> 
> 2 things:
> - I think we should pick 1.53 if possible, since that's what mozilla use
>   for their esr91 binaries

I was suggesting 1.51 since the smaller the difference to the currently 
used version, the lower the risk of new bad surprises when updating 
rustc.

Roberto is doing this primarily for LTS, and for stretch LTS next years
Firefox that will require yet another rustc update will no longer be an
issue.

The Debian packages of rustc 1.53 in experimental and unstable were 
built with LLVM 12, we won't see before it enters stable-pu whether
building rustc 1.53 with LLVM 11 breaks on some architecture (unlikely
but not impossible, especially with the error thresholds).

> - I don't think we need to rename the packages unless there's evidence
>   of breakage that can't be easily fixed by either simple patches or
>   removing the affected packages.  Renamed packages are acceptable but
>   that seems like extra work and overhead that may not be necessary.

We have already learned the hard way that such evidence might appears
after it is too late.

In bullseye there are > 800 non-Firefox packages build depending on rustc.

In buster there are "only" around 450 packages build depending on rustc.
One of them is librsvg, which failed to build with last years new rustc 
for Firefox.

The librsvg updated for rustc 1.41 updated for last years Firefox ESR
did build on amd64 but not on ppc64el.

And BTW, this rustc/firefox misery also blocks the CVE-2019-20446 fix in 
librsvg from entering buster.

Assuming ppc64el will continue to not be part of LTS also for buster,
the easiest solution will be to re-upload the fixed librsvg to 
buster-security immediately after LTS starts for buster.

For rustc 1.41 in buster this is exactly the evidence you are asking for.
And it could not have reasonably be discovered before uploading rustc.

The lesson learned is that the normal rustc package can no longer be 
updated in stable series now that Firefox is no longer the sole user.

> Cheers,
> Julien

cu
Adrian

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

2021-11-29 Thread Vincent Bernat

 ❦ 29 November 2021 17:32 GMT, Adam D. Barratt:

>> > What you've uploaded to bullseye is *not* what you proposed in this
>> > request, however.
>> > 
>> > The debdiff attached to this bug report amounts to "4 files
>> > changed,
>> > 130 insertions(+)", the uploaded package is "39 files changed, 561
>> > insertions(+), 221 deletions(-)" and includes a new upstream
>> > release.
>> 
>> Ugh. Very sorry about that!
>> 
>> Here is the appropriate diff. How can I sort out my bad upload?
>> Bumping the version number? I hold uploading anything else until you
>> approve.
>
> Ah, I see the confusion - you used the wrong base upload when
> generating the first diff. As that resulted in an upload of 1.0.12-
> 1+deb11u1 and the fixed package will be 1.0.11-1+deb11u1, they can co-
> exist in the processing queue - free to upload the new diff and we will
> deal with rejecting the larger diff.

Thanks! Done.
-- 
"... all the modern inconveniences ..."
-- Mark Twain

Bug#1000477: gmp 6.2.1+dfsg-1+deb11u1 flagged for acceptance

2021-11-29 Thread Adam D Barratt

package release.debian.org
tags 1000477 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: gmp
Version: 6.2.1+dfsg-1+deb11u1

Explanation: fix integer and buffer overflow issue [CVE-2021-43618]

Bug#992331: keystone 18.0.0-3+deb11u1 flagged for acceptance

2021-11-29 Thread Adam D Barratt

package release.debian.org
tags 992331 = bullseye pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: keystone
Version: 18.0.0-3+deb11u1

Explanation: resolve information leak allowing determination of whether users 
exist [CVE-2021-38155]; apply some performance improvements to the default 
keystone-uwsgi.ini

Bug#992331: bullseye-pu: package keystone/18.0.0-3+deb11u1 (CVE-2021-38155)

2021-11-29 Thread Adam D. Barratt

On Mon, 2021-10-04 at 14:59 +0200, Thomas Goirand wrote:
> Hi,
> 
> Thanks for your reply.
> 
> I have uploaded keystone/18.0.0-3+deb11u2 to Bullseye. You can flag
> it for acceptance.
> 

It's very kind of you to give us permission. ;-)

> For Buster, I'm having the problem that I cannot build the package
> without subunit 1.4.0-3 which is in Bullseye only (Buster has 1.3.0-
> 1).
> Would it be acceptable that I upload both subunit 1.4.0-3 and
> Keystone
> 2:14.2.0-0+deb10u2 to Buster? Please let me know your thoughts.

We'd have to see the relevant diffs, really. In any case, to avoid
potentially confusing issues, please open a new bug(s) for any proposed
update(s) to buster, rather than re-using this one.

Regards,

Adam

Bug#1000820: RFP: onvifviewer -- ONVIF camera viewer

2021-11-29 Thread Petter Reinholdtsen



Package: wnpp
Severity: wishlist

* Package name: onvifviewer
  Version : 0.13
  Upstream Author : Casper Mijn
* URL : https://gitlab.com/caspermeijn/onvifviewer
* License : GPL 3+
  Programming Lang: C++
  Description : ONVIF camera viewer
  
Client for the ONVIF protocol used to connect to and configure IP
Cameras.
  
-- 
Happy hacking
Petter Reinholdtsen

Bug#999673: bullseye-pu: package lldpd/1.0.11-1

2021-11-29 Thread Adam D. Barratt

On Sat, 2021-11-27 at 23:32 +0100, Vincent Bernat wrote:
>  ❦ 27 November 2021 17:43 GMT, Adam D. Barratt:
> 
> > > > Package: release.debian.org
> > > > Severity: normal
> > > > Tags: bullseye
> > > > User: release.debian@packages.debian.org
> > > > Usertags: pu
> > > [...]
> > > 
> > > I did the upload to bullseye as I think the change is not
> > > controversial.
> > 
> > What you've uploaded to bullseye is *not* what you proposed in this
> > request, however.
> > 
> > The debdiff attached to this bug report amounts to "4 files
> > changed,
> > 130 insertions(+)", the uploaded package is "39 files changed, 561
> > insertions(+), 221 deletions(-)" and includes a new upstream
> > release.
> 
> Ugh. Very sorry about that!
> 
> Here is the appropriate diff. How can I sort out my bad upload?
> Bumping the version number? I hold uploading anything else until you
> approve.

Ah, I see the confusion - you used the wrong base upload when
generating the first diff. As that resulted in an upload of 1.0.12-
1+deb11u1 and the fixed package will be 1.0.11-1+deb11u1, they can co-
exist in the processing queue - free to upload the new diff and we will
deal with rejecting the larger diff.

Regards,

Adam

Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10

2021-11-29 Thread Andrey Rahmatullin

On Mon, Nov 29, 2021 at 05:58:47PM +0100, Andreas Tille wrote:
> ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, 
> pytest-django, pytest-xdist]; v = 
> InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install 
> 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
> E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
> /build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
> /build/diskcache-5.2.1/tox.ini --sitepa
The actual error:

ERROR: Could not find a version that satisfies the requirement 
typing-extensions>=3.6.4 (from importlib-metadata)
ERROR: No matching distribution found for typing-extensions>=3.6.4

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10

2021-11-29 Thread Scott Talbert


On Mon, 29 Nov 2021, Andreas Tille wrote:


Control: tags -1 help

Hi,

currently I'm running into


ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, pytest-django, 
pytest-xdist]; v = InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip 
install 'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
/build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
/build/diskcache-5.2.1/tox.ini --sitepa


Any help would be really welcome


Can you post the full build log somewhere?

Scott

Bug#997505: [Help] diskcache: FTBFS now even earlier due to Python3.10

2021-11-29 Thread Andreas Tille

Control: tags -1 help

Hi,

currently I'm running into


ERROR:   py310: could not install deps [django>=2.2.*, pytest, pytest-cov, 
pytest-django, pytest-xdist]; v = 
InvocationError("/build/diskcache-5.2.1/.tox/py310/bin/python -m pip install 
'django>=2.2.*' pytest pytest-cov pytest-django pytest-xdist", 1)
E: pybuild pybuild:354: test: plugin distutils failed with: exit code=1: cd 
/build/diskcache-5.2.1/.pybuild/cpython3_3.10_diskcache/build; tox -c 
/build/diskcache-5.2.1/tox.ini --sitepa


Any help would be really welcome

  Andreas.


-- 
http://fam-tille.de

Bug#992676: Bug#999523: python-skbio: fixed upstream

2021-11-29 Thread Andreas Tille

Hi Graham,

Am Mon, Nov 29, 2021 at 12:55:29PM +0200 schrieb Graham Inggs:
> Control: tags -1 + patch fixed-upstream
> 
> Both of these issues are fixed in:
> 
> https://github.com/biocore/scikit-bio/commit/357c7fe847187bc540c4914c3ffd607d9432857d

I can't confirm this after testing the patch.  The package does not
build by simply applying this very patch (which needs several changes to
apply). 

Kind regards

Andreas.

-- 
http://fam-tille.de

Bug#1000472: bullseye-pu: package rustc-mozilla/1.51.0+dfsg1-1~deb11u1

2021-11-29 Thread Julien Cristau

cc: rustc and firefox maintainers

On Tue, Nov 23, 2021 at 03:20:45PM -0500, Roberto C. Sanchez wrote:
> In preparing the rustc 1.51 upload/backport (to support backports of the
> latest firefox-esr and thunderbird packages) it has been suggested that
> to avoid some issues associated with providing a significant new version
> of rustc in the rustc binary package (along with the associated library
> packages), that I prepare the 1.51 rustc package with a different name.
> Following the model of what was done for gcc, nasm, and nodejs, I was
> considering source package rustc-mozilla with a single binary package
> (also rustc-mozilla) to ensure that rdeps don't end up getting surprised
> by a new rustc.  Would this be considered acceptable for the bullseye
> and buster uploads of rustc 1.51?

2 things:
- I think we should pick 1.53 if possible, since that's what mozilla use
  for their esr91 binaries
- I don't think we need to rename the packages unless there's evidence
  of breakage that can't be easily fixed by either simple patches or
  removing the affected packages.  Renamed packages are acceptable but
  that seems like extra work and overhead that may not be necessary.

Cheers,
Julien

Bug#999906: After upgrade to Debian Bullseye, I am not able to burn DVDs.

2021-11-29 Thread Thomas Schmitt

Hi,

> I am not such a purist, so I really appreciate the comfort of a desktop like
> KDE or LXDE in this case.

It's not so much about purism in my personal case, but rather about
the unwillingness to repeatedly learn how to do the same things in
frequently (*) changing ways.

(*) Once every ten years is too much for my ageing brain.


> So is there anything I can do to help?

Not before somebody shows up and asks for tests or experiments.

I don't see suspicious upstream commits at
  https://github.com/KDE/k3b/commits/master
and multiple pages until version 18.08.1 which is in Debian 10.
In Debian 11 the K3B version is 20.12.2.

The Debian 11 changelog
  https://tracker.debian.org/media/packages/k/k3b/changelog-20.12.2-1
gives no hint that the Debian maintainers changed something related to
burn speed or burning in general.

The patches in
  https://sources.debian.org/src/k3b/20.12.2-1/debian/patches/
don't look suspicious either.

So i am out of ideas about how to find the trigger for your problems
in Debian 11.


> PS: I am on vacation till December 14th.

Stay safe. Best in a plague-free hut in a remote mountain valley ...


Have a nice day :)

Thomas

Bug#1000208: ITP: pcmemtest -- stand-alone memory tester

2021-11-29 Thread Stephan Lachnit

Hi Felix,

I'm finished with my review. I've opened a PR on Salsa [1] with my suggestions.

Regards,
Stephan

[1] https://salsa.debian.org/fzielcke/pcmemtest/-/merge_requests/1

On Mon, Nov 29, 2021 at 4:17 PM Stephan Lachnit
 wrote:
>
> Hi Felix,
>
> thanks for the ping, looking at it right now.
>
> Regards,
> Stephan
>
> On Mon, Nov 29, 2021 at 2:14 PM Felix Zielcke  wrote:
> >
> > Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit:
> > > Hi Felix,
> > >
> > > I was a bit more stressed this week than I hoped, I'll try to look at
> > > it
> > > saturday or sunday. If you don't get a reply by monday morning, feel
> > > free
> > > to ping me again.
> >
> > Hi Stephan,
> >
> > here's your friendly ping.
> > Did you have time to look at pcmemtest?
> >
> > Regards,
> > Felix
> >

Bug#1000622: ser2net: Fails to start on boot since the serial port is not ready

2021-11-29 Thread Marc Haber

tags #1000622 confirmed pending
thanks

On Mon, Nov 29, 2021 at 08:17:29AM +, Mario Volterra wrote:
> I have added to /lib/systemd/system/ser2net.service
> 
> After=network-online.target
> Wants=network-online.target
> 
> ad below and rebooted the pi and upon restart ser2net started successfully!

This will be in the next package.

Greetings
Marc

Bug#1000817: RFP: openhab -- Vendor and technology agnostic home automation software

2021-11-29 Thread Petter Reinholdtsen



Package: wnpp
Severity: wishlist

* Package name: openhab
  Version : 3.2.0
  Upstream Author : The OpenHAB team
* URL : https://www.openhab.org/
* License : Eclipse Public License 2.0
  Programming Lang: Java
  Description : Vendor and technology agnostic home automation software

-- 
Happy hacking
Petter Reinholdtsen

Bug#1000816: xmlAddEntity: invalid redeclaration of predefined entity

2021-11-29 Thread Vincent Lefevre

Package: docbook2x
Version: 0.8.8-17+b1
Severity: normal

Consider as a simple testcase test.xml:


http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;>


I get:

$ /usr/bin/docbook2x-texi test.xml
error : xmlAddEntity: invalid redeclaration of predefined entity
[...]

"xmllint --loaddtd --valid test.xml" does not show any redeclaration
of predefined entity issue. So this seems to come from docbook2x-texi.

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

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

Versions of packages docbook2x depends on:
ii  libc6  2.32-4
ii  libtext-wrapi18n-perl  0.06-9
ii  libxml-sax-expat-perl  0.51-1
ii  opensp 1.5.2-13+b2
ii  perl   5.32.1-6
ii  texinfo6.8-3
ii  xml-core   0.18+nmu1
ii  xsltproc   1.1.34-4

Versions of packages docbook2x recommends:
ii  docbook-xml  4.5-11
ii  docbook-xsl  1.79.2+dfsg-1

docbook2x suggests no packages.

-- no debconf information

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

Bug#1000208: ITP: pcmemtest -- stand-alone memory tester

2021-11-29 Thread Stephan Lachnit

Hi Felix,

thanks for the ping, looking at it right now.

Regards,
Stephan

On Mon, Nov 29, 2021 at 2:14 PM Felix Zielcke  wrote:
>
> Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit:
> > Hi Felix,
> >
> > I was a bit more stressed this week than I hoped, I'll try to look at
> > it
> > saturday or sunday. If you don't get a reply by monday morning, feel
> > free
> > to ping me again.
>
> Hi Stephan,
>
> here's your friendly ping.
> Did you have time to look at pcmemtest?
>
> Regards,
> Felix
>

Bug#923550: man page for dmarc-cat

2021-11-29 Thread Antoine Beaupré

On 2021-11-26 12:04:07, Ethan Blanton wrote:
> Package: dmarc-cat
> Tags: patch
> .TH dmarc-cat 1 "November 2021" "dmarc-cat"
>
> .SH NAME
> .B dmarc-cat
> - displays DMARC XML reports in a human-readable summary form
>
> .SH SYNOPSIS
> .TP
> \fBdmarc-cat\fP [\fIOPTION\FP]... \fIinput-file\fP
>
> .SH OVERVIEW
> This utility decodes the standard XML reports sent by providers to the "rua" 
> record configured in DMARC.
> It is useful to make sense of reports that are otherwise very difficult to 
> read.
>
> .SH DESCRIPTION
>   \-DDebug mode
>   \-NDo not resolve IPs
>   \-S string Sort results (default "\"Count\" \"dsc\"")
>   \-j intParallel jobs (default 16)
>   \-vVerbose mode
>   \-version  Display version

this is a bit unusual: typically, this section is called `OPTIONS`. See
the man-pages(7) manual page.

> .SH COPYRIGHT
> This minimal man page Copyright (C) 2021 Ethan Blanton.
> .br
> The OVERVIEW Copyright (C) 2019 Antoine Beaupr\[u00E9] .
> .br
> The DESCRIPTION Copyright (C) 2018 Ollivier Robert.
>
> .SH AUTHOR
> This man page was written by Ethan Blanton  for the Debian 
> system (but may be used by other).
> Permission is granted to copy, distribute, and/or modify this document under 
> the terms of the GNU General Public License, Version 2 or any later version 
> published by the Free Software Foundation.
> .PP
> On Debian systems, the complete text of the GNU General Public License can be 
> found in /usr/share/common\-licenses/GPL.

"AUTHOR" is also refered to as "AUTHORS" in the aforementioned
man-pages(7), but its use is Discouraged. COPYRIGHT similarly comes
after AUTHORS and says "Not used". I would typically just keep "AUTHORS"
and elide the copyright altogether, especially if you intend to break up
the copyright per section like this... It feels a bit weird to assign
copright to specific sections like that, for example.

I certainly don't see how I own the copyright on the OVERVIEW section,
in any case.

Sorry for the legal nitpicking...

A.

-- 
Sous un gouvernement qui emprisonne injustement, la place de l’homme
juste est aussi en prison.
- La désobéissance civile, Henry David Thoreau

Bug#998627: linux: please enable the new NTFS3 driver in 5.15

2021-11-29 Thread Heinz Repp

On Tue, 23 Nov 2021 22:34:25 +0100 Salvatore Bonaccorso 
 wrote:

Are tools available to handle creation and checking of such NTFS3
filesystems? The last time I went to the paragon software site it
mentioned it was planning. This is not a must, but kept me for
slightly on the on hold position for enabling it.


You mean you are holding back the DRIVER because you are missing 
USERSPACE utilities to handle and examine NTFS 3.1 filesystems?!?


One has nothing to do with the other. There are a lot of NTFS utilities 
available with the ntfs-3g package, namely:



mkntfs
ntfscat
ntfsclone
ntfscluster
ntfscmp
ntfscp
ntfsdecrypt
ntfsfallocate
ntfsfix
ntfsinfo
ntfslabel
ntfsls
ntfsrecover
ntfsresize
ntfssecaudit
ntfstruncate
ntfsundelete
ntfswipe


Nearly all of them (apart from ntfssecaudit cases) work on devices, not 
on mounted file systems, so the NTFS driver used is not in involved. An 
idea would be to split the ntfs-3g package into

ntfs-3g-tools
ntfs-3g-fusedriver
libntfs-3g (on which the former depends)

A Paragon donated mkfs.ntfs would be a nice thing, but mkntfs from 
ntfs-3g already fits for nearly all purposes. And I guess most people 
would want the new ntfs3 driver for filesystems created with Windows.



On Sat, 27 Nov 2021 14:14:53 +0100 Salvatore Bonaccorso 
 wrote:

Apart from Ted Ts'o comments, I looked up the mailinglist,
https://lore.kernel.org/ntfs3/ which relatively quiet. The same
goes for commits in fs/ntfs3 in mainline, since the merge in 5.15
there ws almost no activity, which is slightly unusual for something
new entering.


Looking on the same mailinglist, I think they recently did a lot to fix 
the test issues and much more, as can be seen:



[PATCH] ntfs3: Fix showing umask option
 2021-11-27 13:51 UTC 


[PATCH 1/2] fs/ntfs3: clarify why $Extend init is being skipped
 2021-11-26 12:04 UTC  (2+ messages)

[PATCH] Doc/fs/ntfs3: Fix a trivial typo
 2021-11-26 11:52 UTC  (2+ messages)

[ramfs] 0858d7da8a: canonical_address#:#[##]
 2021-11-26 11:36 UTC  (2+ messages)

[PATCH] fs/ntfs3: Fix some memory leaks in an error handling path of 
'log_replay()'
 2021-11-23 15:47 UTC  (2+ messages)

Bug using new ntfs3 file system driver (5.15.2 on Arch Linux)
 2021-11-19 14:19 UTC  (3+ messages)

No more accessible (compromised) NTFS volume
 2021-11-16 17:16 UTC 


[PATCH v2 0/4] fs/ntfs3: Various fixes for xattr and files
 2021-11-15 15:50 UTC  (11+ messages)
` [PATCH 1/4] fs/ntfs3: Keep preallocated only if option prealloc enabled
` [PATCH 2/4] fs/ntfs3: Restore ntfs_xattr_get_acl and ntfs_xattr_set_acl 
functions
` [PATCH 3/4] fs/ntfs3: Update i_ctime when xattr is added
` [PATCH 4/4] fs/ntfs3: Optimize locking in ntfs_save_wsl_perm

[BUG] Unable to mount NTFS drive, no error in dmesg
 2021-11-11  4:39 UTC 


Readahead for compressed data
 2021-10-29  6:15 UTC  (16+ messages)

[PATCH v2] checkpatch: Improve CVS revision marker check
 2021-10-27 10:56 UTC 


[PATCH] checkpatch: Remove cvs keyword check
 2021-10-27  9:21 UTC  (4+ messages)

[PATCH 0/4] fs/ntfs3: Various fixes for xfstests problems
 2021-10-26 21:37 UTC  (11+ messages)
` [PATCH 1/4] fs/ntfs3: In function ntfs_set_acl_ex do not change inode->i_mode 
if called from function ntfs_init_acl
` [PATCH 2/4] fs/ntfs3: Fix fiemap + fix shrink file size (to remove 
preallocated space)
` [PATCH 3/4] fs/ntfs3: Check new size for limits
` [PATCH 4/4] fs/ntfs3: Update valid size if -EIOCBQUEUED

[PATCH] fs/ntfs3: clarify emitted log message when marking volumes as dirty
 2021-10-26 20:56 UTC  (3+ messages)

[PATCH 2/2] fs/ntfs3: clarify emitted log message when marking volumes as dirty
 2021-10-26 20:55 UTC 


[PATCH] fs/ntfs3: clarify why $Extend init is being skipped
 2021-10-26 20:49 UTC  (2+ messages)

(very low importance) NTFS version message
 2021-10-26 18:03 UTC  (2+ messages)

[PATCH 0/4] fs/ntfs3: Various fixes for xattr and files
 2021-10-24 11:13 UTC  (12+ messages)
` [PATCH 1/4] fs/ntfs3: Keep preallocated only if option prealloc enabled
` [PATCH 2/4] fs/ntfs3: Restore ntfs_xattr_get_acl and ntfs_xattr_set_acl 
functions
` [PATCH 3/4] fs/ntfs3: Optimize locking in ntfs_save_wsl_perm
` [PATCH 4/4] fs/ntfs3: Update i_ctime when xattr is added

NTFS3: junctions are not properly resolved
 2021-10-22 12:50 UTC 


[PATCH 0/2] Removing of old code
 2021-10-19 17:11 UTC  (4+ messages)
` [PATCH 1/2] fs/ntfs3: Remove unnecessary functions

cleanup block device inode syncing
 2021-10-19 13:54 UTC  (14+ messages)
` [PATCH 1/7] fs: remove __sync_filesystem
` [PATCH 2/7] block: remove __sync_blockdev
` [PATCH 3/7] xen-blkback: use sync_blockdev
` [PATCH 4/7] btrfs: "
` [PATCH 5/7] fat: use sync_blockdev_nowait
` [PATCH 6/7] ntfs3: "
` [PATCH 7/7] block: simplify the block device syncing code

don't use ->bd_inode to access the block device size v3
 2021-10-19  1:04 UTC  (40+ messages)
` [PATCH 01/30] block: move the SECTOR_SIZE related definitions to blk_types.h
` [PATCH 02/30] block: add a bdev_nr_bytes helper
` [PATCH 03/30] bcache: remove

Bug#995202: horst: diff for NMU version 5.1-2.1

2021-11-29 Thread Antoine Beaupré

On 2021-11-28 20:55:34, Adrian Bunk wrote:
> Dear maintainer,
>
> I've prepared an NMU for horst (versioned as 5.1-2.1) and uploaded
> it to DELAYED/14. Please feel free to tell me if I should cancel it.

Feel free to upload it directly, thanks!

-- 
We are discreet sheep; we wait to see how the drove is going, and then go
with the drove.
- Mark Twain

Bug#990702: matrix-mirage: 'invite' KeyError exception

2021-11-29 Thread fromage

I believe this has been fixed upstream: 
https://github.com/mirukana/mirage/issues/220

Bug#1000333: gem2deb: ignore or find a way to make <= constraint in gemspec work

2021-11-29 Thread Antonio Terceiro

Control: tag -1 - wontfix

> Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, Nov 23, 2021 at 06:21:14AM +0530, Pirate Praveen wrote:
> 
> 
> 2021, നവംബർ 22 11:12:36 PM IST, Antonio Terceiro ൽ എഴുതി
> >Control: tag -1 + wontfix
> >
> >On Sun, Nov 21, 2021 at 11:51:22PM +0530, Pirate Praveen wrote:
> >> Package: gem2deb
> >> Version: 1.7
> >> Severity: wishlist
> >> 
> >> should we really honor <= constraint in gemspecs? in ruby-google-fog
> >> upstream wants fog-core <= 2.1.0 it will never be satisfied in debian
> >> 
> >> because 2.1.0-1 >= 2.1.0 and we have 2.1.0-3.1 in archive
> >> 
> >> we could either ignore or may be detect the current version in the archive
> >> (it will require a rebuild if dependency change)
> >
> >In cases like this, IMO the gemspec needs to be patched to drop such
> >dependency. Even if we did ignore it and didn't represent that with a
> >corresponding << constraint in debian/control, the dependency check will
> >still fail during the build unless the gemspec is patched.
> 
> In this specific case the build did not fail, only installation during 
> autopkgtest that failed because of control file.
> 
> fog-core version in its gemspec is 2.1.0 and it satisfies.
> 
> This is to take care of debian revision only, for new upstream versions, we 
> still have to patch if update needed.

Yes, now I understand what is the issue. I think we could fix that by
translating <= x.y to <= x.y- ?

<= is not handled in any special way at the moment.


signature.asc
Description: PGP signature

Bug#995189: RFH: isc-dhcp

2021-11-29 Thread Martin-Éric Racine

ke 24. marrask. 2021 klo 16.20 Santiago Ruano Rincón
(santiag...@riseup.net) kirjoitti:
> I've started doing some work at https://salsa.debian.org/santiago/isc-dhcp/
>
> I still didn't get any answer from current maintainers (keeping them in
> CC), so I plan to retitle this bug as an ITS bug soon. Hopefully no
> later than next Friday.

Btw, you might wanna look at the changes that Ubuntu made as well, in
case they have already fixed some pending issues.

https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/isc-dhcp/4.4.1-2.3ubuntu1/isc-dhcp_4.4.1-2.3ubuntu1.dsc

This one is obviously against what's currently in unstable.

Martin-Éric

Bug#998790: firefox: Video not playing

2021-11-29 Thread dyna


Wasn't able to track down the problem but it seems to have been fixed now.

Bug#1000208: ITP: pcmemtest -- stand-alone memory tester

2021-11-29 Thread Felix Zielcke

Am Freitag, dem 26.11.2021 um 15:34 +0100 schrieb Stephan Lachnit:
> Hi Felix,
> 
> I was a bit more stressed this week than I hoped, I'll try to look at
> it
> saturday or sunday. If you don't get a reply by monday morning, feel
> free
> to ping me again.

Hi Stephan,

here's your friendly ping.
Did you have time to look at pcmemtest?

Regards,
Felix

Bug#1000588: evince,mailcap: "evince --new-window $file" opens the file chooser dialog instead of the requested file

2021-11-29 Thread Julien Cristau

On Fri, Nov 26, 2021 at 06:28:56AM +0900, Charles Plessy wrote:
> Le Thu, Nov 25, 2021 at 03:15:27PM +, Simon McVittie a écrit :
> > Control: reassign -1 mailcap 3.70
> > 
> > On Thu, 25 Nov 2021 at 15:13:01 +0100, Julien Cristau wrote:
> > 
> > Yes, update-mime should only be parsing the fields from the
> > [Desktop Entry] group, something like this (untested):
> 
> Thanks Julien and Simon,
> 
> I agree that the problem and the solution are in mailcap.
> 
> I am about to go for a business trip, so the fix may take a couple of
> weeks.  If you consider an NMU please go straight for a team upload
> and push the change in Salsa; as DDs you should have commit rights.
> 
> https://salsa.debian.org/debian/mailcap
> 
Thank you both.  I've tested locally, Simon's suggested patch fixes
evince, libreoffice and evolution entries for me, so I'll go ahead and
upload it.

Cheers,
Julien

Bug#1000811: bullseye-pu: package debian-edu-doc/2.11.26+deb11u1

2021-11-29 Thread Wolfgang Schweer

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu

Dear relese team,

[ Reason ]
Documentation update for the Debian Edu Bullseye manual and translation 
updates for both the Debian Edu Bullseye and Buster manuals. 

[ Impact ]
Users would be left without proper documentation concerning the Debian 
Edu specific LTSP setup and maintenance tools.
Also, improved translations would be missing.

[ Tests ]
Manual tests, translation status equals the one in the master branch / 
Debian unstable.

[ Risks ]
No risk apparent.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Update Debian Edu Bullseye manual from the wiki; this makes sure that:
- all LTSP setup and maintenance related changes are in the manual.
- the Debian Edu Bullseye manual source file is the same like the one in
  the master branch / Debian unstable.

Update Bullseye and Buster manual translations (PO files) from the master
branch / Debian unstable.

Update related PO addendum files from the master branch to make sure that
all translators are credited correctly in the generated manuals.

[ Other info ]
Holger Levsen will do the upload.

Wolfgang


debdiff_d-e-doc.xz
Description: application/xz


signature.asc
Description: PGP signature

Bug#1000810: python3-django-hyperkitty: Internal Server Error (500): ImportError: cannot import name 'url_has_allowed_host_and_scheme'

2021-11-29 Thread Colin Turner

Package: python3-django-hyperkitty
Version: 1.3.4-4
Severity: normal

Dear Maintainer,

Thank you for work in packaging the mailman3 ecosystem.

At some recent point, it became impossible to access the mailman 3 web 
interface, hyperkitty. An Internal Server Error is being reported on all 
attempts to access.

The Traceback is a bit puzzling, since it looks like one part of Django is 
trying to import from another and finding a missing symbol name.

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/django/core/handlers/wsgi.py", line 141, 
in __call__
]
  File "/usr/lib/python3/dist-packages/django/core/handlers/base.py", line 75, 
in get_response
self._view_middleware.insert(
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
36, in inner
async def inner(request):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
90, in response_for_exception
elif isinstance(exc, SuspiciousOperation):
  File "/usr/lib/python3/dist-packages/django/core/handlers/exception.py", line 
128, in handle_uncaught_exception

  File "/usr/lib/python3/dist-packages/django/urls/resolvers.py", line 597, in 
resolve_error_handler
# urlconf_module might be a valid set of patterns, so we default to it
  File "/usr/lib/python3/dist-packages/django/utils/functional.py", line 80, in 
__get__
the lazy evaluation code is triggered. Results are not memoized; the
  File "/usr/lib/python3/dist-packages/django/urls/resolvers.py", line 577, in 
urlconf_module
sub_match_dict,
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/share/mailman3-web/./urls.py", line 29, in 
url(r'^postorius/', include('postorius.urls')),
  File "/usr/lib/python3/dist-packages/django/urls/conf.py", line 34, in include
urlconf_module = import_module(urlconf_module)
  File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
  File "", line 1030, in _gcd_import
  File "", line 1007, in _find_and_load
  File "", line 986, in _find_and_load_unlocked
  File "", line 680, in _load_unlocked
  File "", line 850, in exec_module
  File "", line 228, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/postorius/urls.py", line 23, in 
from postorius.views import list as list_views
  File "/usr/lib/python3/dist-packages/postorius/views/list.py", line 48, in 

from postorius.auth.mixins import ListOwnerMixin
  File "/usr/lib/python3/dist-packages/postorius/auth/mixins.py", line 21, in 

from django.contrib.auth.mixins import LoginRequiredMixin, 
UserPassesTestMixin
  File "/usr/lib/python3/dist-packages/django/contrib/auth/mixins.py", line 5, 
in 
from django.contrib.auth.views import redirect_to_login
  File "/usr/lib/python3/dist-packages/django/contrib/auth/views.py", line 20, 
in 
from django.utils.http import (
ImportError: cannot import name 'url_has_allowed_host_and_scheme' from 
'django.utils.http' (/usr/lib/python3/dist-packages/django/utils/http.py)

The last files indicated are both in python3-django and it's not obvious to me 
why the import is failing or whether that's a red herring, but it seems as 
though this was linked to a recent python3-django upgrade?

Happy to do any useful tests to investigate further.

Kind regards,

CT.

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

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

Versions of packages python3-django-hyperkitty depends on:
ii  fonts-glyphicons-halflings   1.009~3.4.1+dfsg-2
ii  libjs-bootstrap4 4.5.2+dfsg1-8
ii  libjs-sphinxdoc  4.2.0-5
ii  python3  3.9.7-1
ii  python3-dateutil 2.8.1-6
ii  python3-django   2:3.2.9-2
ii  python3-django-compressor2.4-2
ii  python3-django-extensions3.1.5-1
ii  python3-django-gravatar2 1.4.4-2
ii  python3-django-haystack  3.1.1-1
ii  python3-django-mailman3  1.3.7-1
ii  python3-django-q 1.2.1-1
ii  python3-djangorestframework  3.12.4-1
ii  python3-elasticsearch7.1.0-5
ii  python3-flufl.lock   5.0.1-1
ii  python3-mailmanclient3.3.3-1
ii  python3-networkx 2.5+ds-2
ii  python3-robot-detection  0.4.0-2
ii  python3-tz   2021.3-1

Versions of packages

Bug#999906: AW: After upgrade to Debian Bullseye, I am not able to burn DVDs.

2021-11-29 Thread w_t...@t-online.de

Hey Thomas,

yes. At the moment, using xorrecord or xfburn, I am able to do the job.
Thanks a lot for your advice.

I am not such a purist, so I really appreciate the comfort of a desktop like KDE
or LXDE in this case. But I see that there is a huge overhead and with this also
the additional source of errors. But I have great respect for guys like you, 
doing it
the straight way. :-)

So is there anything I can do to help?

CU
Werner

PS: I am on vacation till December 14th.

-Original-Nachricht-
Betreff: Re: After upgrade to Debian Bullseye, I am not able to burn DVDs.
Datum: 2021-11-26T12:45:47+0100
Von: "Thomas Schmitt" 
An: "999...@bugs.debian.org" <999...@bugs.debian.org>

Hi,

w_t...@t-online.de wrote:
> When I click the tiny icon beside "DVD-R sequential recording",
> the former grayed menus for speed and writing mode are now available.
> Then I can also
> start the writing  process, and it does not go to max speed and completes
> successfully.

So - with the necessary black magic - it is possible to use Xfburn
for your purpose with your drive.

Insofar this is a success. {:)

> This is all very confusing.

I agree. Desktops like XFCE, GNOME, or KDE and their applications bring
my blood pressure up to unhealthy levels every time i have use them.
(As a good classic Linuxer i use fvwm2 as window manager with a config
file that essentially stems from a 20 year old SuSE installation.)

> I have no clue what's going on here, and I am so
> sorry for bothering you with that.

No need to apologize. If i would not be interested i could just have
staid away from this bug report.
Given the lack of any active GUI developers for optical disc burning,
i have to check out the user problems with those programs in order to
distinguish their own problems from potential problems in libburn or in
my command line programs.

Any normal desktop user is more qualified than me to operate Xfburn,
Brasero, or K3B. So i cannot help with talking one of them into doing
what the user wants. At best i can lookup error messages in their code
and follow the traces to a burner problem for which i have knowledge.

But especially with K3B's C++ spaghetti code i have big difficulties
to understand. Program execution tends to vanish in a fog of class
inheritance and function overloading. Often it is hard to find the code
part which does the actual work of talking to the drive or to the burn
program.

I will next dig out the instructions how to attribute this bug report
to the Debian package K3B, because you report a reproducible K3B problem
with the upgrade from Debian 10 to Debian 11.
(I don't hold a Debian rank. But any amateur is allowed to operate the
bug tracking system by mail messages. See:
  https://www.debian.org/Bugs/server-control
)

Have a nice day :)

Thomas

1 2 >

1 - 100 of 121 matches

Mail list logo