date:20220802

Package: ftp.debian.org
Severity: normal

No autoremoval due to different architecture list.

Bug#1016567: python3-wtforms: missing compiled message files

2022-08-02 Thread Joseph Nahmias

Package: python3-wtforms
Version: 2.2.1-1
Severity: normal
X-Debbugs-Cc: j...@nahmias.net

Hello,

It seems that the wtforms.mo compiled gettext message catalogs are no
longer being generated and distributed in the python3-wtforms package.
They do exist in 2.1-1 (stretch). This causes an issue if a python
program which uses wtforms tries to respect the declared locale. For
example, I see the following error in the wtforms-alchemy testsuite:

 TestModelFormFactory.test_class_meta_wtforms2 _

self = 

def test_class_meta_wtforms2(self):
if LooseVersion(wtforms.__version__) < LooseVersion('2'):
return  # skip test for wtforms < 2

self.init()

class SomeForm(Form):
class Meta:
locales = ['fr']
foo = 9

class OtherForm(SomeForm):
class Meta:
pass

class TestCustomBase(model_form_factory(SomeForm)):
class Meta:
model = self.ModelTest

>   form = TestCustomBase()

tests/test_model_form_factory.py:112: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
/usr/lib/python3/dist-packages/wtforms/form.py:212: in __call__
return type.__call__(cls, *args, **kwargs)
wtforms_alchemy/__init__.py:290: in __init__
super(ModelForm, self).__init__(*args, **kwargs)
/usr/lib/python3/dist-packages/wtforms/form.py:272: in __init__
super(Form, self).__init__(self._unbound_fields, meta=meta_obj, 
prefix=prefix)
/usr/lib/python3/dist-packages/wtforms/form.py:44: in __init__
translations = self._get_translations()
/usr/lib/python3/dist-packages/wtforms/form.py:85: in _get_translations
return self.meta.get_translations(self)
/usr/lib/python3/dist-packages/wtforms/meta.py:108: in get_translations
translations = self.translations_cache[locales] = 
i18n.get_translations(locales)
/usr/lib/python3/dist-packages/wtforms/i18n.py:37: in get_translations
translations = getter(languages)
/usr/lib/python3/dist-packages/wtforms/i18n.py:25: in 
get_builtin_gnu_translations
return gettext.translation('wtforms', messages_path(), languages)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

domain = 'wtforms', localedir = '/usr/lib/python3/dist-packages/wtforms/locale'
languages = ('fr',), class_ = 
fallback = False, codeset = ['unspecified']

def translation(domain, localedir=None, languages=None,
class_=None, fallback=False, codeset=_unspecified):
if class_ is None:
class_ = GNUTranslations
mofiles = find(domain, localedir, languages, all=True)
if not mofiles:
if fallback:
return NullTranslations()
from errno import ENOENT
>   raise FileNotFoundError(ENOENT,
'No translation file found for domain', 
domain)
E   FileNotFoundError: [Errno 2] No translation file found for domain: 
'wtforms'

/usr/lib/python3.10/gettext.py:607: FileNotFoundError


Please add this back into the package.
Thanks,
--Joe

Bug#1013228: python-werkzeug: Please keep version < 2.1

2022-08-02 Thread Emmanuel Arias


Hi,

I was going to open a wishlist bug to package the new upstream release, 
because new upstream release of python-flask-jwt-extended (4.4.3) fails 
two tests:


=== FAILURES 
===
__ test_add_context_processor 
__


app = 

    def test_add_context_processor(app):
    jwt_manager = JWTManager(app, add_context_processor=True)

    @jwt_manager.user_lookup_loader
    def user_lookup_callback(_jwt_header, _jwt_data):
    return "test_user"

    test_client = app.test_client()

    with app.test_request_context():
    access_token = create_access_token("username")

    access_headers = {"Authorization": "Bearer 
{}".format(access_token)}
    response = test_client.get("/context_current_user", 
headers=access_headers)

>   assert response.text == "test_user"
E   AttributeError: 'WrapperTestResponse' object has no attribute 'text'

tests/test_add_context_processor.py:37: AttributeError

The 'text' property was added in version 2.1.


Cheers,

--
Emmanuel Arias
@eamanu
yaerobi.com



OpenPGP_0xFA9DEC5DE11C63F1.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016566: libdap FTBFS on 32bit

Source: libdap
Version: 3.20.10-1
Severity: serious
Tags: ftbfs patch fixed-upstream
Forwarded: https://github.com/OPENDAP/libdap4/pull/192

https://buildd.debian.org/status/logs.php?pkg=libdap=3.20.10-1

...
HTTPCache.cc: In member function ‘void libdap::HTTPCache::read_metadata(const 
std::string&, std::vector >&)’:
HTTPCache.cc:1034:17: error: no matching function for call to ‘min(const long 
unsigned int&, size_t)’
 1034 | line[min(line_buf_len, strnlen(line, line_buf_len))-1] = '\0'; 
// erase newline
  |  ~~~^~~
...

Bug#1016565: liblibrecast0.5: Missing Breaks+Replaces headers against liblibrecast0.4: trying to overwrite '/usr/share/man/man3/lc_ctx_new.3.gz', which is also in package liblibrecast0.4:amd64 0.4.5-1

2022-08-02 Thread Axel Beckert

Package: liblibrecast0.5
Severity: serious
Version: 0.5.1-1
Control: affects -1 lcsync

lcsync fails to upgrade due to this issue:

Unpacking liblibrecast0.5:amd64 (0.5.1-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/liblibrecast0.5_0.5.1-1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/man/man3/lc_ctx_new.3.gz', which is also in 
package liblibrecast0.4:amd64 0.4.5-1
Errors were encountered while processing:
 /var/cache/apt/archives/liblibrecast0.5_0.5.1-1_amd64.deb

There seem to be Breaks and Replaces headers missing for moving this and
potentially further files from liblibrecast0.4 to liblibrecast0.5.

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

Kernel: Linux 5.18.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Bug#1016534: Bug #1016534: osk-sdl: "failed to open iris" cannot use it

2022-08-02 Thread Benjamin Moody

I noticed this too, although on my system (Intel HD Graphics 5300) it
seems to work with or without iris_dri.so.  However, I also needed to
patch SDL, because SDL's hardcoded pixel format (DRM_FORMAT_ARGB)
is not supported.

I also noticed that it would be better to use 'dri_inst' here instead
of 'copy_exec'; on amd64 just as on arm64, there are many *_dri.so
files that are duplicates (hard links, actually.)

Bug#864423: Software RAID is not activated at boot time

Hi,

* Holger Wansing  [220802 23:37]:
> Cyril Brulebois  wrote (Sun, 31 Jul 2022 14:31:20 +0200):
> > > I was digging around in the d-i code, and it appears for dmraid to
> > > be invoked, one has to boot with disk-detect/dmraid/enable. 
> > > 
> > > I have opened merge requests to remove the dmraid/sataraid code from
> > > d-i. The changes look like low risk to me, but obviously I have no
> > > idea. For the lack of a build environment I also didn't test them.
> > > 
> > > Given d-i does nothing with dmraid unless the boot flag is present,
> > > I want to ask if dmraid could also stop shipping its udeb, if thats
> > > ok with debian-boot?
> > 
> > Given how specific it is, opt-in, on a specific arch, and dead upstream,
> > looks like a wholesale removal would be the best way forward, yes.
> 
> I have merged the merge requests filed by Chris (partman-base, partman-auto,
> hw-detect, grub-installer).
> 
> The packages build fine with those changings.
> And a locally built mini.iso with those changings in local udebs also 
> installs fine (default install) in QEMU VM.

Great, thanks for testing!

Maybe these changes can make it into unstable soon?

I'm attaching a draft patch to drop udebs from src:dmraid. Maybe you
want to use this as a starting point, László?

I would also suggest keeping dmraid for one more release, and
putting something into the release notes. To keep dmraid, I think
the severity of this bug also might need adjusting, or something.

Thanks everyone for your helping hands.

Best,
Chris

diff -Nru dmraid-1.0.0.rc16/debian/changelog dmraid-1.0.0.rc16/debian/changelog
--- dmraid-1.0.0.rc16/debian/changelog  2022-02-16 16:44:50.0 +
+++ dmraid-1.0.0.rc16/debian/changelog  2022-08-02 23:30:56.0 +
@@ -1,3 +1,10 @@
+dmraid (1.0.0.rc16-11.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop udebs. 
+
+ -- Chris Hofstaedtler   Tue, 02 Aug 2022 23:30:56 +
+
 dmraid (1.0.0.rc16-11) unstable; urgency=medium
 
   [ Helmut Grohne  ]
diff -Nru dmraid-1.0.0.rc16/debian/control dmraid-1.0.0.rc16/debian/control
--- dmraid-1.0.0.rc16/debian/control2022-02-16 16:44:50.0 +
+++ dmraid-1.0.0.rc16/debian/control2022-08-02 23:30:56.0 +
@@ -28,28 +28,6 @@
  Please read the documentation in /usr/share/doc/dmraid BEFORE attempting
  any use of this software. Improper use can cause data loss!
 
-Package: dmraid-udeb
-Architecture: linux-any
-Section: debian-installer
-Package-Type: udeb
-Depends: ${shlibs:Depends}, dmsetup-udeb
-Description: Device-Mapper Software RAID support tool (udeb)
- dmraid discovers, activates, deactivates and displays properties
- of software RAID sets (eg, ATARAID) and contained DOS partitions.
- .
- This is the minimal package (udeb) used by debian-installer
-
-Package: libdmraid1.0.0.rc16-udeb
-Architecture: linux-any
-Section: debian-installer
-Package-Type: udeb
-Depends: ${shlibs:Depends}
-Description: Device-Mapper Software RAID support tool - shared library (udeb)
- dmraid discovers, activates, deactivates and displays properties
- of software RAID sets (eg, ATARAID) and contained DOS partitions.
- .
- This is the minimal package (udeb shared library) used by debian-installer
-
 Package: libdmraid1.0.0.rc16
 Architecture: linux-any
 Multi-Arch: same
diff -Nru dmraid-1.0.0.rc16/debian/dmraid.install 
dmraid-1.0.0.rc16/debian/dmraid.install
--- dmraid-1.0.0.rc16/debian/dmraid.install 2017-08-30 21:28:37.0 
+
+++ dmraid-1.0.0.rc16/debian/dmraid.install 2022-08-02 23:30:56.0 
+
@@ -1,5 +1,5 @@
 debian/initramfs/dmraid.initramfs-hook/dmraid usr/share/initramfs-tools/hooks
 debian/initramfs/dmraid.initramfs-local-top/dmraid 
usr/share/initramfs-tools/scripts/local-top
-debian/standard/sbin/dmraid sbin
-debian/standard/usr/share/man usr/share
+debian/tmp/sbin/dmraid sbin
+debian/tmp/usr/share/man usr/share
 debian/dmraid-activate sbin
diff -Nru dmraid-1.0.0.rc16/debian/dmraid-udeb.install 
dmraid-1.0.0.rc16/debian/dmraid-udeb.install
--- dmraid-1.0.0.rc16/debian/dmraid-udeb.install2017-08-30 
21:28:37.0 +
+++ dmraid-1.0.0.rc16/debian/dmraid-udeb.install1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-debian/udeb/sbin/dmraid sbin
-debian/dmraid-activate sbin
diff -Nru dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install 
dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install
--- dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install2022-02-03 
16:28:13.0 +
+++ dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16.install2022-08-02 
23:30:56.0 +
@@ -1,2 +1,2 @@
 #!/usr/bin/dh-exec
-debian/standard/lib/${DEB_HOST_MULTIARCH}/*.so.* lib/${DEB_HOST_MULTIARCH}
+debian/tmp/lib/${DEB_HOST_MULTIARCH}/*.so.* lib/${DEB_HOST_MULTIARCH}
diff -Nru dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16-udeb.install 
dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16-udeb.install
--- dmraid-1.0.0.rc16/debian/libdmraid1.0.0.rc16-udeb.install   2022-02-03

Bug#1016561: sysvinit-core: Please recommend systemd-tmpfiles and systemd-tmpfiles

2022-08-02 Thread Thorsten Glaser

On Wed, 3 Aug 2022, Adam Borowski wrote:

> On Wed, Aug 03, 2022 at 12:04:29AM +0200, GSR wrote:

> > Otherwise in cases like upgrading lvm2 (see bug #1014565) the full

This is weird, but I looked at how debootstrap resolves dependencies,
and this is indeed a problem. Did anyone look at whether adding the
systemd-standalone-tmpfiles package to the list of dependencies, instead
of relying on the virtual package, helps?

> Sysvinit is often installed in small containers, and I would be wary of
> bloating them by 460KB with gratuitous dependences.

It’d be a Recommends. Power users have been annoyed since squeeze
enabled the installation of Recommends by default and have been
disabling it ever since :|

> > systemd is installed unnecessarily.

My guess is you don’t have systemd pinned away.

$ cat /etc/apt/preferences.d/systemd 
Package: systemd
Pin: version *
Pin-Priority: -1

Does it still want to install systemd with this enabled? (If so, apt
bug.) Does it successfully resolve this to systemd-standalone-tmpfiles
instead of exploding and refusing to do anything? (I don’t have a
suitably up-to-date sid system handy.)

Given how Debian currently treats nōn-systemd users I think asking
them to run with such a pinning (and not annoying maintainers so
much that they remove the standalone packages altogether) might be
sensible :/

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

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

Bug#1016561: sysvinit-core: Please recommend systemd-tmpfiles and systemd-tmpfiles

2022-08-02 Thread Adam Borowski

On Wed, Aug 03, 2022 at 12:04:29AM +0200, GSR wrote:
> The package already "Recommends: orphan-sysvinit-scripts", in same
> fashion it could recommend systemd-tmpfiles and systemd-tmpfiles (or
> the packages that provide those, systemd-standalone-tmpfiles and
> systemd-standalone-sysusers, whatever follows Debian policy better).
> Otherwise in cases like upgrading lvm2 (see bug #1014565) the full
> systemd is installed unnecessarily.

That's a bug in the dependency that pulls in systemd.

Sysvinit is often installed in small containers, and I would be wary of
bloating them by 460KB with gratuitous dependences.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Say what you want about Adolf, at least he was the man who
⢿⡄⠘⠷⠚⠋⠀ killed Hitler.  Your turn, Vlad!
⠈⠳⣄

Bug#1016564: haskell-cracknum FTBFS: Package contains no library to register: crackNum-3.2

Source: haskell-cracknum
Version: 3.2-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/logs.php?pkg=haskell-cracknum=3.2-1

...
Running debian/hlibrary.setup copy --builddir=dist-ghc 
--destdir=debian/tmp-inst-ghc
Installing executable crackNum in debian/tmp-inst-ghc/usr/bin
ln --symbolic --force "debian/tmp-inst-ghc" debian/tmp
dh_haskell_install_ghc_registration --package=libghc-cracknum-dev
Running debian/hlibrary.setup register --builddir=dist-ghc --gen-pkg-config 
--verbose=verbose+nowrap
Package contains no library to register: crackNum-3.2...
Cannot generate package registration. at 
/usr/bin/dh_haskell_install_ghc_registration line 70.
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:194: 
install/libghc-cracknum-dev] Error 25

Bug#1004770: octave-video: Use this patch instead

2022-08-02 Thread William 'jawn-smith' Wilson

Package: octave-video
Followup-For: Bug #1004770
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

The first patch I submitted was a bit messy and failed to build
with older versions of ffmpeg. A version with this patch has
built successfully for me in Ubuntu kinetic and Debian sid.

In Ubuntu, the attached patch was applied to achieve the following:


  * d/patches/ffmpeg5.patch: Update to FFMPEG 5 API.


Thanks for considering the patch.


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

Kernel: Linux 5.15.0-27-generic (SMP w/32 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
diff -Nru octave-video-2.0.2/debian/control octave-video-2.0.2/debian/control
--- octave-video-2.0.2/debian/control   2022-07-19 08:01:01.0 -0500
+++ octave-video-2.0.2/debian/control   2022-08-02 15:58:29.0 -0500
@@ -1,8 +1,7 @@
 Source: octave-video
 Section: math
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Octave Group 

+Maintainer: Debian Octave Group 
 Uploaders: Rafael Laboissière 
 Build-Depends: debhelper-compat (= 13),
dh-octave (>= 0.7.1),
diff -Nru octave-video-2.0.2/debian/patches/ffmpeg5.patch 
octave-video-2.0.2/debian/patches/ffmpeg5.patch
--- octave-video-2.0.2/debian/patches/ffmpeg5.patch 1969-12-31 
18:00:00.0 -0600
+++ octave-video-2.0.2/debian/patches/ffmpeg5.patch 2022-08-02 
15:58:29.0 -0500
@@ -0,0 +1,568 @@
+Description: Fix FTBFS with ffmpeg 5
+Author: William 'jawn-smith' Wilson 
+Origin: Ubuntu
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1004770
+Last-Update: 2022-08-02
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+Index: octave-video-2.0.2/src/cap_ffmpeg_impl_ov.hpp
+===
+--- octave-video-2.0.2.orig/src/cap_ffmpeg_impl_ov.hpp
 octave-video-2.0.2/src/cap_ffmpeg_impl_ov.hpp
+@@ -525,7 +525,9 @@
+ 
+ const char* get_video_codec_name () const
+   {
+-#if LIBAVFORMAT_BUILD > 4628
++#if LIBAVFORMAT_BUILD > 6027
++return _opencv_avcodec_get_name(video_st->codecpar->codec_id);
++#elif LIBAVFORMAT_BUILD > 4628
+ return _opencv_avcodec_get_name(video_st->codec->codec_id);
+ #else
+ return _opencv_avcodec_get_name(video_st->codec.codec_id);
+@@ -604,7 +606,9 @@
+ 
+ void CvCapture_FFMPEG::init()
+ {
++#if LIBAVFORMAT_BUILD < CALC_FFMPEG_VERSION(59, 0, 0)
+ av_register_all();
++#endif
+ ic = 0;
+ video_stream = -1;
+ video_st = 0;
+@@ -651,7 +655,10 @@
+ 
+ if( video_st )
+ {
+-#if LIBAVFORMAT_BUILD > 4628
++#if LIBAVFORMAT_BUILD > 6027
++AVCodecContext *context;
++avcodec_parameters_to_context(context, video_st->codecpar);
++#elif LIBAVFORMAT_BUILD > 4628
+ avcodec_close( video_st->codec );
+ 
+ #else
+@@ -842,6 +849,7 @@
+ 
+ static ImplMutex _mutex;
+ 
++#if LIBAVFORMAT_BUILD < CALC_FFMPEG_VERSION(59, 0, 0)
+ static int LockCallBack(void **mutex, AVLockOp op)
+ {
+ ImplMutex* localMutex = reinterpret_cast(*mutex);
+@@ -872,6 +880,7 @@
+ }
+ return 0;
+ }
++#endif
+ 
+ 
+ static void ffmpeg_log_callback(void *ptr, int level, const char *fmt, 
va_list vargs)
+@@ -900,11 +909,13 @@
+ avformat_network_init();
+ #endif
+ 
++#if LIBAVFORMAT_BUILD < CALC_FFMPEG_VERSION(59, 0, 0)
+ /* register all codecs, demux and protocols */
+ av_register_all();
+ 
+ /* register a callback function for synchronization */
+ av_lockmgr_register();
++#endif
+ 
+ #ifndef NO_GETENV
+ char* debug_option = getenv("OPENCV_FFMPEG_DEBUG");
+@@ -919,10 +930,12 @@
+ av_log_set_level(AV_LOG_ERROR);
+ }
+ }
++#if LIBAVFORMAT_BUILD < CALC_FFMPEG_VERSION(59, 0, 0)
+ ~InternalFFMpegRegister()
+ {
+ av_lockmgr_register(NULL);
+ }
++#endif
+ };
+ 
+ bool CvCapture_FFMPEG::open( const char* _filename )
+@@ -962,6 +975,9 @@
+ #else
+ av_dict_set(, "rtsp_transport", "tcp", 0);
+ #endif
++#if LIBAVFORMAT_BUILD > CALC_FFMPEG_VERSION(59, 0, 0)
++const
++#endif
+ AVInputFormat* input_format = NULL;
+ AVDictionaryEntry* entry = av_dict_get(dict, "input_format", NULL, 0);
+ if (entry != 0)
+@@ -993,7 +1009,10 @@
+ }
+ for(i = 0; i < ic->nb_streams; i++)
+ {
+-#if LIBAVFORMAT_BUILD > 4628
++#if LIBAVFORMAT_BUILD >= CALC_FFMPEG_VERSION(59, 0, 0)
++AVCodecContext *enc;
++avcodec_parameters_to_context(enc, ic->streams[i]->codecpar);
++#elif LIBAVFORMAT_BUILD > 4628
+ AVCodecContext *enc =

Bug#1016538: systemd-boot: Kernel postinst and initramfs post-update hooks copy initrd twice

2022-08-02 Thread Michael Biebl

Am 02.08.22 um 21:17 schrieb Victor Westerhuis:

On Tue, 2 Aug 2022 20:46:55 +0200 Michael Biebl  wrote:

Am 02.08.22 um 18:20 schrieb Victor Westerhuis:
  > Package: systemd-boot
  > Version: 251.3-1
  > Severity: normal
  >

Both /etc/kernel/postinst.d/systemd-boot and 
/etc/initramfs/post-update.d/systemd-boot
call kernel-install to add a newly installed kernel. However, the initramfs hook
explicitly passes the initrd filename, leading to the initrd being copied to 
the EFI
partition twice.

Duplicate of #1016538 basically.

Ideas how to fix this welcome.

This bug is #1016538. What bug is this one a duplicate of?

C failure, I meant #1014455

OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016563: debhelper: Should dh_dwz be dropped?

Package: debhelper
Version: 13.8
Severity: serious
X-Debbugs-Cc: debian-de...@lists.debian.org

[ debian-devel is in Cc for getting further input. ]

dh_dwz is part of the standard sequence in dh since debhelper compat 12.

dwz offers small optimizations of debug info, the typical benefit
seems to be ~ 3% size reduction.

These optimizations are only in the -dbgsym packages that nearly
noone installs and nearly noone uses.

Debug info is super useful when needed, but it is not installed by
default and dwz optimizations have little practical relevance in the
cases when it is used.

OTOH, the cases where dh_dwz has created additional work for maintainers
are many.[1]

dwz is processing debug info from several producers on many architectures,
and this sometimes breaks in various ways.

On arm64, gcc in stable sometime produces debug info that dwz in
stable cannot handle.[2]

C++ code can result in huge debuginfo, resulting in dwz exhausting
the address space on 32bit architectures, requiring workarounds from
maintainers.[3]

clang 14 which is now default in instable defaults to DWARF 5,
and dwz in unstable has some problems with that.[4,5]

Scroll through [1] for more workarounds for problems in dwz.

The track record of such bugs in dwz getting fixed swiftly is not good.
This is a real problem if dwz is a core toolchain tool most packages
are using by default, and usually maintainers are forced to use
override_dh_dwz whenever dwz chokes on what it is supposed to process.

IMHO the small benefits of dh_dwz are not worth the constant extra work
it causes, and it should be dropped from the standard sequence in dh.

Dropping dh_dwz from the standard sequence in dh could also be done
in the compat levels 12 and 13 since such a change should not cause
user-visible changes (except for a slight size increase of -dbgsym)

Ignoring errors from dh_dwz by default might work if we can trust
that dwz does not touch the file in case of errors, but it feels
wrong to ignore errors.


[1] https://codesearch.debian.net/search?q=override_dh_dwz=1
[2] 
https://sources.debian.org/src/qt6-base/6.2.4%2Bdfsg-10~bpo11%2B1/debian/rules/#L97
[3] https://sources.debian.org/src/qtcreator/8.0.0-2/debian/rules/#L66
[4] https://bugs.debian.org/1016329
[5] https://bugs.debian.org/1016330

Bug#1016562: fp-compiler-3.2.0: Fails to setup during install due to "Invalid floating point operation"

2022-08-02 Thread Graham Ollis

Package: fp-compiler-3.2.0
Version: 3.2.0+dfsg-12
Severity: important
X-Debbugs-Cc: plice...@cpan.org

Dear Maintainer,

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

   * What led up to the situation?

I was trying to install the Free Pascal Compiler on Debian 11 running under 
VMware Fusion on an Mac
with an M2 processor.  I tried to install using `sudo apt-get install fpc`.  
The error that I got
during install was:

sandy% sudo apt-get install fpc
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  fp-compiler-3.2.0 fpc-3.2.0
Suggested packages:
  lazarus
The following NEW packages will be installed:
  fp-compiler-3.2.0 fpc fpc-3.2.0
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/1,979 kB of archives.
After this operation, 12.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Preconfiguring packages ...
Selecting previously unselected package fp-compiler-3.2.0:arm64.
(Reading database ... 274284 files and directories currently installed.)
Preparing to unpack .../fp-compiler-3.2.0_3.2.0+dfsg-12_arm64.deb ...
Unpacking fp-compiler-3.2.0:arm64 (3.2.0+dfsg-12) ...
Selecting previously unselected package fpc-3.2.0.
Preparing to unpack .../fpc-3.2.0_3.2.0+dfsg-12_all.deb ...
Unpacking fpc-3.2.0 (3.2.0+dfsg-12) ...
Selecting previously unselected package fpc.
Preparing to unpack .../fpc_3.2.0+dfsg-12_all.deb ...
Unpacking fpc (3.2.0+dfsg-12) ...
Setting up fp-compiler-3.2.0:arm64 (3.2.0+dfsg-12) ...
An unhandled exception occurred at $00470960:
EInvalidOp: Invalid floating point operation
  $00470960
  $00472FC0
  $00472F04
  $00470FA8
  $00400EEC
  $00402ACC
  $9ACA0218
  $00400668

dpkg: error processing package fp-compiler-3.2.0:arm64 (--configure):
 installed fp-compiler-3.2.0:arm64 package post-installation script subprocess 
returned error exit status 217
dpkg: dependency problems prevent configuration of fpc-3.2.0:
 fpc-3.2.0 depends on fp-compiler-3.2.0 (>= 3.2.0+dfsg-12); however:
  Package fp-compiler-3.2.0:arm64 is not configured yet.

dpkg: error processing package fpc-3.2.0 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of fpc:
 fpc depends on fpc-3.2.0 (= 3.2.0+dfsg-12); however:
  Package fpc-3.2.0 is not configured yet.

dpkg: error processing package fpc (--configure):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.9.4-2) ...
Errors were encountered while processing:
 fp-compiler-3.2.0:arm64
 fpc-3.2.0
 fpc
E: Sub-process /usr/bin/dpkg returned an error code (1)


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.10.0-16-arm64 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fp-compiler-3.2.0 depends on:
ii  binutils   2.35.2-2
ii  debconf [debconf-2.0]  1.5.77
ii  fp-units-rtl-3.2.0 3.2.0+dfsg-12
ii  libc6  2.31-13+deb11u3

Versions of packages fp-compiler-3.2.0 recommends:
ii  fp-utils-3.2.0  3.2.0+dfsg-12

Versions of packages fp-compiler-3.2.0 suggests:
ii  fp-docs-3.2.0  3.2.0+dfsg-12

-- debconf information:
  fp-compiler/rename_cfg: true
  fp-compiler/windres-select: Select manually
  fp-compiler/windres:

Bug#1016561: sysvinit-core: Please recommend systemd-tmpfiles and systemd-tmpfiles

2022-08-02 Thread GSR

Package: sysvinit-core
Version: 3.03-1
Severity: normal

Hi:

The package already "Recommends: orphan-sysvinit-scripts", in same
fashion it could recommend systemd-tmpfiles and systemd-tmpfiles (or
the packages that provide those, systemd-standalone-tmpfiles and
systemd-standalone-sysusers, whatever follows Debian policy better).
Otherwise in cases like upgrading lvm2 (see bug #1014565) the full
systemd is installed unnecessarily.

Cheers,
GSR
 

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

Kernel: Linux 5.17.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages sysvinit-core depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  initscripts3.03-1
ii  libc6  2.33-8
ii  libselinux13.3-1+b1
ii  mount  2.38-6
ii  sysv-rc3.03-1
ii  sysvinit-utils 3.03-1

Versions of packages sysvinit-core recommends:
ii  orphan-sysvinit-scripts  0.11

Versions of packages sysvinit-core suggests:
pn  bootlogd  

-- debconf information:
  sysvinit/hurd-fix-inittab:

Bug#1016560: glibc 2.34 breaks scalpel autopkgtest on amd64: bash: line 1: 1961 Segmentation fault

Source: scalpel
Version: 1.60-9
Severity: important
Tags: upstream patch
User: debian-gl...@lists.debian.org
Usertags: glibc2.34

Dear maintainer,

The autopkgtest of scalpel fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

 passfail
glibcfrom sid2.34-0experimental5
scalpel  from sid1.60-9
all others   from sidfrom sid

Here is the relevant part of the test log:

autopkgtest [10:36:40]: test command1: scalpel -c debian/tests/scalpel.conf 
debian/tests/lua.img
autopkgtest [10:36:40]: test command1: [---

Opening target 
"/tmp/autopkgtest-lxc.93yq46zi/downtmp/build.fXk/src/debian/tests/lua.img"

bash: line 1:  1961 Segmentation fault  bash -ec 'scalpel -c 
debian/tests/scalpel.conf debian/tests/lua.img' 2> >(tee -a 
/tmp/autopkgtest-lxc.93yq46zi/downtmp/command1-stderr >&2) > >(tee -a 
/tmp/autopkgtest-lxc.93yq46zi/downtmp/command1-stdout)

The full test log is available there:
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scalpel/24235565/log.gz

After some debugging, I have found the issue to be a duplicate use of a
va_list without using va_copy. Please find attached a patch to fix that.

Regards
Aurelien
--- scalpel-1.60.orig/helpers.c
+++ scalpel-1.60/helpers.c
@@ -70,12 +70,14 @@ void setProgramName(char *s) {
 // write entry to both the screen and the audit file 
 void scalpelLog(struct scalpelState *state, char *format, ...) {
 
-  va_list argp;
+  va_list argp, argp2;
 
   va_start(argp,format);
+  va_copy(argp2, argp);
   vfprintf (stderr,format,argp);
-  vfprintf (state->auditFile,format,argp);
   va_end(argp);
+  vfprintf (state->auditFile,format,argp2);
+  va_end(argp2);
 }
 
 // determine if two characters match, with optional case

Bug#1016559: RFP: osmscoutserver -- Maps server providing tiles, geocoder, and router

2022-08-02 Thread Martin

Package: wnpp
Severity: wishlist

* Package name: osmscoutserver
  Version : 2.2.1
  Upstream Author : Rinigus https://github.com/rinigus
* URL : https://github.com/rinigus/osmscout-server
* License : GPL-3+
  Programming Lang: C++
  Description : Maps server providing tiles, geocoder, and router

OSM Scout Server can be used as a drop-in replacement for online map
services providing map tiles, search, and routing. As a result, an
offline operation is possible if the device has a server and map client
programs installed and running. OSM Scout Server is mainly developed for
Sailfish OS, but could be used on a regular Linux system as a console or
QtQuick application.

Bug#1016558: O: muse-el

2022-08-02 Thread Nicholas D Steeves

Package: wnpp
Severity: normal
X-Debbugs-Cc: Debian Emacsen team , Leo Butler 

Control: affects -1 src:muse-el

Muse-el has been kept in good shape for five years, but I now lack
sufficient time/interest to solve RC bug #1016335, so it's clear that
I should step aside and let someone else take care of the package.  In
that bug, QuickStart.pdf is no longer generated from QuickStart.muse,
so yes, it seems like an important one that will affect the 100 or
more users of this package.  I'm guessing a recent change in texinfo
caused the regression.

Muse-el is currently maintained by the Debian Emacsen Team, and the
new maintainer may wish to keep it under team maintenance, so here
are convenience links to begin work immediately:

  Writeable remote: g...@salsa.debian.org:emacsen-team/muse-el.git
  Vcs-Git: https://salsa.debian.org/emacsen-team/muse-el.git
  Vcs-Browser: https://salsa.debian.org/emacsen-team/muse-el
  Homepage: https://www.gnu.org/software/emacs-muse/index.html

This was the first package I adopted, and I think it was probably the
first one I was granted DM for; as often happens, workflows and tastes
change, I haven't used muse-el for a while, and have been holding onto
it for sentimental reasons.

#1016335 will need to be resolved before February 2023 for muse-el to be part 
of Debian bookworm.


Regards,
Nicholas

Bug#1016557: xfonts-cronyx: Non-DFSG file

2022-08-02 Thread Joao Eriberto Mota Filho

Source: xfonts-cronyx
Version: 2.3.8
Severity: serious
Tags: upstream
Justification: Policy 2.2.1
X-Debbugs-Cc: eribe...@debian.org

The license for tryfont/ISO8859-5 says:

---
Copyright (c) 1991-1995 Unicode, Inc.  All Rights reserved.

This file is provided as-is by Unicode, Inc. (The Unicode Consortium).
No claims are made as to fitness for any particular purpose.  No
warranties of any kind are expressed or implied.  The recipient
agrees to determine applicability of information provided.  If this
file has been provided on magnetic media by Unicode, Inc., the sole
remedy for any claim will be exchange of defective media within 90
days of receipt.

Recipient is granted the right to make copies in any form for
internal distribution and to freely use the information supplied
in the creation of products supporting Unicode.  Unicode, Inc.
specifically excludes the right to re-distribute this file directly
to third parties or other organizations whether for profit or not.
---

Eriberto

Bug#1016556: fpc: glibc 2.34 breaks fpc autopkgtest on arm64: undefined reference to `__libc_csu_init'

Source: fpc
Version: 3.2.2+dfsg-10
Severity: important
Tags: patch
User: debian-gl...@lists.debian.org
Usertags: glibc2.34

Dear maintainer,

The autopkgtest of fpc fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

 passfail
glibcfrom sid2.34-0experimental5
fpc  from sid3.2.2+dfsg-10
all others   from sidfrom sid

Here is the relevant part of the test log:

/usr/bin/ppca64 fpmake.pp -n -Fu../../rtl/units/aarch64-linux 
-Fu../../packages/paszlib -Fu../../packages/fcl-process -Fu../../packages/hash 
-Fu../../packages/libtar -Fu../../packages/fpmkunit/units_bs/aarch64-linux  
@/tmp/autopkgtest-lxc.pdlnszmr/downtmp/build.u8l/src/debian/deb-build-fpc.cfg
/usr/bin/ld.bfd: 
/tmp/autopkgtest-lxc.pdlnszmr/downtmp/build.u8l/src/fpcsrc/rtl/units/aarch64-linux/cprt0.o:
 in function `_start':
(.text+0x54): undefined reference to `__libc_csu_init'
/usr/bin/ld.bfd: (.text+0x58): undefined reference to `__libc_csu_init'
/usr/bin/ld.bfd: (.text+0x5c): undefined reference to `__libc_csu_fini'
/usr/bin/ld.bfd: (.text+0x60): undefined reference to `__libc_csu_fini'
fpmake.pp(258) Error: Error while linking
fpmake.pp(258) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted

The full test log is available there:
https://ci.debian.net/data/autopkgtest/unstable/arm64/f/fpc/24224856/log.gz

It seems that the startup code has to be adjusted for glibc 2.34, Ubuntu
has a patch available there:
https://patches.ubuntu.com/f/fpc/fpc_3.2.2+dfsg-11ubuntu1.patch

Regards
Aurelien

Bug#1016555: src:squeekboard: fails to migrate to testing for too long: FTBFS on ppc64el

2022-08-02 Thread Paul Gevers


Source: squeekboard
Version: 1.17.1-1
Severity: serious
Control: close -1 1.19.0-1
Tags: sid bookworm
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 1016396

Dear maintainer(s),

The Release Team considers packages that are out-of-sync between testing 
and unstable for more than 60 days as having a Release Critical bug in 
testing [1]. Your package src:squeekboard has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package fails to build 
from source on ppc64el, which was reported in bug #1016396.


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


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016554: dash: glibc 2.34 breaks dash autopkgtest on amd64: symbol lookup error

Package: dash
Version: 0.5.11+git20210903+057cd650a4ed-8
Severity: important
User: debian-gl...@lists.debian.org
Usertags: glibc2.34

Dear maintainer,

The autopkgtest of dash fails in sid on amd64 when that autopkgtest is
run with the binary packages of glibc from experimental. It passes when
run with only packages from sid. In tabular form:

 passfail
glibcfrom sid2.34-0experimental5
dash from sid0.5.11+git20210903+057cd650a4ed-8
all others   from sidfrom sid

The relevant part of the test log is the following

  env: symbol lookup error: 
/tmp/mmdebstrap.zcyyAwHdpW//lib/x86_64-linux-gnu/libc.so.6: undefined symbol: 
_dl_catch_error_ptr, version GLIBC_PRIVATE

The full test log is available there:
https://ci.debian.net/data/autopkgtest/unstable/amd64/d/dash/24221304/log.gz

It seems that fakechroot is mixing glibc from inside and outside of the
chroot, which have different GLIBC_PRIVATE symbols.

Regards
Aurelien

Bug#1004770: octave-video: FTBFS with ffmpeg 5.0

2022-08-02 Thread William 'jawn-smith' Wilson

Package: octave-video
Followup-For: Bug #1004770
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch
Control: tags -1 patch

Dear Maintainer,

As noted in this bug, octave-video FTBFS with ffmpeg 5. This patch
resolves that failure.

In Ubuntu, the attached patch was applied to achieve the following:

  * d/patches/ffmpeg5.patch: Update to FFMPEG 5 API.

Thanks for considering the patch.


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

Kernel: Linux 5.15.0-27-generic (SMP w/32 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
diff -Nru octave-video-2.0.2/debian/control octave-video-2.0.2/debian/control
--- octave-video-2.0.2/debian/control   2022-07-19 08:01:01.0 -0500
+++ octave-video-2.0.2/debian/control   2022-08-01 14:26:51.0 -0500
@@ -1,8 +1,7 @@
 Source: octave-video
 Section: math
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Octave Group 

+Maintainer: Debian Octave Group 
 Uploaders: Rafael Laboissière 
 Build-Depends: debhelper-compat (= 13),
dh-octave (>= 0.7.1),
diff -Nru octave-video-2.0.2/debian/patches/ffmpeg5.patch 
octave-video-2.0.2/debian/patches/ffmpeg5.patch
--- octave-video-2.0.2/debian/patches/ffmpeg5.patch 1969-12-31 
18:00:00.0 -0600
+++ octave-video-2.0.2/debian/patches/ffmpeg5.patch 2022-08-01 
14:26:51.0 -0500
@@ -0,0 +1,545 @@
+Index: octave-video-2.0.2/src/cap_ffmpeg_impl_ov.hpp
+===
+--- octave-video-2.0.2.orig/src/cap_ffmpeg_impl_ov.hpp
 octave-video-2.0.2/src/cap_ffmpeg_impl_ov.hpp
+@@ -110,6 +110,8 @@
+ #define CV_WARN(message) fprintf(stderr, "warning: %s (%s:%d)\n", message, 
__FILE__, __LINE__)
+ #endif
+ 
++#define FF_API_LOCKMGR 1
++
+ static int global_err;
+ 
+ std::string get_last_err_msg ()
+@@ -526,9 +528,9 @@
+ const char* get_video_codec_name () const
+   {
+ #if LIBAVFORMAT_BUILD > 4628
+-return _opencv_avcodec_get_name(video_st->codec->codec_id);
++return _opencv_avcodec_get_name(video_st->codecpar->codec_id);
+ #else
+-return _opencv_avcodec_get_name(video_st->codec.codec_id);
++return _opencv_avcodec_get_name(video_st->codecpar.codec_id);
+ #endif
+   }
+ 
+@@ -604,7 +606,6 @@
+ 
+ void CvCapture_FFMPEG::init()
+ {
+-av_register_all();
+ ic = 0;
+ video_stream = -1;
+ video_st = 0;
+@@ -651,11 +652,13 @@
+ 
+ if( video_st )
+ {
++AVCodecContext *codec;
++  avcodec_parameters_to_context(codec, video_st->codecpar);
+ #if LIBAVFORMAT_BUILD > 4628
+-avcodec_close( video_st->codec );
++avcodec_close( codec );
+ 
+ #else
+-avcodec_close( &(video_st->codec) );
++avcodec_close(  );
+ 
+ #endif
+ video_st = NULL;
+@@ -842,38 +845,6 @@
+ 
+ static ImplMutex _mutex;
+ 
+-static int LockCallBack(void **mutex, AVLockOp op)
+-{
+-ImplMutex* localMutex = reinterpret_cast(*mutex);
+-switch (op)
+-{
+-case AV_LOCK_CREATE:
+-localMutex = new ImplMutex();
+-if (!localMutex)
+-return 1;
+-*mutex = localMutex;
+-if (!*mutex)
+-return 1;
+-break;
+-
+-case AV_LOCK_OBTAIN:
+-localMutex->lock();
+-break;
+-
+-case AV_LOCK_RELEASE:
+-localMutex->unlock();
+-break;
+-
+-case AV_LOCK_DESTROY:
+-delete localMutex;
+-localMutex = NULL;
+-*mutex = NULL;
+-break;
+-}
+-return 0;
+-}
+-
+-
+ static void ffmpeg_log_callback(void *ptr, int level, const char *fmt, 
va_list vargs)
+ {
+ static bool skip_header = false;
+@@ -900,12 +871,6 @@
+ avformat_network_init();
+ #endif
+ 
+-/* register all codecs, demux and protocols */
+-av_register_all();
+-
+-/* register a callback function for synchronization */
+-av_lockmgr_register();
+-
+ #ifndef NO_GETENV
+ char* debug_option = getenv("OPENCV_FFMPEG_DEBUG");
+ if (debug_option != NULL)
+@@ -919,10 +884,6 @@
+ av_log_set_level(AV_LOG_ERROR);
+ }
+ }
+-~InternalFFMpegRegister()
+-{
+-av_lockmgr_register(NULL);
+-}
+ };
+ 
+ bool CvCapture_FFMPEG::open( const char* _filename )
+@@ -962,7 +923,7 @@
+ #else
+ av_dict_set(, "rtsp_transport", "tcp", 0);
+ #endif
+-AVInputFormat* input_format = NULL;
++const AVInputFormat* input_format = NULL;
+ AVDictionaryEntry* entry = av_dict_get(dict, "input_format", NULL, 0);
+ if (entry != 0)
+ {
+@@ -994,7 +955,8 @@

Bug#1016543: rsync: CVE-2022-29154

2022-08-02 Thread Salvatore Bonaccorso

Hi Samuel,

On Tue, Aug 02, 2022 at 09:30:07PM +0100, Samuel Henrique wrote:
> Hello Salvatore, thanks for reporting this.
> 
> I've been following the discussions around this during the day and I
> did notice there were multiple commits related to it indeed.
> 
> My take so far is that we should wait a bit before releasing the fix
> on unstable, as there might be regressions in the fix itself. There
> isn't even a proper release with the fix yet (only v3.2.5pre1). After
> confirming that there's no regressions in 3.2.5, then we can consider
> backporting it [0].
> 
> [0] That is, of course, just a suggestion, if someone from the
> Security team is willing to do all the investigative work to look out
> for regressions earlier, they're free to go ahead.

I agree, let's wait for 3.2.5 even for unstable. The issue is not that
urgent and when rsync'ing from an untrusted server, as described, it's
safest to copy into a dedicated destination directory for the remote
content.

Regards,
Salvatore

Bug#1016553: Recently (since early 2022?), broken terminal handling in LXC consoles (lxc-attach inside screen or tmux)

2022-08-02 Thread Andras Korn

Package: joe
Version: 4.6-1+b1
Severity: important

Hi,

as of recently, if I start screen (or tmux, doesn't seem to matter) on a Linux 
host, then use lxc-attach to enter a running LXC container, and start joe 
inside that container, the terminal behaves in a hard to describe, but 
completely broken way, making the editor essentially unusable.

Some examples:

1. Subsequent lines appear concatenated and then broken at an off-by-one 
location. A file that contains

<<<
#
# foo
>>>

would be rendered as

<<<
# [... spaces up to the end of the terminal line ... ] #
foo
>>>

CTRL-R has no apparent effect. Enabling syntax highlighting seems to make it 
worse (mangling more lines), but not always.

2. When typing, the cursor keeps jumping back to column 2 or 3, and the typed 
characters are hidden, as if they were off-screen to the left. Pressing CTRL-R 
fixes this problem temporarily. After pressing CTRL-R, pressing END (but not 
^E) repeatedly moves the cursor to somewhere around colum 40, but the column 
display in the upper right corner displays the correct position even after the 
first END press (or ^E press).

3. Similar to #2, but happens especially when editing a new file, or an empty 
line: instead of echoing the typed characters, either spaces echo, or the 
cursor stays at the leftmost position.

If you can suggest a way for me to record what I see on the screen and the keys 
I press concurrently, I suppose I can produce a "movie" of the breakage.

Other editors are unaffected (I tried vim, mcedit and nano).

I can't reproduce the problem without screen or tmux (ssh host, lxc-attach 
container, joe works).

I can't reproduce the problem if I start the container's joe binary by 
chrooting into the container's filesystem from the host.

I can't reproduce the problem if I ssh into the container instead of entering 
it via lxc-attach, not even if I subsequently start screen inside the container 
and joe inside screen.

I experimented with downgrading screen, ncurses, and joe itself, but either I 
wasn't systematic enough or it really didn't help.

I experimented with using different terminal applications to ssh into the LXC 
host (xterm, konsole), and it seemed to make no difference.

I *can* reproduce the problem by starting screen(1) locally, then ssh'ing into 
the LXC host, using lxc-attach, then starting joe inside the container.

screen(1) sets my TERM to screen.xterm-256color. Setting TERM to just "screen" 
apparently fixes problem #1 but not the others.

In tmux (whether started locally or on the LXC host doesn't matter), which sets 
TERM to "screen-256color", breakage #1 is less pronounced and slightly 
different: some lines are just visually missing their first character, but it's 
not rendered at the end of the previous line. The other two problems are just 
as in screen(1).

If I start tmux locally, then ssh into the LXC host and start screen there, 
TERM is set to just "screen" but after lxc-attach, problem #1 is present again.

As a demonstration, I opened a 150x47 terminal, reproduced problem #1, and used 
the X clipboard to copy and paste the contents of the window (with 
/etc/login.defs opened in joe) into this message below, disabling automatic 
line breaks:

--- 8< ---
IW   /etc/login.defs
 Row 45   Col 1   
 Enable display of unknown usernames when login failures are recorded.
#   
 # WARNING: 
Unknown usernames may become world readable. 
# See #290803 and #298773 for details about how this could become a security
# concern
LOG_UNKFAIL_ENABno

#   
 # Enable 
logging of successful logins
#   
 
LOG_OK_LOGINS   no

#   
 # Enable 
"syslog" logging of su activity - in addition to sulog file logging.
# SYSLOG_SG_ENAB does the same for newgrp and sg.
#   
 
SYSLOG_SU_ENAB  yes
SYSLOG_SG_ENAB  yes

#   
 # If 
defined, all su activity is logged to this file.
#

Bug#1016543: rsync: CVE-2022-29154

2022-08-02 Thread Samuel Henrique

Hello Salvatore, thanks for reporting this.

I've been following the discussions around this during the day and I
did notice there were multiple commits related to it indeed.

My take so far is that we should wait a bit before releasing the fix
on unstable, as there might be regressions in the fix itself. There
isn't even a proper release with the fix yet (only v3.2.5pre1). After
confirming that there's no regressions in 3.2.5, then we can consider
backporting it [0].

[0] That is, of course, just a suggestion, if someone from the
Security team is willing to do all the investigative work to look out
for regressions earlier, they're free to go ahead.

Thanks,

-- 
Samuel Henrique

Bug#1016546: rust-vergen inserts build timestamps

2022-08-02 Thread Maxime Devos


On 02-08-2022 20:41, Geert Stappers wrote:


Date: Tue, 2 Aug 2022 19:18:46 +0200, From: Maxime Devos

In Guix, I've noticed that rust-vergen embeds build timestamps. There is also
a work-around available: .
  


Thanks for reporting the FTBR.

Please update the workaround, so it looks more
like https://en.wikipedia.org/wiki/Diff#Unified_format
and can be absured by https://en.wikipedia.org/wiki/Patch_(Unix)


Just telling the filename that needs modification would be a great help.


Oops, I did not send the full work-around, here it is:


     (substitute* (find-files "." "\\.rs$")
       (("^extern crate chrono;") "extern crate chrono; use 
chrono::Utc; use chrono::TimeZone;")
       (("^use chrono::Utc;") "use chrono::Utc; use 
chrono::TimeZone;")

       (("\\bUtc::now\\(\\)") "Utc.timestamp(0, 0)"))

(Should hopefully be clearer now!)

The important thing here is replacing all instances of Utc::now() 
(across all Rust source files of rust-vergen) by Utc.timestamp(0, 0), 
the rest is just adding the required imports -- I have not made a list 
of all file names.  If you want a list, try "grep -rF Utc::now" or such.


I do not intend to update the workaround, it works fine in Guix and 
frankly porting it to whatever format Debian likes is Debian's concern, 
not Guix', I'm just sharing our workaround as a courtesy to another distro.


Greetings,
Maxime.



OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#966524: "lvconvert --merge" does not remove the snapshot after completing

2022-08-02 Thread Antonio


Hi Alexander,

For now I understand that, unlike the previous time, I can eliminate the 
stall condition with:

    vgchange -ay

Perhaps an unavailable condition occurs, but not knowing how Lvconvert 
works can only hypothesize...


I would like this bug to be closed, since it has been going on for a 
long time.

Bug#1016538: systemd-boot: Kernel postinst and initramfs post-update hooks copy initrd twice

2022-08-02 Thread Victor Westerhuis

On Tue, 2 Aug 2022 20:46:55 +0200 Michael Biebl  wrote:
> Am 02.08.22 um 18:20 schrieb Victor Westerhuis:
>  > Package: systemd-boot
>  > Version: 251.3-1
>  > Severity: normal
>  >
> > Both /etc/kernel/postinst.d/systemd-boot and 
> > /etc/initramfs/post-update.d/systemd-boot
> > call kernel-install to add a newly installed kernel. However, the initramfs 
> > hook
> > explicitly passes the initrd filename, leading to the initrd being copied 
> > to the EFI
> > partition twice.
> 
> Duplicate of #1016538 basically.
> 
> Ideas how to fix this welcome.
This bug is #1016538. What bug is this one a duplicate of?

Bug#1004361: obs-studio: Adding qtwayland5 also fixed it for me

2022-08-02 Thread Brandon Simmons

Package: obs-studio
Version: 27.2.4+dfsg1-2+b3
Followup-For: Bug #1004361

It would be great if qtwayland5 could be added as a dependency (and if 
I can shake my fist at the sky for a second: this is the 4th of the 
screencast applications in the repositories broken or non-functional
on wayland that I've tried this afternoon). 


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
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 obs-studio depends on:
ii  libavcodec59   7:5.0.1-3+b1
ii  libavdevice59  7:5.0.1-3+b1
ii  libavformat59  7:5.0.1-3+b1
ii  libavutil577:5.0.1-3+b1
ii  libc6  2.33-8
ii  libcurl3-gnutls7.84.0-2
ii  libfontconfig1 2.13.1-4.4
ii  libfreetype6   2.12.1+dfsg-3
ii  libgcc-s1  12.1.0-5
ii  libglib2.0-0   2.72.3-1
ii  libjansson42.14-2
ii  libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4
ii  libmbedcrypto7 2.28.1-1
ii  libmbedtls14   2.28.1-1
ii  libmbedx509-1  2.28.1-1
ii  libobs027.2.4+dfsg1-2+b3
ii  libpci31:3.7.0-6
ii  libpipewire-0.3-0  0.3.54-2
ii  libpulse0  15.0+dfsg1-4+b1
ii  libpython3.10  3.10.5-1
ii  libqt5core5a   5.15.4+dfsg-4
ii  libqt5gui5 5.15.4+dfsg-4
ii  libqt5network5 5.15.4+dfsg-4
ii  libqt5svg5 5.15.4-2
ii  libqt5widgets5 5.15.4+dfsg-4
ii  libqt5xml5 5.15.4+dfsg-4
ii  libspeexdsp1   1.2.0-1
ii  libstdc++6 12.1.0-5
ii  libswscale67:5.0.1-3+b1
ii  libudev1   251.2-7
ii  libv4l-0   1.22.1-4
ii  libx11-6   2:1.7.5-1
ii  libx264-1642:0.164.3095+gitbaee400-2+b1
ii  libxcb-randr0  1.14-3
ii  libxcb-shm01.14-3
ii  libxcb-xfixes0 1.14-3
ii  libxcb-xinerama0   1.14-3
ii  libxcb11.14-3
ii  libxcomposite1 1:0.4.5-1
ii  libxfixes3 1:6.0.0-1
ii  python33.10.5-3
ii  python3.10 3.10.5-1

Versions of packages obs-studio recommends:
ii  obs-plugins  27.2.4+dfsg1-2+b3

Versions of packages obs-studio suggests:
ii  policykit-10.105-33
ii  v4l2loopback-dkms  0.12.5-1

-- no debconf information

Bug#1014346: apache2 2.4.38-3+deb10u8 flagged for acceptance

2022-08-02 Thread Adam D Barratt

package release.debian.org
tags 1014346 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: apache2
Version: 2.4.38-3+deb10u8

Explanation: fix denial of service issue [CVE-2022-22719], HTTP request 
smuggling issue [CVE-2022-22720], integer overflow issue [CVE-2022-22721], 
out-of-bounds write issue [CVE-2022-23943], HTTP request smuggling issue 
[CVE-2022-26377], out-of-bounds read issues [CVE-2022-28614 CVE-2022-28615], 
denial of service issue [CVE-2022-29404], out-of-bounds read issue 
[CVE-2022-30556], possible IP-based authentication bypass issue [CVE-2022-31813]

Bug#1016439: procmail 3.22-26+deb10u1 flagged for acceptance

2022-08-02 Thread Adam D Barratt

package release.debian.org
tags 1016439 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: procmail
Version: 3.22-26+deb10u1

Explanation: fix NULL pointer dereference

Bug#1016112: transition: phodav 3.0 & friends

2022-08-02 Thread Sebastian Ramacher

Contol: tags -1 = confirmed

On 2022-08-02 15:39:13 -0400, Jeremy Bicha wrote:
> Control: tags -1 -moreinfo
> 
> On Tue, Aug 2, 2022 at 3:32 PM Sebastian Ramacher  
> wrote:
> > On 2022-07-27 08:32:41 -0400, Jeremy Bicha wrote:
> > > I am filing this bug for the phodav transition. Affected packages are:
> > > phodav
> > > spice-gtk
> > > libosinfo
> > > virt-viewer
> > > remmina
> > > gnome-boxes
> > > There was no soname bump for most of this transition and I don't have
> > > a ben file for it.
> >
> > If I read https://release.debian.org/transitions/html/auto-phodav.html
> > correctly, then there was a SONAME bump and only spice-gtk needs a
> > rebuild. Is the ben file wrong? Please clarify
> 
> The benfile is incomplete.
> 
> phodav had an API bump when it switched to libsoup3. spice-gtk also
> uses libsoup and did not have its soname bumped. It's not possible for
> apps to link against both libsoup2.4 and libsoup3. Therefore, we need
> to update spice-gtk to libsoup3. We also need to update libosinfo to
> libsoup3 since gnome-boxes and virt-manager link against both
> spice-gtk and libosinfo.
> 
> Without a soname bump, I don't know how to make an easy ben file for
> this transition but I need to do sourceful uploads for all these
> packages anyway (except for remmina which has already been taken care
> of). I am a team uploader for all the packages.
> 
> Lots more details at
> https://discourse.gnome.org/t/phodav-transition-notes/10483

I see. Please go ahead.

Cheers
-- 
Sebastian Ramacher

Bug#1016416: Coq-related packages transition - coq-elpi

2022-08-02 Thread Sebastian Ramacher

On 2022-07-31 13:23:38 +0200, julien.pu...@gmail.com wrote:
> Package: release.debian.org
> 
> Some Coq-related packages need a rebuild:
> 
> coq-hierarchy-builder
> mathcomp-algebra-tactics mathcomp-analysis
> 
> where packages on the same line can be handled in parallel.
> 
> I can't give a nice ben script because the abi checksum varies with the
> architecture (see today's mail on debian-devel where I'm trying to find
> ideas for a better approach).

>From the discussion on -devel, a permanent tracker like the one for
Haskell (https://release.debian.org/transitions/html/haskell.html) could
help with the rebuilds for coq-* and related packages. Do all affected
packages depends on some package that we can use as a basis for the
permapermanent tracker?

Cheers
-- 
Sebastian Ramacher

Bug#1016112: transition: phodav 3.0 & friends

2022-08-02 Thread Jeremy Bicha

Control: tags -1 -moreinfo

On Tue, Aug 2, 2022 at 3:32 PM Sebastian Ramacher  wrote:
> On 2022-07-27 08:32:41 -0400, Jeremy Bicha wrote:
> > I am filing this bug for the phodav transition. Affected packages are:
> > phodav
> > spice-gtk
> > libosinfo
> > virt-viewer
> > remmina
> > gnome-boxes
> > There was no soname bump for most of this transition and I don't have
> > a ben file for it.
>
> If I read https://release.debian.org/transitions/html/auto-phodav.html
> correctly, then there was a SONAME bump and only spice-gtk needs a
> rebuild. Is the ben file wrong? Please clarify

The benfile is incomplete.

phodav had an API bump when it switched to libsoup3. spice-gtk also
uses libsoup and did not have its soname bumped. It's not possible for
apps to link against both libsoup2.4 and libsoup3. Therefore, we need
to update spice-gtk to libsoup3. We also need to update libosinfo to
libsoup3 since gnome-boxes and virt-manager link against both
spice-gtk and libosinfo.

Without a soname bump, I don't know how to make an easy ben file for
this transition but I need to do sourceful uploads for all these
packages anyway (except for remmina which has already been taken care
of). I am a team uploader for all the packages.

Lots more details at
https://discourse.gnome.org/t/phodav-transition-notes/10483

Thank you,
Jeremy Bicha

Bug#1016112: transition: phodav 3.0 & friends

2022-08-02 Thread Sebastian Ramacher

Control: tags -1 moreinfo

On 2022-07-27 08:32:41 -0400, Jeremy Bicha wrote:
> Package: release.debian.org
> Tags: moreinfo
> User: release.debian@packages.debian.org
> Usertags: transition
> X-Debbugs-Cc: pho...@packages.debain.org
> Severity: normal
> 
> I am filing this bug for the phodav transition. Affected packages are:
> phodav
> spice-gtk
> libosinfo
> virt-viewer
> remmina
> gnome-boxes
> There was no soname bump for most of this transition and I don't have
> a ben file for it.

If I read https://release.debian.org/transitions/html/auto-phodav.html
correctly, then there was a SONAME bump and only spice-gtk needs a
rebuild. Is the ben file wrong? Please clarify

Cheers

> 
> All of these packages require sourceful uploads. I am a team uploader
> for all these packages except for Remmina.
> 
> I am filing this bug as moreinfo since I want coordination from the
> Remmina maintainer before starting this transition in Unstable.
> 
> Perhaps too much detail:
> https://discourse.gnome.org/t/phodav-transition-notes/10483
> 
> I successfully completed this transition recently in Ubuntu 22.10.
> 
> This transition allows completing a small part of the big GNOME 43
> libsoup transition without entangling as many packages.
> 
> Thank you,
> Jeremy Bicha
> 

-- 
Sebastian Ramacher

Bug#1016551: cawbird: Switch to librest 1.0 and libsoup3

2022-08-02 Thread Jeremy Bicha

Source: cawbird
Version: 1.5-1
Severity: serious
Forwarded: https://github.com/IBBoard/cawbird/issues/464

cawbird won't work with the new version of librest that is linked
against libsoup3. See more details in the forwarded bug.

We will upload the new librest to experimental soon after
https://bugs.debian.org/1015285 is handled.


Thank you,
Jeremy Bicha

Bug#1014860: llvm-toolchain-13 13.0.1-6~deb10u4 flagged for acceptance

2022-08-02 Thread Adam D Barratt

package release.debian.org
tags 1014860 = buster pending
thanks

Hi,

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

Thanks for your contribution!

Upload details
==

Package: llvm-toolchain-13
Version: 13.0.1-6~deb10u4

Explanation: disable libunwind on mips

Bug#1016550: gfbgraph: unmaintained, depends on old libsoup

2022-08-02 Thread Jeremy Bicha

Source: gfbgraph
Version: 0.2.5-2
Severity: serious

gfbgraph needs to be ported to the new librest 1.0 API and libsoup3.
Because I don't intend to have more than one version of librest in
Debian, gfbgraph will need to be removed.

There really isn't anything else using gfbgraph currently since core
GNOME has stopped using it because of this issue.

Thank you,
Jeremy Bicha

Bug#1016528: [Pkg-javascript-devel] Bug#1016528: node-fetch: please upgrade to at least v3.2.3

On 02/08/2022 17:59, Yadd wrote:

On 02/08/2022 13:00, Jonas Smedegaard wrote:
 > Package: node-fetch
 > Version: 2.6.7+~2.6.1-1
 > Severity: normal
 > Tags: upstream
 >

Please upgrade node-fetch to at least v3.2.3, needed by several projects
I am preparing for Debian.

(yes, I am aware that there is a package in experimental - this
bugreport is to track availability in unstable)

  - Jonas

Hi,

node-fetch >= 3 seems to break node-solid-rest [1], that's why I didn't 
pushed it to unstable. Since you're maintainer of node-solid-rest, could 
you fix that ?

Cheers,
Yadd

[1] 
https://release.debian.org/britney/pseudo-excuses-experimental.html#node-fetch 

I think I'm able to fix that in node-fetch

Bug#1016546: rust-vergen inserts build timestamps

2022-08-02 Thread Geert Stappers

Date: Tue, 2 Aug 2022 19:18:46 +0200, From: Maxime Devos
> 
> In Guix, I've noticed that rust-vergen embeds build timestamps. There is also
> a work-around available: .
 

Thanks for reporting the FTBR.

Please update the workaround, so it looks more
like https://en.wikipedia.org/wiki/Diff#Unified_format
and can be absured by https://en.wikipedia.org/wiki/Patch_(Unix)


Just telling the filename that needs modification would be a great help.



Groeten
Geert Stappers
Has set Reply-To to wanted destination (the BTS).
-- 
Silence is hard to parse

Bug#1016538: systemd-boot: Kernel postinst and initramfs post-update hooks copy initrd twice

2022-08-02 Thread Michael Biebl


Am 02.08.22 um 18:20 schrieb Victor Westerhuis:
> Package: systemd-boot
> Version: 251.3-1
> Severity: normal
>

Both /etc/kernel/postinst.d/systemd-boot and 
/etc/initramfs/post-update.d/systemd-boot
call kernel-install to add a newly installed kernel. However, the initramfs hook
explicitly passes the initrd filename, leading to the initrd being copied to 
the EFI
partition twice.


Duplicate of #1016538 basically.

Ideas how to fix this welcome.


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016526: [Pkg-openssl-devel] Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

2022-08-02 Thread Jérémy Lal

Control: reassign -1 nodejs

Le mar. 2 août 2022 à 18:40, Kurt Roeckx  a écrit :

> On Tue, Aug 02, 2022 at 12:50:05PM +0200, Jérémy Lal wrote:
> > Package: openssl
> > Version: 3.0.5-1
> > Severity: normal
> > Control: affects -1 nodejs
> >
> > Hi,
> >
> > while building nodejs 18.6.0+dfsg-4 on mips64el, some SSL tests did
> regress,
> > https://buildd.debian.org/status/logs.php?pkg=nodejs=mips64el
> > (look for "not ok" tests).
> >
> > In particular, test-crypto-sign-verify test failed with an unexpected
> error:
> > 'error:1E08010C:DECODER routines::unsupported'
>
> For some reason it seems to expect to fail with some other error
> instead.
>
> It's currently unclear that this is an openssl bug. Can you show
> what that code is trying to do, and what it expects openssl to return?
>
> There seem to be various other test suite failures that don't seem to be
> related to openssl at all.
>
> > I suppose the root cause is similar to the one for
> > [EC code appears to be broken on s390x](https://bugs.debian.org/1016290
> ),
> > but it's not the same bug.
>
> It will be totally unrelated. That one is very specific to s390x.
>

Indeed, something has changed somewhere else.

Jérémy

Bug#1016539: libregexp-wildcards-perl: We want to make sure that the test-suite that libregexp-wildcards-perl has runs at autopkgtest time.

2022-08-02 Thread Christoph Biedl

Control: tags 1016539 pending

Olivier Gayot wrote...

>As part of a main inclusion request in Ubuntu, we want to ensure that
>the test suites runs at autopkgtest time.

Sure thing. After almost four years, the packaging could see some
cleanup anyway.

Christoph


signature.asc
Description: PGP signature

Bug#1016548: linux-image-5.19.0-rc6-amd64: Corrupted cursor and broken resume with amdgpu driver with Radeon RX 6600

2022-08-02 Thread George Shuklin

Package: linux-image-5.19.0-rc6-amd64
Version: 5.19~rc6-1~exp1
Severity: important
X-Debbugs-Cc: george.shuk...@gmail.com

Dear Maintainer,

After upgrade from 5.18.0-3-amd64 to 5.19.0-rc6-amd64 video subsystem start
misbehave:

* Visual artefacts after cursor
* Hangs when X is active
* Unable to show anything after resume on DisplayPort monitor (but working
otherwise, like ssh).

Following kernel trace was observed:

[  193.941836] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[  199.061275] [drm:amdgpu_dm_atomic_commit_tail [amdgpu]] *ERROR* Waiting for
fences timed out!
[  199.071242] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0
timeout, signaled seq=3956, emitted seq=3958
[  199.071340] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information:
process Xorg pid 2028 thread Xorg:cs0 pid 3062
[  199.071424] amdgpu :0a:00.0: amdgpu: GPU reset begin!
[  199.491788] amdgpu :0a:00.0: [drm:amdgpu_ring_test_helper [amdgpu]]
*ERROR* ring kiq_2.1.0 test failed (-110)
[  199.491863] [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* KGQ disable failed
[  199.767776] [drm:gfx_v10_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
[  199.781910] [drm] free PSP TMR buffer
[  199.827452] CPU: 11 PID: 81 Comm: kworker/u64:7 Not tainted 5.19.0-rc6-amd64
#1  Debian 5.19~rc6-1~exp1
[  199.827454] Hardware name: System manufacturer System Product Name/PRIME
X570-P, BIOS 3405 02/01/2021
[  199.827455] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]
[  199.827460] Call Trace:
[  199.827461]  
[  199.827463]  dump_stack_lvl+0x45/0x5e
[  199.827467]  amdgpu_do_asic_reset+0x28/0x434 [amdgpu]
[  199.827576]  amdgpu_device_gpu_recover_imp.cold+0x628/0x8fc [amdgpu]
[  199.827672]  amdgpu_job_timedout+0x153/0x190 [amdgpu]
[  199.827765]  drm_sched_job_timedout+0x76/0x110 [gpu_sched]
[  199.827767]  process_one_work+0x1e5/0x3b0
[  199.827770]  worker_thread+0x50/0x3a0
[  199.827772]  ? rescuer_thread+0x390/0x390
[  199.827773]  kthread+0xe8/0x110
[  199.827774]  ? kthread_complete_and_exit+0x20/0x20
[  199.827775]  ret_from_fork+0x22/0x30
[  199.827778]  
[  199.827779] amdgpu :0a:00.0: amdgpu: MODE1 reset
[  199.827781] amdgpu :0a:00.0: amdgpu: GPU mode1 reset
[  199.827855] amdgpu :0a:00.0: amdgpu: GPU smu mode1 reset
[  200.341240] amdgpu :0a:00.0: amdgpu: GPU reset succeeded, trying to
resume
[  200.341406] [drm] PCIE GART of 512M enabled (table at 0x00800030).
[  200.341430] [drm] VRAM is lost due to GPU reset!
[  200.341435] [drm] PSP is resuming...
...
[  200.897511] amdgpu :0a:00.0: amdgpu: GPU reset(2) succeeded!
[  200.906284] amdgpu_cs_ioctl: 16 callbacks suppressed
[  200.906286] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize
parser -125!
[  200.906954] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize
parser -125!
[  200.907311] [drm:amdgpu_cs_ioctl [amdgpu]] *ERROR* Failed to initialize
parser -125!


Xorg log is clean (no errors observed).

Reverting back to 5.18.0-3-amd64 fix the problem.

GPU details: Radeon 6600.

lspci data:

0a:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi
23 [Radeon RX 6600/6600 XT/6600M] (rev c7) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] Navi 23 [Radeon RX
6600/6600 XT/6600M]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ SERR-

Bug#1016547: /etc/default/grub.d/xen.cfg: Extraneous output line causes error message at boot

2022-08-02 Thread John E. Krokes

Package: xen-hypervisor-common
Version: 4.14.5+24-g87d90d511c-1
Severity: minor
File: /etc/default/grub.d/xen.cfg

Dear Maintainer,

When invoked via grub-mkconfig, xen.cfg outputs this as its first line:
Including Xen overrides from /etc/default/grub.d/xen.cfg

The output of grub-mkconfig is expected to be redirected into a grub.cfg file.
Grub will read the grub.cfg at boot. Unfortunately, "Including" is not a
valid grub command. So when booting, grub emits this error message before
displaying its menu:
error: can't find command `Including'.

The error message is obscured very quickly. It does not affect functionality
in any way. It requires booting on a VERY slow machine in order to read
the error message at all.

If I add a '#' to the start of the "Including", the resulting grub config file
boots with no error.
echo "#Including Xen overrides from /etc/default/grub.d/xen.cfg"

I'm not sure if this line was intended to go into the generated config
file as a comment, or if it was intended to be shown to the user while
grub-mkconfig is running.

I have observed this and tested my fix against version
4.14.5+24-g87d90d511c-1 of xen-hypervisor-common. I have also checked
with the debian git at
https://salsa.debian.org/xen-team/debian-xen/-/blob/master/debian/tree/xen-hypervisor-common/etc/default/grub.d/xen.cfg.
This line
has not changed in a very long time.

I can also duplicate the behavior using grub-emu, with the output redirected
to a file.

I am running devuan, and originally reported this to their BTS but was
redirected to debian. So my version number does not match. Apologies for
that.

Thanks for your time.

-Mag

-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-16-amd64 (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

-- Configuration Files:
/etc/default/grub.d/xen.cfg changed:
echo "#Including Xen overrides from /etc/default/grub.d/xen.cfg"
XEN_OVERRIDE_GRUB_DEFAULT=0
if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "" ]; then
echo "WARNING: GRUB_DEFAULT changed to boot into Xen by default!"
echo " Edit /etc/default/grub.d/xen.cfg to avoid this warning."
XEN_OVERRIDE_GRUB_DEFAULT=1
fi
if [ "$XEN_OVERRIDE_GRUB_DEFAULT" = "1" ]; then
GRUB_DEFAULT=$( \
printf "$(gettext "%s, with Xen hypervisor")" \
"$GRUB_DISTRIBUTOR GNU/Linux")
fi

-- no debconf information

Bug#1016546: rust-vergen inserts build timestamps

2022-08-02 Thread Geert Stappers

Package: rust-vergen
Version: 3.0.4-2
Severity: serious
Justify: fails to build reproducible
Tags: +patch

- Forwarded message from Maxime Devos  -

Date: Tue, 2 Aug 2022 19:18:46 +0200
From: Maxime Devos 
To: debian-r...@lists.debian.org
Subject: rust-vergen is irreproducible and causes irreproducibility
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 
Thunderbird/91.11.0

Hi,

In Guix, I've noticed that rust-vergen embeds build timestamps. There is also
a work-around available: .

Greetings,
Maxime.


pub EdDSA 256/191725EE 2020-10-14 Maxime Devos 
sub  ECDH 256/52A5D546 2020-10-14

- End forwarded message -

Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1016516: notion: Notion fails on startup (in sid)

2022-08-02 Thread Dima Kogan

Jurij: thanks for the report. This issue is already tracked here:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016363#15

and here:

  https://github.com/raboof/notion/issues/345

Arnout (upstream) can't reproduce it currently.

Jurij and Göran: since you can realiably see this breakage, can you get
a log to Arnout so that he can debug? One useful tool here would be the
rr debugger:

  http://rr-project.org

You can save a trace of the crashing process, which can then be replayed
forwards and backwards later. "rr pack" would make the traces portable
so that they can be replayed on another machine.

Bug#1016545: dpkg-conffile prompt when autopkgtesting a package from the minimal set

2022-08-02 Thread Marc Haber

Package: autopkgtest
Version: 5.22
Severity: minor
X-Debbugs-Cc: ja...@oneway.dev

Hi,

Severity: minor because this is probably an exotic corner case. I'm
filing this anyway becuse it is probably easily fixed.

I'm on the adduser team. Adduser is part of the minimal install and is
therefore installed in every environment that autopkgtest is run in. In
current experimental, adduser has migrated /etc/adduser.conf to being an
dpkg-conffile. Before that, adduser.conf was kind of "managed" in
postinst.

adduser.conf suddenly becoming a dpkg-conffile causes dpkg to emit a
conffile prompt in every case of adduser <= 3.123 being updated to
adduse >= 3.125.

This also happens when the newly built adduser.deb gets installed during
autopkgtest. The autopkgtest run stalls in this case and needs manual
intervention to continue.

Is this autopkgtest's intended behavior? If not, would passing
--force-confnew to dpkg solve this issue?

This most probably only happens iff:

- the package in test is already part of the base install AND
- the package in test has recently changed a maintainer-managed
  configuration file to being a dpkg-conffile.

Since this is probably exotic, I'm holding off uploading a new version
of adduser to unstable until Friday Aug 5 to give you a chance to
reproduce this behavior. Let me know when I can upload earlier please.

I am setting Jason Franklin, my team colleague who investgated this in
depth, as Cc so that he can give additional information that I might
have forgotten.

Greetings
Marc

Bug#1016544: pipewire-pulse: pacmd says no pulseaudio daemon running

2022-08-02 Thread Sam Hartman

Package: pipewire-pulse
Version: 0.3.56-1
Severity: normal

Many of the pipewire docs imply that pacmd ought to work even when 
pipewire-pulse is running.

Unfortunately, when I run

hartmans@industrial-algebra:~(1)> pacmd info
No PulseAudio daemon running, or not running as session daemon.

Other users on #debian-devel reported the same.
strace gets as far as reading $XDG_RUNTIME_DIR/pulse/pid, then looking up info 
on that process in /proc, then starting to open message catalogs.

I'm happy to provide more information as needed.


-- System Information:
Debian Release: 11.3
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable'), (200, 'unstable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
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 pipewire-pulse depends on:
ii  init-system-helpers  1.60
ii  pipewire 0.3.56-1

pipewire-pulse recommends no packages.

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.56-1
ii  pulseaudio-utils  15.0+dfsg1-4+b1

-- no debconf information

Bug#775443: libgpm errors in a lxc container

2022-08-02 Thread Harald Welte

I'm seeing *tons* of these in a pretty standard debian 11 lxc container
on a debian 10 host.

insie the container:

ii  libgpm2:amd64   1.20.7-8   amd64
General Purpose Mouse - shared library
ii  vim 2:8.2.2434-3+deb11u1   amd64Vi 
IMproved - enhanced vi editor
ii  vim-common  2:8.2.2434-3+deb11u1   all  Vi 
IMproved - Common files
ii  vim-runtime 2:8.2.2434-3+deb11u1   all  Vi 
IMproved - Runtime files

there is no non-standard vim config whatsoever.  It's a pretty stock bullseye 
that I just
created today using 'lxc -t download'

---
Aug 02 16:51:51 vpn vi[9459]: *** err
Aug 02 16:51:51 vpn vi[9459]: unable to open gpm console, check your /dev 
filesystem!
Aug 02 16:51:51 vpn vi[9459]: *** err
Aug 02 16:51:51 vpn vi[9459]: Oh, oh, it's an error! possibly I die!
---
I see lots of repeats every few seconds, possibly every time vim was used?

Clearly running an editor like vim inside a container is nothing unexpected in 
2022,
and shouldn't result in tons of error messages spamming syslog / journal?

-- 
- Harald Weltehttp://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

Bug#1016483: [Pkg-javascript-devel] Bug#1016483: Bug#1016483: pkg-js-tools: pkgjs-depends eats all memory and dies (probably by linux OOM Killer)

On 02/08/2022 18:25, Yadd wrote:

On 01/08/2022 16:53, Jonas Smedegaard wrote:
 > Package: pkg-js-tools
 > Version: 0.14.31
 > Severity: important
 >

I tries run the following command in a pristine Sid environment:

   pkgjs-depends @solid/community-server

After hanging at 4% for 5-6 minutes, the process ate all available
memory (16+ GB!) and then died (probably killed by the linux OOM
Killer).

  - Jonas

Thanks for the report, the problem is that pkgjs-depends doesn't see 
circular dependencies

Fixed in 0.14.32. Here is the report (without duplicates) of your query 
(with 2 npm errors for paseto@2 and paseto@3 (maybe replace them by 
paseto2 and paseto3):

# @solid/community-server
paseto2@npm:paseto@^2.1.3 not foundver 
   ]

npm ERR! code E404
npm ERR! 404 No match found for version npm:paseto@^2.1.3
npm ERR! 404
npm ERR! 404  'paseto@npm:paseto@^2.1.3' is not in this registry.
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
{
  "error": {
"code": "E404",
"summary": "No match found for version npm:paseto@^2.1.3",
"detail": "\n 'paseto@npm:paseto@^2.1.3' is not in this 
registry.\n\nNote that you can also install from a\ntarball, folder, 
http url, or git url."

  }
}

npm ERR! A complete log of this run can be found in:
npm ERR! /home/yadd/.npm/_logs/2022-08-02T17_10_32_492Z-debug-0.log
paseto3@npm:paseto@^3.0.0 not found
npm ERR! code E404
npm ERR! 404 No match found for version npm:paseto@^3.0.0
npm ERR! 404
npm ERR! 404  'paseto@npm:paseto@^3.0.0' is not in this registry.
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.
{
  "error": {
"code": "E404",
"summary": "No match found for version npm:paseto@^3.0.0",
"detail": "\n 'paseto@npm:paseto@^3.0.0' is not in this 
registry.\n\nNote that you can also install from a\ntarball, folder, 
http url, or git url."

  }
}

npm ERR! A complete log of this run can be found in:
npm ERR! /home/yadd/.npm/_logs/2022-08-02T17_10_33_541Z-debug-0.log

DEPENDENCIES: 

  handlebars (handlebars)
  libjs-json (canonicalize)
  node-accepts (accepts)
  node-co (co)
  node-content-disposition (content-disposition)
  node-content-type (content-type)
  node-cookies (@types/cookies, cookies)
  node-cors (cors)
  node-cross-fetch (cross-fetch)
  node-debug (debug)
  node-deep-equal (deep-equal)
  node-delegates (delegates)
  node-depd (depd)
  node-ejs (ejs)
  node-encodeurl (encodeurl)
  node-end-of-stream (@types/end-of-stream, end-of-stream)
  node-escape-html (escape-html)
  node-escape-string-regexp (escape-string-regexp)
  node-fast-deep-equal (fast-deep-equal)
  node-fetch (node-fetch)
  node-follow-redirects (follow-redirects)
  node-fresh (fresh)
  node-fs-extra (@types/fs-extra, fs-extra)
  node-got (cacheable-lookup, got)
  node-graphql (graphql)
  node-hash.js (hash.js)
  node-htmlparser2 (htmlparser2)
  node-http-errors (@types/http-errors, http-errors)
  node-immutable (immutable)
  node-is-stream (is-stream)
  node-jose (jose)
  node-jsdom (decimal.js)
  node-jsesc (jsesc)
  node-jsonparse (jsonparse)
  node-jsonstream (JSONStream)
  node-keygrip (@types/keygrip)
  node-lodash-packages (@types/lodash.orderby, lodash.defaults, 
lodash.isarguments, lodash.orderby)

  node-lru-cache (lru-cache)
  node-marked (@types/marked, marked)
  node-mime-types (@types/mime-types, mime-types)
  node-minimist (@types/minimist, minimist)
  node-n3 (@types/n3, n3)
  node-nodemailer (@types/nodemailer, nodemailer)
  node-on-finished (on-finished)
  node-parseurl (parseurl)
  node-postcss (nanoid)
  node-pre-gyp (@mapbox/node-pre-gyp)
  node-pump (pump)
  node-punycode (punycode)
  node-quick-lru (quick-lru)
  node-raw-body (raw-body)
  node-readable-stream (readable-stream)
  node-redis (cluster-key-slot)
  node-rollup-plugin-typescript2 (object-hash)
  node-safe-buffer (safe-buffer)
  node-sax (sax)
  node-semver (@types/semver, semver)
  node-send (destroy)
  node-statuses (statuses)
  node-type-is (type-is)
  node-url-join (url-join)
  node-util (is-generator-function)
  node-uuid (@types/uuid, uuid)
  node-vary (vary)
  node-winston (winston)
  node-winston-transport (winston-transport)
  node-ws (@types/ws, ws)
  node-xtend (xtend)
  node-yargs (@types/yargs, yargs)
  nodejs (@types/node)

MISSING:
@solid/community-server
 └── @comunica/actor-init-sparql (1.22.3)
 └── @comunica/actor-abstract-bindings-hash (1.22.0)
 └── @comunica/types (1.22.0)
 └── @rdfjs/types (1.1.0)
 └── asynciterator (3.6.0)
 └── sparqlalgebrajs (3.0.3)
 └── @types/sparqljs (3.1.3)
 └── rdf-js (4.0.2)
 └── rdf-data-factory (1.1.1)
 └── rdf-isomorphic (1.3.0)
 └── rdf-string (1.6.1)
 └── rdf-terms (1.9.0)
 └── sparqljs (3.5.2)
 └──

Bug#1016543: rsync: CVE-2022-29154

2022-08-02 Thread Salvatore Bonaccorso

Source: rsync
Version: 3.2.4-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for rsync.

CVE-2022-29154[0]:
| An issue was discovered in rsync before 3.2.5 that allows malicious
| remote servers to write arbitrary files inside the directories of
| connecting peers. The server chooses which files/directories are sent
| to the client. However, the rsync client performs insufficient
| validation of file names. A malicious rsync server (or Man-in-The-
| Middle attacker) can overwrite arbitrary files in the rsync client
| target directory and subdirectories (for example, overwrite the
| .ssh/authorized_keys file).

IMHO the issue does not warrant a DSA, but can be fixed at a point
release time. Note that apart the initial commit mentioned in the
oss-security post there were additional commits done upstream around
that.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-29154
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29154
[1] https://www.openwall.com/lists/oss-security/2022/08/02/1

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#1016541: ruby-aruba: FTBFS with ruby3.1: ERROR: Test "ruby3.1" failed: RuntimeError:

2022-08-02 Thread Antonio Terceiro

Source: ruby-aruba
Version: 1.0.4-1
Severity: important
Justification: FTBFS
Tags: bookworm sid ftbfs
User: debian-r...@lists.debian.org
Usertags: ruby3.1

Hi,

We are about to start the ruby3.1 transition in unstable. While trying to
rebuild ruby-aruba with ruby3.1 enabled, the build failed.

Relevant part of the build log (hopefully):
> RuntimeError:
>   coverage measurement is already setup
> # 
> /usr/share/rubygems-integration/all/gems/simplecov-0.21.2/lib/simplecov.rb:354:in
>  `start'
> # 
> /usr/share/rubygems-integration/all/gems/simplecov-0.21.2/lib/simplecov.rb:354:in
>  `start_coverage_with_criteria'
> # 
> /usr/share/rubygems-integration/all/gems/simplecov-0.21.2/lib/simplecov.rb:343:in
>  `start_coverage_measurement'
> # 
> /usr/share/rubygems-integration/all/gems/simplecov-0.21.2/lib/simplecov.rb:59:in
>  `start'
> # ./spec/spec_helper.rb:6:in `'
> # ./spec/event_bus_spec.rb:1:in `'
> No examples found.
> 
> 
> Finished in 0.5 seconds (files took 0.16456 seconds to load)
> 0 examples, 0 failures, 31 errors occurred outside of examples
> 
> Coverage report generated for rspec to /<>/coverage. 35 / 1854 
> LOC (1.89%) covered.
> Stopped processing SimpleCov as a previous error not related to SimpleCov has 
> been detected
> /usr/bin/ruby3.1 
> -I/usr/share/rubygems-integration/all/gems/rspec-support-3.10.3/lib:/usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/lib
>  /usr/share/rubygems-integration/all/gems/rspec-core-3.10.1/exe/rspec 
> --pattern ./spec/\*\*/\*_spec.rb failed
> ERROR: Test "ruby3.1" failed: 


The full build log is available from:
https://people.debian.org/~terceiro/ruby3.1/ruby-aruba_1.0.4-1+rebuild1659414397_amd64-2022-08-02T04:26:38Z.build

To reproduce this, you need to install ruby-all-dev >= 1:3.0+2 (in 
experimental).
If you fail to reproduce, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects


signature.asc
Description: PGP signature

Bug#1016466: ImportError: /usr/lib/x86_64-linux-gnu/libgnuradio-runtime.so.3.10.3: undefined symbol

2022-08-02 Thread Jan van Gils

Good day,

I am new to the Debian bug system so maybe I am wrong regarding my next remark.

This bug that I filed causes 'GNURadio unable to start' and is now depending on 
a libspdlog1 bug 1015742
Looking at that bug it seems it isn't possible to reproduce after a distro 
reinstall.

I guess now this GNURadio bug will also not be addressed, please change the 
status back to grave and have another look.

Bug#1016540: wmanager: FTBFS / autopkgtest regression with glibc 2.34

Source: wmanager
Version: 0.3.0-2
Severity: important
Tags: upstream patch
Forwarded: https://gitlab.com/wmanager/wmanager/-/merge_requests/1

wmanager fails to build when built against glibc 2.34, and the
autopkgtest fails when run against glibc 2.34 due to a timeout:

https://ci.debian.net/data/autopkgtest/unstable/amd64/w/wmanager/24248015/log.gz

The problem has already been reported upstream with a patch available:
https://gitlab.com/wmanager/wmanager/-/merge_requests/1

Could you please do an upload with this fix?

Thanks
Aurelien

Bug#1016526: [Pkg-openssl-devel] Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

2022-08-02 Thread Kurt Roeckx

On Tue, Aug 02, 2022 at 12:50:05PM +0200, Jérémy Lal wrote:
> Package: openssl
> Version: 3.0.5-1
> Severity: normal
> Control: affects -1 nodejs
> 
> Hi,
> 
> while building nodejs 18.6.0+dfsg-4 on mips64el, some SSL tests did regress,
> https://buildd.debian.org/status/logs.php?pkg=nodejs=mips64el
> (look for "not ok" tests).
> 
> In particular, test-crypto-sign-verify test failed with an unexpected error:
> 'error:1E08010C:DECODER routines::unsupported'

For some reason it seems to expect to fail with some other error
instead.

It's currently unclear that this is an openssl bug. Can you show
what that code is trying to do, and what it expects openssl to return?

There seem to be various other test suite failures that don't seem to be
related to openssl at all.

> I suppose the root cause is similar to the one for
> [EC code appears to be broken on s390x](https://bugs.debian.org/1016290),
> but it's not the same bug.

It will be totally unrelated. That one is very specific to s390x.

Kurt

Bug#1016539: libregexp-wildcards-perl: We want to make sure that the test-suite that libregexp-wildcards-perl has runs at autopkgtest time.

2022-08-02 Thread Olivier Gayot

Package: libregexp-wildcards-perl
Version: 1.05-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear Maintainer,

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

   As part of a main inclusion request in Ubuntu, we want to ensure that
   the test suites runs at autopkgtest time.

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


*** /tmp/tmpi21cmu5u/bug_body

In Ubuntu, the attached patch was applied to achieve the following:


  * Make sure the test-suite runs at autopkgtest time (LP: #1983397).


Thanks for considering the patch.


-- System Information:
Debian Release: bookworm/sid
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.15.0-43-generic (SMP w/8 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libregexp-wildcards-perl-1.05/debian/control 
libregexp-wildcards-perl-1.05/debian/control
--- libregexp-wildcards-perl-1.05/debian/control2018-11-10 
15:44:55.0 +0100
+++ libregexp-wildcards-perl-1.05/debian/control2022-08-01 
11:32:32.0 +0200
@@ -5,6 +5,7 @@
 Vcs-Browser: https://git.in-ulm.de/cbiedl/libregexp-wildcards-perl
 Vcs-Git: https://git.in-ulm.de/cbiedl/libregexp-wildcards-perl.git
 Build-Depends: debhelper (>= 10~),
+Testsuite: autopkgtest-pkg-perl
 Priority: optional
 Section: perl

Bug#1016483: [Pkg-javascript-devel] Bug#1016483: pkg-js-tools: pkgjs-depends eats all memory and dies (probably by linux OOM Killer)

On 01/08/2022 16:53, Jonas Smedegaard wrote:
> Package: pkg-js-tools
> Version: 0.14.31
> Severity: important
>

I tries run the following command in a pristine Sid environment:

   pkgjs-depends @solid/community-server

After hanging at 4% for 5-6 minutes, the process ate all available
memory (16+ GB!) and then died (probably killed by the linux OOM
Killer).

  - Jonas

Thanks for the report, the problem is that pkgjs-depends doesn't see 
circular dependencies

Bug#1016538: systemd-boot: Kernel postinst and initramfs post-update hooks copy initrd twice

2022-08-02 Thread Victor Westerhuis

Package: systemd-boot
Version: 251.3-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Both /etc/kernel/postinst.d/systemd-boot and 
/etc/initramfs/post-update.d/systemd-boot
call kernel-install to add a newly installed kernel. However, the initramfs hook
explicitly passes the initrd filename, leading to the initrd being copied to 
the EFI
partition twice.


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd-boot depends on:
ii  libc6  2.33-8
ii  libsystemd-shared  251.3-1
ii  systemd-boot-efi   251.3-1

Versions of packages systemd-boot recommends:
ii  efibootmgr  17-1

systemd-boot suggests no packages.

- -- Configuration Files:
/etc/initramfs/post-update.d/systemd-boot changed:
set -eu
test -x /usr/bin/bootctl || exit 0
bootctl is-installed --quiet || exit 0
echo "Updating kernel version $1 in systemd-boot..."
kernel-install add "$1" "/boot/vmlinuz-$1"


- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmLpTsUTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+4rRD/9vPqQdwIpV4qJK7j8COfKFxxwg49es
KryM1dJKp2OymMWZ74UZnZtgXUNSmy+7QwPp1R3qkTJpaP5yEVVGrRtapNMGu8BW
EvkpyCWtNDJFXmLZ8UBwDB1gVX4S6e0tiCd88djqSb3N6XuPxxSToJzSiitIJl2B
/Jt1G7i8LWkRMXcgmmvGZOuWoPvelF4pJ1coqEwNhbPrZHufxMQzBmhp7AH5/h91
km2HRum8Cxhha60uJ3e5tcWvbW+tPbFXHNfBDlm3DlzHLn5CED5+joRqkUXO1EJU
bsexIOX6uEzOcnozK8qiEriBjfCUmEJrCyLppCzvpmOmsNoEhur/tBZ6iWZB49Gs
vx+lY7HWAGK+xD7k9qqeK5vfdP5L7Qq8gcoEXZlADoMgeNCitM8phPISP6/ByvcF
jNsww8O+EOxbVUCG4YhcJu30XN0qSWXJDhOxcwdQr2EImXFoQ5SWnjre3l81fdvG
+NegoRcC/sMNac+JNdwIg3xS8O4frMndNP05McU/SX9tIVOXeyyQ0uHB9xal3tMu
JY9B7IElWYrm8A1udcKGpaC9ySZs8dpCqvvqJLG3ig4HvXwRcirOA5hYBzt5Zxaj
UfvuGnqERRG7zCSaoFv5nRw2u1x7aL2Tt5f0HPw0Msfr336mzUbCzX6quX9q9tVr
wG5wkWMA8oLllw==
=3eOm
-END PGP SIGNATURE-

Bug#1013929: src:goffice: FTBFS on mips64el

2022-08-02 Thread Ludovic Rousseau


Le 02/08/2022 à 11:27, Dmitry Smirnov a écrit :

Hi Ludovic,

On Sunday, 31 July 2022 12:36:04 AM AEST Ludovic Rousseau wrote:

I am the Debian maintainer of the package grisbi that depends on
libgoffice-0.10-10

I see no update on this bug since 3 weeks.

It looks like the fix is proposed upstream at
https://gitlab.gnome.org/GNOME/goffice/-/issues/59#note_1495045


Sorry, I'm being very slow lately...

I've applied the upstream patch but unfortunately it did not fix the
problem...


I think we now have a *different* issue.
The initial build failure 
https://buildd.debian.org/status/fetch.php?pkg=goffice=mips64el=0.10.52-2=1656999642=0
 was during execution of dh_auto_build command:

/usr/bin/ld: .libs/goffice-0.10-scan.o: in function `get_object_types':
./docs/reference/goffice-0.10-scan.c:207: undefined reference to 
`go_complexl_get_type'
/usr/bin/ld: ./docs/reference/goffice-0.10-scan.c:207: undefined reference to 
`go_complexl_get_type'
collect2: error: ld returned 1 exit status
2022-07-05 05:40:30,271:scangobj.py:execute_command:1289:WARNING:Linking scanner failed: 1, 
command: /bin/bash ../../libtool --tag=CC --mode=link mips64el-linux-gnuabi64-gcc 
-lgobject-2.0 -lglib-2.0 -g -O2 -ffile-prefix-map=/<>=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wall -g -Wall -Werror=init-self 
-Werror=missing-include-dirs -Wsign-compare -Werror=pointer-arith -Wchar-subscripts 
-Wwrite-strings -Wdeclaration-after-statement -Wnested-externs -Wmissing-noreturn 
-Werror=missing-prototypes -Werror=implicit-function-declaration -Wmissing-declarations 
-Wno-pointer-sign -Werror=format-security -Wstrict-prototypes -Wno-error=format-nonliteral 
-Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -L/usr/X11R6/lib 
goffice-0.10-scan.lo ../../goffice/libgoffice-0.10.la -Wl,--export-dynamic -lgmodule-2.0 
-pthread -lgsf-1 -lrsvg-2 -lm -lxslt -lxml2 -lgtk-3 -lgdk-3 -lpangocairo-1.0 -lpango-1.0 
-lharfbuzz -latk-1.0 -lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lgobject-2.0 
-lglib-2.0 -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,-O1 -Wl,--as-needed -L/usr/X11R6/lib -o 
goffice-0.10-scan
make[3]: *** [Makefile:695: scan-build.stamp] Error 1
make[3]: Leaving directory '/<>/docs/reference'
make[2]: *** [Makefile:438: all-recursive] Error 1
make[2]: Leaving directory '/<>/docs'
make[1]: *** [Makefile:552: all-recursive] Error 1
make[1]: Leaving directory '/<>'
dh_auto_build: error: make -j4 returned exit code 2
make: *** [debian/rules:70: binary-arch] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit 
status 2


With the new upstream patch the build failure is during ecxecution of 
dpkg-gensymbols command:

dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: debian/libgoffice-0.10-10/DEBIAN/symbols doesn't 
match completely debian/libgoffice-0.10-10.symbols
--- debian/libgoffice-0.10-10.symbols (libgoffice-0.10-10_0.10.52-3_mips64el)
+++ dpkg-gensymbolsz0mJDF   2022-08-02 08:51:19.169391884 +
@@ -60,22 +60,22 @@
  go__VOID__INT_BOOLEAN_BOOLEAN_BOOLEAN@Base 0.9.0
  go_accumulator_add@Base 0.9.0
  go_accumulator_add_quad@Base 0.9.1
- go_accumulator_add_quadl@Base 0.9.1
- go_accumulator_addl@Base 0.9.0
+#MISSING: 0.10.52-3# go_accumulator_add_quadl@Base 0.9.1
+#MISSING: 0.10.52-3# go_accumulator_addl@Base 0.9.0
  go_accumulator_clear@Base 0.9.0
- go_accumulator_clearl@Base 0.9.0
+#MISSING: 0.10.52-3# go_accumulator_clearl@Base 0.9.0
[...]

Some symbols, ending with "l", were previously defined but are no more present.

From the header file 
https://gitlab.gnome.org/GNOME/goffice/-/blob/master/goffice/math/go-accumulator.h#L29
 we see that the symbol go_accumulator_addl() is defined only if 
GOFFICE_WITH_LONG_DOUBLE is defined.

But in debian/rules we still have "--without-long-double" option for mips64el. 
I think that is the source of the new problem.

Have you tried to *revert* 
https://salsa.debian.org/debian/goffice/-/commit/3cd973d85f5b6d337100270e068f09fd30d8cea5
 and keep only the new upstream patch?


Hope this helps.

--
Dr. Ludovic Rousseau

Bug#1016467: python3-configobj: places "private" files in top level of /usr/lib/python3/dist-packages

2022-08-02 Thread Stefano Rivera

Hi Julian (2022.08.01_11:08:22_+0200)
> So, we could do the same thing. But it'll need some testing with
> reverse-deps.

Did that and ran into a failure in cloud-init:
https://github.com/canonical/cloud-init/pull/1632

But nothing else.

SR

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

Bug#1016090: python-django breaks lots of autopkgtests

2022-08-02 Thread Chris Lamb

Raphael Hertzog wrote:

> As such, as much as I hate it, I think than only (a) is realistic.

Yeah. :/   Okay, I'll upload 3.3.14 shortly.


Regards,

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

Bug#1013890: closed by Jerome BENOIT (reply to calcu...@rezozer.net) (sagemath: ABI breakage without SONAME bump)

2022-08-02 Thread Paul Gevers


Hi,

On 02-08-2022 14:30, Debian Bug Tracking System wrote:

the gmp-ecm migration troubles appear to have been fixed.
So I am closing the report.


Hmmm, and how about derivatives, or people that build local packages 
linked to gmp-ecm? There's a reason why SONAME is tracked and why in 
Debian we want the library package to match the SONAME.


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1016528: [Pkg-javascript-devel] Bug#1016528: node-fetch: please upgrade to at least v3.2.3

On 02/08/2022 13:00, Jonas Smedegaard wrote:
> Package: node-fetch
> Version: 2.6.7+~2.6.1-1
> Severity: normal
> Tags: upstream
>

Please upgrade node-fetch to at least v3.2.3, needed by several projects
I am preparing for Debian.

(yes, I am aware that there is a package in experimental - this
bugreport is to track availability in unstable)

  - Jonas

Hi,

node-fetch >= 3 seems to break node-solid-rest [1], that's why I didn't 
pushed it to unstable. Since you're maintainer of node-solid-rest, could 
you fix that ?

Cheers,
Yadd

[1] 
https://release.debian.org/britney/pseudo-excuses-experimental.html#node-fetch

Bug#1016535: Merge request

2022-08-02 Thread Gard Spreemann

A merge request that accomplishes this has been filed on Salsa:

 https://salsa.debian.org/debian/ns3/-/merge_requests/4


 -- Gard
 


signature.asc
Description: PGP signature

Bug#991859: Is a different opinion about a license a case for the ctte?

2022-08-02 Thread Sam Hartman



[I  accidentally sent this as a private reply earlier this morning
 before Phil's message.]
 
 TL;DR: you don't have any recourse that is appropriate for this
 situation.
 All the hammers are bigger than your nail.

 > "Andreas" == Andreas Tille  writes:

 Andreas> Hi folks, before I follow the advise how to refer a
 Andreas> question to the CTTE[1] I'm wondering whether licensing
 Andreas> questions are also a topic here.  I admit I'm a bit unsure
 Andreas> whether this minor issue about a license is really worth
 Andreas> that even more people spent time into it.  I'm demotivated
 Andreas> myself by no progress in something I would consider
 Andreas> nitpicking about a non-issue.  But I would like to use this
 Andreas> as a general example to know whether CTTE could be of help
 Andreas> in licensing questions.

 The secretary ruled that the CT cannover overrule a delegate acting in
 their delegated responsibility,
 so no the CT cannot overrule ftpmaster.

 The CT could give advice to ftpmaster, especially if ftpmaster requested
 that advice.
 I'd expect the CT would be reluctant to give non-technical advice.

 The CT could set *technical policy* and I'd expect delegates would
 generally be expected to follow reasonable technical policy established
 by the CT or be accountable to the DPL and membership at large.
 However, I don't really think that license standards are technical
 enough to be technical policy.

 ftpmaster could establish an appeals procedure.

 The DPL could establish another set of delegates for setting license
 policy and separate that out from the ftpmaster delegation.
 I.E. someone sets license policy, and ftpmaster interprets it.
 That said, some questions could not be separated.
 In particular, because of liability concerns, if ftpmaster believes
 something is not redistributable, it would be highly inappropriate to
 ask them to redistribute it in the current Debian liability model.

 Any of this could be handled by a GR.

Bug#991859: Is a different opinion about a license a case for the ctte?

2022-08-02 Thread Philip Hands

Hi Andreas,

While I think you're right that this is just some example text, and
given that it was added in quite a large commit, touching many other
files, all of which are presumably under GPL, with no mention of the
intent to license that one file differently, it would be quite
surprising if that was the way that's supposed to be interpreted.

On the other hand, given that it's an example, perhaps the author wanted
to make sure people could cheerfully cut it into things that were
not GPLed?

I'd say the only way to be sure would be to ask the author(he seems
pretty active on GitHub, so seems likely to respond in a timely manner).

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#1012451: Control: fixed 1012451 31.0.2

2022-08-02 Thread Hans-Christoph Steiner




Control: fixed 1012451 31.0.2

Bug#1007889: All interfaces with dot symbol and without colon symbol will be deleted after ifdown call

2022-08-02 Thread Муравьев Александр


Dear Maintainers,

The situation is even worse. All interfaces with dot and without colon
symbol will be removed from the system after ifdown call.

After crashing the condition statement, instructions in "else" block
will be executed (link.defn, none down method):

 if test `cat /sys/class/net/%link%/type` -eq 32; then \
 echo 0x%vlan_id1% > /sys/class/net/%link%/delete_child; \
 else \
 ip link del %iface%; \
 fi if (iface_has(".") && !iface_has(":"))

Interface will be deleted.

Note that it will be created after ifup call only if it fits
. pattern. link.defn, none up:

 if test -d /sys/class/net/%link% && \
 ! ip link show %iface0% >/dev/null 2>&1; \
 then \
 if test `cat /sys/class/net/%link%/type` -eq 32; then \
 echo 0x%vlan_id1% > /sys/class/net/%link%/create_child; \
 else \
 ip link set up dev %link%; \
 ip link add link %link% name %iface0% type vlan id %vlan_id%; \
 fi; \

Best regards
Aleksandr Muravev

Bug#1016536: kexec-tools: broken on systemd without EFI

2022-08-02 Thread Martin-Éric Racine

Package: kexec-tools
Version: 1:2.0.24-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The init.d scripts are currently skipped on hosts running systemd. This is a 
bad idea:

$ sudo systemctl kexec
No kexec kernel loaded and autodetection failed.
Automatic loading works only on systems booted with EFI.

Therefore init.d scripts should only be skipped if we run systemd AND on an 
EFI-enabled host.

Martin-Éric

- -- System Information:
Debian Release: bookworm/sid
  APT prefers testing-debug
  APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: i386 (i586)

Kernel: Linux 5.18.0-3-686 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kexec-tools depends on:
ii  debconf [debconf-2.0]  1.5.79
ii  dpkg   1.21.9
ii  libc6  2.33-8
ii  lsb-base   11.2

kexec-tools recommends no packages.

kexec-tools suggests no packages.

- -- debconf information:
* kexec-tools/use_grub_config: true
* kexec-tools/load_kexec: true

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmLpOG4ACgkQrh+Cd8S0
17Z3BhAAlefaeJ0AvhG5buqM3ijFomQ7Scden50mZZCCEtteh3BE4UKucufYUz6N
47zV1L1KW9bH76Q8BPZ7/KhPZYmaURv3Hl6ZhXsMF7DadPEHeMiIzZQEU4G5dxK0
SiahHmWPvDPpp90NFHVw2Icy/qu22PlOYxRL61TSd0xRjXL91S7z9Rnn1Ikx8HO7
IP8x9KGKdJi6kCRGzOVKsijH0DB8925SL4bkXpMD/v1tP92J3IQofkBbklLgCgBL
+5WQnIto1tBQrT/abg7QzsPktqEshBJDDyctnIlyubQtLXBE/VAaFuj1/70H/X90
tgVOb5LmDqvoslpysk2fPk1obefJ+mDeG1MPAOglis9dMUk8N8TSqYxy4HqwLjXf
FjPX/cTZtm0vOfyTeK2cLUzpjvAP6lh5zLHhrbiiDCJ+VVtpa7f2JqeT8YCvcloJ
bc9VP4h4ypUFJDgzevgsfG2h+BrPxP0XQBw1rbW/7PkqRma4JKBrkV0g/gR1cshX
27kkmNaIL2n9ad4k6Spaqj/5WcwqxLlyuWMw639KgxI7k9j6n1DLB+8db8Fd3z1p
Uf2AGfX0GiuyRjhYinw1RCkJrWQPlzwxWHvex6xgugyWqISyts5Nb2VgpoNdxXgT
EG7xbBtRwJZzSzYIbnl38hwF5er/sY/TK2PJOHJJgwsXHZG0RPo=
=Uq1P
-END PGP SIGNATURE-

Bug#1016527: rst2man: --date should be used to form the .TH title heading

2022-08-02 Thread Ingo Schwarze

Strictly speaking, the third argument of the man(7) .TH macro is supposed
to be the date when a human being last edited the content of the manual
page, or in case rst2man(1) is used, the date when a human being last
edited the content of the input '*.rst' file, *not* the date when
rst2man(1) did the format conversion.

That said, i am able to reproduce that the rst2man(1) program contained
in the py3-docutils-0.17.1 package on OpenBSD-current also puts the line
"Generated on: 2022\-08\-02." into the NAME section, which is indeed a
severe man(7) syntax error.  So the bug appears to be operating system
independent.

If the date of the last human edit is unknown, putting the date on
which rst2man(1) was run into the third argument of the .TH macro
is of course still better than putting it into a place where it
violates the syntax of the man(7) language.  On the other hand,
couldn't the correct time be found by inspecting the mtime of
the inode of the '*.rst' file?

Finally, "Generated on: 2022\-08\-02" also contains a typographic
error:  \- is a minus sign, and you are not doing any subtraction
here.  The character you want is a dash, so

  Generated on: 2022\(en08\(en02

would be correct typography if you want to put it somewhere in the
body of the manual page.  In the .TH macro, by contrast, the correct
format for the third argument would be "2022-08-02" with no
escaping, neither "2022\-08\-02" nor "2022\(en08\(en02".

Bug#966524: "lvconvert --merge" does not remove the snapshot after completing

2022-08-02 Thread Antonio


Package: lvm2
Version:2.03.16-1
Dear Maintainer,
I would like to remember that this problem is still present.

Thanks,
Antonio

Bug#1016535: ns3: Please enable building of version module

2022-08-02 Thread Gard Spreemann

Source: ns3
X-Debbugs-Cc: g...@nonempty.org
Version: 3.36.1+dfsg-4
Severity: wishlist

Dear Maintainer,

As of upstream 3.32, ns3 comes with an optional "version" module
[1]. This module gives run-time access to ns3 version information [2].

The module is useful, and I encourage you to please enable its building
and inclusion into the Debian package. Due to upstream's convoluted
build system ("helpfully" trying to extract this information from
git(!)), it's a bit of a struggle. I have a working suggestion that I'll
create a Salsa merge request for shortly.

[1] https://www.nsnam.org/docs/tutorial/html/getting-started.html#build-version

[2] https://www.nsnam.org/docs/release/3.36/doxygen/classns3_1_1_version.html



 Best,
 Gard


signature.asc
Description: PGP signature

Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

2022-08-02 Thread Jérémy Lal

Package: openssl
Version: 3.0.5-1
Followup-For: Bug #1016526

The same test also fails when building nodejs on riscv64.


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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 openssl depends on:
ii  libc62.33-8
ii  libssl3  3.0.5-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20211016

-- Configuration Files:
/etc/ssl/openssl.cnf changed [not included]

-- no debconf information

Bug#1016533: libxslt1.1: CVE-2021-30560 not fixed in stable

2022-08-02 Thread Michael Kesper

Package: libxslt1.1
Version: 1.1.34-4
Severity: important
X-Debbugs-Cc: mkes...@web.de

Dear Maintainer,

please apply the upstream patch for CVE-2021-30560 to libxslt in Debian stable 
(bullseye).
This is a non-disputed security issue and chromium was fixed but not libxslt.
https://security-tracker.debian.org/tracker/CVE-2021-30560

Best regards
Michael

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

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

Versions of packages libxslt1.1 depends on:
ii  libc62.31-13+deb11u3
ii  libgcrypt20  1.8.7-6
ii  libxml2  2.9.10+dfsg-6.7+deb11u2

libxslt1.1 recommends no packages.

libxslt1.1 suggests no packages.

-- no debconf information

Bug#657711: please make COPYFILES more flexible

2022-08-02 Thread Guillem Jover

Control: forwarded -1 https://codeberg.org/shelter/reschroot/pulls/3
Control: tags -1 patch

On Sat, 2012-01-28 at 09:26:03 +0100, Marc Haber wrote:
> Package: schroot
> Version: 1.4.24-1
> Severity: wishlist

> maybe one wants to copy files to a chroot that are not active in the
> host system. For example, I might want apt in the chroot not to honor
> recommends and suggests, but in the host, this behavior is fine.
> 
> To solve this, I would like schroot to copy a file from
> /etc/schroot/foo/files/etc/apt/apt.conf.d/70RecommendsSuggests to
> /etc/apt/apt.conf.d/70RecommendsSuggests in the schroot.
> 
> To allow this, the COPYFILES functionality could be changed to allow
> two file names per line. If only one is given, behavior is not
> changed, preserving backwards-compatibility. If two are given, one is
> the source path from the host system, one is the target path inside
> the chroot.

I implemented this for myself some time ago, and submitted it to the
previous upstream repo, where it got merged. I resubmitted this again
to the new fork, as it branched from a different point in history.

Thanks,
Guillem

Bug#1013578: golang-github-prometheus-exporter-toolkit: FTBFS: dh_auto_test: error: cd _build && go test -vet=off -v -p 8 github.com/prometheus/exporter-toolkit/web github.com/prometheus/exporter-tool

2022-08-02 Thread Santiago Vila


Hi.

I have not tested in sid, but these are my statistics:

In bookworm, it FTBFS for me:

100% of the time on systems with 1 CPU.
 80% of the time on systems with 2 CPUs.

In bullseye, it FTBFS for me:

100% of the time on systems with 1 CPU
  0% of the time on systems with 2 CPUs.

I'm currently using Hetzner machines with 8 GB of RAM and either 1 or 2 
CPUs. To emulate a single CPU on a machine with 2 CPUs I do this in 
/etc/default/grub:


GRUB_CMDLINE_LINUX="nr_cpus=1"

I can give you access to a machine where this happens, please contact me 
privately for details.


Thanks.

Bug#991859: Is a different opinion about a license a case for the ctte?

2022-08-02 Thread Andreas Tille

Hi folks,

before I follow the advise how to refer a question to the CTTE[1] I'm
wondering whether licensing questions are also a topic here.  I admit
I'm a bit unsure whether this minor issue about a license is really
worth that even more people spent time into it.  I'm demotivated myself
by no progress in something I would consider nitpicking about a non-issue.
But I would like to use this as a general example to know whether CTTE
could be of help in licensing questions.

FTPMaster was asking to mention the MIT license of the test-dummy
package[2] since "upstream decided that this test package should have a
different license than the rest of his software and said so in the
corresponding setup.py"[3].  The statement of FTPMaster is based on line
9 of a 12 line of code example file[4].  It contains the string
"license='MIT'" while all other code of the package is GPL-3.

I expressed that an example string "license='MIT'" is not a license
statement but ftpmaster gave a second reject.  I feel in the situation
to do something that is wrong but accepted by ftpmaster or simply do
not provide our users with this package (since I have better things to
do than play pingpong).

At the DebConf CTTE BoF I was just wondering, whether such kind of
licensing questions are a topic for CTTE since I do not see any other
instance that could stop this pingpong game.  So for the moment I would
just like an answer like:  Yes, Andreas, we like to draw a decision
about this, please file an according bug report.

Thanks a lot for working as CTTE members

  Andreas.

[1] https://www.debian.org/devel/tech-ctte.en.html
[2] 
https://alioth-lists.debian.net/pipermail/r-pkg-team/2022-February/024165.html
[3] 
https://alioth-lists.debian.net/pipermail/r-pkg-team/2022-February/024248.html
[4] 
https://salsa.debian.org/r-pkg-team/r-bioc-basilisk/-/blob/master/inst/example/inst/test_dummy/setup.py#L9

-- 
http://fam-tille.de

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

2022-08-02 Thread Patrick Franz

Hej,

Am Dienstag, 2. August 2022, 13:34:24 CEST schrieb Didier 'OdyX' Raboud:
> Hello there,
[...]
> I can't remember what the Qt-KDE Extras practices is, so I checked;
> https://qt-kde-team.pages.debian.net/gitguidelines.html seems to be
> the latest recommendations.

Almost all of the repositories under https://salsa.debian.org/qt-kde-team only 
contain the debian/ directory and no upstream sources
with the master branch pointing to the unstable packaging.

If you want to go that route, I'd delete the repo just as Didier 
suggested.

The quickest way to get help in such questions is ususally to ask on IRC 
in #debian-qt-kde.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1016531: ITP: node-ky -- tiny and elegant HTTP client based on the browser Fetch API

2022-08-02 Thread Jonas Smedegaard

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 
X-Debbugs-Cc: debian-de...@lists.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: node-ky
  Version : 0.31.1
  Upstream Author : Sindre Sorhus 
* URL : https://github.com/sindresorhus/ky
* License : Expat
  Programming Lang: JavaScript
  Description : tiny and elegant HTTP client based on the browser Fetch API

 Ky is a tiny and elegant HTTP client
 based on the browser Fetch API.
 Ky targets modern browsers and Deno.
 For older browsers,
 you will need to transpile and use fetch and globalThis polyfills.
 For use only with Node.js, check out Got.
 For isomorphic needs (like server-side rendering),
 check out ky-universal.
 .
 It's just a tiny file with no dependencies.
 .
 Benefits over plain fetch:
  * Simpler API
  * Method shortcuts ( ky.post() )
  * Treats non-2xx status codes as errors (after redirects)
  * Retries failed requests
  * JSON option
  * Timeout support
  * URL prefix option
  * Instances with custom defaults
  * Hooks
 .
 Deno is a runtime for JavaScript and TypeScript
 that is based on the V8 JavaScript engine
 and the Rust programming language.
 .
 A polyfill is code that implements a feature
 on web browsers that do not support the feature.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is needed by solid-server (bug#910111).
It will be maintained in the js-team section of Salsa, here:
.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLpFZUACgkQLHwxRsGg
ASHPtQ/9Hq6XvMbuH1z4Txj9XfbGvasPTEw7oS78CWaDe9pWmuE6LvBD1BPDMlw6
rk7aZGsxndQaIBCk1zsimcV7i6Q0nkl4tkVy6bB18M2ivpDi99oiaTkPYtHVcinN
KG1aX4KX0U5qHghQAdCUPjrCKFIM4qaLlgoLSN+H+GNWOnqHok87Bh1dgkiaJBjE
AYGTwlVYA+2/OPhcJQGbwhed4vvODhraPzXwME4f0KMj7wfDXB1hjxgJX/lou0Yd
4OTTYnILme0yPIiobUyTqtcYWNDRGpRCiHZdIx5KtvGPz+1MgdimB8t9ZckU+of4
ZYw3FTftL09FAvZDtDntRlyrvomUxloa/XjTa88BKe3r+OLFgBWS9EiR02tzOx2J
35OMPCMdo+vx41EpTjQUeVg5co8UAKDEG+htJhE9XYYKSdfNPWUvYFj9wh4eUlnj
yG4GNzvDJDT6frYeDcKEtYNNLQUQ3yJlRYoXSNFK8owJB2SPkjs3AfAorGRG6Qku
GNASgHKanuV39HFjq8a1YmQlmKeRgtPp/E0SCMHDAxYLVzdLlNJfjqoTen93dKWs
XinxRrRyREPKNO3qpe2M210qYPlbn6lOA8/ILpEgdgu4To8SSTK+9PXu5ZMffiAd
JHVV9pKJdIo9GVmHx6vPFqOGcACoWPt6V5hee/dgPgSierKf5Jg=
=9jb1
-END PGP SIGNATURE-

Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` change japanese to anthy with kanji key.

2022-08-02 Thread Osamu Aoki

Hi,

> -Original Message-
> From: Yukiharu YABUKI 
> To: Osamu Aoki 
> Cc: 1014...@bugs.debian.org
> Subject: Re: Bug#1014052: ibus:After rebooted, I must do `ibus-daemon -rxd` 
> change
> japanese to anthy with kanji key.
> Date: Mon, 1 Aug 2022 02:14:11 +0900
> 
> ...

> I did 'ps axjf'. This output was too big. I selected from output.
> ...
> python3 /usr/share/ibus-anthy/engine/main.py --ibus 1  385655  385641
> 385641 ? -1 Sl1000   0:11 /usr/libexec/ibus-x11
> --kill-daemon
> 

I don't know but "kill" sounds dangerous :-) but maybe OK.   It's installed by 
ibus.

Anyway, since you are running relatively minor desktop with i3, this may be the
reason.  Proper working of im-config rely on xdm/kdm like start up.

Since it is almost impossible to figure-out when did it broke, the best thing 
is to
set up testing VMs.

Then try different DE settings: GNOME -> KDE -> LXDE -> i3
Once you know when things break, we have better chance to identify issue.

Good luck.

Osamu

Bug#1016530: Fwd: mesa-utils-bin: some applications do not start

2022-08-02 Thread Antonio


Package: mesa-utils-bin
Version: 8.5.0-1
Severity: normal

Dear Maintainer,
there are some applications that no longer start and return this error:

$ glxgears
glxgears: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full:
Assertion `e != ESRCH || !robust' failed.
Annullato

$ glxinfo
name of display: :0
glxinfo: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full: 
Assertion

`e != ESRCH || !robust' failed.
Annullato

$ glxheads
glxheads: exercise multiple GLX connections (any key = exit)
Usage:
  glxheads xdisplayname ...
Example:
  glxheads :0 mars:0 venus:1
glxheads: ../nptl/pthread_mutex_lock.c:424: __pthread_mutex_lock_full:
Assertion `e != ESRCH || !robust' failed.
Annullato

Thanks,
Antonio


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'stable'), (100, 'experimental')

Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-15.2-liquorix-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) (ignored: 
LC_ALL set to it_IT.UTF-8), LANGUAGE=it

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

Versions of packages mesa-utils-bin depends on:
ii  libc6   2.33-8
ii  libegl1 1.4.0-1
ii  libgl1  1.4.0-1
ii  libgles2    1.4.0-1
ii  libwayland-client0  1.21.0-1
ii  libwayland-egl1 1.21.0-1
ii  libx11-6    2:1.8.1-1

mesa-utils-bin recommends no packages.

mesa-utils-bin suggests no packages.

-- no debconf information

Bug#981009: charybdis abandoned upstream, do not ship in bullseye

* Antoine Beaupre :
> After a somewhat long period of uncertainty, Charybdis has been
> finally abandoned upstream. The official git repository here:
> 
> https://github.com/charybdis-ircd/charybdis
> 
> .. is marked as "archived by the owner [and] read-only".

Is it time to file an RM bug, given that its probably going to be
solanum?

Chris

Bug#1008816: ITP: kwin-bismuth -- KDE Plasma extension for tiling windows

2022-08-02 Thread Didier 'OdyX' Raboud

Hello there,

I found the repo; https://salsa.debian.org/qt-kde-team/extras/kwin-bismuth

One thing that struck me first is that the repository isn't in any of the 
standard git formats.
See https://dep-team.pages.debian.net/deps/dep14/ for a long description of the 
possibilities.

I can't remember what the Qt-KDE Extras practices is, so I checked; 
https://qt-kde-team.pages.debian.net/gitguidelines.html seems to be the latest 
recommendations.

Basically, I think it's reasonable to say that most Debian packages' 
repositories try to avoid mixing upstream and debian/* changes on the same 
branches. See https://wiki.debian.org/PackagingWithGit for some documentation 
on that area; specifically  
https://honk.sigxcpu.org/piki/projects/git-buildpackage/ git-buildpackage is 
pretty standard nowadays.

As for what I'm concerned, my ideal repository has an upstream/latest branch 
with upstream's own history, upstream/1.2.3 tags for releases, debian/latest 
for the changes (and initial addition) in debian/*, and debian/1.2.3-1 tags 
upon releases. Now, how to go there from where you are? I'd basically start a 
new repo from scratch, start from upstream's branch tip and reconstruct (in one 
commit, or more) the debian/latest branch.

Finally, another thing that will really help testing many Debian'isms before 
going to sid is the Salsa CI pipeline: 
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/README.md This 
will test many many things out-of-the-box, from the repository; so it'll also 
error-out early, and before reaching the Debian archive.

I'm aware this is a lot of links, and a lot of specific quirks to learn about 
Debian specificities. But getting them right upfront will make any and all 
later collaboration much easier and faster as the repository (and package) will 
look familiar to the rest of Debian. It's really worth going through the effort!

Best,
OdyX


2 août 2022 04:43 "Blake Lee"  a écrit:
> 
> I've moved over the repository into Salsa, updated it for the latest release 
> `3.1.2`.
> 
> I've built it on my Sid desktop with sbuild, lintian reports no errors, and 
> it the software is
> working as expected.
> 
> Let me know if you see anything you would change.

Bug#1016529: webp-pixbuf-loader: backport to stable

2022-08-02 Thread michel

Package: webp-pixbuf-loader
Version: 0.0.5-5
Severity: wishlist
X-Debbugs-Cc: okgomdjgbm...@gmail.com

Dear Maintainer,


It would be nice to backport this to stable. It was probably a mistake, not to 
include it earlier.

I already installed the binary package that was ment for testing and it works 
fine.
The only additional dependency is libwebp7. That's a brand new lib, and they 
are no conflicts.
It seams like a painless backport.

Bug#1016528: node-fetch: please upgrade to at least v3.2.3

2022-08-02 Thread Jonas Smedegaard

Package: node-fetch
Version: 2.6.7+~2.6.1-1
Severity: normal
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please upgrade node-fetch to at least v3.2.3, needed by several projects
I am preparing for Debian.

(yes, I am aware that there is a package in experimental - this
bugreport is to track availability in unstable)

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmLpA6wACgkQLHwxRsGg
ASGxzg/9GE3ROAVwppNJQDSvle2baV/v68kgALAB/tLvmF5ZitIQVGeRbmr2CRXG
yOTZ++tv89qLg78RVLaFcTJR7W2oYbBwrAPtQSMRiS7zROjPqjlnZMe7Dx2+eDb9
eUX9rDTeKT+X7wQKuaIuMkykdTIcr2Ipvq80RWgt/icIuVQyZPEvA2QfGwDW9pBq
DRftUQ7G7eL7pig9I8xv74D6toA6wD7nXdyWs8oDDqdd/s0yVyDWHyCIpQLpqNgS
XvOytl1ncYNTf+MI0c69yVuo+RbXLFjWgdSym46XURZaa1Ob4GiXNhgW+u9KjWgr
dMEbndHpGSRIreqWZnSTA5VllnZslN25bY8KqGjupQ0XryCbpFIvgxZPzmgxHCxP
8Fw+FyZ7/sqfGP9ONSjDb6/lq3N7zCJ603HAogRLRGboZuzBIFeqlMwt6LbrhkY2
PI+PVaUZKoe/dik13iplL6tgcvxQ/+7G5evQWoFiOAknyWUGwc9vq4J/Yav11TdR
2kSVivBMEkbKjbuEyTtZFjZ5XUUCMQZev2WuDbCsfakV3Ltlvp09bhUgX4+3tomN
ujqCGmq7Zl1n/xH39Lu3u2WrhdArQUQMxYi5vfOyNNNq1IBw2zYJrN5Y+BCG/jqF
D/C8lyhkyySUbltY8x0JkN18lLIYoCU9GNSece5mhVXLlxtjhg4=
=TbB9
-END PGP SIGNATURE-

Bug#947892: dma: postinst maintainer script fails

2022-08-02 Thread d.petr

Same mistake for me.

Apparently related to the word SMARTHOST in /etc/dma/dma.conf.

When I leave the line
#SMARTHOST
and add the line
SMARTHOST 192.168.222.23,
ie.
---
# Your smarthost (also called relayhost).  Leave blank if you don't want
# smarthost support.
# NOTE: on Debian systems this is handled via debconf!
# Please use dpkg-reconfigure dma to change this value.
#SMARTHOST
SMARTHOST 192.168.222.23
---
error occurs.

The error also occurs when
#SMARTHOST
#SMARTHOST 192.168.222.23

Here the error does not occur
#SMARTHOST 192.168.222.23
#SMARTHOST

Here also the error does not occur
SMARTHOST 192.168.222.23
#SMARTHOST

Petr

Bug#1016527: rst2man: --date should be used to form the .TH title heading

2022-08-02 Thread Alejandro Colomar

Package: python3-docutils
Version: 0.17.1+dfsg-2
Severity: normal
Tags: upstream
X-Debbugs-Cc: Alejandro Colomar , , 
Quentin Monnet 

Hi,

The --date argument to rst2man(1) produces the following text:

Generated on: -MM-DD

And that text is put in the NAME section of the manual page.  That
is incorrect.  The date should be put as the 3rd argument to the
.TH macro, preferably in ISO 8601 format (-MM-DD):

.TH title section date source-and-version manual


Cheers,

Alex



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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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 python3-docutils depends on:
ii  docutils-common  0.17.1+dfsg-2
ii  python3  3.10.5-3
ii  python3-roman3.3-1

Versions of packages python3-docutils recommends:
ii  libpaper-utils1.1.28+b1
ii  python3-pil   9.2.0-1+b1
ii  python3-pygments  2.12.0+dfsg-2

Versions of packages python3-docutils suggests:
pn  docutils-doc
pn  fonts-linuxlibertine | ttf-linux-libertine  
pn  texlive-lang-french 
ii  texlive-latex-base  2022.20220722-1
ii  texlive-latex-recommended   2022.20220722-1

-- no debconf information

Bug#1016526: openssl: Regression on mips64el throws error:1E08010C:DECODER

2022-08-02 Thread Jérémy Lal

Package: openssl
Version: 3.0.5-1
Severity: normal
Control: affects -1 nodejs

Hi,

while building nodejs 18.6.0+dfsg-4 on mips64el, some SSL tests did regress,
https://buildd.debian.org/status/logs.php?pkg=nodejs=mips64el
(look for "not ok" tests).

In particular, test-crypto-sign-verify test failed with an unexpected error:
'error:1E08010C:DECODER routines::unsupported'

I suppose the root cause is similar to the one for
[EC code appears to be broken on s390x](https://bugs.debian.org/1016290),
but it's not the same bug.

Also note that nodejs tests run with
CipherString = DEFAULT:@SECLEVEL=1

Also the same tests don't fail on mipsel, or any other arch,
including s390x.

Jérémy



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

Kernel: Linux 5.18.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (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 openssl depends on:
ii  libc62.33-8
ii  libssl3  3.0.5-1

openssl recommends no packages.

Versions of packages openssl suggests:
ii  ca-certificates  20211016

-- Configuration Files:
/etc/ssl/openssl.cnf changed [not included]

-- no debconf information

Bug#314832: unzip: does not respect umask

2022-08-02 Thread Bruno Haible

Package: unzip
Version: 6.0
Severity: normal

I still see this bug in version 6.0 (6.0-26ubuntu3, to be precise).

It's a security issue (because it allows other users on the same machine to
overwrite the extracted files, if they know the file names).

As such:
  * It should be treated with severity at least 'normal', per [1].
  * Secure behaviour should be the default, not just enabled by an option.
Even if it breaks backward compatibility!

[1] https://www.debian.org/Bugs/Developer.en.html#severities

Bug#1016525: python-h5netcdf: CI tests fail with h5py 3.7.0

2022-08-02 Thread Drew Parsons

Source: python-h5netcdf
Version: 1.0.1-1
Severity: serious
Tags: patch
Justification: debci
Control: forwarded -1 https://github.com/h5netcdf/h5netcdf/issues/179

h5netcdf tests fail with h5py 3.7.0, which was recently uploaded to
unstable.

The problem is fixed upstream, the fix is available in the new release
h5netcdf 1.0.2



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

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

Bug#1016090: python-django breaks lots of autopkgtests

2022-08-02 Thread Raphael Hertzog

Hi,

On Mon, 01 Aug 2022, Chris Lamb wrote:
> Regardless of that though, I think we have two options:
> 
> a) Revert back to the 3.2.14 LTS version in Debian unstable.
> 
> b) Wait for the 4.x stream to become designated LTS. I believe this
>should happen with version 4.2, due for release in about 6 or 7
>months:

The Django and Debian releases are not well aligned. The 4.2 release
is planned in April 2023 so a bit late given the freeze. If the number of
reverse dependencies was lower, it could argued to try to have some sort
of exceptions and offering extra work to help fix/migrate the reverse
dependencies.

But unfortunately I assume that most of the important reverse dependencies
track mainly the LTS releases and the upstream fixes for 4.x compatibility
will only materialize once Django 4.2 is released and we would have to
commit to too much work to be able to push Django 4.x (including 4.2~rc1
or similar) in bookworn.

As such, as much as I hate it, I think than only (a) is realistic.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS

Bug#1013929: src:goffice: FTBFS on mips64el

2022-08-02 Thread Dmitry Smirnov

Hi Ludovic,

On Sunday, 31 July 2022 12:36:04 AM AEST Ludovic Rousseau wrote:
> I am the Debian maintainer of the package grisbi that depends on
> libgoffice-0.10-10
> 
> I see no update on this bug since 3 weeks.
> 
> It looks like the fix is proposed upstream at
> https://gitlab.gnome.org/GNOME/goffice/-/issues/59#note_1495045

Sorry, I'm being very slow lately...

I've applied the upstream patch but unfortunately it did not fix the
problem...


> Dmitry, do you need help?

Yes please. I'm clueless what to do next. Thank you.

-- 
Best wishes,
 Dmitry Smirnov
 GPG key : 4096R/52B6BBD953968D1B

---

The entire notion of "a government of the people, by the people, and for
the people," while it makes nice feel-good political rhetoric, is a
logical impossibility. A ruling class cannot serve or represent those it
rules any more than a slave owner can serve or represent his slaves.
 -- Larken Rose, The Most Dangerous Superstition

---

The Face Mask Folly in Retrospect
https://swprs.org/the-face-mask-folly-in-retrospect/


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

Bug#982459: mdadm examine corrupts host ext4

Control: reassign -1 src:linux

Dear Håkan,

thanks for reporting back and testing!

* Håkan T Johansson  [220801 19:31]:
> On Sun, 31 Jul 2022, Chris Hofstaedtler wrote:
> 
> > I can't see a difference that should matter from userspace.
> > 
> > I have stared a bit at the kernel code... there have been quite some
> > changes and fixes in this area. Which kernel version were you
> > running when testing this?
> > 
> > Could you retry on something >= 5.9? I.e. some version with patch
> >08fc1ab6d748ab1a690fd483f41e2938984ce353.
> 
> I believe that I was running 5.10 (bullseye).
> 
> It looks like 5.18 (from backports) does not show the issue!  (i.e. works)

Okay, I think we are now clearly in "this is not an mdadm bug per
se" territory (-> reassigning to src:linux).

[..]
>   This time I did get some dmesg BUG output as well (attached).
>   It does not seem to be the same backtrace on two occurances.
> 
>   I also noticed that the BUG: report in dmesg does not happen directly
>   when doing 'mdadm --examine --scan --config=partitions'.  It rather
>   occurs when some activity happens on the host filesystem, e.g.
>   a 'touch /root/a' command.
> 
> host:
>   linux-image-5.18.0-0.bpo.1-amd64  5.18.2-1~bpo11+1
> 
>   (did not re-install anything else, except upgraded zfs, also from
>   backports (since pure bullseye would not compile with 5.18))
> 
>   Does not exhibit the problem.
> 
> I have tried with both kernels several times, and it was repeatable that
> 5.10 got stuck while 5.18 does not show issues.

Its good that this now works in 5.18. However I'm not sure how we
should find the commit fixing this - in 5.14 lots of block layer
code was shuffled around/refactored.

If you have the time, maybe trying the various kernel versions
between 5.10 and 5.18 would be a good start. If they are not in
backports anymore, they should still be at
  http://snapshot.debian.org/package/linux/

> Reminder: to get the issue, /dev/ should not be mounted in the chroot.
> With /dev/ mounted, 5.10 also works.

I'll see if I can repro this on 5.10, but need to find a box first.

Best,
Chris

> [mån aug  1 15:53:08 2022] BUG: kernel NULL pointer dereference, address: 
> 0010
> [mån aug  1 15:53:08 2022] #PF: supervisor read access in kernel mode
> [mån aug  1 15:53:08 2022] #PF: error_code(0x) - not-present page
> [mån aug  1 15:53:08 2022] PGD 0 P4D 0 
> [mån aug  1 15:53:08 2022] Oops:  [#1] SMP PTI
> [mån aug  1 15:53:08 2022] CPU: 2 PID: 284256 Comm: cron Tainted: P   
> OE 5.10.0-16-amd64 #1 Debian 5.10.127-2
> [mån aug  1 15:53:08 2022] Hardware name: Dell Computer Corporation PowerEdge 
> 2850/0T7971, BIOS A04 09/22/2005
> [mån aug  1 15:53:08 2022] RIP: 
> 0010:__ext4_journal_get_write_access+0x29/0x120 [ext4]
> [mån aug  1 15:53:08 2022] Code: 00 0f 1f 44 00 00 41 57 41 56 41 89 f6 41 55 
> 41 54 49 89 d4 55 48 89 cd 53 48 83 ec 10 48 89 3c 24 e8 ab d7 bb e1 48 8b 45 
> 30 <4c> 8b 78 10 4d 85 ff 74 2f 49 8b 87 e0 00 00 00 49 8b 9f 88 03 00
> [mån aug  1 15:53:08 2022] RSP: 0018:ae27c059fd60 EFLAGS: 00010246
> [mån aug  1 15:53:08 2022] RAX:  RBX: 9d1b94505480 RCX: 
> 9d1bc52e5e38
> [mån aug  1 15:53:08 2022] RDX: 9d1bc13782d8 RSI: 0c14 RDI: 
> c096feb0
> [mån aug  1 15:53:08 2022] RBP: 9d1bc52e5e38 R08: 9d1be04d5230 R09: 
> 0001
> [mån aug  1 15:53:08 2022] R10: 9d1bc985f000 R11: 001d R12: 
> 9d1bc13782d8
> [mån aug  1 15:53:08 2022] R13: 9d1be04d5000 R14: 0c14 R15: 
> 9d1bc13782d8
> [mån aug  1 15:53:08 2022] FS:  7fed5ecb1840() 
> GS:9d1cd7c8() knlGS:
> [mån aug  1 15:53:08 2022] CS:  0010 DS:  ES:  CR0: 80050033
> [mån aug  1 15:53:08 2022] CR2: 0010 CR3: 0001a46d8000 CR4: 
> 06e0
> [mån aug  1 15:53:08 2022] Call Trace:
> [mån aug  1 15:53:08 2022]  ext4_orphan_del+0x23f/0x290 [ext4]
> [mån aug  1 15:53:08 2022]  ext4_evict_inode+0x31f/0x630 [ext4]
> [mån aug  1 15:53:08 2022]  evict+0xd1/0x1a0
> [mån aug  1 15:53:08 2022]  __dentry_kill+0xe4/0x180
> [mån aug  1 15:53:08 2022]  dput+0x149/0x2f0
> [mån aug  1 15:53:08 2022]  __fput+0xe4/0x240
> [mån aug  1 15:53:08 2022]  task_work_run+0x65/0xa0
> [mån aug  1 15:53:08 2022]  exit_to_user_mode_prepare+0x111/0x120
> [mån aug  1 15:53:08 2022]  syscall_exit_to_user_mode+0x28/0x140
> [mån aug  1 15:53:08 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [mån aug  1 15:53:08 2022] RIP: 0033:0x7fed5eea2d77
> [mån aug  1 15:53:08 2022] Code: 44 00 00 48 8b 15 19 a1 0c 00 f7 d8 64 89 02 
> b8 ff ff ff ff eb bc 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 03 00 00 00 0f 
> 05 <48> 3d 00 f0 ff ff 77 01 c3 48 8b 15 e9 a0 0c 00 f7 d8 64 89 02 b8
> [mån aug  1 15:53:08 2022] RSP: 002b:7ffd50452818 EFLAGS: 0202 
> ORIG_RAX: 0003
> [mån aug  1 15:53:08 2022] RAX:  RBX: 55dab4578910 RCX: 
> 7fed5eea2d77
> [mån

Bug#1016512: multipath-tools: ships /usr/share/bug/multipath-tools-boot/script