Bug#1063832: mailman3: Wrong database scheme for postgresql not resolved for stable
Package: mailman3 Version: 3.3.8-2~deb12u1 Severity: important Dear Maintainer, this bug is related to bug #1040708, where an issue with database scheme for postgresql was resolved in package version mailman3/3.3.8-3. That version never landed in stable, despite the bug was tagged bookworm (actual stable), so using mailman3 with postgres doesn't work out of the box in stable/bookworm, as the service refuses to start. I don't know if this is related with a transition occurring with mailman3 packages, but I think it is worth to leave the version 3.3.8-3 to reach the stable repository. Thanks Paolo
Bug#1058929: Warning at install time could be fixed and will become errors in future versions
Package: python3-wxgtk4.0
Version: 4.2.0+dfsg-3
Severity: minor
While updating:
Setting up python3-wxgtk4.0 (4.2.1+dfsg-2) ...
/usr/lib/python3/dist-packages/wx/lib/docview.py:1026: SyntaxWarning: invalid
escape sequence '\*'
"""
/usr/lib/python3/dist-packages/wx/lib/layoutf.py:135: SyntaxWarning: invalid
escape sequence '\s'
rexp1 = re.compile('^\s*([tlrbhwxy])\s*([!\?\*])\s*(\d*)\s*$')
/usr/lib/python3/dist-packages/wx/lib/layoutf.py:136: SyntaxWarning: invalid
escape sequence '\s'
rexp2 =
re.compile('^\s*([tlrbhwxy])\s*([=%<>^_])\s*([tlrbhwxy]?)\s*(\d*)\s*#(\d+)\s*$')
/usr/lib/python3/dist-packages/wx/lib/wxpTag.py:17: SyntaxWarning: invalid
escape sequence '\*'
'''
/usr/lib/python3/dist-packages/wx/tools/pywxrc.py:524: SyntaxWarning: invalid
escape sequence '\S'
subclass = re.sub("^\S+\.", "", subclass)
/usr/lib/python3/dist-packages/wx/tools/pywxrc.py:763: SyntaxWarning: invalid
escape sequence '\ '
"""
Note that Puthon 3.12 changelog reports:
A backslash-character pair that is not a valid escape sequence now generates a
SyntaxWarning, instead of DeprecationWarning. For example,
re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an invalid escape
sequence, use raw strings for regular expression: re.compile(r"\d+\.\d+")). In a
future Python version, SyntaxError will eventually be raised, instead of
SyntaxWarning. (Contributed by Victor Stinner in gh-98401.)
So, this is something which can be easily fixed and reported upstream, just in
case.
-cheers
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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-wxgtk4.0 depends on:
ii libc6 2.36-9+deb12u3
ii libgcc-s1 12.2.0-14
ii libstdc++612.2.0-14
ii libwxbase3.2-13.2.2+dfsg-2
ii libwxgtk-gl3.2-1 3.2.2+dfsg-2
ii libwxgtk3.2-1 3.2.2+dfsg-2
ii python3 3.11.2-1+b1
ii python3-numpy 1:1.24.2-1
ii python3-pil 9.4.0-1.1+b1
ii python3-six 1.16.0-4
python3-wxgtk4.0 recommends no packages.
Versions of packages python3-wxgtk4.0 suggests:
pn wx3.2-doc
-- no debconf information
Bug#1033482: also here
Hi, I have tripped onto this while following blindly the automatic sbuild setup using sbuild-debian-developer-setup described here: https://wiki.debian.org/sbuild#Automatic_setup_using_sbuild-debian-developer-setup Alberto's workaround (sudo apt install -t bookworm-backports debootstrap) worked for me. Paolo
Bug#1055637: Debian debdiff attached
For your convenience, i've attached the Debian debdiff - the original patch
contained some binaries as part of the unit test, i removed them and i kept only
the code section.
Let me know.
--
bye,
p.
diff -Nru libabigail-2.4/debian/changelog libabigail-2.4/debian/changelog
--- libabigail-2.4/debian/changelog 2023-10-31 11:03:41.0 +
+++ libabigail-2.4/debian/changelog 2023-11-09 11:29:34.0 +
@@ -1,3 +1,10 @@
+libabigail (2.4-2) unstable; urgency=medium
+
+ *
debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch:
+- Fix assert violation while setting translation unit for unique types
(Closes: #1055637)
+
+ -- Paolo Pisati Thu, 09 Nov 2023 11:29:34 +
+
libabigail (2.4-1) unstable; urgency=medium
* New upstream version.
diff -Nru
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
---
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
1970-01-01 00:00:00.0 +
+++
libabigail-2.4/debian/patches/0001-Bug-31045-Don-t-try-setting-translation-unit-for-uni.patch
2023-11-09 11:29:34.0 +
@@ -0,0 +1,100 @@
+From 35eed7922edf2e49604ff9d60eba20357152e36c Mon Sep 17 00:00:00 2001
+From: Dodji Seketeli
+Date: Wed, 8 Nov 2023 14:46:04 +0100
+Subject: [PATCH] Bug 31045 - Don't try setting translation unit for unique
+ types
+
+Unique types (void, pointer to void and variadic parameter types)
+should not have their translation unit set whenever they are being
+added to a scope. This is because they are supposed to be created
+independently from any translation unit, even if technically, they are
+set to the translation unit they are referenced from, for the first
+time.
+
+To handle this, a new function maybe_set_translation_unit is created
+to handle the setting of the translation unit for decls added to a
+scope by scope_decl::{add,insert}_member_decl. That new function
+asserts that unique types should have their translation unit be set.
+
+ * src/abg-ir.cc (maybe_set_translation_unit): Define new static
+ function.
+ (scope_decl::{add,insert}_member_decl): Use it.
+ *
tests/data/test-abidiff-exit/PR31045/zfs-abigail-2.4/libnvpair.{abi,so,suppr}:
+ New test input files.
+ *
tests/data/test-abidiff-exit/PR31045/zfs-abigail-2.4/test-PR31045-report-1.txt:
+ New reference test output.
+ * tests/data/Makefile.am: Add the new test material above to
+ source distribution.
+ * tests/test-abidiff-exit.cc (in_out_specs): Add the input above
+ to this test harness.
+
+Signed-off-by: Dodji Seketeli
+---
+ src/abg-ir.cc | 42 +-
+ 1 file changed, 30 insertions(+), 12 deletions(-)
+
+--- a/src/abg-ir.cc
b/src/abg-ir.cc
+@@ -7974,6 +7974,34 @@
+ && get_canonical_types().empty());
+ }
+
++/// Set the translation unit of a decl
++///
++/// It also perform some IR integrity checks.
++///
++/// This is a sub-routine of scope_decl::{insert,add}_member_decl.
++///
++/// @param decl the decl to set the translation unit for.
++///
++/// @param tu the translation unit to set.
++static void
++maybe_set_translation_unit(const decl_base_sptr& decl,
++ translation_unit* tu)
++{
++ if (translation_unit* existing_tu = decl->get_translation_unit())
++// The decl already belongs to a translation unit.
++// Either:
++//
++// 1/ it's a unique type, in which case we should not add it to
++// any translation unique since unique types are "logically"
++// supposed to belong to no translation unit in particular, as
++// they are unique.
++//
++// 2/ or the decl was already added to this translation unit.
++ABG_ASSERT(tu == existing_tu || is_unique_type(is_type(decl)));
++ else
++decl->set_translation_unit(tu);
++}
++
+ /// Add a member decl to this scope. Note that user code should not
+ /// use this, but rather use add_decl_to_scope.
+ ///
+@@ -7999,12 +8027,7 @@
+ update_qualified_name(member);
+
+ if (translation_unit* tu = get_translation_unit())
+-{
+- if (translation_unit* existing_tu = member->get_translation_unit())
+- ABG_ASSERT(tu == existing_tu);
+- else
+- member->set_translation_unit(tu);
+-}
++maybe_set_translation_unit(member, tu);
+
+ maybe_update_types_lookup_map(member);
+
+@@ -8141,12 +8164,7 @@
+ update_qualified_name(member);
+
+ if (translation_unit* tu = get_translation_unit())
+-{
+- if (translation_unit* existing_tu = member->get_translation_unit())
+- ABG_ASSERT(tu == existing_tu);
+- else
+- member->set_translation_unit(tu);
+-}
++maybe_set_translation_unit(member, tu);
+
+ maybe_update_types_lookup_map(member);
+
diff -
Bug#1055637: libabigail-2.4: assert violation while setting translation unit for unique types
Source: libabigail Version: 2.4-1 Severity: normal Dear Maintainer, while building the zfs-dkms package in Ubuntu/noble, in the checkabi target, abidiff core dumps: https://launchpadlibrarian.net/696568269/buildlog_ubuntu-noble-amd64.zfs-linux_2.2.0-0ubuntu2_BUILDING.txt.gz abigail-2.3 was fine, and it started crashing after we moved to abigail-2.4. I was able to reproduce the issue locally with abigail src from git: $ abidiff --no-unreferenced-symbols --headers-dir1 include --suppressions ./lib/libnvpair/libnvpair.suppr ./lib/libnvpair/libnvpair.abi .libs/libnvpair.so abidiff: ../../src/abg-ir.cc:8004: virtual abigail::ir::decl_base_sptr abigail::ir::scope_decl::add_member_decl(const abigail::ir::decl_base_sptr&): Assertion `__abg_cond__' failed. Aborted (core dumped) and i bisected it down to this commit: commit d00a2cc2da9b33be5a6e5376cbee4591c042d3a3 (break5) Author: Dodji Seketeli Date: Thu May 25 14:15:56 2023 +0200 Bug 30466 - harfbuzz fails self-check on f38 Sent the report upstream, and got a fix: https://sourceware.org/bugzilla/show_bug.cgi?id=31045 Tested the fix against zfs-dkms, it built successfully this time. Can you apply it and cut a new release?
Bug#1052452: python3-pyvmomi version too old, breaks ansible 7.3.0+dfsg-1
Package: python3-pyvmomi
Version: 6.7.1-4
Severity: important
Tags: patch
Running ansible vmware_guest module in debian stable fails with this error:
AttributeError: module 'pyVmomi.VmomiSupport' has no attribute
'VmomiJSONEncoder'
Actually the vmware_guest module in stable cannot be used and version
6.7.1-6 in testing and sid is still too old, as support for JSON
encoding in vmomi is tracked in pyvmomi #732[1] and solved in
v6.7.1.2018.12 Bug Fix release.
It would be nice if python3-pyvmomi can be upgraded to a ever newer
version (now is at 8.0U1 patch 2), but I include a patch with
differences in file pyVmomi/VmomiSupport between version v6.7.1.2018.12
and v6.7.1, if you want to stay minimal (in the upstream diff there are
also many other changes in docs and examples that aren't related to this
bug). I tested it in my environment and it works for me.
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-12-amd64 (SMP w/1 CPU thread; PREEMPT)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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-pyvmomi depends on:
ii dpkg 1.21.22
ii python3 3.11.2-1+b1
ii python3-requests 2.28.1+dfsg-1
ii python3-six 1.16.0-4
python3-pyvmomi recommends no packages.
Versions of packages python3-pyvmomi suggests:
pn python-pyvmomi-doc
-- no debconf information
Best regards.
Paolo
1. https://github.com/vmware/pyvmomi/pull/732
diff --git a/pyVmomi/VmomiSupport.py b/pyVmomi/VmomiSupport.py
index 925d4a9..b3b7878 100644
--- a/pyVmomi/VmomiSupport.py
+++ b/pyVmomi/VmomiSupport.py
@@ -1,5 +1,5 @@
# VMware vSphere Python SDK
-# Copyright (c) 2008-2016 VMware, Inc. All Rights Reserved.
+# Copyright (c) 2008-2018 VMware, Inc. All Rights Reserved.
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
@@ -27,6 +27,7 @@ from six import PY3
from datetime import datetime
from pyVmomi import Iso8601
import base64
+import json
import threading
if PY3:
from functools import cmp_to_key
@@ -273,6 +274,131 @@ class LazyModule(object):
else:
raise AttributeError("'%s' does not exist" % self.name)
+
+class VmomiJSONEncoder(json.JSONEncoder):
+"""
+Custom JSON encoder to encode vSphere objects.
+
+When a ManagedObject is encoded, it gains three properties:
+_vimid is the _moId (ex: 'vm-42')
+_vimref is the moRef (ex: 'vim.VirtualMachine:vm-42')
+_vimtype is the class name (ex: 'vim.VirtualMachine')
+
+When a DataObject is encoded, it gains one property:
+_vimtype is the class name (ex: 'vim.VirtualMachineQuestionInfo')
+
+If the dynamicProperty and dynamicType are empty, they are optionally
+omitted from the results of DataObjects and ManagedObjects
+
+@example "Explode only the object passed in"
+data = json.dumps(vm, cls=VmomiJSONEncoder)
+
+@example "Explode specific objects"
+data = json.dumps(vm, cls=VmomiJSONEncoder,
+ explode=[vm, vm.network[0]])
+
+@example "Explode all virtual machines in a list and their snapshots"
+data = json.dumps([vm1, vm2], cls=VmomiJSONEncoder,
+ explode=[templateOf('VirtualMachine'),
+ templateOf('VirtualMachineSnapshot')])
+"""
+def __init__(self, *args, **kwargs):
+"""
+Consumer must specify what types to explode into full content
+and what types to leave as a ManagedObjectReference. If the
+root object of the encoding is a ManagedObject, it will be
+added to the explode list automatically.
+
+A ManagedObject is only exploded once, the first time it is
+encountered. All subsequent times it will be a moRef.
+
+@param explode (list) A list of objects and/or types to
+expand in the conversion process. Directly add any
+objects to the list, or add the type of any object
+using type(templateOf('VirtualMachine')) for example.
+
+@param strip_dynamic (bool) Every object normally contains
+a dynamicProperty list and a dynamicType field even if
+the contents are [] and None respectively. These fields
+clutter the output making it more difficult for a person
+to read and bloat the size of the result unnecessarily.
+This option removes them if they are the empty values above.
+The default is Fal
Bug#1051236: proftpd-core: SSH key exchanges fail unexpectedly with "unable to write X bytes of raw data"
On Mon, Sep 04, 2023 at 10:10:05PM +0200, Jeremy Lecour wrote: Package: proftpd-core Version: 1.3.8+dfsg-4+deb12u1 Severity: normal Dear Maintainer, After upgrading to Debian 12, my SFTP client stopped working with errors when connecting. I've opened a GitHub issue and the problem has been solved. https://github.com/proftpd/proftpd/issues/1694 It will even be backported to the 1.3.8 branch, so I hope that it might be available in an upcoming update in Debian 12. Nice catch, thanks. A PU can be prepared, but of course it requires a go by SRMs. -- Francesco P. Lovergine
Bug#1052161: ITP: libmozilla-ca-perl -- Mozilla's CA cert bundle in PEM format
Package: wnpp Severity: wishlist Owner: Francesco Paolo Lovergine X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: libmozilla-ca-perl Version : 20230821-1 Upstream Contact: Gisle Aas * URL : https://github.com/libwww-perl/Mozilla-CA * License : MPL-2.0 Programming Lang: Perl Description : Mozilla's CA cert bundle in PEM format Mozilla::CA provides a copy of Mozilla's bundle of Certificate Authority certificates in a form that can be consumed by modules and libraries based on OpenSSL. The module provide a single function: SSL_ca_file() Returns the absolute path to the Mozilla's CA cert bundle PEM file.
Bug#1051166: FTBFS with doxygen 1.9.8
Package: breathe-doc Version: 4.35.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: paolo.gre...@libpf.com While preparing to upload doxygen 1.9.8, I did a partial rebuild of packages that build-depend on it. More info here: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial Of 510 packages I tried, 6 failed and one is breathe-doc. The build error was: Exception occurred while building, starting debugger: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/sphinx/cmd/build.py", line 281, in build_main app.build(args.force_all, args.filenames) File "/usr/lib/python3/dist-packages/sphinx/application.py", line 341, in build self.builder.build_update() File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 310, in build_update self.build(to_build, File "/usr/lib/python3/dist-packages/sphinx/builders/__init__.py", line 325, in build with logging.pending_warnings(): File "/usr/lib/python3.11/contextlib.py", line 144, in __exit__ next(self.gen) File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 218, in pending_warnings memhandler.flushTo(logger) File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 183, in flushTo logger.handle(record) File "/usr/lib/python3.11/logging/__init__.py", line 1644, in handle self.callHandlers(record) File "/usr/lib/python3.11/logging/__init__.py", line 1706, in callHandlers hdlr.handle(record) File "/usr/lib/python3.11/logging/__init__.py", line 974, in handle rv = self.filter(record) ^^^ File "/usr/lib/python3.11/logging/__init__.py", line 830, in filter result = f.filter(record) File "/usr/lib/python3/dist-packages/sphinx/util/logging.py", line 426, in filter raise exc sphinx.errors.SphinxWarning: /<>/documentation/source/specific.rst:195:Invalid C++ declaration: Expected identifier in nested name. [error at 0] ^ > /usr/lib/python3/dist-packages/sphinx/util/logging.py(426)filter() -> raise exc (Pdb) make[3]: *** [Makefile:56: html] Error 2 I attach the full build log. Paolo -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages breathe-doc depends on: ii libjs-mathjax2.7.9+dfsg-1 ii libjs-sphinxdoc 5.3.0-7 breathe-doc recommends no packages. breathe-doc suggests no packages. -- no debconf information breathe_4.35.0-2.xz Description: application/xz
Bug#1051165: FTBFS with doxygen 1.9.8
Package: libstxxl-doc
Version: 1.4.1-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the
past)
X-Debbugs-Cc: paolo.gre...@libpf.com
While preparing to upload doxygen 1.9.8, I did a partial rebuild of
packages that build-depend on it.
More info here:
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial
Of 510 packages I tried, 6 failed and one is libstxxl-doc.
The build error was:
! LaTeX Error: File `topics.tex' not found.
Type X to quit or to proceed,
or enter new name. (Default extension: tex)
Enter file name:
! Emergency stop.
l.211 \input{topics}
^^M
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on refman.log.
I attach the full build log.
Paolo
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libstxxl-doc depends on:
ii libjs-jquery 3.6.1+dfsg+~3.5.14-1
libstxxl-doc recommends no packages.
libstxxl-doc suggests no packages.
-- no debconf information
libstxxl_1.4.1-3.xz
Description: application/xz
Bug#1051162: FTBFS with doxygen 1.9.8
Package: netcdf-doc Version: 1:4.9.2-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: paolo.gre...@libpf.com While preparing to upload doxygen 1.9.8, I did a partial rebuild of packages that build-depend on it. More info here: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial Of 510 packages I tried, 6 failed and one is netcdf-doc. The build error was: /<>/docs/dispatch.md:392: error: Unexpected subsubsection command found inside section! (warning treated as error, aborting now) make[3]: *** [docs/CMakeFiles/doc_all.dir/build.make:74: docs/CMakeFiles/doc_all] Error 1 I attach the full build log. Paolo -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information netcdf_1:4.9.2-1.xz Description: application/xz
Bug#1051156: FTBFS with doxygen 1.9.8
Package: seqan-raptor-doc Version: 3.0.1+ds-3 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: paolo.gre...@libpf.com While preparing to upload doxygen 1.9.8, I did a partial rebuild of packages that build-depend on it. More info here: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial Of 510 packages I tried, 6 failed and one is seqan-raptor-doc. The build error was: xelatex refman This is XeTeX, Version 3.141592653-2.6-0.95 (TeX Live 2023/Debian) (preloaded format=xelatex) restricted \write18 enabled. entering extended mode (./refman.tex LaTeX2e <2023-06-01> L3 programming layer <2023-06-05> make[2]: *** [Makefile:12: refman.pdf] Error 1 I attach the full build log. Paolo -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information seqan-raptor_3.0.1+ds-3.xz Description: application/xz
Bug#1051155: FTBFS with doxygen 1.9.8
Package: wxpython-tools Version: 4.2.1+dfsg-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: paolo.gre...@libpf.com While preparing to upload doxygen 1.9.8, I did a partial rebuild of packages that build-depend on it. More info here: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial Of 510 packages I tried, 5 failed and one is wxpython-tools. The build error was: Running command: etg "/usr/bin/python3.11" etg/_core.py --sip --nodoc "/usr/bin/python3.11" etg/_html2.py --sip --nodoc "/usr/bin/python3.11" etg/_xml.py --sip --nodoc "/usr/bin/python3.11" etg/_xrc.py --sip --nodoc "/usr/bin/python3.11" etg/_richtext.py --sip --nodoc "/usr/bin/python3.11" etg/_stc.py --sip --nodoc "/usr/bin/python3.11" etg/_grid.py --sip --nodoc "/usr/bin/python3.11" etg/_msw.py --sip --nodoc "/usr/bin/python3.11" etg/_propgrid.py --sip --nodoc "/usr/bin/python3.11" etg/_dataview.py --sip --nodoc "/usr/bin/python3.11" etg/_glcanvas.py --sip --nodoc Traceback (most recent call last): File "/<>/etg/_glcanvas.py", line 137, in run() File "/<>/etg/_glcanvas.py", line 49, in run etgtools.parseDoxyXML(module, ITEMS) File "/<>/etgtools/__init__.py", line 91, in parseDoxyXML item = module.addElement(element) ^^ File "/<>/etgtools/extractors.py", line 1576, in addElement self.addElement(node) File "/<>/etgtools/extractors.py", line 1547, in addElement item = EnumDef(element, inClass) ^ File "/<>/etgtools/extractors.py", line 1185, in __init__ self.extract(element) File "/<>/etgtools/extractors.py", line 1189, in extract super(EnumDef, self).extract(element) File "/<>/etgtools/extractors.py", line 65, in extract if '::' in self.name: ^ TypeError: argument of type 'NoneType' is not iterable I attach the full build log. Paolo -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wxpython-tools depends on: ii python3 3.11.4-5+b1 ii python3-wxgtk4.0 4.2.1+dfsg-1 wxpython-tools recommends no packages. wxpython-tools suggests no packages. -- no debconf information wxpython4.0_4.2.1+dfsg-1.xz Description: application/xz
Bug#1051154: FTBFS with doxygen 1.9.8
Package: libcaca-dev
Version: 0.99.beta20-3
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the
past)
X-Debbugs-Cc: paolo.gre...@libpf.com
While preparing to upload doxygen 1.9.8, I did a partial rebuild of
packages that build-depend on it.
More info here:
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.8+ds-1_amd64-partial
Of 510 packages I tried, 6 failed and one is libcaca-dev.
The build error was:
The control sequence at the end of the top line
of your error message was never \def'ed. If you have
misspelled it (e.g., `\hobx'), type `I' and the correct
spelling (e.g., `I\hbox'). Otherwise just continue,
and I'll forget about whatever was undefined.
! TeX capacity exceeded, sorry [text input levels=15].
\tabu@textbar ...ar \m@ne \scantokens {\def \:{|}}
\expandafter
\endgroup \ex...
l.46 \begin{DoxyParams}{Parameters}
^^M
If you really absolutely need more capacity,
you can ask a wizard to enlarge me.
Here is how much of TeX's memory you used:
18690 strings out of 477695
304727 string characters out of 5831649
1925759 words of memory out of 500
38172 multiletter control sequences out of 15000+60
560241 words of font info for 97 fonts, out of 800 for 9000
14 hyphenation exceptions out of 8191
101i,15n,117p,1820b,797s stack positions out of
1i,1000n,2p,20b,20s
! ==> Fatal error occurred, no output PDF file produced!
make[3]: *** [Makefile:663: stamp-latex] Error 1
I attach the full build log.
Paolo
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libcaca-dev depends on:
ii libcaca0 0.99.beta20-3
ii libslang2-dev 2.3.3-3
libcaca-dev recommends no packages.
libcaca-dev suggests no packages.
-- no debconf information
libcaca_0.99.beta20-3.xz
Description: application/xz
Bug#1040864:
Hi Andreas! Il 11/07/23 22:27, Andreas Hasenack ha scritto: So I took a stab at backporting the upstream patches, and there are many: $ grep ^commit debian/patches/doc-build-with-newer-cairo-*.patch debian/patches/doc-build-with-newer-cairo-1.patch:commit c22ae5ed4ca8d7e5568be7d5a930ee388117703e debian/patches/doc-build-with-newer-cairo-2.patch:commit 9df76e22464a0b6302b7c1cda980a35b39185bc4 debian/patches/doc-build-with-newer-cairo-3.patch:commit 293d3beaf03c8798899332b7a948b32c4a3da3e9 debian/patches/doc-build-with-newer-cairo-4.patch:commit 966d69c603b5a6ae22e3132b6ecc6a39b86e52ab debian/patches/doc-build-with-newer-cairo-5.patch:commit 7b2a6027775b0158304635a98de0f9b5672f163a debian/patches/doc-build-with-newer-cairo-6.patch:commit 8129939c312e4b5060042fdb93bd071b7b133381 debian/patches/doc-build-with-newer-cairo-7.patch:commit e002e293d9dc956a0634b3a4bcc8d93e655582d5 This looks risky. It's probably best to update to 1.9.7. What do you think? My WIP branch is at https://code.launchpad.net/~ahasenack/ubuntu/+source/doxygen/+git/doxygen/+ref/mantic-doxygen-cairo-compat many thanks for the timely heads-up and for the research. I think the best would be to just upgrade to 1.9.7. I'll take care. Paolo
Bug#502195: invoke-rc.d with action [force-]reload doesn't obey runlevel constraints
I think this long-standing bug can be closed as the explanations provided on how the reload and force-reload actions work have been satisfactory. Regards. Paolo Miotto
Bug#1038628: Acknowledgement (webext-eas4tbsync: MS Exchange OAUTH2 setup fails)
I was able to apply the patch to the network.js file in /usr/share/webext/eas4tbs...@jobisoft.de.xpi and now it works as expected.
Bug#1038628: webext-eas4tbsync: MS Exchange OAUTH2 setup fails
Package: webext-eas4tbsync
Version: 4.1.5-1
Severity: important
Tags: patch
As stated in [1] trying to setup a MS Exchange account with OAuth2 fails
because it
wants to connect to a "undefined" server.
It was resolved upstream [2] but that changes are not ported in debian.
>From what I see, this patch resolve the issuei, but I wasn't able to try it
>yet:
$ diff -b content/includes/network.js EAS/content/includes/network.js
96c96,101
< let oauth = new OAuth2(config.auth_uri, config.token_uri, config.scope,
config.client_id, config.client_secret);
---
> let oauth = new OAuth2(config.scope, {
> authorizationEndpoint: config.auth_uri,
> tokenEndpoint: config.token_uri,
> clientId: config.client_id,
> clientSecret: config.client_secret
> });
Regards.
Paolo
1. https://github.com/jobisoft/TbSync/issues/649
2. https://github.com/jobisoft/EAS-4-TbSync/issues/215#issuecomment-1416725608,
paolo.mio...@uniud.it
-- System Information:
Debian Release: 12.0
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 webext-eas4tbsync depends on:
ii thunderbird1:102.12.0-1~deb12u1
ii webext-tbsync 4.3-1
webext-eas4tbsync recommends no packages.
webext-eas4tbsync suggests no packages.
-- no debconf information
Bug#1035355: Fwd: btrbk: warnings with backported btrfs-progs in bullseye
Package: btrbk Version: 0.27.1-1.1 I'm using a Raspberry Pi4 with RaspberryOS bullseye. RaspberryOS is Debian with some modified packages: in particular a personalized kernel. RaspberryOS Bullseye has recently updated the kernel to 6.1 (against Bullseye's 5.10). I have installed the backported version of btrfs-progs for matching the kernel version (and solving some bugs), so now I have btrfs-progs 6.1. The problem: running btrbk now i get this (informative) warning: WARNING: Failed to parse subvolume detail "Send transid: 0" for: > /srv/dev-disk-by-uuid-c50a9181 > WARNING: Failed to parse subvolume detail "Send time: 2021-09-26 17:19:24 > +0200" for: /srv/dev-disk-by-uuid-c50a9181 > WARNING: Failed to parse subvolume detail "Receive transid: 0" for: > /srv/dev-disk-by-uuid-c50a9181 > WARNING: Failed to parse subvolume detail "Receive time: -" for: > /srv/dev-disk-by-uuid-c50a9181 This push my server to send a mail every time btrbk run. It is discussed heare: https://github.com/digint/btrbk/issues/422 My proposed solutions (if possible): - Backport btrbk 0.32.5-1 from testing - or patch btrbk with the change of one code line (see https://github.com/digint/btrbk/commit/74be074e6f0347dd729ea450fd5811dc1500f2f8) (whitch I have done). This problem should show up for every bullseye user with backported kernel and btrfs-progs, not only in my setting. Thank for yours attention.
Bug#1034677: Marco 1.26.1 core dumps under X2go on bookworm
Package: marco Version: 1.26.1 Severity: important Hi, during my tests with commonly used software here, I found that the Mate window manager is currently unusable under X2go due to a seg fault at startup. I even found the reason: https://github.com/mate-desktop/marco/issues/746 fixed in 1.26.2 A possible workaround for users would be using another WM such as Metacity, by changing window manager under org.mate.desktop.session.required-components via dconf-editor/gsettings. Of course, upgrading to 1.26.2 would be HIGHLY appreciated. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-21-amd64 (SMP w/32 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 marco depends on: ii libc62.31-13+deb11u5 ii libcairo21.16.0-5 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 pn libmarco-private2 ii libpango-1.0-0 1.46.2-3 ii libx11-6 2:1.7.2-1 pn marco-common pn mate-desktop-common ii zenity 3.32.0-6 marco recommends no packages. marco suggests no packages.
Bug#1030156: mailman3 starts before local mariadb
Package: mailman3 Version: 3.3.3-1 Severity: important Dear Maintainer, on bullseye mailman3 fails to start at boot when mailman3 is configured to use a local mariadb database, because systemd starts mailman3 before mariadb. I have a feeling the same could happen with postgresql. I temporarily fixed this by adding these lines Wants=mariadb.service > After=mariadb.service in the [Unit] section of /lib/systemd/system/mailman3.service, but this is not safe in case of upgrades. I understand that these lines cannot be added indiscriminately in the unit file, but I'm not a systemd expert and my attempts to use systemctl --add-wants and systemctl --add-requires have not achieved the desired results. As a MySQL or a PostgreSQL database is recommended instead of SQLite3, it would be nice to have at least a notice on this in the README.debian, better along with a solution effective in case of an upgrade. Regards. Paolo
Bug#1017504: Enabling large file support in doxygen
Hi! sorry for the long delay, at last I'm looking at incorporating your patch. It's now WIP here: https://salsa.debian.org/debian/doxygen Before I upload it to unstable, I was wandering: 1. what would be the easiest way to turn this on only for 32-bit builds? 2. what side effects can we expect? ~600 packages build-depend on doxygen, I would not want to break havoc 3. reading some threads about enabling large file support for all packages, I was scared by the issue of ABI breaking, are we 100% sure that we will not trigger that? Thanks for you comments, Paolo
Bug#1015864: doxygen: diff for NMU version 1.9.4-3.1
Hi Adrian, Il 15/10/22 14:30, Adrian Bunk ha scritto: Control: tags 1015864 + patch Control: tags 1015864 + pending Dear maintainer, I've prepared an NMU for doxygen (versioned as 1.9.4-3.1) and uploaded it to DELAYED/15. Please feel free to tell me if I should cancel it. cu Adrian thanks for the NMU. I'll let it go through and afterwards import it back into the salsa git repo for reference. Paolo
Bug#1019238: fixed in redmine 5.0.2-1
On Tue, 13 Sep 2022 14:50:00 + Debian FTP Masters wrote: > Source: redmine > Source-Version: 5.0.2-1 [---] > We believe that the bug you reported is fixed in the latest version of >redmine, which is due to be installed in the Debian FTP archive. This bug was reported for version 4.0.7-1~bpo10+1 in buster-backports, the new package is at version 5, this means that we have redmine 5.0.2-1 in stable/oldstable backports in few days? This would be great. Otherwise this ticket must be kept open IMHO
Bug#1019238: Wirkaround
i am experiencing the same error. I temporarily fixed it by reverting the libraries to the previous version, this might come in handy to someone: apt install --reinstall --allow-downgrades \ ruby-rails=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-actionpack=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-actionview=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-activemodel=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-activerecord=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-activesupport=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-activestorage=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-actioncable=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-activejob=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-railties=2:5.2.2.1+dfsg-1+deb10u3 \ ruby-actionmailer=2:5.2.2.1+dfsg-1+deb10u3 Paolo
Bug#1016208: jenkins.debian.org: downloading artifacts from tests.reproducible-builds.org
Package: jenkins.debian.org X-Debbugs-Cc: paolo.gre...@libpf.com Severity: normal Hi, I am looking at the reproducible build results for doxygen: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/doxygen.html If I remember well, previously it was possible to download the build artifacts (i.e. doxygen-doc_1.9.4-2_all.deb ... maybe the build dirs ...) for the reference build and the perturbed build, so that I could run diffoscope here, compare PDF files etc. I ca'nt find these artifacts links anymore. Have they been moved or removed ? As a workaround, it would be nice to have a oneliner I can try at home to reproduce here the reproducible builds! Thanks, Paolo
Bug#1016050: sddm: intermittedly shows black page instead of login screen
Package: sddm
X-Debbugs-Cc: paolo.gre...@libpf.com
Version: 0.19.0-3
Severity: important
About 90% of the times after a fresh reboot, sddm shows a black page
with mouse pointer instead of the login screen.
The systemd sddm service is up and running. If I restart it on tty 1,
the login screen reappears.
I attach two extracts from journalctl -u sddm, one for a successful
boot, where the login screen was showed so that I could login
(success.log) and one for a non-successful boot (failure.log).
They are similar up to "Greeter session started successfully". But in
failure.log after that it says:
lug 25 17:25:50 localhost sddm[1442]: Greeter session started
successfully
lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: [PAM]
Closing session
lug 25 17:25:50 localhost.localdomain sddm-helper[1573]: [PAM] Ended.
lug 25 17:25:50 localhost.localdomain sddm-helper[1573]:
pam_unix(sddm-greeter:session): session closed for user sddm
lug 25 17:25:50 localhost.localdomain sddm[1442]: Auth: sddm-helper
exited with 6
lug 25 17:25:50 localhost.localdomain sddm[1442]: Greeter stopped.
In that case at 17:27:21 I restarted the service ("Signal received:
SIGTERM") and then I could login.
In success.log after "Greeter session started successfully" it goes on with:
lug 26 06:54:27 localhost sddm[1503]: Greeter session started
successfully
lug 26 06:54:27 localhost sddm[1503]: Message received from greeter:
Connect
lug 26 06:54:38 localhost.localdomain sddm[1503]: Message received
from greeter: Login
lug 26 06:54:38 localhost.localdomain sddm[1503]: Reading from
"/usr/share/xsessions/plasma.desktop"
lug 26 06:54:38 localhost.localdomain sddm[1503]: Reading from
"/usr/share/xsessions/plasma.desktop"
lug 26 06:54:38 localhost.localdomain sddm[1503]: Session
"/usr/share/xsessions/plasma.desktop" selected, command:
"/usr/bin/startplasma-x11"
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Starting...
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Authenticating...
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Preparing to converse...
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM]
Conversation with 1 messages
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_kwallet5(sddm:auth): (null): pam_sm_authenticate
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: [PAM] returning.
lug 26 06:54:38 localhost.localdomain sddm[1503]: Authenticated
successfully
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_kwallet5(sddm:setcred): pam_kwallet5: pam_sm_setcred
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_unix(sddm:session): session opened for user paolog(uid=1000) by (uid=0)
lug 26 06:54:38 localhost.localdomain sddm[1503]: Auth: sddm-helper
exited successfully
lug 26 06:54:38 localhost.localdomain sddm[1503]: Greeter stopped.
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]:
pam_kwallet5(sddm:session): pam_kwallet5: pam_sm_open_session
lug 26 06:54:38 localhost.localdomain sddm-helper[1970]: Starting:
"/etc/sddm/Xsession \"/usr/bin/startplasma-x11\""
lug 26 06:54:38 localhost.localdomain sddm[1503]: Session started
So the difference is that in the second case sddm gets to "Message
received from greeter: Connect" and all goes well, whereas in the first
case that status is never reached because sddm-helper closes the PAM
session and bails out, causing the greeter to stop.
It looks to me as a race condition.
Probably the PAM system is not yet ready when sddm-helper tries to connect.
Paolo
-- System Information:
Debian Release: 11.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable-debug'), (500, 'stable'), (400, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages sddm depends on:
ii adduser 3.118
ii debconf [debconf-2.0] 1.5.77
ii libc6 2.31-13+deb11u3
ii libgcc-s1 10.2.1-6
ii libpam0g1.4.0-9+deb11u1
ii libqt5core5a5.15.2+dfsg-9
ii libqt5dbus5 5.15.2+dfsg-9
ii libqt5gui5 5.15.2+dfsg-9
ii libqt5network5 5.15.2+dfsg-9
ii libqt5qml5 5.15.2+dfsg-6
ii libqt5quick55.15.2+dfsg-6
ii libstdc++6 10.2.1-6
ii libsystemd0 247.3-7
ii libxcb-xkb1 1.14-3
ii libxcb1 1.14-3
ii qml-module-qtquick2 5.15.2+dfsg-6
ii x11-common 1:7.7+22
Bug#1015862: geos-bin: FTBFS with upcoming doxygen 1.9.4
Hi! thanks for the quick reaction. Il 22/07/22 18:01, Sebastiaan Couwenberg ha scritto: Control: tags -1 upstream Control: forwarded -1 https://github.com/libgeos/geos/issues/654 On 7/22/22 17:37, Paolo Greppi wrote: I am about to upload the current version of doxygen, before doing that I ran a quick scan of ~500 build-deps (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.4-1_amd64-partial) and found that this package was one of 4 that FTBFS. I don't see 1.9.4 in experimental, will you upload it there first? I've added a patch that should fix the issue by ignoring the (new) warning: https://salsa.debian.org/debian-gis-team/geos/-/commit/693b718e4b701ede6f28e94e9e9d2dcac67a8a6a But I cannot easily test it without 1.9.4 in experimental. Kind Regards, Bas I'd like to skip experimental and go to unstable by today or tomorrow. Also there are are deb files you can use as artifacts from the latest salsa CI run: https://salsa.debian.org/debian/doxygen/-/jobs/3014516/artifacts/browse/debian/output/ Paolo
Bug#1015865: liblog4c3: FTBFS with upcoming doxygen 1.9.4
Package: liblog4c3
Version: 1.2.4-2
Severity: important
File: /usr/share/doc/liblog4c3/copyright
Tags: ftbfs
X-Debbugs-Cc: paolo.gre...@libpf.com
Hello,
I am about to upload the current version of doxygen, before doing that I
ran a quick scan of ~500 build-deps
(https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.4-1_amd64-partial)
and found that this package was one of 4 that FTBFS.
The errors were:
Output written on refman.dvi (90 pages, 336368 bytes).
Transcript written on refman.log.
latex_count=%(LATEX_COUNT) ; \
while egrep -s 'Rerun (LaTeX|to get cross-references right|to get
bibliographical references right)' refman.log && [ $latex_count -gt 0 ] ;\
do \
echo "Rerunning latex" ;\
latex refman.tex ; \
latex_count=`expr $latex_count - 1` ;\
done
/bin/sh: 1: Syntax error: "(" unexpected
make[4]: *** [Makefile:30: refman.dvi] Error 2
The errors do not occur with the current version of doxygen (1.9.1). I
attach the build logs.
Paolo
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN,
TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages liblog4c3 depends on:
ii libc6 2.33-7
ii libexpat1 2.4.8-1
liblog4c3 recommends no packages.
liblog4c3 suggests no packages.
-- no debconf information
1_9_1.log.xz
Description: application/xz
1_9_4.log.xz
Description: application/xz
Bug#1015861: bamtools: FTBFS with upcoming doxygen 1.9.4
Package: bamtools Version: 2.5.1+dfsg-10+b1 Severity: important Tags: ftbfs X-Debbugs-Cc: paolo.gre...@libpf.com Hello, I am about to upload the current version of doxygen, before doing that I run a quick scan of build-deps of doxygen (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.4-1_amd64-partial) and found that this package FTBFS with this error: mv: cannot stat 'docs/Doxyfile.bak': No such file or directory The error does not occur with the current version of doxygen (1.9.1). I attach the build logs. Paolo -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages bamtools depends on: ii libbamtools2.5.1 2.5.1+dfsg-10+b1 ii libc6 2.33-7 ii libgcc-s1 12.1.0-5 ii libjsoncpp25 1.9.5-4 ii libstdc++612.1.0-5 bamtools recommends no packages. bamtools suggests no packages. -- no debconf information 1_9_1.log.xz Description: application/xz 1_9_4.log.xz Description: application/xz
Bug#924040: next steps
I installed the package above and when I tried the archivebox command I got the same error about the missing atomicwrites module. This is easy to fix by adding lib/python3.9/site-packages/atomicwrites/__init__.py from https://pypi.org/project/atomicwrites/ 1.4.1 as debian/vendor/atomicwrites.py. A better way of vendoring dependencies would be to use gbp components, so that they are versioned, uscan looks for new versions etc. Another issue is that if I try to "archivebox add" an url I get these warnings: ! SINGLEFILE_BINARY: single-file (unable to detect version) ! READABILITY_BINARY: readability-extractor (unable to detect version) ! MERCURY_BINARY: mercury-parser (unable to detect version) Indeed the page is archived as (I have the recommended dep chromium): - Chrome > PDF - Chrome Screenshot - wget > HTML - Archive.org - Headers - Chrome > HTML - MEdia - Git But these fail: - Chrome > SingleFile - Readability - Mercury - Git (not sure why) Getting the first three to work would require installing the JS dependencies listed in package.json which is a mess. But after the atomicwrites fix the package seems to be usable as-is and worth uploading! Paolo
Bug#924040: 0.6.2
Hi! and thanks for your efforts to package archivebox. I have picked it up from there and tried to build the current version (0.6.2). For that I have refreshed the patches, here is a MR: https://salsa.debian.org/debian/archivebox/-/merge_requests/1 Feel free to pick up whatever you need from there. There is a test error: = test session starts == platform linux -- Python 3.9.2, pytest-6.0.2, py-1.10.0, pluggy-0.13.0 rootdir: /tmp/build-area/archivebox-0.6.2 plugins: django-3.5.1, sugar-0.9.4 collected 44 items / 1 error / 43 selected ERRORS ERROR collecting .pybuild/cpython3_3.9/build/tests/test_extractors.py _ ImportError while importing test module '/tmp/build-area/archivebox-0.6.2/.pybuild/cpython3_3.9/build/tests/test_extractors.py'. Hint: make sure your test modules/packages have valid Python names. Traceback: ... archivebox/system.py:14: in from .vendor.atomicwrites import atomic_write as lib_atomic_write E ModuleNotFoundError: No module named 'archivebox.vendor.atomicwrites' === short test summary info ERROR tests/test_extractors.py Interrupted: 1 error during collection === 1 error in 0.60s === but this does not prevent the package to build (?). Anyway I m not familiar with this style of tracking only the debian dir in salsa (I normally use gbp and push the upstream sources as well). How can you enable salsa CI BTW ? Paolo
Bug#808641: duplicate of #818379
Thanks for your bug report. This is caused by doxygen not reporting dot failures, which is tracked at bug #818379. Paolo
Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1
Il 15/07/22 00:23, Sebastian Ramacher ha scritto: On 2022-07-14 16:23:16 +0200, Paolo Greppi wrote: ... ACK, I've canceled the NMU. Please consider that doxygen is a key package and thus effectively keeping llvm-toolchain-11 in testing. A timely fix for this issue would be much appreciated. Cheers Many thanks. I have prepared the new version with a fix for your issue (https://salsa.debian.org/debian/doxygen) and started a "fast" ratt job (https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.1-1_amd64%20partial). This will take a few days to compete, so far we're at 22% of the progress and 8% of packages fail on the first pass, but all are probably false positives. If all goes well I should be able to upload by Friday. Paolo
Bug#1001682: should be fixed by the upcoming 1.9.4 version
Hi! and thanks for reporting. I am in the process of packaging doxygen 1.9.4 and this issue seems to be fixed in that version. To test, I did this twice: cd `mktemp -d` git clone https://github.com/BYVoid/OpenCC cd OpenCC/ cd doc # no need to run cmake etc. just quickly generate the Doxyfile ... cp opencc.doxy.in Doxyfile sed -i 's/@CMAKE_SOURCE_DIR@/../g' Doxyfile sed -i 's/@OPENCC_VERSION/1.1.4/g' Doxyfile doxygen -u doxygen the compared the dirs: kdiff3 html/ ../../../tmp.bcQZ8jaXXy/OpenCC/doc/html While with 1.9.1 I get: with 1.9.4 I get: so the build path is not embedded anymore. If you have time to test yourself, you can try with this package here on unstable: https://salsa.debian.org/debian/doxygen/-/jobs/3001759/artifacts/browse/debian/output/ Paolo
Bug#235576: fixed in the current version, will close soon
I reproduced with the attached minimal example and no warning is printed. Upstream issue is also closed. Will now close. P. test.tar.xz Description: application/xz
Bug#216195: fixed in the current version, will close soon
I reproduced with the attached minimal example and no warning is printed. Upstream issue is also closed. Will now close. P. test.tar.xz Description: application/xz
Bug#818379: WARN_AS_ERROR=YES could be the solution
Since some time doxygen has a WARN_AS_ERROR config option: https://doxygen.nl/manual/config.html#cfg_warn_as_error Since version 1.9.1 or 1.9.2 if that is set to YES, graphviz's dot is absent but HAVE_DOT=YES is set, doxygen will stop and exit with status of 1 (upstream choose this opt-in way for enabling stricter error trapping so that users are not hit by unexpected failures). If we think we should be strict, we could set the default value of WARN_AS_ERROR to YES (we already deviate from upstream defaults overriding HAVE_DOT's default from 0 to 1). Do you think this would a valid solution for Debian? Paolo
Bug#1000932: doxygen: diff for NMU version 1.9.1-2.1
Hi Sebastian! Il 14/07/22 11:22, Sebastian Ramacher ha scritto: Control: tags 1000932 + patch Control: tags 1000932 + pending Dear maintainer, I've prepared an NMU for doxygen (versioned as 1.9.1-2.1) and uploaded it to DELAYED/7. Please feel free to tell me if I should delay it longer. Cheers thanks for the quick patch; alas your fix will break this logic: https://salsa.debian.org/debian/doxygen/-/blob/master/debian/rules#L23 which was contributed by Norbert Lange to fix https://bugs.debian.org/945427. At this point I am unsure what effects this may cause, I only vaguely remember that the Clang_DIR and LLVM_DIR env vars plug into cmake somehow. So I'd propose to skip this NMU, as I'd rather address this as part of the new upstream release (https://bugs.debian.org/1013636). With each upstream release, I usually run massive archive rebuilds with ratt which helps pinpoint which of the ~700 paackages that reverse-build-dep on doxygen might fail when the new version is pushed through. Having said that, if you feel confident this will not break too many things, feel free to let it go. Otherwise I'm more than happy if you are inspired to contribute in any way to doxygen maintenance; for me the preferred way is by means of Merge Requests on salsa. MfG, Paolo P.S. I also tried reviving the salsa gitlab CI: https://salsa.debian.org/debian/doxygen/-/commits/bugfix/sramacher/1000932 but ATM the pipeline is failing for unrelated reasons: https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/358
Bug#1012097: NIS broken in sid
Package: libnssswitch-nis
Version: 3.1-4
Severity: grave
It seems that currently unstable has a totally not working NIS binding for
users. I
performed my trials using an existing setup (bullseye-based NIS master+slaves
and
clients network in the real life).
I recently upgraded a bullseye NIS client box to sid for testing and discovered
that while
ypbind-mt is regularly working, the usual mapping of NIS users has gone.
To be sure of the issue I prepared a vagrant bullseye VM and bound that to
the regular bullseye NIS master as usual: perfectly working.
Then I full-upgraded to sid with the same broken result:
vagrant@debian:/etc$ ypcat passwd
[...]
lovergine:x:2003:2000:Francesco Lovergine (trial),,,:/home/lovergine:/bin/bash
[...]
{sorry, I stripped the full output for privacy)
vagrant@debian:/etc$ id lovergine
id: ‘lovergine’: no such user
vagrant@debian:/etc$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat systemd
group: compat systemd
shadow: compat
gshadow:compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc:db files
netgroup: nis
vagrant@debian:/etc$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System
(admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:101:101:systemd Time
Synchronization,,,:/run/systemd:/usr/sbin/nologin
systemd-network:x:102:103:systemd Network
Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:104:105::/nonexistent:/usr/sbin/nologin
_chrony:x:105:112:Chrony daemon,,,:/var/lib/chrony:/usr/sbin/nologin
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
vagrant:x:1000:1000::/home/vagrant:/bin/bash
systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin
_rpc:x:107:65534::/run/rpcbind:/usr/sbin/nologin
+::
My next step will be running a full-sid setup for a test network, but I don't
see any reason why the working NIS maps could be broken, my guess is that
the problem is connected to some inner libnss/libc issue.
-cheers
--
Francesco P. Lovergine
Bug#1012021: [Pkg-javascript-devel] Bug#1012021: unreproducible here
Il 29/05/22 21:34, Pirate Praveen ha scritto:
On തി, മേയ് 30 2022 at 12:56:53 രാവിലെ +05:30:00 +05:30:00, Pirate
Praveen wrote:
On ഞാ, മേയ് 29 2022 at 09:34:45 രാവിലെ +02:00:00 +02:00:00, Paolo
Greppi wrote:
Hi Andreas! thanks for your report. To try to reproduce it, I set
...
Finally there is more trouble ahead when building this package,
because I also tried:
apt install git
git clone
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant
cd greenbone-security-assistant
yarnpkg
yarnpkg build
and the last command failed with:
...
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at module.exports
(/greenbone-security-assistant/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash
(/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:417:16)
at
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:452:10
at
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:323:13
at
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:367:11
at
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:233:18
at context.callback
(/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
at
/greenbone-security-assistant/node_modules/babel-loader/lib/index.js:59:103
at processTicksAndRejections
(node:internal/process/task_queues:96:5) {
opensslErrorStack: [ 'error:0386:digital envelope
routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
error Command failed with exit code 1.
(this also happens on amd64 BTW).
According to the interwebs this should only occur with node v17
(whereas in unstable we have v16.15.0) and indeed the commonly
proposed workaround fails:
NODE_OPTIONS=--openssl-legacy-provider yarnpkg build
/usr/bin/node: --openssl-legacy-provider is not allowed in
NODE_OPTIONS
I was also seeing this error while looking at node-babel-loader
We might need to fix node-babel-loader
https://github.com/babel/babel-loader/issues/923
Even though the pull request is merged
https://github.com/babel/babel-loader/pull/924 I get same error on
master branch of upstream babel-loader repo with yarnpkg test.
It seems ad-hoc fixes may be required for each package, such as this
other one:
https://salsa.debian.org/js-team/node-cacache/-/commit/214b963bd02fd74d445789b184d344777dda8ee2
What is mysterious is that all that should only happen with nodejs v17 ...
P.
Bug#1012021: unreproducible here
Hi Andreas! thanks for your report. To try to reproduce it, I set up
multiarch for docker (https://github.com/multiarch/qemu-user-static) then:
docker run --rm -it arm64v8/debian:unstable bash
apt update
apt upgrade
apt install curl yarnpkg
curl -o package.json
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant/-/raw/debian/master/package.json?inline=false
curl -o yarn.lock
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant/-/raw/debian/master/yarn.lock?inline=false
yarnpkg
(this command reads the list of dependencies from package.json + the
exact versions from yarn.lock and downloads them all in node_modules/ dir).
While the command runs, top reports that the node process is using quite
some memory:
PID USER PR NIVIRTRESSHR S %CPU %MEM
TIME+ COMMAND
595069 root 20 0 2202764 688100 44356 R 128,2 2,9
9:06.30 node
but ultimately it succeeds:
root@f679258d6a63:/# yarnpkg
yarn install v1.22.19
[1/5] Validating package.json...
[2/5] Resolving packages...
[3/5] Fetching packages...
[4/5] Linking dependencies...
warning "@greenbone/ui-components > bootstrap@4.6.0" has unmet peer
dependency "jquery@1.9.1 - 3".
warning "@greenbone/ui-components > bootstrap@4.6.0" has unmet peer
dependency "popper.js@^1.16.1".
warning "@greenbone/ui-components > styled-components@5.2.1" has
unmet peer dependency "react-is@>= 16.8.0".
warning " > babel-loader@8.1.0" has unmet peer dependency
"webpack@>=2".
warning "react-scripts > @typescript-eslint/eslint-plugin >
tsutils@3.17.1" has unmet peer dependency "typescript@>=2.8.0 || >=
3.2.0-dev || >= 3.3.0-dev || >= 3.4.0-dev || >= 3.5.0-dev || >=
3.6.0-dev || >= 3.6.0-beta || >= 3.7.0-dev || >= 3.7.0-beta".
warning "@storybook/react > react-docgen-typescript-plugin@0.6.2"
has unmet peer dependency "typescript@>= 3.x".
warning "@storybook/react > react-docgen-typescript-plugin >
react-docgen-typescript@1.20.5" has unmet peer dependency "typescript@>=
3.x".
warning "@storybook/react > react-docgen-typescript-plugin >
react-docgen-typescript-loader@3.7.2" has unmet peer dependency
"typescript@*".
warning " > @testing-library/user-event@13.1.9" has unmet peer
dependency "@testing-library/dom@>=7.21.4".
warning " > eslint-config-prettier@8.3.0" has unmet peer dependency
"eslint@>=7.0.0".
[5/5] Building fresh packages...
Done in 448.36s.
root@f679258d6a63:/# uname -a
Linux f679258d6a63 5.10.0-14-amd64 #1 SMP Debian 5.10.113-1
(2022-04-29) aarch64 GNU/Linux
Could it be an issue of low-memory on the !amd64 builder machines ?
Also I was looking for logs here but no luck:
https://buildd.debian.org/status/package.php?p=greenbone-security-assistant
Finally there is more trouble ahead when building this package, because
I also tried:
apt install git
git clone
https://salsa.debian.org/pkg-security-team/greenbone-security-assistant
cd greenbone-security-assistant
yarnpkg
yarnpkg build
and the last command failed with:
...
Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:67:19)
at Object.createHash (node:crypto:130:10)
at module.exports
(/greenbone-security-assistant/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash
(/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:417:16)
at
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:452:10
at
/greenbone-security-assistant/node_modules/webpack/lib/NormalModule.js:323:13
at
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:367:11
at
/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:233:18
at context.callback
(/greenbone-security-assistant/node_modules/loader-runner/lib/LoaderRunner.js:111:13)
at
/greenbone-security-assistant/node_modules/babel-loader/lib/index.js:59:103
at processTicksAndRejections
(node:internal/process/task_queues:96:5) {
opensslErrorStack: [ 'error:0386:digital envelope
routines::initialization error' ],
library: 'digital envelope routines',
reason: 'unsupported',
code: 'ERR_OSSL_EVP_UNSUPPORTED'
}
error Command failed with exit code 1.
(this also happens on amd64 BTW).
According to the interwebs this should only occur with node v17 (whereas
in unstable we have v16.15.0) and indeed the commonly proposed
workaround fails:
NODE_OPTIONS=--openssl-legacy-provider yarnpkg build
/usr/bin/node: --openssl-legacy-provider is not allowed in NODE_OPTIONS
Paolo
Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center
Il 29/03/22 21:24, Simon McVittie ha scritto: Control: tags -1 + moreinfo unreproducible On Tue, 29 Mar 2022 at 20:40:03 +0200, Paolo Redaelli wrote: the Online Account section of gnome control center disappered. I tried to explicitly invoke it with "gnome-control-center online-accounts" and all I got is this error: (gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not find settings panel "online-accounts" This works for me, with gnome-control-center 1:41.4-2, but I can't find any changes between 1:41.4-1 and 1:41.4-2 that look related... I have skipped some versions; I don't know when this issue started. I went through 3.38.0-3 → 3.38.1-2 → 3.40.0-2 → 3.40.1-2 → 3.43.1-1 I noticed it now but I can't say when it began
Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center
Il 29/03/22 21:24, Simon McVittie ha scritto: Control: tags -1 + moreinfo unreproducible On Tue, 29 Mar 2022 at 20:40:03 +0200, Paolo Redaelli wrote: the Online Account section of gnome control center disappered. I tried to explicitly invoke it with "gnome-control-center online-accounts" and all I got is this error: (gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not find settings panel "online-accounts" This works for me, with gnome-control-center 1:41.4-2, but I can't find any changes between 1:41.4-1 and 1:41.4-2 that look related... Does debsums -c gnome-control-center report any changes? No, it doesn't, even after issuing: sudo apt install --reinstall gnome-control-center gnome-online-accounts
Bug#1008628: gnome-online-accounts: Online accounts disappeared from gnome-control-center
Package: gnome-online-accounts Version: 3.43.1-1 Severity: important Dear Maintainer, the Online Account section of gnome control center disappered. I tried to explicitly invoke it with "gnome-control-center online-accounts" and all I got is this error: (gnome-control-center:49141): cc-window-WARNING **: 20:37:31.872: Could not find settings panel "online-accounts" -- System Information: Debian Release: bookworm/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-online-accounts depends on: ii libatk1.0-0 2.36.0-3 ii libc6 2.33-7 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libcom-err2 1.46.5-2 ii libgck-1-03.40.0-4 ii libgcr-base-3-1 3.40.0-4 ii libgcr-ui-3-1 3.40.0-4 ii libgdk-pixbuf-2.0-0 2.42.6+dfsg-2 ii libglib2.0-0 2.72.0-1 ii libgoa-1.0-0b 3.43.1-1 ii libgoa-backend-1.0-1 3.43.1-1 ii libgtk-3-03.24.33-1 ii libharfbuzz0b 2.7.4-1 ii libk5crypto3 1.19.2-2+b1 ii libkrb5-3 1.19.2-2+b1 ii libp11-kit0 0.24.0-6 ii libpango-1.0-01.50.6+ds-1 ii libpangocairo-1.0-0 1.50.6+ds-1 ii librest-0.7-0 0.8.1-1.1 ii libsoup2.4-1 2.74.2-3 ii libwebkit2gtk-4.0-37 2.36.0-1 ii libxml2 2.9.13+dfsg-1 Versions of packages gnome-online-accounts recommends: ii gnome-control-center 1:41.4-1 gnome-online-accounts suggests no packages. -- no debconf information
Bug#967896: Failed to load firmware chunk for iwlwifi Intel(R) Dual Band Wireless AC 9560 on debian-installer
Dear all, shortly after this bug commit, I successfully managed to install Debian SID on this machine with netinst image. IWLWIFI currently working and happily upgraded to Linux sid 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18) x86_64 GNU/Linux with bookworm/sid without any tweaks in grub/modprobe Connot repeat a full install: maybe you could need the output of some system command or file? Thanx, Pp l e x h a c k . i t PIER PAOLO FRANCO avvocato | diritto tributario e d'impresa www.lexhack.it // pierpaolo.fra...@lexhack.it / pierpaolo.fra...@pec.lexhack.it (PEC) P.Iva 03459781203 / Polizza R.C. LLOYD'S A121C540307-LB VENEZIA, 30032, Fiesso D'Artico, Riviera del Brenta, 305 / T. 041 88 77 018 / F. 041 88 17 341 Il giorno dom 16 gen 2022 alle ore 00:26 Holger Wansing < hwans...@mailbox.org> ha scritto: > Hi all, > > Holger Wansing wrote (Sun, 29 Aug 2021 21:06:11 > +0200): > > Control: tag -1 moreinfo > > > > Pier Paolo Franco wrote: > > > Debian installer warns about missing firmware for iwlwifi Intel > wireless > > > AC9560, so I manually copied over (on subsequent attempt) > > > - debian packages (firmware-misc-nonfree, firmware-nonfree, > > > firmware-iwlwifi), > > > - tried to get ucodes (34, 38, 41) from USB drive (grabbed from > > > > https://cdimage.debian.org/cdimage/unofficial/non-free/firmware/buster/current/ > ), > > > > > > - manually copied ucodes avaible for Debian buster in /lib/firmware and > > > outside in /lib/ (iwlwifi-9000-pu-jf-b0-34, 38, 41 and 43 .ucode) > > > - iwlwifi-9000-pu-jf-b0-34 from > > > > https://www.intel.it/content/www/it/it/support/articles/05511/network-and-i-o/wireless-networking.html > > > > > > Neither works. This is a blocking issue on my Lenovo Yoga C640 without > any > > > LTE or ethernet fallback. > > > > Would you be in the position for testing this with a current bullseye > > installer? > > There have been major improvements regarding firmware installation > > shortly before the release of Bullseye. > > You will need to use one of the unofficial images with firmware included > > for such test: > > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/ > > Would you be in the position to test this with a Debian Bullseye > installer, from > > https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.2.0+nonfree/ > ? > (unofficial, due to non-free firmware) > > > Thanks > > Holger > > > -- > Holger Wansing > PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076 > -- Comunicazione riservata esclusivamente ai destinatari indicati soggetta a segreto professionale. Ogni invio o inoltro a diversi destinatari è da ritenersi erroneo o illegittimo, nel qual caso si prega di darne notizia al mittente ed eliminare la comunicazione dai propri dispositivi. // Reserved to disclosed recipients only, communication subject to attorney-client privilege according to Italian law. It is strictly forbidden to post or forward this message to any other recipient, if you received said message by mistake please inform the sender and delete it from your devices. Module Size Used by ctr16384 2 ccm20480 6 sd_mod 61440 0 sg 36864 0 uas32768 0 usb_storage81920 1 uas cdc_ether 24576 0 usbnet 57344 1 cdc_ether scsi_mod 270336 4 sd_mod,usb_storage,uas,sg r8152 126976 0 mii16384 2 usbnet,r8152 scsi_common16384 4 scsi_mod,usb_storage,uas,sg cmac 16384 2 algif_hash 16384 1 algif_skcipher 16384 1 af_alg 32768 6 algif_hash,algif_skcipher hid_multitouch 32768 0 mei_hdcp 24576 0 bnep 28672 2 btusb 65536 0 btrtl 28672 1 btusb btbcm 20480 1 btusb btintel45056 1 btusb bluetooth 753664 28 btrtl,btintel,btbcm,bnep,btusb jitterentropy_rng 16384 1 uvcvideo 118784 0 videobuf2_vmalloc 20480 1 uvcvideo sha512_ssse3 45056 1 videobuf2_memops 20480 1 videobuf2_vmalloc videobuf2_v4l2 36864 1 uvcvideo sha512_generic 16384 1 sha512_ssse3 videobuf2_common 69632 4 videobuf2_vmalloc,videobuf2_v4l2,uvcvideo,videobuf2_memops drbg 40960 1 videodev 270336 3 videobuf2_v4l2,uvcvideo,videobuf2_common mc 65536 4 videodev,videobuf2_v4l2,uvcvideo,videobuf2_common ansi_cprng
Bug#983035: Missing dependency on dbus-x11
On Thu, Jan 13, 2022 at 05:06:29PM +1100, Trent W. Buck wrote: Francesco, Is dbus-user-session installed? xfce4-session recommends dbus-user-session, so it SHOULD already be installed. As explained this is a bug found casually while using testing64, at the stage of its development in that date, by installing xfce4 (the meta-package) after a base system installation (i.e. without any desktop task installed). I have no idea if currently this isssue is still present, but I think it could be reproduced as detailed, something I could eventually try again in a nearest future. -cheers Francesco P. Lovergine wrote: Package: xfce4 Version: 4.16 Severity: normal I found a missing dependency on /usr/bin/dbus-launch (dbus-x11) in bullseye, somewhere. Not sure this is an xfce4 issue specifically, feel free to reassign to another proper package. In order to replicate the problem: I just installed from scratch a bullseye current image (debian/testing64) in vagrant, with virtualbox provider, an upgraded it. Then installed xfce4i (the metapackage) and started lightdm. After that, the user cannot login and start a session due to missing dbus-launch, with appropriate message at screen. Installing dbus-x11 solves the problem. dbus-launch (from "dbus-x11") package is the Old Way, which is still attempted as a fallback. Most systemd linux systems will instead use libpam-systemd to set up the user dbus session. In this case, dbus-launch is not used. You can see this in the source code -- if there's already a dbus session (usually created by systemd), it just returns immediately. https://sources.debian.org/src/xfce4-session/4.16.0-1/xfce4-session/main.c/#L275-L278 This is encoded in the control file like this: https://sources.debian.org/src/xfce4-session/4.16.0-1/debian/control/#L31 On a Debian GNU/Linux architecture, that will default to the systemd path (dbus-user-session). Where systemd isn't available (e.g. Debian GNU/kFreeBSD), it falls back to dbus-x11 (dbus-launch). See also https://sources.debian.org/src/xfce4-session/4.16.0-1/debian/changelog/#L37-L38 https://bugs.debian.org/836062 -- Francesco P. Lovergine
Bug#980316: about corepack and yarnpkg
I stumbled upon this thread related to packaging corepack for gentoo: https://github.com/nodejs/corepack/issues/76 We now have node 16 in experimental, but our package does not bundle corepack (as upstream does): https://packages.debian.org/experimental/amd64/nodejs/filelist I propose that we create a RFP/ITP for corepack separate from nodejs, with Conflicts: yarnpkg The corepack binary would install /usr/bin/yarnpkg pointing to the corepack shims; this would allow Debian users who "use different package manager versions across multiple projects" to happily install random binaries downloaded from the internet if they wish. If we agree that we (as a distribution) need specific versions of yarnpkg (for building other stuff, we need to keep one or more yarnpkg packages in Debian, all with Conflicts: corepack + each other. If we really want yarnpkg 1, according to my tests, the corepack route is useless: docker pull node:16 docker run -it --rm node:16 bash yarn -v # 1.22.15 # this downloads https://registry.npmjs.org/yarn/-/yarn-1.22.17.tgz # based on the versions / 1.22.17 / dist / tarball value in: # https://registry.yarnpkg.com/yarn/ corepack prepare yarn@1.22.17 --activate yarn -v # 1.22.15 corepack yarn -v # 1.22.17 ls -l /root/.node/corepack total 2 -rw-r--r-- 1 root root 63 Jan 9 18:33 lastKnownGood.json drwxr-xr-x 1 root root 14 Jan 9 18:13 yarn To "build" it quick and dirty we can download once and for all the same pre-built binary that corepack would download, extract it and symlink it to /usr/bin/yarnpkg (without shims); this package should go to contrib since it downloads stuff from the internet during the build, but would fix the issue of yarnpkg blocking the migration to webpack5 and removal of node-request. Or else keep alive the current version in main by just bundling into it webpack4 and node-request. If we really want a new yarnpkg3 package, corepack is also useless as it merely installs yarnpkg 1. The upstream recommended way of installing yarnpkg 3 (get yarn 1 with corepack then yarn init -2 (sic!)) just downloads the current pre-built binary (ATM https://repo.yarnpkg.com/3.1.1/packages/yarnpkg-cli/bin/yarn.js, 2199165 bytes) to .yarn/releases/yarn-3.1.1.cjs. AFAICT this does not integrate with the shared package manager versions stored in ~/.node/corepack. One way to "build" yarnpkg3 quick and dirty is to download once and for all the same pre-built binary that yarn init -2 would download, and symlink it to /usr/bin/yarnpkg (without shims). Or if we want it in main we should replicate the way upstream builds this yarn.js binary. Sorry for the long message, this is a mess! Paolo
Bug#1001532: [Pkg-javascript-devel] Bug#1001532: yarnpkg: yarnpkg --version cannot find @babel/runtime/helpers module
Il 11/12/21 18:29, Brian Thompson ha scritto: Package: yarnpkg Severity: important Dear Maintainer, After install yarnpkg for the first time and running `yarnpkg --version`, I got the following error: Error: Cannot find module '@babel/runtime/helpers/interopRequireWildcard' I expected the package to return its version. Thanks for reporting the issue. Unfortunately I can not reproduce it on any of my systems here. I also tried on a "clean" Debian stable install with: docker run -it --rm debian:bullseye bash apt update && apt install yarnpkg yarnpkg --version and I get: 1.22.10 I run the command under strace and it looks like indeed it does not find /usr/share/nodejs/yarn/node_modules/@babel/runtime/helpers/interopRequireWildcard.js, but it then proceeds to also try /usr/lib/x86_64-linux-gnu/nodejs/@babel/runtime/helpers/interopRequireWildcard.js (not here) and finally /usr/share/nodejs/@babel/runtime/helpers/interopRequireWildcard.js (this one is there). With: dpkg -S /usr/share/nodejs/@babel/runtime/helpers/interopRequireWildcard.js I find that interopRequireWildcard.js is installed by package node-babel7-runtime which is listed as a "dep" of yarnpkg here: https://packages.debian.org/bullseye/yarnpkg Is it possible that on your system you have installed some non-Debian node module that takes precedence over the ones installed by the Debian packages? Paolo
Bug#999389: Version clash in bullseye-backports
The problem resides in the dependencies of the qemu-system-common package in bullseye-backports: Package: qemu-system-common Version: 1:6.1+dfsg-6~bpo11+1 Priority: optional Section: otherosfs Source: qemu Maintainer: Debian QEMU Team Installed-Size: 8.852 kB Depends: libaio1 (>= 0.3.93), libasound2 (>= 1.0.16), libbrlapi0.8 (>= 6.3+dfsg), libc6 (>= 2.28), libcacard0 (>= 2.2), libcap-ng0 (>= 0.7.9), libepoxy0 (>= 1.3), libfuse3-3 (>= 3.2.3), libgbm1 (>= 7.11~1), libglib2.0-0 (>= 2.37.1), libgnutls30 (>= 3.7.0), libncursesw6 (>= 6), libnettle8, libpixman-1-0 (>= 0.19.6), libseccomp2 (>= 0.0.0~20120605), libspice-server1 (>= 0.14.2), libtinfo6 (>= 6), liburing1 (>= 0.7), libusb-1.0-0 (>= 2:1.0.23~), libusbredirparser1 (>= 0.6), zlib1g (>= 1:1.1.4) Breaks: libvirt-daemon (<< 7.2.0-1), qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~) Replaces: qemu-system-data (<< 1:3.1+dfsg-1~), qemu-utils (<< 1:3.1+dfsg-3~) Homepage: http://www.qemu.org/ As you can see, it breaks libvirt-daemon < 7.2.0-1. It would be great if you backported the 7.6.0-1 version of libvirt-daemon in bookworm to bullseye-backports. -- Mandi. Paolo
Bug#1001174: libmutter-9-0: Screen rotation doesn't work and icon disappeared from top-right menu in gnome
Package: libmutter-9-0 Version: 41.1-1 Severity: important X-Debbugs-Cc: pierpaolo.fra...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Update libmutter to 41 or 40 * What exactly did you do (or not do) that was effective (or ineffective)? Changes settings-daemon.peripherals and desktop-peripherals orientation-lock in dconf/gsetting ineffective (also after logout and login again from the session). monitor-sensor give the expected results. * What was the outcome of this action? Nothing changes. Bear in mind that even in tablet mode (rotating the keybord behind the screen does not resolve the issue). * What outcome did you expect instead? Screen must autorotate. Icon (rotation lock) in top-right menu must show both in desktop and in tablet mode. I found some bugs in gnome tracker (already closed) about libmutter/mutter changes. Cannot refer to them now. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.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 libmutter-9-0 depends on: ii adwaita-icon-theme 41.0-1 ii gsettings-desktop-schemas 41.0-2 ii libatk1.0-02.36.0-2 ii libc6 2.32-4 ii libcairo-gobject2 1.16.0-5 ii libcairo2 1.16.0-5 ii libcanberra0 0.30-8 ii libdrm22.4.108-1 ii libegl11.3.4-2+b1 ii libfontconfig1 2.13.1-4.2 ii libfribidi01.0.8-2 ii libgbm121.2.6-1 ii libgdk-pixbuf-2.0-02.42.6+dfsg-2 ii libgl1 1.3.4-2+b1 ii libglib2.0-0 2.70.1-1 ii libgnome-desktop-3-19 41.1-1 ii libgraphene-1.0-0 1.10.6+dfsg1-2 ii libgtk-3-0 3.24.30-4 ii libgudev-1.0-0 237-2 ii libice62:1.0.10-1 ii libinput10 1.19.2-1 ii libjson-glib-1.0-0 1.6.6-1 ii libpango-1.0-0 1.48.10+ds1-1 ii libpangocairo-1.0-01.48.10+ds1-1 ii libpangoft2-1.0-0 1.48.10+ds1-1 ii libpipewire-0.3-0 0.3.40-2 ii libsm6 2:1.2.3-1 ii libstartup-notification0 0.12-6+b1 ii libsystemd0249.7-1 ii libudev1 249.7-1 ii libwacom2 1.12-1 ii libwayland-server0 1.19.0-2+b1 ii libx11-6 2:1.7.2-2+b1 ii libx11-xcb12:1.7.2-2+b1 ii libxau61:1.0.9-1 ii libxcb-randr0 1.14-3 ii libxcb-res01.14-3 ii libxcb11.14-3 ii libxcomposite1 1:0.4.5-1 ii libxcursor11:1.2.0-2 ii libxdamage11:1.1.5-2 ii libxext6 2:1.3.4-1 ii libxfixes3 1:5.0.3-2 ii libxi6 2:1.8-1 ii libxinerama1 2:1.1.4-2 ii libxkbcommon-x11-0 1.3.1-1 ii libxkbcommon0 1.3.1-1 ii libxkbfile11:1.1.0-1 ii libxrandr2 2:1.5.2-1 ii libxtst6 2:1.2.3-1 ii mutter-common 41.1-1 libmutter-9-0 recommends no packages. libmutter-9-0 suggests no packages. Versions of packages libmutter-9-0 is related to: ii libegl-mesa0 [libegl-vendor] 21.2.6-1 ii libgl1-mesa-dri 21.2.6-1 ii libglx-mesa0 [libglx-vendor] 21.2.6-1 -- no debconf information
Bug#991809: A brief note about NIS installation
Package: release-notes Severity: normal NIS does not more use debconf for its initial installation. While existing setups should smoothly upgrade to the new multi-package organization, the recommended configuration way in bullseye is by following the nis-howto document included in the `nis` meta-package for both clients and servers.
Bug#991544: closing rathen than merging
See https://bugs.debian.org/985857 Paolo
Bug#991544: [Pkg-javascript-devel] Bug#991544: please package bootstrap 5
Hi, Il 27/07/21 08:51, Daniel Baumann ha scritto: Package: twitter-bootstrap4 Hi, thanks a lot for maintaining bootstrap in Debian. Do you already have an ETA for bootstrap 5 (probably a new package in Debian I guess)? Regards, Daniel thanks for your request but twitter-bootstrap4 is no Debian package (it's libjs-bootstrap4) Anyway libjs-bootstrap5 has been requested before as a RFP proper, so I'll merge this one with the bug #985857. RFPs (Requests for Package) are the correct way of entering new package requests in Debian: https://wiki.debian.org/RFP As you can see there is no activity in #985857 yet, so it's basically up for anyone to pick it (we welcome new contributors ;-). Paolo
Bug#987920: ypbind-mt: /etc/defaultdomain should be created at installation time
Indeed, the general NIS howto included in the nis package provides the full documentation for who upgrades or install both servers and clients. A small per program README could probably be a good idea for minimal setup. My original idea was having the nis package as a doc only package after bullseye. It is now a migration package, instead. Well, I think that a simple README file could be added at this stage of release... Il 02 maggio 2021 06:01:40 CEST, Yasuhiro Kimura ha scritto: >Package: ypbind-mt >Version: 2.7.2-2 >Severity: important > >Dear Maintainer, > >What I did: > >1. Download Release Candidate 1 Debian Installer image for Bullseye. >2. Make clean install with it >3. Login as root >4. apt install ypbind-mt >5. Add 'ypserver (IP address of NIS server)' to /etc/yp.conf >6. systemctl start ypbind.service > >Expected behavior: > >ypbind starts successfully. > >What really happens: > >ypbind fails to start. `systemctl status ypbind.service` shows >following log messages > >-- >May 02 10:26:10 nisclienthost systemd[1]: Starting NIS Binding >Service... >May 02 10:26:10 nisclienthost domainname[1234]: domainname: No such >file or directory >May 02 10:26:10 nisclienthost systemd[1]: ypbind.service: Control >process exited, code=exited, status=1/FAILURE >May 02 10:26:10 nisclienthost systemd[1]: ypbind.service: Failed with >result 'exit-code'. >May 02 10:26:10 nisclienthost systemd[1]: Failed to start NIS Binding >Service. >-- > >What is the problem: > >The source of the problem is that following is necessary between step >5 and 6. > >5.5. cat (name of my NIS domain) > /etc/defaultdomain > >But is isn't documented anywhere. So at least it should be documented >in the document of this packages. However, ypbind.service doesn't >start successfully without this file. So it should be created when >this package is installed. > >-- System Information: >Debian Release: bullseye/sid > APT prefers testing-security > APT policy: (500, 'testing-security'), (500, 'testing') >Architecture: amd64 (x86_64) > >Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) >Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), >LANGUAGE=en_US:en >Shell: /bin/sh linked to /usr/bin/dash >Init: systemd (via /run/systemd/system) >LSM: AppArmor: enabled > >Versions of packages ypbind-mt depends on: >ii hostname 3.23 >ii libc6 2.31-11 >ii libnsl21.3.0-2 >ii libsystemd0247.3-5 >ii libtirpc3 1.3.1-1 >ii rpcbind [portmap] 1.2.5-9 > >Versions of packages ypbind-mt recommends: >ii libnss-nis 3.1-4 >ii nscd2.31-11 >ii yp-tools4.2.3-3 > >ypbind-mt suggests no packages. > >-- Configuration Files: >/etc/yp.conf changed: >ypserver 192.168.0.1 > > >-- no debconf information -- Francesco P. Lovergine
Bug#977440: gmusicbrowser: New version not in testing
I suppose 1.1.16 does not solve the underlying issue of gmusicbrowser relying on gtk2. However 1.1.99.1 beta is out supporting gtk3, so it might be worth packaging for experimental! Development is active upstream. Not frenetic, but definitely not dead. Paolo
Bug#982009: Please, drop the obsolete /var for PIDFile in systemd unit file.
Package: krb5-kdc Version: 1.18.3-4 Severity: minor Syslog warns about that. systemd[1]: /lib/systemd/system/krb5-kdc.service:7: PIDFile= references a path below legacy directory /var/run/, updating /var/run/krb5-kdc.pid → /run/krb5-kdc.pid; please update the unit file accordingly. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages krb5-kdc depends on: ii debconf [debconf-2.0] 1.5.74 ii init-system-helpers1.60 ii krb5-config2.6+nmu1 ii krb5-user 1.18.3-4 ii libc6 2.31-9 ii libcom-err21.45.7-1 ii libgssrpc4 1.18.3-4 ii libk5crypto3 1.18.3-4 ii libkadm5srv-mit12 1.18.3-4 ii libkdb5-10 1.18.3-4 ii libkrb5-3 1.18.3-4 ii libkrb5support01.18.3-4 ii libverto-libev10.3.1-1 ii libverto1 0.3.1-1 ii lsb-base 11.1.0 krb5-kdc recommends no packages. Versions of packages krb5-kdc suggests: ii krb5-admin-server 1.18.3-4 pn krb5-kdc-ldap pn krb5-kpropd -- debconf information excluded
Bug#981739: manpages-posix: no-one built the package for debian archive (non-free, source-only upload)
On Wed, Feb 03, 2021 at 02:58:27PM +0200, Juhani Numminen wrote: Package: manpages-posix Version: 2017a-1 Severity: grave Hello, The latest upload of manpages-posix was source-only but was not built on the buildd network either. So, no binaries are available. I think the text of this lintian tag applies in this case: https://lintian.debian.org/tags/source-only-upload-to-non-free-without-autobuild.html regards, Juhani Ah finally someone noted it, eh? Yes, it has been my oversight at upload time. -- Francesco P. Lovergine
Bug#981459: Please, provide a systemd service unit file too
On Tue, Feb 02, 2021 at 09:37:00AM +0300, Sergey B Kirpichev wrote: tags 981459 +wontfix thanks No. Please read README.Debian. I see, indeed the only reason to have it still around is my laziness :-) Ok, let it to go as a ruin of the past... -- Francesco P. Lovergine
Bug#981464: Please, provide systemd service units for multiple use cases
Package: fetchmail Version: 6.4.15-1 Severity: wishlist Please, add at least a proper systemd service unit file as current systemd complains about that at every restart: systemd-sysv-generator: SysV service V'/etc/init.d/fetchmail' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Also, consider that in many cases having a single system service could be not the right solution, so a template service which could be enable by each user who likes that, could be a nice idea too. That could be installed at system level or provided as an example in documentation for people who are not aware of this type of feature for systemd. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fetchmail depends on: ii adduser 3.118 ii debianutils 4.11.2 ii libc6 2.31-9 ii libcom-err2 1.45.7-1 ii libgssapi-krb5-2 1.18.3-4 ii libkrb5-3 1.18.3-4 ii libssl1.1 1.1.1i-2 ii lsb-base 11.1.0 Versions of packages fetchmail recommends: ii ca-certificates 20210119 Versions of packages fetchmail suggests: ii exim4-daemon-heavy [mail-transport-agent] 4.94-12 pn fetchmailconf pn resolvconf -- Configuration Files: /etc/default/fetchmail changed [not included] -- no debconf information
Bug#981462: Please, provide a systemd service unit file too
Package: hddtemp Version: 0.3-beta15-53 Severity: wishlist Please, provide a native systemd service support, as current systemd complains about the missing of a proper unit file. systemd-sysv-generator: SysV service '/etc/init.d/hddtemp' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hddtemp depends on: ii debconf [debconf-2.0] 1.5.74 ii libc6 2.31-9 ii lsb-base 11.1.0 hddtemp recommends no packages. hddtemp suggests no packages. -- debconf information excluded
Bug#981459: Please, provide a systemd service unit file too
Package: monit Version: 1:5.27.2-1 Severity: wishlist As taken from syslog at every restart: systemd-sysv-generator: SysV service '/etc/init.d/monit' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. Note that a sample unit file is already provided among examples, too. -- Francesco P. Lovergine
Bug#981458: Please, provide a systemd unit service too
Package: vtun Version: 3.0.4-2 Severity: wishlist As taken from syslog, at every restart of services: systemd-sysv-generator: SysV service '/etc/init.d/vtun' lacks a native systemd unit file. Automatically generating a unit file for compatibility. Please update package to include a native systemd unit file, in order to make it more safe and robust. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages vtun depends on: ii libc6 2.31-9 ii liblzo2-2 2.10-2 ii libssl1.1 1.1.1i-2 ii lsb-base 11.1.0 ii makedev2.3.1-94.1 ii udev 247.2-5 ii zlib1g 1:1.2.11.dfsg-2 vtun recommends no packages. vtun suggests no packages. -- Configuration Files: /etc/vtund.conf [Errno 13] Permesso negato: '/etc/vtund.conf' -- no debconf information
Bug#981438: Please, provide a proper systemd unit file
Package: sasl2-bin Version: 2.1.27+dfsg-2 Severity: wishlist Please, provide a systemd unit file for sasl-auth and help to reduce systemd-sysv-generator verbosity at boot time about a missing one. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sasl2-bin depends on: ii db-util5.3.1+nmu1 ii debconf [debconf-2.0] 1.5.74 ii init-system-helpers1.60 ii libc6 2.31-9 ii libcrypt1 1:4.4.17-1 ii libdb5.3 5.3.28+dfsg1-0.6 ii libkrb5-3 1.18.3-4 ii libldap-2.4-2 2.4.57+dfsg-1 ii libpam0g 1.4.0-2 ii libsasl2-2 2.1.27+dfsg-2 ii libssl1.1 1.1.1i-2 ii lsb-base 11.1.0 sasl2-bin recommends no packages. sasl2-bin suggests no packages. -- Configuration Files: /etc/default/saslauthd changed [not included] -- debconf information excluded
Bug#981437: Please, provide a systemd unit file also
Package: bitlbee-common Version: 3.6-1.2 Severity: normal Please, help to reduce the noise of systemd-sysv-generator in syslog by providing a proper unit file for bitlbee. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bitlbee-common depends on: ii adduser 3.118 bitlbee-common recommends no packages. bitlbee-common suggests no packages. -- Configuration Files: /etc/bitlbee/bitlbee.conf [Errno 13] Permesso negato: '/etc/bitlbee/bitlbee.conf' -- debconf information excluded
Bug#981407: sysv-generator is really annoying with an eccessive verbosity
Package: systemd Version: 247.2-5 Severity: wishlist Tags: upstream This is the result of rebooting one of my boxes with bullseye: $ sudo dmesg|grep 'lacks a native systemd'|wc -l 463 It gives the same message for tons of init scripts and even for scripts that are there for historical reasons due to packages never purged. While I could undestand the idea of trying to encourage the maintainers to provide also unit files, on the users side this is a nice way to encourage haters of systemd and the whole distribution. -- Package-specific info: -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii adduser3.118 ii libacl12.2.53-9 ii libapparmor1 2.13.6-7 ii libaudit1 1:3.0-2 ii libblkid1 2.36.1-6 ii libc6 2.31-9 ii libcap21:2.44-1 ii libcrypt1 1:4.4.17-1 ii libcryptsetup122:2.3.4-2 ii libgcrypt201.8.7-2 ii libgnutls303.7.0-5 ii libgpg-error0 1.38-2 ii libip4tc2 1.8.7-1 ii libkmod2 28-1 ii liblz4-1 1.9.3-1 ii liblzma5 5.2.5-1.0 ii libmount1 2.36.1-6 ii libpam0g 1.4.0-2 ii libseccomp22.5.1-1 ii libselinux13.1-2+b2 ii libsystemd0247.2-5 ii libzstd1 1.4.8+dfsg-1 ii mount 2.36.1-6 ii ntp [time-daemon] 1:4.2.8p15+dfsg-1 ii util-linux 2.36.1-6 Versions of packages systemd recommends: ii dbus 1.12.20-1 Versions of packages systemd suggests: ii policykit-10.105-29 ii systemd-container 247.2-5 Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.139 ii libnss-systemd 247.2-5 ii libpam-systemd 247.2-5 ii udev 247.2-5 -- no debconf information
Bug#940704: I give up
Control: noowner -1 Control: tags -1 - pending Trying to make the upstream test suite, designed for jest 22, work with our jest 26 is tricky. Also some things defy intuition, i.e. I patch here: https://salsa.debian.org/js-team/node-yarnpkg/-/blob/wip/paolog/jest/debian/patches/20-jest-require-actual.diff#L26 and the autopkgtest baffles me: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1387234#L273 I have parked my work in the wip/paolog/jest branch. I'll release 1.22.10+~cs22.25.14-2 without the test suite FTMB, we can pick it up from there later. Paolo
Bug#981241: tracker.debian.org: please update uscan
Package: tracker.debian.org X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org Severity: important For yarnpkg: https://tracker.debian.org/pkg/node-yarnpkg tracker.debian.org reports: uscan had problems while searching for a new upstream version: unrecognized option ctype=nodejs The option was added with devscripts 2.20.5: https://lists.debian.org/debian-perl/2020/11/msg00047.html Please upgrade devscripts so that uscan works reliably for packages that use the option. BTW thanks for the excellent service! Paolo -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#940704: [Pkg-javascript-devel] Bug#940704: next error
Dear Xavier,
Il 27/01/21 06:30, Xavier ha scritto:
Le 27/01/2021 à 00:14, Paolo Greppi a écrit :
I fixed the error:
Cannot find module 'babel-preset-env'
but I am not sure if the fix is 100% right.
Now I get:
TypeError: Cannot read property 'mkdir' of undefined
5 | export default function(filename?: string):
Promise {
6 | return new Promise((resolve, reject) => {
> 7 | temp.mkdir(filename, function(err, path) {
I added node-temp in debian/tests/control Depends afetr jest, but that
did not help (it would have errored on require('temp') anyway).
I have then turned my attention at brushing up node-temp, see this
message to the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html
Hi,
fixed (patch for node-mkdirp ≥ 1), take a look at my changes
Fantastic job thanks!
I suggest that you also upload it - I am still a DM so I'd nee to bother
someone for sponsorship anyway.
The only comment I have is that the Salsa CI was already enabled, as I had set the Custom CI
config path to recipes/debian.yml@salsa-ci-team/pipeline in Settings -> CI/CD -> General
Pipelines as advised "If the base pipeline configuration fits your needs without further
modifications" here:
https://salsa.debian.org/salsa-ci-team/pipeline#basic-use
But now you have set it to debian/salsa-ci.yml and added that file, with the
same content as:
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/recipes/debian.yml
so nothing changes.
Is there any reason why you prefer the debian/salsa-ci.yml way ?
Paolo
Bug#940704: next error
I fixed the error:
Cannot find module 'babel-preset-env'
but I am not sure if the fix is 100% right.
Now I get:
TypeError: Cannot read property 'mkdir' of undefined
5 | export default function(filename?: string): Promise {
6 | return new Promise((resolve, reject) => {
> 7 | temp.mkdir(filename, function(err, path) {
I added node-temp in debian/tests/control Depends afetr jest, but that did not
help (it would have errored on require('temp') anyway).
I have then turned my attention at brushing up node-temp, see this message to
the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html
Paolo
Bug#981105: RM: node-i18next-xhr-backend -- ROM; not used and deprecated upstream
Package: ftp.debian.org Severity: normal This package has low popcon (1), and according to upstream: https://github.com/i18next/i18next-xhr-backend it is "[deprecated] can be replaced with i18next-http-backend". The latter we already have in Debian: https://tracker.debian.org/pkg/node-i18next-http-backend The maintainer is the Debian Javascript Maintainers team of which I am part of. The original owner of the ITP (https://bugs.debian.org/969295) wrote to the js-team list that he does not "need it anymore since [he] replaced it with node-i18next-http-backend": https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052128.html Thanks, Paolo
Bug#940704: new error: Cannot find module 'babel-preset-env'
Hi, I think I fixed the error:
Cannot find module 'babel-plugin-transform-inline-imports-commonjs'
with this commit:
https://salsa.debian.org/js-team/node-yarnpkg/-/commit/d055e01b6d1a7f6fad6df2ccdf6d0f7d01ddcbc2
but the tests still fail, all with this new error:
FAIL __tests__/commands/licenses.js
● Test suite failed to run
Cannot find module 'babel-preset-env'
Require stack:
- /usr/share/nodejs/@babel/core/lib/config/files/plugins.js
- /usr/share/nodejs/@babel/core/lib/config/files/index.js
- /usr/share/nodejs/@babel/core/lib/index.js
- /usr/share/nodejs/babel-jest/build/loadBabelConfig.js
- /usr/share/nodejs/babel-jest/build/index.js
- /usr/share/nodejs/@jest/transform/build/ScriptTransformer.js
- /usr/share/nodejs/@jest/transform/build/index.js
- /usr/share/nodejs/jest-runtime/build/index.js
- /usr/share/nodejs/jest-runner/build/testWorker.js
- /usr/share/nodejs/jest-worker/build/workers/processChild.js
- Did you mean "@babel/env"?
89 |
90 | try {
> 91 | return require.resolve(standardizedName, {
|^
92 | paths: [dirname]
93 | });
94 | } catch (e) {
at resolveStandardizedName (../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:91:20)
at resolvePreset
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:48:10)
at loadPreset
(../../../../../usr/share/nodejs/@babel/core/lib/config/files/plugins.js:67:20)
at createDescriptor
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:154:9)
at
../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:50
at Array.map ()
at createDescriptors
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:109:29)
at createPresetDescriptors
(../../../../../usr/share/nodejs/@babel/core/lib/config/config-descriptors.js:101:10)
see: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1373973
I tried the obvious fix in debian/tests/control:
-Depends: @, jest
+Depends: @, jest, node-babel-preset-env
but no change.
Paolo
Bug#980775: your initial example also fails with upstream
I tried using the docker "official image" for node: docker pull node docker run -it --rm node bash mkdir -p test/foo cd test yes '' | yarn init yarn add file:foo yields: yarn add file:foo yarn add v1.22.5 info No lockfile found. [1/4] Resolving packages... [2/4] Fetching packages... error /test@0.0.0: Name contains illegal characters info Visit https://yarnpkg.com/en/docs/cli/add for documentation about this command. you need to add the following as in my previous message: cd foo yes '' | yarn init cd .. P.
Bug#980775: patch
With this WIP patch: https://salsa.debian.org/js-team/node-yarnpkg/-/blob/master/debian/patches/18-uuid.diff I can do: rm -rf /tmp/test mkdir -p /tmp/test/foo cd /tmp/test yes '' | yarn init cd foo yes '' | yarn init cd .. yarn add file:foo and get: yarn add v1.22.10 info No lockfile found. [1/4] Resolving packages... [2/4] Fetching packages... [3/4] Linking dependencies... [4/4] Building fresh packages... success Saved lockfile. success Saved 1 new dependency. info Direct dependencies └─ foo@1.0.0 info All dependencies └─ foo@1.0.0 Done in 0.25s. Paolo
Bug#977814: should be fixed with clazy 1.9-3
Hi I see "pass" for clazy/1.9-3 with llvm-toolchain-11/1:11.0.1-2: https://ci.debian.net/packages/c/clazy/testing/amd64/ I also tried this here on unstable and the autopkgtest did pass. Can you check and if confirmed as fixed close this bug? Thanks, Paolo
Bug#975931: should be fixed with pocl 1.6 ?
pocl 1.6-3 has migrated to testing on 2021-01-13, and upstream declares that v1.6 includes "Support for Clang/LLVM 11". Can you try your reproducer now ? Thanks Paolo
Bug#980306: Required dependency now available in main
Package: offlineimap Version: Required dependency now available in main. Severity: normal As reported in d/changelog: Patch OfflineIMAP to remove 'Happy Eyeballs' functionality. The code relies on the rfc6555 Python package, which is not available on Debian. rfc6555 is now available in Debian. -cheers -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#979007: Processed: retitle and set severity to critical
Dear Melvin, Il 14/01/21 13:51, Melvin Vermeeren ha scritto: Hi Paolo, On Thursday, 14 January 2021 10:28:32 CET Paolo Greppi wrote: Doh I had not seen this: https://bugs.debian.org/976227 Let me put both the future Debian maintainer and the current upstream maintainer in Cc. Thanks for the CC. I'm currently finalising some unrelated work so if all goes according to plan I'll have the Debian packaging updated before the end of the month. Still some uncertainty with handling the uploads though. The patch you found should indeed fix FTBFS, there have been no other changes for compatibility since Breathe 4.24.0. It's probably a good idea for this to be released as a quick update if there is some form of time pressure on this. Thanks, as I wrote earlier, this FTBFS is blocking the new version of doxygen (1.9.1) from entering testing / bullseye. So the urgency is given by the upcoming freeze: https://lists.debian.org/debian-devel-announce/2021/01/msg2.html If you intend to take over maintenance of berathe, please prepare the new upload and get it sponsored. FWIW I have given you maintainer access to my fork on salsa. Paolo
Bug#979007: Processed: retitle and set severity to critical
Il 14/01/21 09:40, Sebastian Ramacher ha scritto: ... The package is orphaned. If you a fix for it, please upload it. Best Doh I had not seen this: https://bugs.debian.org/976227 Let me put both the future Debian maintainer and the current upstream maintainer in Cc. I am a DM and currently maintain among other things doxygen. I have no urge to pick up breathe, and I can't upload the NMU myself or sponsor some else's. But I have created a MR to the current repo with just the upstream patch imported: https://salsa.debian.org/sramacher/breathe/-/merge_requests/1 Salsa CI (https://salsa.debian.org/salsa-ci-team/pipeline) is active in my repo and most tests have passed: https://salsa.debian.org/paolog/breathe/-/pipelines/218933 This is blocking the new minor version of doxygen from entering testing. Please push the fix through soon ! Paolo
Bug#979007: Processed: retitle and set severity to critical
Hi Sebastian, Il 09/01/21 11:41, Sebastian Ramacher ha scritto: Control: severity -1 serious ... No, critical is not the correct severity for FTBFS bugs. That's serious. Sorry my fault. I just added a "forwarded upstream" link, it is possible that just by applying the patch provided by upstream fixes the issue. You can import the github patch like this (may require adjustments and adding some DEP-3 tags): wget https://github.com/michaeljones/breathe/commit/41d520e86cb96fba276b7bd3ec0d35e6b4734de3.patch -O debian/patches/41d520e86cb96fba276b7bd3ec0d35e6b4734de3.patch This is blocking the new minor version of doxygen from entering testing. Paolo
Bug#979551: [Pkg-javascript-devel] Bug#979551: node-babel7: update-alternatives set up fails
Il 08/01/21 11:35, Jonas Smedegaard ha scritto: Quoting Paolo Greppi (2021-01-08 08:46:36) I guess that's because the bullseye-slim image lacks the manpages. A Debian install with man pages excluded seems to be an unsupported system: Whatever hooks applied to do that trick should be extended to handle update-alternatives - not the packages providing alternatives nor the update-alternatives mechanism itself! If you disagree, then please try locate passages in Debian Policy to support your view. - Jonas Sorry I am not qualified to respond. Using Debian official images with docker/podman is a use case we should support as it is one significant way for Debian to stay relevant in this post-devops world. Also see: - https://hub.docker.com/_/debian/#Image_Variants - https://github.com/debuerreotype/debuerreotype/issues/10 Paolo
Bug#979551: node-babel7: update-alternatives set up fails
Package: node-babel7 Version: 7.12.11+~cs150.141.84-3 Severity: important Dear Maintainer, installing node-babel7 on official debian "bullseye-slim" docker image fails like this: docker pull debian:bullseye-slim docker run --rm -it debian:bullseye-slim apt update && apt install -y --no-install-recommends yarnpkg ... Setting up node-babel7 (7.12.11+~cs150.141.84-3) ... update-alternatives: using /usr/bin/babeljs-7 to provide /usr/bin/babeljs (babeljs) in auto mode update-alternatives: using /usr/bin/babeljs-7-external-helpers to provide /usr/bin/babeljs-external-helpers (babeljs-external-helpers) in auto mode update-alternatives: using /usr/bin/babeljs-7-node to provide /usr/bin/babeljs-node (babeljs-node) in auto mode update-alternatives: using /usr/bin/babeljs-7-parser to provide /usr/bin/babeljs-parser (babeljs-parser) in auto mode update-alternatives: error: alternative path /usr/share/man/man1/babeljs-7.1.gz doesn't exist dpkg: error processing package node-babel7 (--configure): installed node-babel7 package post-installation script subprocess returned error exit status 2 dpkg: dependency problems prevent configuration of yarnpkg: yarnpkg depends on node-babel7; however: Package node-babel7 is not configured yet. dpkg: error processing package yarnpkg (--configure): dependency problems - leaving unconfigured I guess that's because the bullseye-slim image lacks the manpages. BTW, why is node-babel7 a run-time dependency of yarnpkg ? Should it not just be a build-dep ? Paolo -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: unable to detect Versions of packages node-babel7 depends on: ii node-browserslist 4.16.0+~cs5.4.69-1 ii node-chalk 4.1.0-1 ii node-commander 6.2.1-2 ii node-convert-source-map 1.7.0+~1.5.1-1 ii node-core-js3.8.1-1 ii node-debug 4.3.1+~cs4.1.5-1 ii node-esutils2.0.3-1 ii node-find-cache-dir 3.3.1-1 ii node-fs-readdir-recursive 1.1.0-1 ii node-glob 7.1.6+~7.1.3-1 ii node-globals13.5.0-1 ii node-js-tokens 6.0.0-1 ii node-jsesc 3.0.2-1 ii node-json5 2.1.3-2 ii node-lodash 4.17.20+dfsg+~cs8.31.170-1 ii node-make-dir 3.0.2-1 ii node-quick-lru 1.1.0-2 ii node-regenerator-runtime0.13.7-1 ii node-regenerator-transform 0.14.5-4 ii node-regexpu-core 4.7.1-1 ii node-resolve1.19.0+~cs5.20.8-2 ii node-semver 7.3.4-1 ii node-slash 3.0.0-1 ii node-source-map 0.7.0++dfsg2+really.0.6.1-4 ii node-source-map-support 0.5.19+ds+~0.5.3-1 ii node-to-fast-properties 3.0.1-1 ii node-v8flags3.2.0-1 ii nodejs 12.19.0~dfsg-1 node-babel7 recommends no packages. node-babel7 suggests no packages. -- no debconf information
Bug#979426: missing linux-headers-amd64 prevents running dkms when kernel is updated in debian/contrib-testing64
Package: cloud.debian.org Severity: normal While upgrading the current debian/current-testing64 (half of 2020) under virtualbox provider: [...] /etc/kernel/postinst.d/dkms: dkms: running auto installation service for kernel 5.9.0-5-amd64:Error! Your kernel headers for kernel 5.9.0-5-amd64 cannot be found. Please install the linux-headers-5.9.0-5-amd64 package, or use the --kernelsourcedir option to tell DKMS where it's located [...] That's due to 5.6 -> 5.9 migration and missing of linux-headers-amd64 package apparently. -- System Information: Debian Release: 10.7 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-13-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#979403: skopeo: Error loading trust policy: open /etc/containers/policy.json: no such file or directory
Package: skopeo Version: 1.2.0+dfsg1-2 Severity: important Dear Maintainer, I noticed that if skopeo is installed without buildah, a simple command such as: skopeo copy docker://busybox oci:busybox fails with: FATA[] Error loading trust policy: open /etc/containers/policy.json: no such file or directory as mentioned here: https://github.com/containers/skopeo/issues/181 this can be worked around by executing skopeo with a command-line option: skopeo --insecure-policy copy docker://busybox oci:busybox But /etc/containers/policy.json is installed by buildah, should skopeo recommend buildah ? Or should /etc/containers/policy.json be installed by a new package from which both skopeo and buildah depend ? Thanks, Paolo -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing'), (400, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/12 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages skopeo depends on: ii libc6 2.31-6 ii libdevmapper1.02.1 2:1.02.173-1 ii libgpgme11 1.14.0-1+b2 skopeo recommends no packages. skopeo suggests no packages. -- no debconf information
Bug#979230: offlineimap should install systemd unit files to allow multi-user setup
Package: offlineimap Version: 7.3.3+dfsg1 Severity: normal Offlineimap does allow multiple ways of installing services via systemd as suggested by manual and examples. The package should also install required unit files and allow users to enable/start at their will, which could be useful in multiple use cases. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-12-amd64 (SMP w/32 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect
Bug#979014: wxpython4.0: FTBFS with doxygen 1.9.0 from experimental
Il 02/01/21 02:51, Scott Talbert ha scritto: On Sat, 2 Jan 2021, Paolo Greppi wrote: The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.8.20 is 50 MB and contains 1812 files. The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.9.0 is 42 MB and contains 1583 files. I attach the list of contained files. This could well be a doxygen issue. Please let me know what you think about it. Thanks for the heads up. I think in this case it might be a bug in wxWidgets' Doyxfile, or at least I think I've found a simple way to fix it. I just need to do a full test. BTW, do you happen to know how to install just a single package from experimental when using sbuild? Scott According to the sbuild manpage the charm should be: --extra-repository="deb http://deb.debian.org/debian experimental main" but TBH I dont' use sbuild directly, I use ratt which in turn calls sbuild, and ratt takes as input a .changes file. So I build doxygen locally for sid and pass this .changes file to ratt. Here are the debs I used in case they may help you: https://www.libpf.com/doxygen_1.9.0.tar.xz Paolo
Bug#979014: wxpython4.0: FTBFS with doxygen 1.9.0 from experimental
Source: wxpython4.0 Severity: important Dear Maintainer, in a partial rebuild of the doxygen build dependencies against 1.9.0 from experimental: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.0-1_amd64-partial this package failed to build with this error: Finished command: dox (0m14.759s) Running command: touch Finished command: touch (0.5s) Running command: etg "/usr/bin/python3.9" etg/_core.py --sip --nodoc "/usr/bin/python3.9" etg/_glcanvas.py --sip --nodoc "/usr/bin/python3.9" etg/_stc.py --sip --nodoc Unable to find xml file for ITEM: wxTextCtrl Tried: /root/d/wxpython4.0-4.0.7+dfsg/ext/wxWidgets/docs/doxygen/out/xml/classwx_text_ctrl.xml /root/d/wxpython4.0-4.0.7+dfsg/ext/wxWidgets/docs/doxygen/out/xml/structwx_text_ctrl.xml /root/d/wxpython4.0-4.0.7+dfsg/ext/wxWidgets/docs/doxygen/out/xml/wxTextCtrl Traceback (most recent call last): File "/root/d/wxpython4.0-4.0.7+dfsg/etg/_stc.py", line 243, in run() File "/root/d/wxpython4.0-4.0.7+dfsg/etg/_stc.py", line 151, in run mod = textctrl.parseAndTweakModule() File "/root/d/wxpython4.0-4.0.7+dfsg/etg/textctrl.py", line 32, in parseAndTweakModule etgtools.parseDoxyXML(module, ITEMS) File "/root/d/wxpython4.0-4.0.7+dfsg/etgtools/__init__.py", line 82, in parseDoxyXML raise DoxyXMLError(msg) etgtools.DoxyXMLError: Unable to find xml file for ITEM: wxTextCtrl Command '"/usr/bin/python3.9" etg/_stc.py --sip --nodoc' failed with exit code 1. Finished command: etg (0.688s) The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.8.20 is 50 MB and contains 1812 files. The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.9.0 is 42 MB and contains 1583 files. I attach the list of contained files. This could well be a doxygen issue. Please let me know what you think about it. I am not yet 100% sure that it makes sense to rush doxygen 1.9.0 to bullseye, but I might try, and if so, I'll increase the severity of this bug to serious. Paolo -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled 1.8.20.txt.xz Description: application/xz 1.9.0.txt.xz Description: application/xz
Bug#979011: forgot to attach the log file
libvigraimpex_1.11.1+dfsg-7.xz Description: application/xz
Bug#979011: libvigraimpex: FTBFS with doxygen 1.9.0 from experimental
Source: libvigraimpex Severity: important Dear Maintainer, in a partial rebuild of the doxygen build dependencies against 1.9.0 from experimental: https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.0-1_amd64-partial this package failed to build with this error: Postprocessing html files cd /<>/obj.x86_64-linux-gnu/docsrc && /usr/bin/python3 /<>/docsrc/makeFunctionIndex.py /<>/doc/vigra Traceback (most recent call last): File "/<>/docsrc/makeFunctionIndex.py", line 141, in generateFunctionIndex(functionList) File "/<>/docsrc/makeFunctionIndex.py", line 124, in generateFunctionIndex text = open(path + "/namespaces.html").read() File "/usr/lib/python3.9/codecs.py", line 322, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb3 in position 138922: invalid start byte I attach the full log. The namespaces.html file found in doc/vigra is 142804 bytes long (for reference, the one installed in /usr/share/doc/libvigraimpex-dev/html/namespaces.html by libvigraimpex-doc is 7535 bytes). I cheched with hexdump around position 138922 (hex 21EAA): ... 00021e60 3d 22 64 65 73 63 22 3e 43 6f 6d 70 75 74 61 74 |="desc">Computat| 00021e70 69 6f 6e 20 6f 66 20 57 69 67 6e 65 72 20 44 20 |ion of Wigner D | 00021e80 6d 61 74 72 69 78 20 2b 20 72 6f 74 61 74 69 6f |matrix + rotatio| 00021e90 6e 20 66 75 6e 63 74 69 6f 6e 73 20 69 6e 20 53 |n functions in S| 00021ea0 48 2c 56 48 20 61 6e 64 20 52 b3 20 3c 2f 74 64 |H,VH and R. .CWignerMatrixComputation of Wigner D matrix + rotation functions in SH,VH and R³ This text is extracted from include/vigra/wigner-matrix.hxx: ... 0b90 78 20 2b 20 72 6f 74 61 74 69 6f 6e 20 66 75 6e |x + rotation fun| 0ba0 63 74 69 6f 6e 73 20 0a 20 20 20 20 20 2a 20 20 |ctions . * | 0bb0 20 20 20 20 20 20 20 69 6e 20 53 48 2c 56 48 20 | in SH,VH | 0bc0 61 6e 64 20 52 b3 0a 20 20 20 20 20 2a 0a 20 20 |and R.. *. | 0bd0 20 20 20 2a 20 41 6c 6c 20 72 6f 74 61 74 69 6f | * All rotatio| ... The 0xb3 byte is present in your source, and doxygen merely moves it from one place to the other. You can either fix the byte in the source or file or fix the Python script to be more lax with Unicode errors. I am not yet 100% sure that it makes sense to rush doxygen 1.9.0 to bullseye, but I might try, and if so, I'll increase the severity of this bug to serious. Paolo -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#979007: breathe: FTBFS with doxygen 1.9.0 from experimental
Source: breathe
Severity: important
Dear Maintainer,
in a partial rebuild of the doxygen build dependencies against 1.9.0 from
experimental:
https://salsa.debian.org/debian/doxygen/-/wikis/ratt_doxygen_1.9.0-1_amd64-partial
this package failed to build with this error:
AssertionError
>
/<>/.pybuild/cpython3_3.9/build/breathe/renderer/sphinxrenderer.py(1781)visit_friendclass()
-> assert typ in ("friend class", "friend struct")
A similar error occurred while building liborcus.
I attach the full logs for both.
I am not yet 100% sure that it makes sense to rush doxygen 1.9.0 to bullseye,
but I might try, and if so, I'll increase the severity of this bug to serious.
Paolo
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
breathe_4.24.0-1.xz
Description: application/xz
liborcus_0.16.1-3.xz
Description: application/xz
Bug#940704: autopkgtests now failing
I have enabled he upstream test suite on salsa, it fails with many of these: FAIL __tests__/commands/install/integration.js ● Test suite failed to run Cannot find module 'babel-plugin-transform-inline-imports-commonjs' Require stack: ... See: https://salsa.debian.org/js-team/node-yarnpkg/-/jobs/1287491 Not sure how to proceed .. Paolo
Bug#940704: some tests do pass
I have run jest in the yarnpkg source tree with:
jest --ci __tests__/
having this jest.config.js to disable failing tests:
module.exports = {
testURL: "http://localhost/;,
testPathIgnorePatterns: [
"/node_modules/",
"/__tests__/index.js",
"/__tests__/integration.js",
"/__tests__/lifecycle-scripts.js",
"/__tests__/pipe.js",
"/__tests__/commands/pack.js",
"/__tests__/commands/run.js",
"/__tests__/fixtures",
"/__tests__/reporters/_mock.js",
"/__tests__/commands/_helpers.js",
"/__tests__/_temp.js",
"/__tests__/__mocks__",
"/__tests__/commands/install/lockfiles.js"
]
}
result:
Test Suites: 1 skipped, 81 passed, 81 of 82 total
Tests: 15 skipped, 1116 passed, 1131 total
Snapshots: 111 passed, 111 total
Time:74.936s
Ran all test suites matching /__tests__\//i.
I think we can include it in the autopkgtest, later we can try to understand
why some tests are failing ..
Note:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-November/047062.html
Paolo
Bug#977781: [Pkg-javascript-devel] Bug#977781: Bug#977781: real issue is, it does not pull not-yet-cached modules
Hi Akshay, many thanks for the debugging ! see below Il 22/12/20 06:06, Akshay S Dinesh ha scritto: There are some 4 pipes before the finish event. I'm looking through each one of them to see if there's a mismatch. It seems to be tar-fs Please see https://salsa.debian.org/js-team/node-yarnpkg/-/merge_requests/4 I've just downloaded the latest version from the github of tar-fs and replace in the directory. Not sure if this is the way to do it. It's a pity the salsa Continuous Integration has failed on your fork. I noticed this message in the extract-source job log: gbp:error: upstream/1.22.10+_cs18.39.16 is not a valid treeish indeed your fork only has 33 tags, whereas js-team/node-yarnpkg has 37. Please pull those tags and push them to your fork, then force restart the CI pipeline. This would help us to see if your proposed fix works. As to upgrading tar-fs, it is possible that some other dependency we updated here and there requires it. Upstream are currently using 1.16.3: https://github.com/yarnpkg/yarn/blob/master/yarn.lock#L7137 whereas we were already using version 2 If we want to upgrade tar-fs we need to upgrade its sources and then import them in upstream and master branches: https://wiki.debian.org/Javascript/GroupSourcesTutorial Paolo
Bug#977781: real issue is, it does not pull not-yet-cached modules
Hi Pirate, what you want to put in ~/.yarnrc.yml could be installed globally to /etc/yarn/config or /etc/yarnrc, but that does not actually fix it. I think the real issue is that it does not pull not-yet-cached modules. To reproduce: # clear cache rm -rf ~/.cache/yarn # actual test cd `mktemp -d` yarnpkg init -y yarnpkg add d3-color Adding the nodeLinker: "node-modules" option to ~/.yarnrc.yml or the global locations does not help. It would be interesting to debug the JavaScript execution after it prints "Fetching packages..." Paolo
Bug#977349: Current package does not ensure a smooth upgrade from stable due to breakage of past config and new binary modules.
Source: proftpd-dfsg Version: 1.3.7a+dfsg-2 Severity: serious After upgrade: $ sudo proftpd -t Checking syntax of configuration file 2020-12-14 09:59:09,942 legolas proftpd[5444]: mod_dso/0.5: unable to load 'mod_tls.c'; check to see if '/usr/lib/proftpd/mod_tls.la' exists 2020-12-14 09:59:09,942 legolas proftpd[5444]: fatal: LoadModule: error loading module 'mod_tls.c': No such file or directory on line 22 of '/etc/proftpd/modules.conf' 2020-12-14 09:59:09,942 legolas proftpd[5444]: warning: unable to include '/etc/proftpd/modules.conf': Operation not permitted 2020-12-14 09:59:09,943 legolas proftpd[5444]: mod_dso/0.5: unable to load 'mod_wrap.c'; check to see if '/usr/lib/proftpd/mod_wrap.la' exists 2020-12-14 09:59:09,943 legolas proftpd[5444]: fatal: LoadModule: error loading module 'mod_wrap.c': No such file or directory on line 8 of '/etc/proftpd/proftpd.conf' That's due to mod_wrap and mod_tls move to distinct binaries in the new version of the package. A transitional package is required, the same problem is expected in dist-upgrade from stable. -- System Information: Debian Release: 10.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-12-amd64 (SMP w/32 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen
Hi Hilmar, Il 09/12/20 23:44, Hilmar Preuße ha scritto: Control: reassign -1 src:doxygen ... As explained this issue is probably not related to changed in TL base, hence I'm reassigning to src:doxygen . For the other build failures, w/ docbook based documents I've opened Bug#976887 w/ criticality serious to make sure the new TL packages do not migrate to testing until the issue is sorted out. Hilmar well done ! Paolo
Bug#976056: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9.11 (package linux-image-5.9.0-4-amd64)
About that rule, the only way to prevent breaking testing would have been marking this bug as release critical not for this package, but for the linux kernel package. Which in turn would mean holding off new kernel releases from debian until a proprietary legacy driver is fixed, which might never happen since nvidia officially discontinued this driver. Also remember that this package is in non-free, which is considered to be not part of debian. AFAIU it depends on turning a flag in kernel compilation, and I don't understand what it does but I trust it was shutdown for good reason. Just saying IMHO we shouldn't be mad at debian for what happened, just hope someone will find a way to fix it. Paolo Il lun 7 dic 2020, 02:12 Del Fernandes ha scritto: > It was quite disappointing to see (or not see) the GUI/WM stop working > after a causal system update (not upGrade). > > I was able to get the system somewhat back to normal by using the > NOUVEAU driver instead of NVIDIA. BTW, even that was kind of tricking > because the Nvidia driver blacklisted Nouveau at > /etc/modprobe.d/nvidia-blacklists-nouveau.conf which remained even > after purging everything related to Nvidia via APT. > > PS.: For some reason, the laptop no longer revived with Nouveau after > a suspend (closing the laptop's lid). That was "bypassed" in the > meantime by editing /etc/systemd/logind.conf and replacing all > "suspends" with "ignores". > > Again, that was very disappointing !8-(. What happened with the golden > 'Do no harm, don't break users' rule?! > > On Sun, Dec 6, 2020 at 1:33 PM Paolo Inaudi wrote: > > > > @jim_p Is it possible for you to avoid putting all system information > > and Xorg logs in every message? > > It makes the thread very difficult to follow on the online bug tracker. > > > > I too rolled back to linux-image-5.9.0-3-amd64 which works, hope it > > won't be my very last kernel version. > > > > -- > > To unsubscribe, send mail to 976056-unsubscr...@bugs.debian.org. > > -- > To unsubscribe, send mail to 976056-unsubscr...@bugs.debian.org. >
Bug#976056: nvidia-legacy-340xx-driver: Fails to build with kernel 5.9.11 (package linux-image-5.9.0-4-amd64)
@jim_p Is it possible for you to avoid putting all system information and Xorg logs in every message? It makes the thread very difficult to follow on the online bug tracker. I too rolled back to linux-image-5.9.0-3-amd64 which works, hope it won't be my very last kernel version.
Bug#976405: also happens on amd64, should be worked around by 1.8.20-5 but the real fix will come with 1.8.20-6
Hi Lucas (is it you, or a bot?), thanks for the new bug report about doxygen 1.8.20-4 FTBFS on arm64: https://bugs.debian.org/976495 I had noticed this issue yesterday and worked around it with 1.8.20-5 but the real fix will come with 1.8.20-6, thanks to a tip from Norbert Preining: https://bugs.debian.org/976405#10 It would be interesting to know when you last run the archive rebuild on arm64 or amd64, because it's not clear since when this error happens. Paolo
Bug#976405: texlive-latex-base: pdflatex command fails while building doxygen
Hi Norbert, Il 04/12/20 23:29, Norbert Preining ha scritto: Hi Paolo, /usr/bin/pdflatex: Not writing to ../html/examples/group/latex//group__group2.aux (openout_any = p). make[4]: *** [doc/CMakeFiles/doxygen_pdf.dir/build.make:81: doc/CMakeFiles/doxygen_pdf] Error 1 Is this new? This should have happened already since long time ago. LaTeX etc now ensures to not write out of the current directory and its sub-directories, so writing to ../html is a no go, this is the setting openout_any = p From /usr/share/texlive/texmf-dist/web2c/texmf.cnf ** % Do we allow TeX \input or \openin (openin_any), or \openout % (openout_any) on filenames starting with `.' (e.g., .rhosts) or % outside the current tree (e.g., /etc/passwd)? % a (any): any file can be opened. % r (restricted) : disallow opening dot files % p (paranoid) : as `r' and disallow going to parent directories, and % restrict absolute paths to be under $TEXMFOUTPUT. openin_any = a openout_any = p ** This is not a new change, at least ... at least ... I can't remember, years? So I am very surprised that it would show up only now. Options are: - don't write to .. - use pdflatex -cnf-line="openout_any = r" (never tried it though) - temporarily set in /usr/local/share/texmf/web2c/texmf.cnf by adding the same openout definition Hope that helps Norbert -- PREINING Norbert https://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13 thanks for the tip ! Not sure why this surfaced only now ... anyway your 2nd option seems to fix it. I have also submitted the patch to doxygen upstream for review: https://github.com/doxygen/doxygen/issues/8226 If all goes well I'll upload doxygen 1.8.20-6 in a few days and this will be closed. Paolo
