Bug#1058868: gemmi: Please build shared library
> I appreciate the idea and your patch, thanks for giving gemmi a look. > However, I am hesitant to package gemmi shared library for Debian for > now. The previous two releases had breaking API changes each. If > upstream handles this properly and bumps the soversion, then this is > fine, although having to undergo a transition twice a year is still > quite some work. However, if the upstream does not maintain ABI > stability inside the same soversion, then I would say the shared > library is not yet ready for Debian. > > You have marked this bug as severity:important. Does this mean you > need gemmi's shared library for some package? Hi, yas I'm going to package ovito which depends on it. If shared library isn't provided, cmake automatically uses libgemmi_cpp.a which then embed gemmi into ovito :-( > I never had the need to manually trigger the ldconfig before. The > issue might be the lack of 'Section: libs' in binary package > description. Maybe it's the issue Best regards, Yadd
Bug#1055192: RFS: golang-github-apenella-go-ansible
Hi Ananthu, On Sat, 2023-12-16 at 16:07 +0530, weepingclown wrote: > DH_GOLANG_EXCLUDES_ALL is true by default since DH_COMPAT 12 (according to the > manual at least). I also confirmed that examples/ is not installed in > /usr/share/gocode. Nonetheless, thank you for showing the care :) My mistake, I didn't notice that in the manual. :) Here's some more things I've found (in go-ansible): - golang-github-go-errors-errors-dev is only used in pkg/vault/variableVaulter_test.go, should it be and removed from Deps? - golang-github-spf13-cobra-dev is only used in the examples (specifically examples/ansibleplaybook-cobra-cmd/ansibleplaybook-cobra-cmd.go), should it be removed from (B-)Deps? Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Bug#1058907: princeprocessor: Add support for loong64
Package: princeprocessor
Version: 0.22-5
Severity: normal
X-Debbugs-Cc: zhan...@loongson.cn
Dear Maintainer,
Please add 'loong64' to the 'Architecture' field in the debian/control file,
patch file is attached.
Thanks,
Zhang Na
-- System Information:
Debian Release: trixie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'unstable')
Architecture: loong64 (loongarch64)
Kernel: Linux 5.10.0-60.96.0.126.oe2203.loongarch64 (SMP w/32 CPU threads)
Locale: LANG=zh_CN.UTF-8, LC_CTYPE=zh_CN.UTF-8 (charmap=ANSI_X3.4-1968)
(ignored: LC_ALL set to C), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect
Versions of packages princeprocessor depends on:
ii libc6 2.37-13
princeprocessor recommends no packages.
princeprocessor suggests no packages.
-- no debconf information
diff -Naur princeprocessor-0.22-orj/debian/control
princeprocessor-0.22/debian/control
--- princeprocessor-0.22-orj/debian/control 2023-12-11 12:55:39.0
+
+++ princeprocessor-0.22/debian/control 2023-12-18 07:29:58.031494138 +
@@ -11,7 +11,7 @@
Homepage: https://github.com/hashcat/princeprocessor
Package: princeprocessor
-Architecture: amd64 arm64 mips64el ppc64el s390x alpha kfreebsd-amd64 ppc64
riscv64 sparc64 x32
+Architecture: amd64 arm64 mips64el ppc64el s390x alpha kfreebsd-amd64 ppc64
riscv64 sparc64 x32 loong64
Depends: ${misc:Depends},
${shlibs:Depends}
Description: standalone password candidate generator using the PRINCE algorithm
Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel
Hello, Have you monitored that is memory exhausted at the installation? This could lead error like that. I assume your XEN/KVM/Docker base machine is some older system with not so fancy CPU or is there any particular reason to use armel build? Sincerly, Tuukka Scott Barker kirjoitti 17.12.2023 klo 19.15: Same result with the latest kernel: Linux nas-1 6.1.0-16-marvell #1 Debian 6.1.67-1 (2023-12-12) armv5tel GNU/Linux On Sun, Dec 17, 2023 at 09:59:23AM -0700, Scott Barker wrote: Prior to the installation, /var/lib/mysql did not exist. After installation: 61559 4 drwxr-xr-x 2 mysql mysql 4096 Dec 17 09:56 /var/lib/mysql 61975 4 -rw-rw 1 mysql mysql 52 Dec 17 09:56 /var/lib/mysql/aria_log_control 61983 12304 -rw-rw 1 mysql mysql 12582912 Dec 17 09:56 /var/lib/mysql/ibdata1 61963 0 -rw-r--r-- 1 root root 0 Dec 17 09:56 /var/lib/mysql/debian-10.11.flag 61990 98404 -rw-rw 1 mysql mysql 100663296 Dec 17 09:56 /var/lib/mysql/ib_logfile101 61982 16 -rw-rw 1 mysql mysql 16384 Dec 17 09:56 /var/lib/mysql/aria_log.0001 uname -a reports: Linux nas-1 5.10.0-26-marvell #1 Debian 5.10.197-1 (2023-09-29) armv5tel GNU/Linux On Sun, Dec 17, 2023 at 11:48:16PM +0800, Otto Kekäläinen wrote: Hi Scott and Kr! Did you note this line? 2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero bytes in datafile: ./ibdata1, Space ID:0, Flags: 0 Can you include the output of `find /var/lib/mysql -ls` so we can see what files your system has? What is the hardware you have? The report shows 'Linux 5.10.0-26-marvell '. What does `uname -a` yield? The test suite passes on armhf at e.g. https://launchpad.net/~mysql-ubuntu/ +archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all. At https:// ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to regression in subselect which is unrelated to what you reported. -- Scott Barker -- To unsubscribe, send mail to 1058706-unsubscr...@bugs.debian.org.
Bug#1058868: [Debichem-devel] Bug#1058868: gemmi: Please build shared library
Control: tags -1 + moreinfo Hi Yadd, On 2023-12-17 11:31, Yadd wrote: Source: gemmi Version: 0.6.3+ds-1 Severity: important Tags: patch X-Debbugs-Cc: y...@debian.org Hi, currently src:gemmi builds gemmi and gemmi-dev. This doesn't permit to build any software using gemmi-dev without static linking. The proposed patch adds package libgemmi1 which contains the shared library. I appreciate the idea and your patch, thanks for giving gemmi a look. However, I am hesitant to package gemmi shared library for Debian for now. The previous two releases had breaking API changes each. If upstream handles this properly and bumps the soversion, then this is fine, although having to undergo a transition twice a year is still quite some work. However, if the upstream does not maintain ABI stability inside the same soversion, then I would say the shared library is not yet ready for Debian. You have marked this bug as severity:important. Does this mean you need gemmi's shared library for some package? I never had the need to manually trigger the ldconfig before. The issue might be the lack of 'Section: libs' in binary package description. Thanks, Andrius
Bug#1017780: 1.5.517 in salsa repository [was: Version bump: 1.4.230]
Hello Sven. Thank you very much for your efforts on this bug. Most the changes the patches make and offhand look reasonable, and for the moment I've pulled them from the 'improvement' branch your mumble Git repo. However I'm wondering about the permissions change to /etc/mumble as to why that's desired: chown root:mumble-server /etc/mumble/ What is the benefit of updating the /etc/mumble/ directory to have group ownership by mumble-server? Is the intent for allowing a number of users that are added to the mumble-server group to be allowed to update the mumble-server.ini file? Let me know so I can explain it. ;-) Thanks On 12/8/23 11:36, Sven Hartge wrote: On Fri, 3 Mar 2023 06:16:00 + Chris Knadle wrote: If someone knows how to fix the mumble-server.service file so that mumble-server can start, that would be helpful; once that's fixed I can make an upload to Debian Experimental. The file in the tree is at: Hello Chris, I looked at the problem and I fixed all the problems (and some more) preventing the daemon to start under systemd. You can either pull from https://salsa.debian.org/hartge/mumble.git or apply the attached diff. I tested my changes for fresh installations and upgrades, both work correctly. These changes fix #1039271 as well. Grüße, Sven. -- Chris Knadle chris.kna...@coredump.us
Bug#1058905: QEMU: why not use package opensbi as dependency?
18.12.2023 09:33, Heinrich Schuchardt wrote: Package: qemu-system-data Version: 1:8.2.0~rc2+ds-1 Severity: wishlist Hello Michael, Debian provides package opensbi. I didn't know about opensbi up until this your email. In the qemu package's debian/rules we build another OpenSBI. Wouldn't it be preferable to reuse the existing opensbi package? This would imply that if we update OpenSBI also QEMU will use that new version. Well, this is a two-folded knife, as usual. This also means that if there's an update of opensbi in qemu, we'll have to update separate opensbi package in debian. So far (in recent years) we only had seabios-hppa update like that (and there's no seabios-hppa package in debian anyway). Before, we had to keep some pieces closer to qemu, - eg, seabios were updated much more frequently in qemu (with qemu-specific changes too) than upstream releases were released. This is in the past now though. These are the duplicate files: opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.elf qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.elf opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin Yes, we can do that. I don't see much benefit here though. For one, I dislike dangling symlinks in package, and don't want to add yet another directory to firmware search directories. /mjt
Bug#1028489: boost1.83 as default
Don't forget to raise the severity of the FTBFS bugreports to serious now that the new boost-defaults is in unstable. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1058906: libsbml: add build support for loongarch64
Source: libsbml
Version: 5.19.7+dfsg-2
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
The libsbml source package lacks LoongArch architecture support.
We need to add build support for loongarch64 in d/control.
Please consider the patch I have attached.
If you have any questions, you can contact me at any time.
thanks,
Dandan Zhang
diff --git a/debian/control b/debian/control
index d57c9b6..8c5e710 100644
--- a/debian/control
+++ b/debian/control
@@ -41,7 +41,7 @@ Testsuite: autopkgtest-pkg-python
X-Python3-Version: 3.11
Package: libsbml5-dev
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: libdevel
Depends: libsbml5 (= ${binary:Version}),
${misc:Depends}
@@ -55,7 +55,7 @@ Description: System Biology Markup Language library - development files
This package contains files necessary for development with libsbml.
Package: libsbml5
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: libs
Depends: ${shlibs:Depends},
${misc:Depends}
@@ -69,7 +69,7 @@ Description: System Biology Markup Language library
but rather a library you can embed in your own applications.
Package: python3-sbml5
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: python
Depends: ${shlibs:Depends},
${misc:Depends},
@@ -85,7 +85,7 @@ Description: System Biology Markup Language library - Python3 bindings
This package contains the Python3 bindings of LibSBML.
Package: libsbml5-java
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: java
Depends: ${shlibs:Depends},
${misc:Depends},
@@ -102,7 +102,7 @@ Description: System Biology Markup Language library - Java bindings
This Package contains the Java bindings of LibSBML.
Package: libsbml5-perl
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: perl
Depends: ${shlibs:Depends},
${perl:Depends},
@@ -117,7 +117,7 @@ Description: System Biology Markup Language library - Perl bindings
This package contains the Perl bindings of LibSBML.
Package: libsbml5-octave
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: math
Depends: ${shlibs:Depends},
${misc:Depends},
@@ -132,7 +132,7 @@ Description: System Biology Markup Language library - Octave bindings
This package contains the Octave bindings of LibSBML.
Package: libsbml5-cil
-Architecture: any-amd64 arm64 armel armhf any-i386 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
+Architecture: any-amd64 arm64 armel armhf any-i386 loong64 mips64el ppc64el s390x ia64 ppc64 riscv64 sh4 sparc64 x32
Section: cli-mono
Depends: ${shlibs:Depends},
${misc:Depends},
Bug#1058905: QEMU: why not use package opensbi as dependency?
Package: qemu-system-data Version: 1:8.2.0~rc2+ds-1 Severity: wishlist Hello Michael, Debian provides package opensbi. In the qemu package's debian/rules we build another OpenSBI. Wouldn't it be preferable to reuse the existing opensbi package? This would imply that if we update OpenSBI also QEMU will use that new version. These are the duplicate files: opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.elf qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.elf opensbi: /usr/lib/riscv64-linux-gnu/opensbi/generic/fw_dynamic.bin qemu-system-data: /usr/share/qemu/opensbi-riscv64-generic-fw_dynamic.bin Best regards Heinrich
Bug#1051064: fonts-b612: The package is either missing or has mislabled the regular font style.
Hi Brad Can you tell me in which software the problem occurs? Best,
Bug#1053994: A solution has appeared
hello. It looks like there is a solution. https://bugzilla.kernel.org/show_bug.cgi?id=215119#c52 it is necessary to assemble this core. and try it out.
Bug#1028489: boost1.83 as default
Hi Sebastian, uploded. Anton Am So., 17. Dez. 2023 um 18:13 Uhr schrieb Sebastian Ramacher : ... > Please go ahead. > > Cheers > -- > Sebastian Ramacher
Bug#985184: reminiscence not anymore licensed
On Mon, 18 Dec 2023 00:38:26 +0100, Alexandre Detiste wrote: > I think until the licensing problem is not resolved, > this old version of the game should not be included in a release. Why not? The license of the old version is still valid... Regards, Stephen pgpyLcOab2FeX.pgp Description: OpenPGP digital signature
Bug#1056279: Bug#1057220: Looks like the systemctl links are gone but not the pm-utils ones
Thank you Helmut and Chris for the helpful discussion. I have finally found some time to review your comments and the proposed molly-guard patches. While I'm still not 100% confident I understand the problem (and the fix), the solution you have settled on makes sense to me. With respect to the presence of the real commands in the path, I'm not too worried about it personally. I do agree it's unfortunate and it would be great if we could do this reliably without putting the diverted binary within easy reach, but at the end of the day, molly-guard will never catch all possible mistakes. As Helmut pointed out, it's already missing some cases (and it's always been possible to "init 6" as well), but I think it still provides a useful service if it catches the most common cases of accidental reboots. I had a similar dilemma for another package I maintain (safe-rm) and I've decided there to focus on the most common cases again to reduce complexity, and improve reliability. I will leave this for a few days in case others like Simó want to also chime in, but otherwise I am planning to upload to experimental this week and then unstable a few days later. Again many thanks for all of the work that has gone into solving this thorny problem. Francois
Bug#1058904: python3-apt: apt_pkg.TagFile segfaults on files with comments
Package: python3-apt
Version: 2.7.2
Severity: serious
X-Debbugs-Cc: stu...@debian.org
Dear Maintainer,
With the upgrade to python3-apt 2.7.2, CI for python-debian started
failing for both python3.11 and python3.12. The particular test where
the segfault is found feeds apt_pkg.TagFile data that contains comments
in the form permitted by Policy for source package control files.
https://salsa.debian.org/stuart/python-debian/-/blob/master/tests/test_deb822.py?ref_type=heads#L1279
Previous versions raised apt_pkg.Error for erronous data.
They key feature of the data that is causing the segfault is the
inclusion of a comment in a multiline field.
While users of python-debian's deb822 wrappers are encouraged to not use
apt_pkg.TagFile for anything other than archive-generated files such as
the Sources and Packages files, there are legacy users and
out-of-archive users that could be doing so. Unparsable data should also
not segfault the interpreter but generate an exception.
regards
Stuart
Steps to reproduce (output below are for git HEAD with a slightly
rearranged directory structure; current version in sid does the same):
$ debcheckout python-debian
$ cd python-debian
$ python3.11 -m pytest -k test_iter_paragraphs_comments_use_apt_pkg
== test session starts
==
platform linux -- Python 3.11.7, pytest-7.4.3, pluggy-1.3.0 --
/usr/bin/python3.11
cachedir: .pytest_cache
rootdir: /tmp/pkgs/python-debian
configfile: pyproject.toml
testpaths: src, tests
plugins: cov-4.1.0
collected 295 items / 294 deselected / 1 selected
tests/test_deb822.py::TestDeb822::test_iter_paragraphs_comments_use_apt_pkg
Fatal Python error: Segmentation fault
Current thread 0x7f97ca55a040 (most recent call first):
File "/tmp/pkgs/python-debian/src/debian/deb822.py", line 740 in iter_paragraphs
File "/tmp/pkgs/python-debian/tests/test_deb822.py", line 1297 in
test_iter_paragraphs_comments_use_apt_pkg
File "/usr/lib/python3/dist-packages/_pytest/python.py", line 194 in
pytest_pyfunc_call
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in _multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in _hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in __call__
File "/usr/lib/python3/dist-packages/_pytest/python.py", line 1792 in runtest
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 169 in
pytest_runtest_call
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in _multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in _hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in __call__
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 262 in
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 341 in from_call
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 261 in
call_runtest_hook
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 222 in
call_and_report
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 133 in
runtestprotocol
File "/usr/lib/python3/dist-packages/_pytest/runner.py", line 114 in
pytest_runtest_protocol
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in _multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in _hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in __call__
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 350 in
pytest_runtestloop
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in _multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in _hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in __call__
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 325 in _main
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 271 in wrap_session
File "/usr/lib/python3/dist-packages/_pytest/main.py", line 318 in
pytest_cmdline_main
File "/usr/lib/python3/dist-packages/pluggy/_callers.py", line 77 in _multicall
File "/usr/lib/python3/dist-packages/pluggy/_manager.py", line 115 in _hookexec
File "/usr/lib/python3/dist-packages/pluggy/_hooks.py", line 493 in __call__
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 169 in
main
File "/usr/lib/python3/dist-packages/_pytest/config/__init__.py", line 192 in
console_main
File "/usr/lib/python3/dist-packages/pytest/__main__.py", line 5 in
File "", line 88 in _run_code
File "", line 198 in _run_module_as_main
Or a minimal example directly with apt_pkg:
$ echo "Source: foo
Build-Depends: debhelper,
# quux,
python" > data
$ python3 -c "import apt_pkg; [p for p in apt_pkg.TagFile(open('data', 'rt'))]"
Segmentation fault (core dumped)
Bug#1055575: gst-python1.0 ftbfs with Python 3.12
Hello, I also tried poking at this issue today and ran into the same problem. Replacing imp with what I believe to be the equivalent importlib commands results in a bunch of errors during testing (many "TypeError: SomeFunction() takes no arguments" errors). However, the problematic imports appear only in two files, neither of which are installed in the final .debs, so the FTBFS is only a problem in running the test suite. I was able to build a working package by simply disabling the tests in debian/rules: override_dh_auto_test: @echo "Tests disabled in debian/rules, see https://bugs.debian.org/1055575; While disabling tests isn't the best option in the world, it does prevent autoremoval until the upstream issue is resolved. Thanks for all your work! - Dean
Bug#1058903: minia: add build support for loongarch64
Source: minia
Version: 3.2.6-3
Severity: wishlist
Tags: patch
User: debian-loonga...@lists.debian.org
Usertags: loong64
Dear maintainers,
The minia source package lacks LoongArch architecture support.
Please consider the patch I have attached.
The minia source package was compiled successfully on my local loong64
rootfs environment.
If you have any questions, you can contact me at any time.
thanks,
Dandan Zhang
diff -Nru minia-3.2.6/debian/control minia-3.2.6/debian/control
--- minia-3.2.6/debian/control 2023-02-17 22:57:36.0 +
+++ minia-3.2.6/debian/control 2023-02-17 22:57:56.0 +
@@ -19,7 +19,7 @@
Rules-Requires-Root: no
Package: minia
-Architecture: any-amd64 arm64 mips64el ppc64el ia64 ppc64 riscv64 sparc64 alpha
+Architecture: any-amd64 arm64 loong64 mips64el ppc64el ia64 ppc64 riscv64
sparc64 alpha
Depends: ${misc:Depends},
${shlibs:Depends},
zlib1g,
Bug#956953: cron: add cron jobs to systemd scope cgroups
On Sun, 2023-12-17 at 16:28 +0100, Georges Khaznadar wrote: > So maybe prepending "systemd-run --scope --user" would do the trick, > wouldn't it? I think that would work yes. Please set an appropriate name too though. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Bug#956953: cron: add cron jobs to systemd scope cgroups
Hello Paul, Paul Wise a écrit : > > I presume that one way to implement your wished feature might be to > > modify beforehand the string e->cmd, in order to insert something as > > "systemd-run --scope" at the begin... > > I note that this requires user authentication even when run as a user > so presumably it would not work in cron itself. So maybe prepending "systemd-run --scope --user" would do the trick, wouldn't it? Best regards, Georges. signature.asc Description: PGP signature
Bug#1058902: rakudo: add build support for loongarch64
Source: rakudo Version: 2022.12-1 Severity: wishlist Tags: patch User: debian-loonga...@lists.debian.org Usertags: loong64 Dear maintainers, The rakudo source package lacks LoongArch architecture support. We need to add build support for loongarch64 in d/control, for example, Package: rakudo -Architecture: amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x x32 Package: rakudo +Architecture: amd64 arm64 armel armhf i386 kfreebsd-amd64 kfreebsd-i386 loong64 mips mips64el mipsel powerpc ppc64 ppc64el riscv64 s390x x32 If you have any questions, you can contact me at any time. thanks, Dandan Zhang
Bug#1054012: at: diff for NMU version 3.2.5-2.1
Control: tags 1054012 + patch Control: tags 1054012 + pending Hi Jose, thanks for your answer. I've prepared an NMU for at (versioned as 3.2.5-2.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. I'll also push to a branch (nmu-3.2.5-2.1) on salsa. Best, Chris diff -Nru at-3.2.5/debian/changelog at-3.2.5/debian/changelog --- at-3.2.5/debian/changelog 2023-06-25 23:46:36.0 +0200 +++ at-3.2.5/debian/changelog 2023-12-18 03:33:04.0 +0100 @@ -1,3 +1,12 @@ +at (3.2.5-2.1) unstable; urgency=medium + + * Non-maintainer upload. + + [ Helmut Grohne ] + * Defer placement of systemd units to systemd.pc. (Closes: #1054012) + + -- Chris Hofstaedtler Mon, 18 Dec 2023 03:33:04 +0100 + at (3.2.5-2) unstable; urgency=medium * Fix a race condition on DEP8 test? diff -Nru at-3.2.5/debian/control at-3.2.5/debian/control --- at-3.2.5/debian/control 2023-06-25 23:46:36.0 +0200 +++ at-3.2.5/debian/control 2023-12-18 03:33:04.0 +0100 @@ -12,6 +12,8 @@ libpam0g-dev, libselinux1-dev [linux-any], perl:any (>= 5.10.1), + pkgconf, + systemd-dev, Vcs-Browser: https://salsa.debian.org/debian/at Vcs-Git: https://salsa.debian.org/debian/at.git -b debian Homepage: http://blog.calhariz.com diff -Nru at-3.2.5/debian/rules at-3.2.5/debian/rules --- at-3.2.5/debian/rules 2023-06-25 23:46:36.0 +0200 +++ at-3.2.5/debian/rules 2023-12-18 03:33:04.0 +0100 @@ -9,7 +9,7 @@ confflags = --with-loadavg_mx=1.5 \ --with-jobdir=/var/spool/cron/atjobs \ --with-atspool=/var/spool/cron/atspool \ ---with-systemdsystemunitdir=/lib/systemd/system \ +--with-systemdsystemunitdir=$(shell pkgconf --variable=systemdsystemunitdir systemd) \ $(WITH_SELINUX) \ SENDMAIL=/usr/sbin/sendmail
Bug#1058657: patch
Control: tags -1 +patch https://salsa.debian.org/apt-team/python-apt/-/merge_requests/90
Bug#1058901: python-ipmi: please remove extraneous dependency on python3-future
Source: python-ipmi Severity: important python3-future is not compatible with Python3.12 and will soon be removed from the archive. luckily it's merely a (quite common) mistake from upstream. Here's the simple fix. --- a/setup.py +++ b/setup.py @@ -70,6 +70,5 @@ setup(name=name, test_suite='tests', install_requires=[ 'markdown', - 'future', ], ) It has also already been communicated upstream: https://github.com/kontron/python-ipmi/pull/163 Greetins -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1058900: rocketcea: the Sphix documention should be rebuilt
Source: rocketcea Severity: minor The Sphinx documentation should be regenerated and not taken as-is from the upstream tarball.
Bug#1058899: openssh-client: ssh-copy-id should warn on command= when copying pub key
Package: openssh-client Version: 1:9.5p1-2 Severity: normal Tags: upstream https://blog.thc.org/infecting-ssh-public-keys-with-backdoors The above web page describes how to exploit systems via the athorized_keys file and purports to describe how to hide backdoors in ~/.ssh/id_*.pub, the only way that second claim could be valid is by using ssh-copy-if to blindly copy a .pub file that has the command= string in question installed. To address this sort of thing (and also to prevent needless confusion from less hostile uses of command=) I think ssh-copy-id should either warn about the use of command= in the source file or copy a sanitised version unless explicitely told to copy that with an optional parameter. -- System Information: Debian Release: trixie/sid Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: unable to detect Versions of packages openssh-client depends on: ii adduser 3.137 ii libc6 2.37-13 ii libedit2 3.1-20230828-1 ii libfido2-11.14.0-1 ii libgssapi-krb5-2 1.20.1-5 ii libselinux1 3.5-1+b1 ii libssl3 3.1.4-2 ii passwd1:4.13+dfsg1-3 ii zlib1g1:1.3.dfsg-3 Versions of packages openssh-client recommends: ii xauth 1:1.1.2-1 Versions of packages openssh-client suggests: pn keychain ii ksshaskpass [ssh-askpass] 4:5.27.9-1 pn libpam-ssh pn monkeysphere -- debconf-show failed
Bug#1058880: systemd-binfmt.service: unit fails to start when /proc/sys/fs/binfmt_misc is not mounted
Am 17.12.23 um 13:44 schrieb Aurelien Jarno: commit f74a7cb45c2458f90de6d37c70fa3afc1a3be279 Author: Yu Watanabe Date: Sat Dec 10 11:46:45 2022 +0900 unit: check more specific path to be written by systemd-binfmt Follow-up for 41807efb1594ae8e71e0255e154ea7d17be2251a. Replaces #25690. Would it be possible to backport this commit to bookworm? Seems reasonable. @Luca: can you include that in your next 252-stable batch? Should we file this as an issue in systemd/systemd-stable as a reminder? Regards, Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1004589: GNUnet daemon doesn't start successfully
Package: gnunet Version: 0.20.0-3 Followup-For: Bug #1004589 X-Debbugs-Cc: deb...@kevinsteen.net Version 0.20.0-3 still fails to start because of the incorrect log path in /etc/gnunet.conf By changing it to: OPTIONS = -l /var/log/gnunet/gnunet.log I can get the gnunet service to start correctly. -Kevin -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.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 gnunet depends on: ii debconf [debconf-2.0] 1.5.82 ii libc6 2.36-9+deb12u3 ii libcurl3-gnutls7.88.1-10+deb12u4 ii libextractor3 1:1.11-7 ii libgcrypt201.10.1-3 ii libgnunet0.20 0.20.0-3 ii libgnutls-dane03.8.2-1 ii libgnutls303.8.2-1 ii libidn2-0 2.3.3-1+b1 ii libjansson42.14-2 ii libmicrohttpd120.9.75-6 ii libogg01.3.5-3 ii libopus0 1.3.1-3 ii libpng16-161.6.39-2 ii libpq5 15.5-0+deb12u1 ii libpulse0 16.1+dfsg1-2+b1 ii libsodium231.0.18-1 ii libsqlite3-0 3.40.1-2 ii libunistring5 1.1-2 ii libzbar0 0.23.92-7 ii lsb-base 11.6 ii netbase6.4 ii passwd 1:4.13+dfsg1-1+b1 ii sysvinit-utils [lsb-base] 3.06-4 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages gnunet recommends: pn libnss3-tools ii openssl3.0.11-1~deb12u2 Versions of packages gnunet suggests: pn miniupnpc pn texlive -- Configuration Files: /etc/gnunet.conf [Errno 2] No such file or directory: '/etc/gnunet.conf' -- debconf information: gnunet/title: gnunet/group: gnunet gnunet/user: gnunet gnunet/autostart: true
Bug#985184: reminiscence not anymore licensed
control: severity -1 serious I think until the licensing problem is not resolved, this old version of the game should not be included in a release.
Bug#1058034: webkit2gtk: 2.43 fails to build on riscv64
On Thu, Dec 14, 2023 at 05:25:45PM +0100, Alberto Garcia wrote: > Maybe we can try treating the CPU as unknown, as we do with x32: Jeremy, can you give this one a try? Berto Index: webkitgtk/Source/WTF/wtf/PlatformCPU.h === --- webkitgtk.orig/Source/WTF/wtf/PlatformCPU.h +++ webkitgtk/Source/WTF/wtf/PlatformCPU.h @@ -292,14 +292,6 @@ #endif /* ARM */ -/* CPU(RISCV64) - RISC-V 64-bit */ -#ifdefined(__riscv) \ -&& defined(__riscv_xlen) \ -&& (__riscv_xlen == 64) -#define WTF_CPU_RISCV64 1 -#define WTF_CPU_KNOWN 1 -#endif - #if !CPU(KNOWN) #define WTF_CPU_UNKNOWN 1 #endif Index: webkitgtk/Source/cmake/WebKitCommon.cmake === --- webkitgtk.orig/Source/cmake/WebKitCommon.cmake +++ webkitgtk/Source/cmake/WebKitCommon.cmake @@ -122,8 +122,6 @@ if (NOT HAS_RUN_WEBKIT_COMMON) set(WTF_CPU_PPC64 1) elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "ppc64le") set(WTF_CPU_PPC64LE 1) -elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^riscv64") -set(WTF_CPU_RISCV64 1) elseif (LOWERCASE_CMAKE_SYSTEM_PROCESSOR MATCHES "^loongarch64") set(WTF_CPU_LOONGARCH64 1) else ()
Bug#1058898: [INTL:ro] Romanian debconf templates translation of «uif»
Package: uif Version: 1.99.0-4.1 Severity: wishlist Tags: l10n, patch Dear Maintainer, Please find attached the Romanian translation of the «uif_debconf» file. A draft has been posted to the debian-l10n-romanian mailing list allowing for review. Please add it to your next package revision. - Thanks, Remus-Gabriel# Mesajele în limba românÄ pentru pachetul uif (debconf). # Romanian translation of uif (debconf). # Copyright © 2023 THE PACKAGE'S COPYRIGHT HOLDER # This file is distributed under the same license as the uif package. # # Remus-Gabriel Chelu , 2023 # msgid "" msgstr "" "Project-Id-Version: uif 1.99.0-4.1\n" "Report-Msgid-Bugs-To: u...@packages.debian.org\n" "POT-Creation-Date: 2022-05-06 19:27+0200\n" "PO-Revision-Date: 2023-12-10 18:21+0100\n" "Last-Translator: Remus-Gabriel Chelu \n" "Language-Team: \n" "Language: ro\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=3; plural=(n==1 ? 0 : n==0 || (n!=1 && n%100>=1 && " "n%100<=19) ? 1 : 2);\n" "X-Generator: Poedit 3.2.2\n" #. Type: select #. Choices #: ../templates:1001 msgid "don't touch" msgstr "nu se modificÄ" #. Type: select #. Choices #: ../templates:1001 msgid "workstation" msgstr "staÈie de lucru" #. Type: select #. Choices #: ../templates:1001 msgid "debian-edu-router" msgstr "debian-edu-router" #. Type: select #. Description #: ../templates:1002 msgid "Firewall configuration method" msgstr "Metoda de configurare a paravanului de protecÈie" #. Type: select #. Description #: ../templates:1002 msgid "" "Please choose whether the firewall should be configured now with a simple " "\"workstation\" setup, given a specialized Debian Edu Router configuration, " "or left unconfigured so that you can manually edit /etc/uif/uif.conf." msgstr "" "VÄ rugÄm sÄ alegeÈi dacÄ paravanul de protecÈie trebuie configurat acum cu o " "configuraÈie simplÄ âstaÈie de lucruâ, dacÄ trebuie sÄ primeascÄ o " "configuraÈie specializatÄ pentru âRouter-ul Debian Eduâ sau dacÄ trebuie " "lÄsat neconfigurat pentru a putea edita manual â/etc/uif/uif.confâ." #. Type: string #. Description #: ../templates:2001 msgid "Trusted DNS hostnames:" msgstr "Nume de gazde DNS de încredere:" #. Type: string #. Description #: ../templates:2001 msgid "" "In workstation mode, you can specify some DNS hostnames to be globally " "trusted. All incoming traffic coming from these will be allowed. Multiple " "entries must be separated with spaces." msgstr "" "Ãn modul staÈie de lucru, puteÈi specifica anumite nume de gazdÄ DNS care sÄ " "fie de încredere la nivel global. Tot traficul de intrare provenind de la " "acestea va fi permis. IntrÄrile multiple trebuie sÄ fie separate prin spaÈii." #. Type: string #. Description #: ../templates:2001 msgid "" "Hostnames provided here must be resolvable to both IPv4 and IPv6 addresses." msgstr "" "Numele de gazdÄ furnizate aici trebuie sÄ poatÄ fi rezolvate atât pentru " "adrese IPv4, cât Èi pentru adrese IPv6." #. Type: string #. Description #: ../templates:2001 msgid "Example: trusted-host-v4-and-v6.mydomain.com" msgstr "Exemplu: gazdÄ-de-încredere-v4-Èi-v6.domeniul-meu.com" #. Type: string #. Description #: ../templates:3001 msgid "Trusted IPv4 hosts and/or networks:" msgstr "Gazde Èi/sau reÈele IPv4 de încredere:" #. Type: string #. Description #: ../templates:3001 msgid "" "In workstation mode, you can specify some IPv4 hosts or networks to be " "globally trusted. All incoming traffic coming from these will be allowed. " "Multiple entries must be separated with spaces." msgstr "" "Ãn modul staÈie de lucru, puteÈi specifica anumite gazde sau reÈele IPv4 " "care sÄ fie de încredere la nivel global. Tot traficul de intrare provenind " "de la acestea va fi permis. IntrÄrile multiple trebuie sÄ fie separate prin " "spaÈii." #. Type: string #. Description #: ../templates:3001 msgid "" "If you want to trust DNS hostnames that only resolve to an IPv4 address, " "please enter them here." msgstr "" "DacÄ doriÈi sÄ aveÈi încredere în numele de gazde DNS care se rezolvÄ numai " "la o adresÄ IPv4, introduceÈi-le aici." #. Type: string #. Description #: ../templates:3001 msgid "Example: 10.1.0.0/16 trusted-host-v4-only.mydomain.com 192.168.1.55" msgstr "" "Exemplu: 10.1.0.0/16 gazdÄ-de-încredere-doar-v4.domeniul-meu.com 192.168.1.55" #. Type: string #. Description #: ../templates:4001 msgid "Trusted IPv6 hosts and/or networks:" msgstr "Gazde Èi/sau reÈele IPv6 de încredere:" #. Type: string #. Description #: ../templates:4001 msgid "" "In workstation mode, you can specify some IPv6 hosts or networks to be " "globally trusted. All incoming traffic coming from these will be allowed. " "Multiple entries must be separated with spaces." msgstr "" "Ãn modul staÈie de lucru, puteÈi specifica anumite gazde sau reÈele IPv6 " "care sÄ fie de încredere la nivel global. Tot traficul
Bug#1058897: ITP: pointpats -- statistical analysis of planar point patterns
Package: wnpp Severity: wishlist Owner: Josenilson Ferreira da Silva X-Debbugs-Cc: debian-de...@lists.debian.org, nilsonfsi...@hotmail.com * Package name: pointpats Version : 2.4.0 Upstream Contact: Name pysal developers * URL : ttps://github.com/pysal/pointpats * License : BSD-3-clause Programming Lang: Python Description : statistical analysis of planar point patterns The main objective of this module is to provide methods and functions for analyzing spatial patterns in point data. This includes the detection and characterization of different types of patterns, such as clusters, scatters or random patterns. . The project is integrated with the PySAL library, which is a broader library for spatial analysis in Python. This means that PointPatterns can be used in conjunction with other tools available in the PySAL ecosystem. . One of the main features of the module is to provide methods to calculate descriptive statistics, detect spatial clusters, perform orbit analysis and even perform statistical tests to evaluate the significance of observed patterns. Note: dependency required to build 'spopt' from version 0.6.0
Bug#1058643: dnsdist: re-enable 32-bit support via _TIME_BITS=64
On Thu, Dec 14, 2023 at 12:06:59AM +, Matija Nalis wrote: > So, all that is needed for dnsdist on 32-bit platform (like my Rasperry Pi > armhf, where I tested that solution, and it compiles and runs just fine, > both versions 1.7.3-2 and 1.8.2-3) is: > > export DEB_CXXFLAGS_APPEND="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" > (and skipping dependency on architecture-is-64-bit, of course). My understanding is, doing this on an individual package level, is not safe in any way. It might work when the stars align correctly, but there are zero guarantees for anything. I think we'll wait at the very least until Debian finishes the t64 transition, and then we'll see what to do about 32bit archs. In the meantime, dnsdist works on arm64, also on Raspberrys! Chris
Bug#1058806: HP EliteBook 860 G9 (4C148AV)
On 17/12/2023 à 23:03, Paul van der Vlis wrote: Op 17-12-2023 om 22:36 schreef Pascal Hambourg: It may be an initialization issue: this error has been observed when booting after Windows hibernation or Fast Startup state. There is Windows on the NVMe disk of the laptop. Fastboot and secureboot where off. UEFI/BIOS "fast boot" is not the same as Windows "fast startup". I have also tested if I could boot the installer with fastboot on or secureboot on. But that dit not work. Debian should work with secure boot on.
Bug#1057359: qmake: use qmake6 when QT_SELECT=qt6
Le sam. 16 déc. 2023 à 15:46, Lisandro Damián Nicanor Pérez Meyer a écrit : > The cleanest way is to use CMake, as it can handle this directly in > code. And I guess qmake will probably not be a thing for Qt 7. > Thanks. This just works(TM) for two packages.
Bug#1056888: scipy: ftbfs with cython 3.0.x
Source: scipy Followup-For: Bug #1056888 Using cython3-legacy sounds like a reasonable workaround. I presume the latest version of scipy has been updated to use cython 3, but we won't know until https://salsa.debian.org/salsa/support/-/issues/360 is dealt with. cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042459
Bug#1038137: accountsservice: unit requires /usr/share/accountsservice/interfaces but it is not installed
On Thu, 15 Jun 2023 21:44:27 +0100 Luca Boccassi wrote: accountsservice's unit has: ReadOnlyPaths=\ /usr/share/accountsservice/interfaces/ \ /usr/share/dbus-1/interfaces/ \ /var/log/wtmp \ /run/systemd/seats/ But at least /usr/share/accountsservice/interfaces/ is not installed by the package itself. As far as I can see on my machine, the malcontent package installs files under it. This means that on systemd's autopkgtest it fails to start. The solution is very simple, just prefix each path listed there with "-" to make it optional - if the directory exists on the host then it will be made read-only, otherwise it will be ignored. The other valid alternative is to ship the (empty) directory in the accountsservice package. OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058806: HP EliteBook 860 G9 (4C148AV)
Hello Pascal, and others, Op 17-12-2023 om 22:36 schreef Pascal Hambourg: On 17/12/2023 at 14:31, Paul van der Vlis wrote: Could it be the issue that was fixed in kernel 6.1.67-1 (available in proposed updates)? The 12.4 installer kernel has the wireless bug but it is uncertain whether it affects the installer or not. What was wrong with the integrated Intel wireless controller ? Do you still have the installer logs (/var/log/installer/syslog) ? I will add the syslog. The error was "iwlwifi: probe of :00:14.3 failed with error -110" (Note for those who are reading this thread through the debian-boot mailing list: the mail with attachment was too big for the mailing list) Ah, maybe the next time better compressed... It was 1.1MB. So it is not related with the recent wireless bug in 6.1.66. It may be an initialization issue: this error has been observed when booting after Windows hibernation or Fast Startup state. There is Windows on the NVMe disk of the laptop. Fastboot and secureboot where off. My goal was to test if Debian would work fine without removing Windows, and it does. I have also tested if I could boot the installer with fastboot on or secureboot on. But that dit not work. See https://bugzilla.kernel.org/show_bug.cgi?id=209641 https://bugzilla.kernel.org/show_bug.cgi?id=201319#c55 for possible workarounds if it happens again. I see I did not use my Debian 12.4 stick, but a Debian 12.1 stick. When you tried the installer again, which version was it ? Again 12.1, because I wanted to see if that the problem was. But it worked, even with 12.1. It's a bit strange install, I did install on an external USB SSD. I do not think it is relevant. I think that too. So Linux hibernation worked fine using an USB disk. With regards, Paul van der Vlis -- Paul van der Vlis Linux systeembeheer Groningen https://vandervlis.nl/
Bug#1057602: scm: FTBFS: error: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
Control: tags -1 + patch
On 2023-12-05 23:11 +0100, Santiago Vila wrote:
> Package: src:scm
> Version: 5f3-4
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
> [...]
>
> The above is just how the build ends and not necessarily the most relevant
> part.
Indeed, the actual error causing the FTBFS was missing.
> If required, the full build log is available here:
>
> https://people.debian.org/~sanvila/build-logs/202312/
The only fatal errors are these two:
,
| crs.c: In function ‘owidth’:
| crs.c:253:43: error: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct
_win_st’}
| 253 | if (WINP(arg)) return MAKINUM(WIN(arg)->_maxx+1);
| | ^~
| scmfig.h:556:24: note: in definition of macro ‘MAKINUM’
| 556 | # define MAKINUM(x) (((x)<<2)+2L)
| |^
| crs.c: In function ‘oheight’:
| crs.c:264:43: error: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct
_win_st’}
| 264 | if (WINP(arg)) return MAKINUM(WIN(arg)->_maxy+1);
| | ^~
`
The attached patch fixes them and lets the package build, but I have
not tested if it actually works.
Cheers,
Sven
Description: Fix build with opaque ncurses
Since ncurses patchlevel 20231021 the WINDOW structure is opaque, its
members cannot be addressed directly. Use the functions ncurses
provides for this purpose instead.
Author: Sven Joachim
Bug-Debian: https://bugs.debian.org/1057602
--- scm-5f3.orig/crs.c
+++ scm-5f3/crs.c
@@ -250,7 +250,7 @@ SCM owidth(arg)
if (UNBNDP(arg)) arg = cur_outp;
ASRTER(NIMP(arg) && OPOUTPORTP(arg), arg, ARG1, s_owidth);
if (NIMP(*loc_stdscr)) {
-if (WINP(arg)) return MAKINUM(WIN(arg)->_maxx+1);
+if (WINP(arg)) return MAKINUM(getmaxx(WIN(arg)));
else return MAKINUM(COLS);
}
return MAKINUM(80);
@@ -261,7 +261,7 @@ SCM oheight(arg)
if (UNBNDP(arg)) arg = cur_outp;
ASRTER(NIMP(arg) && OPOUTPORTP(arg), arg, ARG1, s_owidth);
if (NIMP(*loc_stdscr))
-if (WINP(arg)) return MAKINUM(WIN(arg)->_maxy+1);
+if (WINP(arg)) return MAKINUM(getmaxy(WIN(arg)));
else return MAKINUM(LINES);
return MAKINUM(24);
}
Bug#1058755: logcheck: Email not report log lines
On Sun, 17 Dec 2023 at 19:03, Stefano Callegari wrote: > Il Fri, Dec 15, 2023 at 11:31:18PM +, Richard Lewis scrisse: > > On Fri, 15 Dec 2023 at 16:06, Stefano Callegari > > wrote: > > > > > from few days the email from cron are empty, there is only the header.txt. > > > > > /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -l > > > /var/log/syslog" logcheck > > > > > > the email has the log lines. Without the -l option, still empty. > > > > Seems like it isnt checking the syslog -- what is in the files in > > /etc/logcheck/logcheck.logfiles.d/ and logcheck.conf ? > > ~ <-bash> # ls /etc/logcheck/logcheck.logfiles.d/ > journal.logfiles syslog.logfiles [snip] -- everything you posted looked fine and standard to me: it should be checking both syslog and the journal as expected The only other thing you didn't include is a check of the permissions: there was a change in bookworm - i doubt that this is the issue, but for completeness: the directory /etc/logcheck should be owned by logcheck:logcheck and permissions: drwxr-x--- the contents should all be root:root and usual permissions, ie -rw-r--r-- (with subdirectories drwxr-xr-x) (as long permissions allow logcheck to read everything, it should all be fine) > > I suggest also using the -d option -- should say what it is doing in > > great detail (pipe to file or through less) > > I've tried! Many and many of lines, never ending, it seems a loop. I had to > do a ^C. Interesting - that definitely shouldnt happen, and '-d' shouldn't be doing anything 'extra' to cause that (is it definitely a loop or just looking like one because if your log contains lines that dont match any rules (will be reported in the email), logcheck has to check every single rules file, and -d will tell you the results before and after each rule file it uses: so it should look like it's printing the same output many times. to minimise the output, you can run once without -d, then do a 'logger foo' to ensure there's at lease one new line in the log and then re-run with -d) The only potential for a loop that i can immediately think of would be if you had some kind of symlink loop in the rules directory - do you have any symlinks in the ignore.d.server or similar dirs (check with ls -laR) i didnt think that could happen, i've no idea if logcheck would cope with that or not Can you provide the start of the -d output /enough to understand what the loop is? Otherwise, the start of the output should say what files it was checking, unfortunately, if there's an issue sending the issue, it likely wont be obvious until the very end. the only other thing i can think of is a disk space issue (i could imaging bad things happening if /tmp was full, or wherever the mta stores the email - /var or similar) (you could email it to me if you want to avoid it appearing in the public bts - up to you: i wouldnt expect there to be anything too sensitive in the logs, but i suppose we cant rule that out).
Bug#1058806: HP EliteBook 860 G9 (4C148AV)
On 17/12/2023 at 14:31, Paul van der Vlis wrote: Could it be the issue that was fixed in kernel 6.1.67-1 (available in proposed updates)? The 12.4 installer kernel has the wireless bug but it is uncertain whether it affects the installer or not. What was wrong with the integrated Intel wireless controller ? Do you still have the installer logs (/var/log/installer/syslog) ? I will add the syslog. The error was "iwlwifi: probe of :00:14.3 failed with error -110" (Note for those who are reading this thread through the debian-boot mailing list: the mail with attachment was too big for the mailing list) So it is not related with the recent wireless bug in 6.1.66. It may be an initialization issue: this error has been observed when booting after Windows hibernation or Fast Startup state. See https://bugzilla.kernel.org/show_bug.cgi?id=209641 https://bugzilla.kernel.org/show_bug.cgi?id=201319#c55 for possible workarounds if it happens again. I see I did not use my Debian 12.4 stick, but a Debian 12.1 stick. When you tried the installer again, which version was it ? It's a bit strange install, I did install on an external USB SSD. I do not think it is relevant.
Bug#1058896: numptyphysics: de-vendor box2d
Package: numptyphysics Version: 0.3.10-0.2 Severity: normal X-Debbugs-Cc: debian-devel-ga...@lists.debian.org This game embbed a possibily outdated/buggy version of Box2D. Box2D is already packaged and used by LibreOffice and CaveExpress. Please try to build & run the game with this shared library. Greetings, $ apt rdepends libbox2d2 Reverse Depends: Dépend: caveexpress (>= 2.4.1) Dépend: libbox2d-dev (= 2.4.1-3) Dépend: libreoffice-impress (>= 2.4.1) -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (501, 'testing'), (450, 'unstable'), (400, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1058894: etckeeper: Replace B-D: bzr with brz
I am uploading a NMU to DELAYED/10 in order to fix this. Please find the debdiff attached.diff -Nru etckeeper-1.18.20/debian/changelog etckeeper-1.18.20/debian/changelog --- etckeeper-1.18.20/debian/changelog 2023-01-26 20:53:08.0 +0100 +++ etckeeper-1.18.20/debian/changelog 2023-12-17 22:15:13.0 +0100 @@ -1,3 +1,10 @@ +etckeeper (1.18.20-1.1) unstable; urgency=medium + + * Non-maintainer upload + * Replace transitional Build-Depends: bzr with brz (Closes: #1058894) + + -- Bastian Germann Sun, 17 Dec 2023 22:15:13 +0100 + etckeeper (1.18.20-1) unstable; urgency=medium [ Debian Janitor ] diff -Nru etckeeper-1.18.20/debian/control etckeeper-1.18.20/debian/control --- etckeeper-1.18.20/debian/control2023-01-26 20:53:08.0 +0100 +++ etckeeper-1.18.20/debian/control2023-12-17 22:15:13.0 +0100 @@ -3,7 +3,7 @@ Priority: optional Build-Depends: debhelper-compat (= 13), bats, - bzr, + brz, dh-python, fakeroot, git,
Bug#724014: pavucontrol: Output settings are forgotten and must be set again: Bookworm
I am seeing similar to what Gerard ROBIN saw. I have two machines, both using HDMI monitors. I find that the quickest way to restore sound is Configuration -> Digital Stereo (HDMI) Output -> Digital Stereo (HDMI 3) Output (unplugged) (unavailable) [or similar] -> Digital Stereo (HDMI) Output. Host hawk was running bullseye and earlier without seeing this problem. tiassa is a new computer and a fresh installation. M. Robin may well be correct that the real problem lies lower in the stack, but this is where I am seeing it. I note that both machines are running Intel hardware and the snd_hda_intel driver. Another machine, tsalmoth, a laptop, with Intel hardware but with no HDMI monitors, does not exhibit this behavior. root@hawk:~# lspci -s 0:1b 00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller root@hawk:~# lspci -vs 0:1b 00:1b.0 Audio device: Intel Corporation 9 Series Chipset Family HD Audio Controller Subsystem: ASUSTeK Computer Inc. 9 Series Chipset Family HD Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 35 Memory at f7e1 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel root@hawk:~# uname -a Linux hawk 6.1.0-16-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) x86_64 GNU/Linux root@hawk:~# oot@tiassa:~# lspci -vs 0:1f.3 00:1f.3 Audio device: Intel Corporation Device 54c8 DeviceName: Onboard - Sound Subsystem: Intel Corporation Device 7270 Flags: bus master, fast devsel, latency 32, IRQ 131, IOMMU group 8 Memory at 600111 (64-bit, non-prefetchable) [size=16K] Memory at 600100 (64-bit, non-prefetchable) [size=1M] Capabilities: [50] Power Management version 3 Capabilities: [80] Vendor Specific Information: Len=14 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel, snd_sof_pci_intel_tgl root@tiassa:~# uname -a Linux tiassa 6.1.0-15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1 (2023-12-09) x86_64 GNU/Linux root@tiassa:~# root@tsalmoth:~# lspci -vs 0:1b 00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04) Subsystem: Lenovo 7 Series/C216 Chipset Family High Definition Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 42, IOMMU group 6 Memory at e0418000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [70] Express Root Complex Integrated Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [130] Root Complex Link Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel root@tsalmoth:~# uname -a Linux tsalmoth 6.1.0-16-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) x86_64 GNU/Linux root@tsalmoth:~# -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Bug#1058895: python 3.12 slices are hashable, affects one area of Row for 1.4 only
Package: python3-sqlalchemy Version: 1.4.46+ds1-1 Severity: serious Hi, SQLAlchemy 1.4.47+ds1-1 in unstable is affected by this upstream bug: https://github.com/sqlalchemy/sqlalchemy/issues/9819 Latest upstream release for 1.4.x (ie: 1.4.50). I tried building it locally, and rebuild affected packages (for OpenStack), and this fixes these bugs (or at least, it's part of solving these bugs as there are also other issues unrelated): https://bugs.debian.org/1058183 (barbican) https://bugs.debian.org/1058123 (neutron-vpnaas) (FTBFS reported fixed by eventlet, but package affected by this bug) https://bugs.debian.org/1058219 (senlin) https://bugs.debian.org/1058233 (sahara) https://bugs.debian.org/1058531 (heat) (some other failures, but also affected) There's probably more (I didn't attempt to rebuild all affected packages yet), but these are 5 examples of packages that FTBFS because of this problem. It'd be nice if we could have the patch in Unstable with this series 1.4.x before uploading 2.x, so that I have a chance to fix all Python 3.12 bugs and not mix SQLA 2.x and Py 3.12 problems. Cheers, Thomas Goirand (zigo)
Bug#1058133: python-numpy-groupies: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
Control: tags -1 pending This is fixed in the most recent upstream release, which unfortunately FTBFS with python3.12 due to test failures. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#1058894: etckeeper: Replace B-D: bzr with brz
Source: etckeeper Version: 1.18.20-1 Please replace the Build-Depends: bzr with Build-Depends: brz. The bzr support is not built according to the build log but the Build-Depends keeps that package in the key packages set.
Bug#1058836: bug 1058836
Disregard, I had a minor disaster and ended up re-installing Debian and the brightness control came back. Best regards, --glenn
Bug#1025300: 1025300 is grave
severity 1025300 grave thanks Upon further thought, this is an RC bug as it makes the program crash and thus unusable on a large portition of the times when it's used. The patch in the upstream issue still works, but upstream seems inactive so I'm not sure if we want to keep the package in the archive even with the patch. Taavi OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1055338: Bug #1055338 override: dolfin:oldlibs/optional
For more context, note that both src:dolfin and src:fenics-dolfinx are still current (and distinct) as source packages, in the sense that they generate a different set of binary packages. src:dolfin generates python3-dolfin, while src:fenics-dolfinx generates python3-dolfinx (the next generation version of the library). It is true that python3-dolfin is considered legacy (deprecated), nevertheless the old source is still maintained for the purpose of supporting users with existing projects that have been using the old version of the library.
Bug#910664: Acknowledgement (ghc: ghc package can no longer be cross-compiled)
Hi Ilias, On Sat, Dec 16, 2023 at 04:45:00PM +0200, Ilias Tsitsimpis wrote: > Sorry for the late reply. Comments inline. Thank you for taking the time to write such a detailed response. > Let me try to explain how GHC's build system works with the new Hadrian > tool. Then let's see how we can move forward and make it so that the > build fails at the right stage. > > 1. Run boot and configure. Here is where we decide if we want to >build GHC for the same architecture or do cross compilation. I fear this is misleadingly imprecise. If I understand what you write later correctly, we always build GHC for the same architecture (i.e. we ask configure for build=host), but we may opt for a cross compiler (i.e. target!=host). When the ghc Debian package is asked to cross compile, what we ask configure instead is natively building a cross compiler. Do you confirm? > 2. Run hadrian. The build artifacts will be under '_build/stageX'. With >the Hadrian build system, the naming convention for these directories >have changed. '_build/stage1' contains the binaries that were built >using the stage1 compiler. This is still quite confusing to me. I suppose stage0 is /usr/bin/ghc. Do you confirm? Then there should be a _build/stage0 containing the stage1 compiler. That stage1 compiler probably is a simple native build of the ghc sources at hand, which means that its binary may have a different ABI from what the sources expect. That stage1 will be unable to use packages, but it can be used to build ghc again. Is that also correct? Then that stage1 is used to build a stage2 where the ABI of the binary matches the behaviour and this can be used with packages. >If we are building a compiler for the same architecture, >'_build/stage1/' will contain the stage2 compiler for this >architecture (i.e., the binaries that we ship in our Debian package). This would be consistent with the possible understanding given above. >If we are cross compiling, '_build/stage1/' will contain a *stage1 >cross-compiler*. As discussed in this issue [1], upstream is working >towards making this a *stage2 cross-compiler*. Is is still a >cross-compiler though, and not a cross-compiled GHC as it used to be. Do I understand correctly that (currently) stage1 is a simple native build of the current ghc sources where the binary uses the ABI that /usr/bin/ghc generated and doesn't necessarily match the sources? Do I also understand that stage2 (stored in _build/stage1) the is a cross compiler generating code for $DEB_HOST_ARCH and runnable on $DEB_BUILD_ARCH using the ABI given by the current ghc sources? >The final output of this step is a binary distribution of GHC, i.e., >a tarball that you can distribute to anyone that wants to install GHC. > > 3. We run configure and 'make install' to convert the binary >distribution to a Debian binary package. This is why we run configure >twice. At no point do we (currently) actually cross build using that stage2. Do you also confirm? > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/19174 > > I hope the above explains why we cannot cross compile GHC (the build > system doesn't give us this option). I fear it does not. It explains why we currently do not cross compile GHC, but I still fail to understand why we cannot. (Or maybe this is splitting hairs and we mean the same thing with different words.) > Given the above, I believe your patch needs a few adjustments. Probably. > > diff --minimal -Nru ghc-9.4.7/debian/rules ghc-9.4.7/debian/rules > > --- ghc-9.4.7/debian/rules 2023-10-18 21:49:38.0 +0200 > > +++ ghc-9.4.7/debian/rules 2023-12-10 20:03:52.0 +0100 > > @@ -47,8 +47,10 @@ > >EXTRA_HADRIAN_FLAGS += --flavour=quickest > ># Do not build docs *at all* (avoid dependency on Sphinx) > >EXTRA_HADRIAN_FLAGS += --docs=none > > + STAGE1_TOOL = _build/stage1/bin/$(DEB_HOST_GNU_TYPE)- > >BUILD_CROSS = YES > > else > > + STAGE1_TOOL = _build/stage1/bin/ > >BUILD_CROSS = NO > > endif > > As explained, this is not the stage1 tool, this is the tool built by the > stage1 compiler, and this directory contains vastly different tools > depending on whether we cross-compile or not. As far as I can see, the name "STAGE1_TOOL" is misleading and it should be called "STAGE2_TOOL" instead. Do you concur? Then a STAGE2_TOOL always is something that runs on the build machine and operates on $DEB_HOST_ARCH, which seems just about right, no? STAGE2_TOOL not necessarily is something we'd want to install into a .deb though. Do you agree? > > @@ -162,7 +164,7 @@ > > # correct), but we use ghc-pkg from stage2 when we generate our control > > file. > > # Maybe we should consider using ghc-pkg from binary-dist-dir instead. > > # As a work-around for now, regenerate the stage2 package cache. > > - _build/stage1/bin/ghc-pkg recache > > + $(STAGE1_TOOL)ghc-pkg recache > > In case we are cross-compiling, this is
Bug#1058745: debvm enables accel=kvm:tcg on ppc64el despite not available/working
Control: tags -1 + moreinfo Hi Benjamin, On Fri, Dec 15, 2023 at 01:21:06PM +0100, Benjamin Drung wrote: > The debvm 0.2.13 command1 autopkgtest fails on ppc64el on Ubuntu: > > ``` > qemu-system-ppc64el -netdev > user,id=net0,domainname=novalocal,hostfwd=tcp:127.0.0.1:-:22 -device > virtio-net-pci,netdev=net0 -append root=LABEL=debvm rw -nographic -device > virtio-rng-pci,rng=rng0 -object rng-random,filename=/dev/urandom,id=rng0 -cpu > host -machine accel=kvm:tcg -drive > media=disk,format=raw,discard=unmap,file=test.ext4,if=virtio,cache=unsafe > -no-user-config -name debvm-run test.ext4 -m 1G -kernel /proc/self/fd/3 > -initrd /proc/self/fd/4 > ioctl(KVM_CREATE_VM) failed: 22 Invalid argument > PPC KVM module is not loaded. Try modprobe kvm_hv. > qemu-system-ppc64el: failed to initialize kvm: Invalid argument > qemu-system-ppc64el: falling back to tcg > qemu-system-ppc64el: unable to find CPU model 'host' > ``` > > Full log: > https://autopkgtest.ubuntu.com/results/autopkgtest-noble/noble/ppc64el/d/debvm/20231210_104929_cc4af@/log.gz Thank you for the report. I note that the very same autopkgtest succeeds on Debian infrastructure. We should also consider a possible infrastructure issue here. > The environment where debvm is executed does not work with KVM. debvm > should check for that and not enable "accel=kvm:tcg" in that environment. As you can see, it does pass -machine accel=kvm:tcg to support this fallback here. What fails is not the machine selection but the cpu selection. As far as I understand it, we cannot use a similar fallback mechanism for the cpu selection. Therefore debvm tries to open /dev/kvm for writing and only passes -cpu host when that device is accessible. Comparing the log to Debian, we can see that on Debian no -cpu host is being passed. The difference thus is that Ubuntu provides a dysfunctional kvm device accessible to the user under test. Do you agree that this is a deficiency in your test environment? Please remove the moreinfo tag with your response. Helmut
Bug#1058678: blt: disable jpeg support
On Fri, Dec 15, 2023 at 01:43:12PM +0200, Adrian Bunk wrote: > The src:python3.x packages build idle-python3.x packages. > IDLE is an IDE for Python.[1] > > The idle-python3.x packages depend on python3-tk, which depends on blt. The idle-python3.x package is called python3.x-full. It happens to issue a runtime dependency on python3.x-tk which is provided from python3-tk which is built from python3-stdlib-extensions. Since idle is otherwise implemented in Python, one doesn't actually need tk to perform the install step for idle in the Python build. > There is a certain weirdness in Python shipping an IDE that is based > on Tcl/Tk, but that's an upstream issue. ... > The tk-dev/blt-dev build dependencies in src:python3.x: > - might be remnants from the times when python3-tk was built there, or This definitely is true in some sense. > - might be test-only, or I guess this is also true. > - might be workaroundable with a noidle build profile Given your pointer at pkg-config, I now performed another build comparison: * Add uuid-dev and pkg-config to Build-Depends. * Drop tk-dev and blt-dev from Build-Depends (in one of two builds). * Fix the build path. * Disable testing and profile guided optimization (DEB_BUILD_OPTIONS="nocheck nopgo"). The differences reduce significantly. I can no longer spot differences in the filenames. The sysconfigdata changes and around tkinter even though no tkinter module is installed into any package. LTO seems to still shuffle things around quite a bit. Diffing Python binary builds is hard. Helmut
Bug#1058893: medusa FTCBFS: missing Build-Depends: libgcrypt-dev
Source: medusa Version: 2.2-7 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs medusa fails to cross build from source, because it cannot find libgcrypt.so. It is somewhat surprising that linking libgcrypt works natively as its Build-Depends only pull libgcrypt20 and not libgcrypt20-dev. Given that medusa really links -lgcrypt, I think it really should have libgcrypt-dev in its Build-Depends and doing so fixes the cross build. I'm attaching a patch for your convenience. Helmut diff --minimal -Nru medusa-2.2/debian/changelog medusa-2.2/debian/changelog --- medusa-2.2/debian/changelog 2020-09-08 17:09:20.0 +0200 +++ medusa-2.2/debian/changelog 2023-12-17 11:17:27.0 +0100 @@ -1,3 +1,10 @@ +medusa (2.2-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Missing Build-Depends: libgcrypt-dev. (Closes: #-1) + + -- Helmut Grohne Sun, 17 Dec 2023 11:17:27 +0100 + medusa (2.2-7) unstable; urgency=medium * Team upload. diff --minimal -Nru medusa-2.2/debian/control medusa-2.2/debian/control --- medusa-2.2/debian/control 2020-09-08 17:09:20.0 +0200 +++ medusa-2.2/debian/control 2023-12-17 11:17:27.0 +0100 @@ -5,6 +5,7 @@ Uploaders: Luciano Bello , Adrian Alves Build-Depends: debhelper-compat (= 11), gnutls-dev, + libgcrypt-dev, libssl-dev, libsvn-dev, libpq-dev,
Bug#1017039: (no subject)
We have a working 90overlay-root module in Debian which can mount a NFS directory. Currently I see no need to replace this with a new implementation, that was not working when I tested it last time. I also wonder why upstream does not include it? Are there quality issues? Currently I have no time to spend more time into it, because I have to focus on my other software projects. It would be nice if you could test and report if it works for you. -- regards Thomas
Bug#1058892: RFS: shotwell/0.32.4-1 -- digital photo organizer
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "shotwell": Package name : shotwell Version : 0.32.4-1 Upstream contact : Jim Nelson URL : https://wiki.gnome.org/Apps/Shotwell License : LGPL-2.1 Vcs : https://git.jff.email/cgit/shotwell.git Section : gnome The source builds the following binary packages: shotwell - digital photo organizer shotwell-common - digital photo organizer - common files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/shotwell/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.32.4-1.dsc or from git https://git.jff.email/cgit/shotwell.git?h=release%2Fdebian%2F0.32.4-1 or git (old) https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.32.4-1 Changes since the last upload: shotwell (0.32.4-1) unstable; urgency=medium . * New upstream release. - Install new shotwell-video-metadata-handler. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Sun, Dec 17, 2023 at 07:53:52PM +0100, Luca Boccassi wrote: > On Sun, 17 Dec 2023, 17:45 dann frazier, wrote: > > > On Thu, Dec 07, 2023 at 08:58:23PM +, Luca Boccassi wrote: > > > On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier > > > wrote: > > > > Package: wnpp > > > > Severity: wishlist > > > > Owner: dann frazier > > > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > > > > > * Package name: virt-firmware > > > > Version : 23.10 > > > > Upstream Contact: Gerd Hoffmann > > > > * URL : https://gitlab.com/kraxel/virt-firmware > > > > * License : GPL-2+ > > > > Programming Lang: Python > > > > Description : Tools for manipulating edk2 (ovmf/qemu-efi) > > > firmware images > > > > > > > > This is a collection of tools for edk2 firmware images. They support > > > > decoding and printing the content of firmware volumes. Variable > > > stores > > > > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure > > > boot > > > > certificates. Tools included: > > > > > > > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > > > > > > > virt-fw-vars - Print and edit variable store volumes. Currently > > > focused on > > > > enrolling certificates and enabling secure boot. > > > > > > > > virt-fw-sigdb - Print and edit EFI signature database files. > > > > > > > > host-efi-vars - Read efi variables from linux efivarfs and > > > decode/print them. > > > > > > > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified > > > kernel > > > > images) when using direct boot (without boot loader > > > like > > > > grub or systemd-boot). > > > > > > > > pe-dumpinfo - Information dump for pe (the format used by EFI) > > > binaries. > > > > > > > > pe-listsigs - List signatures and certificate chain for pe binaries. > > > Can also > > > >extract certificates & signatures. > > > > > > > > > > > > My immediate motivation for packaging this is that, as the maintainer > > > of > > > > the edk2 package, I need to remove some deprecated image types - > > > specifically > > > > the OVMF 2M images. These utilities can help users migrate their VMs > > > to > > > > supported types by dumping/loading the variable stores. > > > > > > > > In the future, I expect edk2 packaging to evolve into using these > > > tools > > > > to modify images out-of-band, instead of launching QEMU instances to > > > > modify them in-band as part of the build. > > > > > > > > > > Hello Dann, > > > > > > I find myself in need of this package for some CI usage as well, are > > > you planning to work on this soon? Do you need any help? > > > > Hi Luca, > > > > Apologies for the delayed response. I believe I have completed the > > packaging and am prepared to upload: > > > > https://salsa.debian.org/dannf/virt-firmware > > > > Feel free to review and let me know if you have any feedback. > > > > -dann > > > > Looks good to me, thanks. Ship it! Shipped :) -dann
Bug#1057995: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
Hi Andreas On Sun, 17 Dec 2023 at 18:15, Andreas Tille wrote: > Is there > any better way than editing debian/obitools.substvars in d/rules by > adding some override_dh_gencontrol? Remove the line: Cython>=0.24 from requirements.txt. Regards Graham
Bug#1058891: ITP: budgie-session - Budgie Desktop Session Manager
Package: wnpp Severity: wishlist Owner: David Mohammed (fossfree...@ubuntu.com) Package name : budgie-session Version : 0.9 Upstream Author : Budgie Developers URL : https://github.com/buddiesofbudgie/budgie-desktop License : GPL 2+ Programming Lang: C Description :The Budgie Session Manager is in charge of starting the core components of the Budgie Desktop. . This package contains the translations and data files which are required for a budgie desktop session.
Bug#1057995: Why is ${python3:Depends} injecting cython3-legacy (Was: obitools: runtime dependency on cython)
Hi, I checked debian/obitools.substvars which contains python3:Depends=cython3-legacy, python3 (<< 3.12), python3 (>= 3.11~), python3-ipython, python3-sphinx, python3-virtualenv, python3-wheel, python3:any I wonder what mechanism is responsible for adding cython3-legacy to the package dependencies. This looks absolutely unmotivated to me. Is there any better way than editing debian/obitools.substvars in d/rules by adding some override_dh_gencontrol? Kind regards Andreas. -- http://fam-tille.de
Bug#1058890: linux-image-6.1.0-16-amd64 breaks suspend
Package: src:linux Version: 6.1.67-1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Updating the kernel * What exactly did you do (or not do) that was effective (or ineffective)? Booting from old kernel * What was the outcome of this action? Notebook can't wake up from suspend when using noveau driver, but worse yet the xserver doesn't even start when using Nvidia proprietary (error message saying no display was found) * What outcome did you expect instead? I expect updating the kernel doesn't break functionality. *** End of the template - remove these template lines *** -- Package-specific info: ** Version: Linux version 6.1.0-16-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.67-1 (2023-12-12) ** Command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-16-amd64 root=UUID=50906476-3c38-4fac-ab46-38d8ca6b9dd5 ro acpi_backlight=video nowatchdog libata.allow_tpm=1 ** Not tainted ** Kernel log: [7.330870] sd 0:0:0:0: Attached scsi generic sg0 type 0 [7.331146] sr 2:0:0:0: Attached scsi generic sg1 type 5 [7.356487] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input11 [7.392564] ACPI: button: Lid Switch [LID0] [7.393013] ACPI: AC: AC Adapter [ADP0] (on-line) [7.403757] input: Sleep Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input12 [7.421153] ACPI: button: Sleep Button [SLPB] [7.425107] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input13 [7.425323] ACPI: button: Power Button [PWRB] [7.425503] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input14 [7.430812] ACPI: button: Power Button [PWRF] [7.452498] at24 0-0050: supply vcc not found, using dummy regulator [7.453934] at24 0-0050: 256 byte spd EEPROM, read-only [7.454744] at24 0-0051: supply vcc not found, using dummy regulator [7.456352] at24 0-0051: 256 byte spd EEPROM, read-only [7.457463] at24 0-0053: supply vcc not found, using dummy regulator [7.474495] at24 0-0053: 256 byte spd EEPROM, read-only [7.508907] input: PC Speaker as /devices/platform/pcspkr/input/input15 [7.511009] iTCO_vendor_support: vendor-support=0 [7.526518] mc: Linux media interface: v0.10 [7.528097] iTCO_wdt iTCO_wdt.1.auto: Found a Cougar Point TCO device (Version=2, TCOBASE=0x0460) [7.528576] iTCO_wdt iTCO_wdt.1.auto: initialized. heartbeat=30 sec (nowayout=0) [7.548311] Adding 3964924k swap on /dev/sda6. Priority:-2 extents:1 across:3964924k SSFS [7.611599] cfg80211: Loading compiled-in X.509 certificates for regulatory database [7.612026] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [7.612427] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [7.612823] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [7.613701] platform regulatory.0: firmware: direct-loading firmware regulatory.db [7.613950] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [7.631031] random: crng init done [7.678991] videodev: Linux video capture interface: v2.00 [7.684269] RAPL PMU: API unit is 2^-32 Joules, 2 fixed counters, 163840 ms ovfl timer [7.684382] RAPL PMU: hw unit of domain pp0-core 2^-16 Joules [7.684468] RAPL PMU: hw unit of domain package 2^-16 Joules [7.684498] Intel(R) Wireless WiFi driver for Linux [7.684930] iwlwifi :04:00.0: can't disable ASPM; OS doesn't have ASPM control [7.688010] cryptd: max_cpu_qlen set to 1000 [7.700936] iwlwifi :04:00.0: firmware: direct-loading firmware iwlwifi-6000-4.ucode [7.701178] iwlwifi :04:00.0: loaded firmware version 9.221.4.1 build 25532 6000-4.ucode op_mode iwldvm [7.708582] AVX version of gcm_enc/dec engaged. [7.708721] AES CTR mode by8 optimization enabled [7.725197] usb 3-1.6: Found UVC 1.00 device BisonCam, NB Pro (5986:0308) [7.729530] snd_hda_intel :01:00.1: Disabling MSI [7.729620] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client [7.750030] input: BisonCam, NB Pro: BisonCam, NB as /devices/pci:00/:00:1d.0/usb3/3-1/3-1.6/3-1.6:1.0/input/input17 [7.750246] usbcore: registered new interface driver uvcvideo [7.759394] input: HDA NVidia HDMI/DP,pcm=3 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input16 [7.759606] input: HDA NVidia HDMI/DP,pcm=7 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input18 [7.759786] input: HDA NVidia HDMI/DP,pcm=8 as /devices/pci:00/:00:01.0/:01:00.1/sound/card1/input19 [7.759963] input: HDA NVidia HDMI/DP,pcm=9 as
Bug#1058755: logcheck: Email not report log lines
Il Fri, Dec 15, 2023 at 11:31:18PM +, Richard Lewis scrisse: > On Fri, 15 Dec 2023 at 16:06, Stefano Callegari > wrote: > > > from few days the email from cron are empty, there is only the header.txt. > > > /etc/logcheck <-bash> # su -s /bin/bash -c "/usr/sbin/logcheck -l > > /var/log/syslog" logcheck > > > > the email has the log lines. Without the -l option, still empty. > > Seems like it isnt checking the syslog -- what is in the files in > /etc/logcheck/logcheck.logfiles.d/ and logcheck.conf ? ~ <-bash> # ls /etc/logcheck/logcheck.logfiles.d/ journal.logfiles syslog.logfiles ~ <-bash> # cat /etc/logcheck/logcheck.logfiles.d/journal.logfiles ## The word 'journal' tells logcheck to check log entries in the ## systemd journal # (This is enabled by default, but if you do not want to check entries # in the journal you can comment out the next line) journal ~ <-bash> # cat /etc/logcheck/logcheck.logfiles.d/syslog.logfiles ## Log entries in the logs listed below will be checked by logcheck # The default is to check standard syslog files # created by rsyslog or other syslog daemons # (If your system does not use a syslog daemon you # can comment these lines out) /var/log/syslog /var/log/auth.log ~ <-bash> # cat /etc/logcheck/logcheck.conf | egrep -v "^#" | egrep -v "^$" REPORTLEVEL="server" SENDMAILTO="logcheck" MAILASATTACH=0 FQDN=1 TMP="/tmp" ~ <-bash> # ls -l /var/log/syslog -rw-r- 1 root adm 1364965 17 dic 19.55 /var/log/syslog ~ <-bash> # grep logcheck /etc/group adm:x:4:logcheck,stefano logcheck:x:139: > > Are you using systemd? Yes > > I suggest also using the -d option -- should say what it is doing in > great detail (pipe to file or through less) I've tried! Many and many of lines, never ending, it seems a loop. I had to do a ^C. > > > > /etc/logcheck/header.txt [Errno 13] Permesso negato: > > '/etc/logcheck/header.txt' > > /etc/logcheck/logcheck.conf [Errno 13] Permesso negato: > > '/etc/logcheck/logcheck.conf' > > /etc/logcheck/logcheck.logfiles [Errno 13] Permesso negato: > > '/etc/logcheck/logcheck.logfiles' > > /etc/logcheck/logcheck.logfiles.d/journal.logfiles [Errno 13] Permesso > > negato: '/etc/logcheck/logcheck.logfiles.d/journal.logfiles' > > /etc/logcheck/logcheck.logfiles.d/syslog.logfiles [Errno 13] Permesso > > negato: '/etc/logcheck/logcheck.logfiles.d/syslog.logfiles' > > > > -- no debconf information > > Thanks -- Stefano Callegari GnuPG Public Key Server: pgp.mit.edu
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Sun, 17 Dec 2023, 17:45 dann frazier, wrote: > On Thu, Dec 07, 2023 at 08:58:23PM +, Luca Boccassi wrote: > > On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier > > wrote: > > > Package: wnpp > > > Severity: wishlist > > > Owner: dann frazier > > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > > > * Package name: virt-firmware > > > Version : 23.10 > > > Upstream Contact: Gerd Hoffmann > > > * URL : https://gitlab.com/kraxel/virt-firmware > > > * License : GPL-2+ > > > Programming Lang: Python > > > Description : Tools for manipulating edk2 (ovmf/qemu-efi) > > firmware images > > > > > > This is a collection of tools for edk2 firmware images. They support > > > decoding and printing the content of firmware volumes. Variable > > stores > > > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure > > boot > > > certificates. Tools included: > > > > > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > > > > > virt-fw-vars - Print and edit variable store volumes. Currently > > focused on > > > enrolling certificates and enabling secure boot. > > > > > > virt-fw-sigdb - Print and edit EFI signature database files. > > > > > > host-efi-vars - Read efi variables from linux efivarfs and > > decode/print them. > > > > > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified > > kernel > > > images) when using direct boot (without boot loader > > like > > > grub or systemd-boot). > > > > > > pe-dumpinfo - Information dump for pe (the format used by EFI) > > binaries. > > > > > > pe-listsigs - List signatures and certificate chain for pe binaries. > > Can also > > >extract certificates & signatures. > > > > > > > > > My immediate motivation for packaging this is that, as the maintainer > > of > > > the edk2 package, I need to remove some deprecated image types - > > specifically > > > the OVMF 2M images. These utilities can help users migrate their VMs > > to > > > supported types by dumping/loading the variable stores. > > > > > > In the future, I expect edk2 packaging to evolve into using these > > tools > > > to modify images out-of-band, instead of launching QEMU instances to > > > modify them in-band as part of the build. > > > > > > > Hello Dann, > > > > I find myself in need of this package for some CI usage as well, are > > you planning to work on this soon? Do you need any help? > > Hi Luca, > > Apologies for the delayed response. I believe I have completed the > packaging and am prepared to upload: > > https://salsa.debian.org/dannf/virt-firmware > > Feel free to review and let me know if you have any feedback. > > -dann > Looks good to me, thanks. Ship it! >
Bug#1058889: src:openjdk-22: fails to migrate to testing for too long: FTBFS on armhf
Source: openjdk-22 Version: 22~22ea-1 Severity: serious Control: close -1 22~25ea-1 Tags: sid trixie ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), The Release Team considers packages that are out-of-sync between testing and unstable for more than 30 days as having a Release Critical bug in testing [1]. Your package src:openjdk-22 has been trying to migrate for 31 days [2]. Hence, I am filing this bug. The version in unstable failed to build on armhf. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and trixie, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2023/06/msg1.html [2] https://qa.debian.org/excuses.php?package=openjdk-22 OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1017039: (no subject)
https://salsa.debian.org/debian/dracut/-/merge_requests/20 was not merged but will Debian get this change from upstream dracut when a new version is uploaded to Debian?
Bug#1058888: pyferret FTBSF on several architectures: dh_install: error: missing files, aborting
Source: pyferret Version: 7.6.5-5 Severity: serious Tags: ftbfs https://buildd.debian.org/status/logs.php?pkg=pyferret=7.6.5-5 ... dh_install -a dh_install: warning: Cannot find (any matches for) "debian/tmp/ext_func/pylibs" (tried in ., debian/tmp) dh_install: warning: python3-ferret missing files: debian/tmp/ext_func/pylibs install -m0755 -d debian/python3-ferret//usr/bin cp --reflink=auto -a ./debian/pyferret3 debian/python3-ferret//usr/bin/ install -m0755 -d debian/python3-ferret//usr/lib/python3/dist-packages cp --reflink=auto -a ./debian/tmp/lib/python3.11/libpyferret.cpython-311-powerpc64le-linux-gnu.so ./debian/tmp/lib/python3.12/libpyferret.cpython-312-powerpc64le-linux-gnu.so ./install/local/lib/python3.11/dist-packages/__pycache__ ./install/local/lib/python3.11/dist-packages/gcircle-7.65-py3.11.egg-info ./install/local/lib/python3.11/dist-packages/gcircle.py ./install/local/lib/python3.11/dist-packages/pipedviewer ./install/local/lib/python3.11/dist-packages/pipedviewer-7.65-py3.11.egg-info ./install/local/lib/python3.11/dist-packages/pyferret ./install/local/lib/python3.11/dist-packages/pyferret-7.65-py3.11.egg-info debian/python3-ferret//usr/lib/python3/dist-packages/ install -m0755 -d debian/python3-ferret//usr/share/bash-completion/completions/ cp --reflink=auto -a ./debian/bash_completion.d/pyferret3 debian/python3-ferret//usr/share/bash-completion/completions// dh_install: error: missing files, aborting make: *** [debian/rules:8: binary-arch] Error 25
Bug#1058096: Processed: Bug#1058096 marked as pending in xonsh
Hi Debian (2023.12.17_17:48:05_+) Whoops, that was a typo, I was meaning to close 1057596. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1057942: ydpdict: FTBFS: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
Control: tags -1 + patch
On 2023-12-10 20:19 +0100, Santiago Vila wrote:
> Package: src:ydpdict
> Version: 1.0.4-1
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [...]
> gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -DHAVE_CONFIG_H -DSYSCONFDIR=\"/etc\" -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection
> -DHAVE_CONFIG_H -c -o ydpdict-ydpdict.o `test -f 'ydpdict.c' || echo
> './'`ydpdict.c
> ydpdict.c: In function ‘check_size’:
> ydpdict.c:324:22: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 324 | newx = stdscr->_maxx + 1;
> | ^~
> ydpdict.c:325:22: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 325 | newy = stdscr->_maxy + 1;
> | ^~
> ydpdict.c: In function ‘main’:
> ydpdict.c:855:27: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 855 | event.y > (window->_begy + correct1) && event.y <
> (window->_begy + window->_maxy + correct2) &&\
> | ^~
> ydpdict.c:862:88: note: in expansion of macro ‘__MOUSE_IN’
> 862 | if (m_event.bstate &
> BUTTON1_DOUBLE_CLICKED && __MOUSE_IN(window_def, m_event, -2, 1, -3, 2)) {
> |
> ^~
> ydpdict.c:855:67: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 855 | event.y > (window->_begy + correct1) && event.y <
> (window->_begy + window->_maxy + correct2) &&\
> | ^~
> ydpdict.c:862:88: note: in expansion of macro ‘__MOUSE_IN’
> 862 | if (m_event.bstate &
> BUTTON1_DOUBLE_CLICKED && __MOUSE_IN(window_def, m_event, -2, 1, -3, 2)) {
> |
> ^~
> ydpdict.c:855:83: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 855 | event.y > (window->_begy + correct1) && event.y <
> (window->_begy + window->_maxy + correct2) &&\
> |
> ^~
> ydpdict.c:862:88: note: in expansion of macro ‘__MOUSE_IN’
> 862 | if (m_event.bstate &
> BUTTON1_DOUBLE_CLICKED && __MOUSE_IN(window_def, m_event, -2, 1, -3, 2)) {
> |
> ^~
> ydpdict.c:856:27: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 856 | event.x > (window->_begx + correct3) && event.x <
> (window->_begx + window->_maxx + correct4))
> | ^~
> ydpdict.c:862:88: note: in expansion of macro ‘__MOUSE_IN’
> 862 | if (m_event.bstate &
> BUTTON1_DOUBLE_CLICKED && __MOUSE_IN(window_def, m_event, -2, 1, -3, 2)) {
> |
> ^~
> ydpdict.c:856:67: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 856 | event.x > (window->_begx + correct3) && event.x <
> (window->_begx + window->_maxx + correct4))
> | ^~
> ydpdict.c:862:88: note: in expansion of macro ‘__MOUSE_IN’
> 862 | if (m_event.bstate &
> BUTTON1_DOUBLE_CLICKED && __MOUSE_IN(window_def, m_event, -2, 1, -3, 2)) {
> |
> ^~
> ydpdict.c:856:83: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 856 | event.x > (window->_begx + correct3) && event.x <
> (window->_begx + window->_maxx + correct4))
> |
> ^~
> ydpdict.c:862:88: note: in expansion of macro ‘__MOUSE_IN’
> 862 | if (m_event.bstate &
> BUTTON1_DOUBLE_CLICKED && __MOUSE_IN(window_def, m_event, -2, 1, -3, 2)) {
> |
> ^~
> ydpdict.c:887:104: error: invalid use of incomplete typedef ‘WINDOW’ {aka
> ‘struct _win_st’}
> 887 |
Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel
Same result with the latest kernel: Linux nas-1 6.1.0-16-marvell #1 Debian 6.1.67-1 (2023-12-12) armv5tel GNU/Linux On Sun, Dec 17, 2023 at 09:59:23AM -0700, Scott Barker wrote: Prior to the installation, /var/lib/mysql did not exist. After installation: 61559 4 drwxr-xr-x 2 mysql mysql 4096 Dec 17 09:56 /var/lib/mysql 61975 4 -rw-rw 1 mysql mysql52 Dec 17 09:56 /var/lib/mysql/aria_log_control 61983 12304 -rw-rw 1 mysql mysql 12582912 Dec 17 09:56 /var/lib/mysql/ibdata1 61963 0 -rw-r--r-- 1 root root 0 Dec 17 09:56 /var/lib/mysql/debian-10.11.flag 61990 98404 -rw-rw 1 mysql mysql 100663296 Dec 17 09:56 /var/lib/mysql/ib_logfile101 6198216 -rw-rw 1 mysql mysql 16384 Dec 17 09:56 /var/lib/mysql/aria_log.0001 uname -a reports: Linux nas-1 5.10.0-26-marvell #1 Debian 5.10.197-1 (2023-09-29) armv5tel GNU/Linux On Sun, Dec 17, 2023 at 11:48:16PM +0800, Otto Kekäläinen wrote: Hi Scott and Kr! Did you note this line? 2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero bytes in datafile: ./ibdata1, Space ID:0, Flags: 0 Can you include the output of `find /var/lib/mysql -ls` so we can see what files your system has? What is the hardware you have? The report shows 'Linux 5.10.0-26-marvell '. What does `uname -a` yield? The test suite passes on armhf at e.g. https://launchpad.net/~mysql-ubuntu/ +archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all. At https:// ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to regression in subselect which is unrelated to what you reported. -- Scott Barker -- To unsubscribe, send mail to 1058706-unsubscr...@bugs.debian.org. -- Scott Barker
Bug#1028489: boost1.83 as default
Control: tags -1 = confirmed Hi Anton On 2023-11-16 23:08:10 +0100, Anton Gladky wrote: > Hi Sebastian, > > bugs are filed: > > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-boost183-transition=gl...@debian.org=1=1=1=1#results Please go ahead. Cheers -- Sebastian Ramacher
Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel
Prior to the installation, /var/lib/mysql did not exist. After installation: 61559 4 drwxr-xr-x 2 mysql mysql 4096 Dec 17 09:56 /var/lib/mysql 61975 4 -rw-rw 1 mysql mysql52 Dec 17 09:56 /var/lib/mysql/aria_log_control 61983 12304 -rw-rw 1 mysql mysql 12582912 Dec 17 09:56 /var/lib/mysql/ibdata1 61963 0 -rw-r--r-- 1 root root 0 Dec 17 09:56 /var/lib/mysql/debian-10.11.flag 61990 98404 -rw-rw 1 mysql mysql 100663296 Dec 17 09:56 /var/lib/mysql/ib_logfile101 6198216 -rw-rw 1 mysql mysql 16384 Dec 17 09:56 /var/lib/mysql/aria_log.0001 uname -a reports: Linux nas-1 5.10.0-26-marvell #1 Debian 5.10.197-1 (2023-09-29) armv5tel GNU/Linux On Sun, Dec 17, 2023 at 11:48:16PM +0800, Otto Kekäläinen wrote: Hi Scott and Kr! Did you note this line? 2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero bytes in datafile: ./ibdata1, Space ID:0, Flags: 0 Can you include the output of `find /var/lib/mysql -ls` so we can see what files your system has? What is the hardware you have? The report shows 'Linux 5.10.0-26-marvell '. What does `uname -a` yield? The test suite passes on armhf at e.g. https://launchpad.net/~mysql-ubuntu/ +archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all. At https:// ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to regression in subselect which is unrelated to what you reported. -- Scott Barker
Bug#1058849: linphone: diff for NMU version 5.2.0-4.1
Control: tags 1058849 + patch Control: tags 1058849 + pending Dear maintainer, I've prepared an NMU for linphone (versioned as 5.2.0-4.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer or cancel it. Regards. diff -Nru linphone-5.2.0/debian/changelog linphone-5.2.0/debian/changelog --- linphone-5.2.0/debian/changelog 2023-07-29 16:10:37.0 -0400 +++ linphone-5.2.0/debian/changelog 2023-12-17 11:31:05.0 -0500 @@ -1,3 +1,12 @@ +linphone (5.2.0-4.1) unstable; urgency=medium + + * Non-maintainer upload. + * debian/patches/use-cxx17-standard.patch: Build the whole project +with C++17 instead of C++14 due to new requirement from zxing-cpp +headers. (Closes: #1058849) + + -- Boyuan Yang Sun, 17 Dec 2023 11:31:05 -0500 + linphone (5.2.0-4) unstable; urgency=medium * Release to unstable. diff -Nru linphone-5.2.0/debian/patches/series linphone- 5.2.0/debian/patches/series --- linphone-5.2.0/debian/patches/series2023-07-29 16:10:37.0 -0400 +++ linphone-5.2.0/debian/patches/series2023-12-17 11:30:43.0 -0500 @@ -1,4 +1,3 @@ -#desktop-file-keywords fix-jsoncpp-include-path.patch fix-jsoncpp-linker-flag.patch ldap-hostname-override.patch @@ -16,3 +15,4 @@ fix-ldap-abandon.patch fix-L_STRING_TO_C-inlining-errors.patch bc-b52e8f62-build-with-gcc13.patch +use-cxx17-standard.patch diff -Nru linphone-5.2.0/debian/patches/use-cxx17-standard.patch linphone- 5.2.0/debian/patches/use-cxx17-standard.patch --- linphone-5.2.0/debian/patches/use-cxx17-standard.patch 1969-12-31 19:00:00.0 -0500 +++ linphone-5.2.0/debian/patches/use-cxx17-standard.patch 2023-12-17 11:30:20.0 -0500 @@ -0,0 +1,25 @@ +From: Boyuan Yang +Date: Sun, 17 Dec 2023 11:29:16 -0500 +Subject: Use C++17 Standard + +New zxing-cpp header uses C++17 features. This requires building +the project with C++17 instead of C++14. + +Bug-Debian: https://bugs.debian.org/1058849 +--- + CMakeLists.txt | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/CMakeLists.txt b/CMakeLists.txt +index b3060af..c846dc7 100644 +--- a/CMakeLists.txt b/CMakeLists.txt +@@ -93,7 +93,7 @@ cmake_dependent_option(ENABLE_QRCODE "Enable QRCode support" YES "ENABLE_VIDEO" + # * DISABLE_BC_PACKAGE_SEARCH: skip find_package() for every BC package (bctoolbox, ortp, etc.) + # * DISABLE_SOCI_PACKAGE_SEARCH: skip find_package() for Soci. + +-set(CMAKE_CXX_STANDARD 14) ++set(CMAKE_CXX_STANDARD 17) + set(CMAKE_CXX_EXTENSIONS NO) + + if(NOT CMAKE_BUILD_TYPE) signature.asc Description: This is a digitally signed message part
Bug#1055987: ITP: virt-firmware -- Tools for manipulating edk2 (ovmf/qemu-efi) firmware images
On Thu, Dec 07, 2023 at 08:58:23PM +, Luca Boccassi wrote: > On Wed, 15 Nov 2023 05:54:23 -0700 dann frazier > wrote: > > Package: wnpp > > Severity: wishlist > > Owner: dann frazier > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name : virt-firmware > > Version : 23.10 > > Upstream Contact: Gerd Hoffmann > > * URL : https://gitlab.com/kraxel/virt-firmware > > * License : GPL-2+ > > Programming Lang: Python > > Description : Tools for manipulating edk2 (ovmf/qemu-efi) > firmware images > > > > This is a collection of tools for edk2 firmware images. They support > > decoding and printing the content of firmware volumes. Variable > stores > > (e.g. OVMF_VARS.fd) can be modified, for example to enroll secure > boot > > certificates. Tools included: > > > > virt-fw-dump - Decodes and prints the content of firmware volumes. > > > > virt-fw-vars - Print and edit variable store volumes. Currently > focused on > > enrolling certificates and enabling secure boot. > > > > virt-fw-sigdb - Print and edit EFI signature database files. > > > > host-efi-vars - Read efi variables from linux efivarfs and > decode/print them. > > > > kernel-bootcfg - Manage efi boot configuration for UKIs (unified > kernel > > images) when using direct boot (without boot loader > like > > grub or systemd-boot). > > > > pe-dumpinfo - Information dump for pe (the format used by EFI) > binaries. > > > > pe-listsigs - List signatures and certificate chain for pe binaries. > Can also > > extract certificates & signatures. > > > > > > My immediate motivation for packaging this is that, as the maintainer > of > > the edk2 package, I need to remove some deprecated image types - > specifically > > the OVMF 2M images. These utilities can help users migrate their VMs > to > > supported types by dumping/loading the variable stores. > > > > In the future, I expect edk2 packaging to evolve into using these > tools > > to modify images out-of-band, instead of launching QEMU instances to > > modify them in-band as part of the build. > > > > Hello Dann, > > I find myself in need of this package for some CI usage as well, are > you planning to work on this soon? Do you need any help? Hi Luca, Apologies for the delayed response. I believe I have completed the packaging and am prepared to upload: https://salsa.debian.org/dannf/virt-firmware Feel free to review and let me know if you have any feedback. -dann
Bug#1058884: installation-reports: debian testing iso install in franch: Light-DM and mate desktop are in English
Hi again, I forgot to mention both installation were made in accessible mode, by pressing s then enter on boot. Best regards, -- Patrick ZAJDA OpenPGP_0x9D4AD35BEA273DCA.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1058818: Acknowledgement (grub-common: fwsetup --is-supported not supported, boots into setup instead)
Okay, this is a weirdness caused by how I installed this laptop. I did a standard Debian install in 2021, then copied the rootfs from my previous (non-EFI) machine over it. Therefore I ended up with the modules in /usr/lib/grub/x86_64-efi in place, but not part of any installed Debian package. Instead, grub-pc kept the files in /usr/lib/grub/i386-pc up-to-date. However, grub-install correctly identified the machine as EFI and just silently used the stale files from /usr/lib/grub/x86_64-efi: # /usr/sbin/grub-install Installing for x86_64-efi platform. Installation finished. No error reported. # This caused the 2021 files to be installed to /boot/grub/x86_64-efi/ and to the EFI partition. Installing grub-efi-amd64-bin and updating grub got me the efifwsetup.mod with the --is-supported flag and now everything is good. Still, maybe it's a good idea to have grub-install check for the presence of the right / up-to-date package? Thank you very much.
Bug#1058706: Aw: Re: Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel
Hi Otto, root@gast1:~# find /var/lib/mysql -ls 262301 4 drwxr-xr-x 2 mysql mysql 4096 Dec 17 11:17 /var/lib/mysql 263594 4 -rw-rw 1 mysql mysql 52 Dec 17 11:17 /var/lib/mysql/aria_log_control 263597 98304 -rw-rw 1 mysql mysql 100663296 Dec 17 11:17 /var/lib/mysql/ib_logfile101 263596 12288 -rw-rw 1 mysql mysql 12582912 Dec 17 11:17 /var/lib/mysql/ibdata1 263591 0 -rw-r--r-- 1 root root 0 Dec 17 11:17 /var/lib/mysql/debian-10.11.flag 263595 16 -rw-rw 1 mysql mysql 16384 Dec 17 11:17 /var/lib/mysql/aria_log.0001 root@gast1:~# root@gast1:~# uname -a Linux gast1 6.1.0-15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1 (2023-12-09) x86_64 GNU/Linux root@gast1:~# Regards, Konstantin Gesendet: Sonntag, 17. Dezember 2023 um 16:48 Uhr Von: "Otto Kekäläinen" An: "Scott Barker" , 1058...@bugs.debian.org, k-...@web.de Cc: "Faustin Lammler" , "Tuukka Pasanen" Betreff: Re: Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel Hi Scott and Kr! Did you note this line? 2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero bytes in datafile: ./ibdata1, Space ID:0, Flags: 0 Can you include the output of `find /var/lib/mysql -ls` so we can see what files your system has? What is the hardware you have? The report shows 'Linux 5.10.0-26-marvell '. What does `uname -a` yield? The test suite passes on armhf at e.g. https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all. At https://ci.debian.net/packages/m/mariadb/unstable/armel/[https://ci.debian.net/packages/m/mariadb/unstable/armel/] it fails due to regression in subselect which is unrelated to what you reported.
Bug#1057863: slepc4py ftbfs with Python 3.12
Source: slepc4py Followup-For: Bug #1057863 Correction: curexc_traceback is not used in slepc4py 3.19. Maybe it's time to upgrade to PETSc 3.19.
Bug#1058706: mariadb-server-core: mariadbd fails to start on fresh install on armel
Hi Scott and Kr! Did you note this line? 2023-12-14 14:51:33 0 [Note] InnoDB: Header page consists of zero bytes in datafile: ./ibdata1, Space ID:0, Flags: 0 Can you include the output of `find /var/lib/mysql -ls` so we can see what files your system has? What is the hardware you have? The report shows 'Linux 5.10.0-26-marvell '. What does `uname -a` yield? The test suite passes on armhf at e.g. https://launchpad.net/~mysql-ubuntu/+archive/ubuntu/mariadb-10.11/+builds?build_text=_state=all. At https://ci.debian.net/packages/m/mariadb/unstable/armel/ it fails due to regression in subselect which is unrelated to what you reported.
Bug#1058887: linux-image-6.5.0-5-amd64: impossible to switch off iwlwifi adaptor
Package: src:linux Version: 6.5.13-1 Severity: normal Dear Maintainer, When I try to switch off my Wi-Fi adaptor, it just blocks/hangs and never goes down. Trying to get info in cli also blocks: $ env LANG=C nmcli Warning: nmcli (1.44.2) and NetworkManager (Unknown) versions don't match. Restarting NetworkManager is advised. Error: NetworkManager is not running. Even reboot/power-down hangs and the only way to recover is a hard-power down. I added at the end of this report some info from syslog (tail -f /var/log/syslog) I ran at the moment I swithced off my Wi-Fi. Last info, I tried with the previous kernel linux-image-6.5.0-4-amd64 (6.5.10-1) and it works like a charm. Regards, Jean-Marc -- Package-specific info: ** Version: Linux version 6.5.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-7) 13.2.0, GNU ld (GNU Binutils for Debian) 2.41) #1 SMP PREEMPT_DYNAMIC Debian 6.5.13-1 (2023-11-29) ** Command line: BOOT_IMAGE=/vmlinuz-6.5.0-5-amd64 root=/dev/mapper/gandalf--vg-root ro quiet ** Tainted: W (512) * kernel issued warning ** Kernel log: [ 15.121367] hid-alps 0018:044E:120B.0001: input,hidraw0: I2C HID v1.00 Mouse [DLL07A0:01 044E:120B] on i2c-DLL07A0:01 [ 15.160195] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 8265, REV=0x230 [ 15.160285] thermal thermal_zone7: failed to read out thermal zone (-61) [ 15.167411] iwlwifi :02:00.0: reporting RF_KILL (radio disabled) [ 15.224743] EXT4-fs (nvme0n1p2): mounting ext2 file system using the ext4 subsystem [ 15.23] iwlwifi :02:00.0: base HW address: 00:28:f8:e3:43:f6, OTP minor version: 0x0 [ 15.235653] EXT4-fs (nvme0n1p2): mounted filesystem 24d75cff-3492-44c9-bb3b-b3cc1a47ff56 r/w without journal. Quota mode: none. [ 15.244767] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs' [ 15.247297] EXT4-fs (dm-3): mounted filesystem 16ae5ebd-3b09-4b5a-a492-54848826a72c r/w with ordered data mode. Quota mode: none. [ 15.254994] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC3246: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker [ 15.254999] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 15.255002] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 (0x21/0x0/0x0/0x0/0x0) [ 15.255004] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0 [ 15.255005] snd_hda_codec_realtek hdaudioC0D0:inputs: [ 15.255007] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x19 [ 15.255009] snd_hda_codec_realtek hdaudioC0D0: Headphone Mic=0x1a [ 15.255010] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 [ 15.256746] iwlwifi :02:00.0 wlp2s0: renamed from wlan0 [ 15.295867] usb 1-5: New USB device found, idVendor=0bda, idProduct=5650, bcdDevice=60.06 [ 15.295871] usb 1-5: New USB device strings: Mfr=3, Product=1, SerialNumber=2 [ 15.295873] usb 1-5: Product: Integrated Webcam_HD [ 15.295874] usb 1-5: Manufacturer: CN0K49W17248773OA6KAA00 [ 15.295876] usb 1-5: SerialNumber: 200901010001 [ 15.322123] input: HDA Digital PCBeep as /devices/pci:00/:00:1f.3/sound/card0/input12 [ 15.38] input: HDA Intel PCH Headphone Mic as /devices/pci:00/:00:1f.3/sound/card0/input13 [ 15.322338] input: HDA Intel PCH HDMI/DP,pcm=3 as /devices/pci:00/:00:1f.3/sound/card0/input14 [ 15.322437] input: HDA Intel PCH HDMI/DP,pcm=7 as /devices/pci:00/:00:1f.3/sound/card0/input15 [ 15.322533] input: HDA Intel PCH HDMI/DP,pcm=8 as /devices/pci:00/:00:1f.3/sound/card0/input16 [ 15.390559] audit: type=1400 audit(1702826732.654:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name="lsb_release" pid=655 comm="apparmor_parser" [ 15.393865] audit: type=1400 audit(1702826732.654:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="system_tor" pid=658 comm="apparmor_parser" [ 15.401016] audit: type=1400 audit(1702826732.662:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=656 comm="apparmor_parser" [ 15.401021] audit: type=1400 audit(1702826732.662:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" pid=656 comm="apparmor_parser" [ 15.404165] audit: type=1400 audit(1702826732.666:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="torbrowser_tor" pid=675 comm="apparmor_parser" [ 15.406822] audit: type=1400 audit(1702826732.670:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-client.action" pid=657 comm="apparmor_parser" [ 15.406827] audit: type=1400 audit(1702826732.670:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/lib/NetworkManager/nm-dhcp-helper" pid=657 comm="apparmor_parser" [ 15.406829] audit: type=1400 audit(1702826732.670:9): apparmor="STATUS" operation="profile_load" profile="unconfined"
Bug#999964: shush: depends on obsolete pcre3 library
Control: tags -1 + patch
Please find attached a patch.
Description: Port to PCRE2.
Bug-Debian: https://bugs.debian.org/64
Author: Yavor Doganov
Forwarded: no
Last-Update: 2023-12-17
---
--- shush-1.2.3.orig/configure.ac
+++ shush-1.2.3/configure.ac
@@ -60,9 +60,19 @@
# Checks for libraries.
AC_SEARCH_LIBS([basename], [gen])
if test "x$with_pcre" != "xno"; then
- AC_SEARCH_LIBS([pcre_compile], [pcre], ,
- AC_MSG_WARN([Perl Compatible Regular Expressions library is missing.])
- with_pcre="no")
+ save_libs="$LIBS"
+ LIBS="$LIBS -lpcre2-8"
+ AC_MSG_CHECKING([for pcre library])
+ AC_LINK_IFELSE(
+ [AC_LANG_PROGRAM([[#define PCRE2_CODE_UNIT_WIDTH 8
+#include
+]],
+ [[pcre2_match_data_create(4, NULL);]])],
+ [AC_MSG_RESULT([yes])],
+ [AC_MSG_RESULT([no])
+ AC_MSG_WARN([Perl Compatible Regular Expressions library is missing.])
+ with_pcre="no"
+ LIBS="$save_libs"])
fi
AC_SEARCH_LIBS([MD5Data], [md])
AC_SEARCH_LIBS([md5_calc], [md5])
@@ -70,7 +80,11 @@
# Checks for header files.
AC_CHECK_HEADERS([md5.h paths.h pthread.h])
if test "x$with_pcre" != "xno"; then
- AC_CHECK_HEADERS([pcre.h])
+ AC_CHECK_HEADERS([pcre2.h],
+ [AC_DEFINE([HAVE_PCRE_H], [1],
+[Define to 1 if you have the header file.])],
+ [], [[#define PCRE2_CODE_UNIT_WIDTH 8
+ ]])
fi
# Checks for typedefs, structures, and compiler characteristics.
--- shush-1.2.3.orig/src/analyzer.c
+++ shush-1.2.3/src/analyzer.c
@@ -16,7 +16,8 @@
#include
#include
#if defined(HAVE_PCRE_H)
-# include
+# define PCRE2_CODE_UNIT_WIDTH 8
+# include
#endif
#include "analyzer.h"
@@ -40,7 +41,7 @@
{
regex_t re;
#if defined(HAVE_PCRE_H)
- pcre *pcre;
+ pcre2_code *pcre;
#endif
} val;
};
@@ -98,15 +99,19 @@
static int
compile_pcre(void *pcreptr, char *str)
{
-pcre **re;
-const char *errmsg;
-int erroffset;
+pcre2_code **re;
+int err;
+PCRE2_SIZE erroffset;
re = pcreptr;
-*re = pcre_compile(str, 0, , , NULL);
+*re = pcre2_compile((PCRE2_SPTR)str, strlen(str), 0,
+, , NULL);
if (*re == NULL)
{
- error("Bad PCRE (offset %d): %s", erroffset, errmsg);
+ PCRE2_UCHAR errmsg[120];
+
+ pcre2_get_error_message(err, errmsg, sizeof(errmsg));
+ error("Bad PCRE (offset %zu): %s", erroffset, errmsg);
return -1;
}
return 0;
@@ -501,15 +506,17 @@
#if defined(HAVE_PCRE_H)
else if (type == PCRE)
{
- int ovector[3072];
+ PCRE2_SIZE *ovector;
+ pcre2_match_data *md;
- r = pcre_exec(list[condno].val.pcre, NULL, ln,
+ md = pcre2_match_data_create(3072, NULL);
+ r = pcre2_match(list[condno].val.pcre, (PCRE2_SPTR)ln,
(lndup != NULL) ? strlen(lndup) : nl - ln,
- 0, 0, ovector, 3072);
- if (r < 0 && r != PCRE_ERROR_NOMATCH)
+ 0, 0, md, NULL);
+ if (r < 0 && r != PCRE2_ERROR_NOMATCH)
{
/* Something bad happened */
- error("Fatal error during output analysis: pcre_exec() failed
with code %d", r);
+ error("Fatal error during output analysis: pcre2_match()
failed with code %d", r);
error("Regular expression used was: %s",
list[condno].expression);
error("Trying to match the following line of data: %s", ln);
@@ -517,6 +524,7 @@
free(lndup);
else
*nl = '\n';
+ pcre2_match_data_free(md);
return -1;
}
else
@@ -527,14 +535,15 @@
/* Matched */
debug(DDATA,
- "Matched: #%d %d[%c] (PCRE_ERROR_NOMATCH=%d)",
- condno+1, r, list[condno].code, PCRE_ERROR_NOMATCH);
+ "Matched: #%d %d[%c] (PCRE2_ERROR_NOMATCH=%d)",
+ condno+1, r, list[condno].code,
PCRE2_ERROR_NOMATCH);
byteset_set(list[condno].code, 1);
/* Check for substrings */
i = 1;
+ ovector = pcre2_get_ovector_pointer(md);
while (i < r)
{
- if (ovector[i*2] < 0 || ovector[i*2+1] < 0)
+ if ((int)ovector[i*2] < 0 || (int)ovector[i*2+1] < 0)
continue;
set_mark(marks, , ,
ln - str + ovector[i*2], TOGGLE);
@@ -546,8 +555,9 @@
}
else
debug(DVDATA,
- "Failed: #%d %d[%c] (PCRE_ERROR_NOMATCH=%d)",
- condno+1, r,
Bug#1057935: ncurses-hexedit: FTBFS: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct _win_st’}
Control: tags -1 + patch
On 2023-12-10 20:18 +0100, Santiago Vila wrote:
> Package: src:ncurses-hexedit
> Version: 0.9.7+orig-7.2
> Severity: serious
> Tags: ftbfs
>
> Dear maintainer:
>
> During a rebuild of all packages in unstable, your package failed to build:
>
>
> [...]
> gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong
> -fstack-clash-protection -Wformat -Werror=format-security
> -fcf-protection -Wall -c -o file.o file.c
> file.c: In function ‘printPage’:
> file.c:647:34: error: invalid use of incomplete typedef ‘WINDOW’ {aka ‘struct
> _win_st’}
> 647 | for (result = Globals.wmain->_curx; result < COLS; result++)
> | ^~
There are quite a few more instances of such errors across the source
code, the attached patch should fix all of them. The package builds and
from a cursory look appears to work, but it would be good if a potential
NMU'er reviews and tests the patch before uploading.
Cheers,
Sven
From 676299deb4fa83c7f100011da2948c49ba97499c Mon Sep 17 00:00:00 2001
From: Sven Joachim
Date: Sun, 17 Dec 2023 16:15:43 +0100
Subject: [PATCH] Avoid accessing internal ncurses structures
Since ncurses patchlevel 20231021 the WINDOW structure is opaque, its
members cannot be addressed directly. Use the functions ncurses
provides for this purpose instead.
---
src/file.c| 2 +-
src/misc.c| 6 ++
src/print.c | 16
src/widgets.c | 24
4 files changed, 23 insertions(+), 25 deletions(-)
diff --git a/src/file.c b/src/file.c
index 14a2475..ba7c147 100644
--- a/src/file.c
+++ b/src/file.c
@@ -644,7 +644,7 @@ printPage (const struct FileNames *fp)
wprintw (Globals.wmain, "%s", trunc_file);
fp = fp->p;
- for (result = Globals.wmain->_curx; result < COLS; result++)
+ for (result = getcurx(Globals.wmain); result < COLS; result++)
wprintw (Globals.wmain, " ");
}
diff --git a/src/misc.c b/src/misc.c
index 24068b4..8b0fb4b 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -641,10 +641,8 @@ handleSigwinch (int i)
if (!newlines)
die_horribly (NOT_ENOUGH_MEMORY, NULL);
- Globals.wmain->_cury = cursor_y - 1;
- Globals.wmain->_curx = cursor_x;
- stdscr->_cury = cursor_y;
- stdscr->_curx = cursor_x;
+ wmove(Globals.wmain, cursor_y - 1, cursor_x);
+ move(cursor_y, cursor_x);
if (cursor_y >= BOTTOM_LINE)
cursor_y = BOTTOM_LINE;
if (Globals.mode == FILE_MODE)
diff --git a/src/print.c b/src/print.c
index 57b291e..59b0ca1 100644
--- a/src/print.c
+++ b/src/print.c
@@ -196,16 +196,16 @@ drawAsciiDump (unsigned long off, unsigned long *offs)
if (*offs > Globals.filesize)
break;
#ifdef __NCURSES_H /* i don't know why this works */
- if (Globals.wmain->_cury == MAIN_BOTTOM_LINE)
+ if (getcury(Globals.wmain) == MAIN_BOTTOM_LINE)
#else
- if (Globals.wmain->_cury == MAIN_HEIGHT)
+ if (getcury(Globals.wmain) == MAIN_HEIGHT)
#endif
break;
- if (Globals.wmain->_curx == COLS - 2)
+ if (getcurx(Globals.wmain) == COLS - 2)
{
move = 1;
}
- if (Globals.wmain->_curx == 0)
+ if (getcurx(Globals.wmain) == 0)
*(newlines + i++) = *offs;
bold = hash_lookup (*offs, NULL);
if (!bold)
@@ -215,8 +215,8 @@ drawAsciiDump (unsigned long off, unsigned long *offs)
{
if (filebuffer (*offs) == '\n')
{
-int cury = Globals.wmain->_cury;
-int i = Globals.wmain->_curx;
+int cury = getcury(Globals.wmain);
+int i = getcurx(Globals.wmain);
for (; i < COLS - 2; i++)
wprintw (Globals.wmain, " ");
wprintw (Globals.wmain, ".");
@@ -235,7 +235,7 @@ drawAsciiDump (unsigned long off, unsigned long *offs)
{
if (filebuffer (*offs) == EBCDIC['\n'])
{
-int cury = Globals.wmain->_cury;
+int cury = getcury(Globals.wmain);
wprintw (Globals.wmain, ".");
wmove (Globals.wmain, cury + 1, 0);
}
@@ -257,7 +257,7 @@ drawAsciiDump (unsigned long off, unsigned long *offs)
(*offs)++;
if (move)
{
- wmove (Globals.wmain, Globals.wmain->_cury + 1, 0);
+ wmove (Globals.wmain, getcury(Globals.wmain) + 1, 0);
move = 0;
continue;
}
diff --git a/src/widgets.c b/src/widgets.c
index eb627ad..38183f8 100644
--- a/src/widgets.c
+++ b/src/widgets.c
@@ -99,11 +99,11 @@ stringBox (WINDOW *win, int y, int x, int len, int max, char *sample)
case KEY_LEFT:
if (i > 0)
{
- if (win->_curx > x)
+ if (getcurx(win) > x)
/* not at left hand side */
{
i--;
- wmove
Bug#1057863: slepc4py ftbfs with Python 3.12
Source: slepc4py Followup-For: Bug #1057863 slepc4py does not use curexc_traceback. Perhaps this is a bug in cython?
Bug#1058886: irqbalance: floods logs with ---...--- lines
Package: irqbalance Version: 1.9.3-1 Severity: normal Since the latest irqbalance upgrade, I've been encountering log lines like 2023-12-17T10:08:10.722658-05:00 v100a irqbalance[4194303]: #012#012#012- every ten seconds, somewhat burying meaningful logs. Could you please suppress these lines, at least in the absence of --debug? (It's also started logging occasional "Selecting irq N for rebalancing" lines, to which I have no such objection.) Thanks! -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, x32 Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages irqbalance depends on: ii init-system-helpers 1.66 ii libc62.37-12 ii libcap-ng0 0.8.3-3 ii libglib2.0-0 2.78.3-1 ii libncursesw6 6.4+20231209-1 ii libnuma1 2.0.16-1 ii libsystemd0 254.5-1 ii libtinfo66.4+20231209-1 ii runit-helper 2.15.2 irqbalance recommends no packages. irqbalance suggests no packages. -- debconf-show failed
Bug#1056676: /usr/share/wireshark/manuf is gone
Hi Christoph, Christoph Biedl ezt írta (időpont: 2023. dec. 14., Cs, 18:28): > > Bálint Réczey wrote... > > > Technically it is possible, but is there a use case where "tshark -G" > > is not sufficient already? > > That would be good enough, thanks. So, problem solved for me, feel free > to close or to wait until somebody else complains about any other file > now missing. > > Oh, and just in case anybody else stumbles across this: To get the > actual manufacturer list, "tshark -G manuf" does the trick. Thanks, I meant to suggest that, indeed. The data is also available in the independent ieee-data package in multiple formats. Cheers, Balint > > Christoph
Bug#1055300: Reopen + fix
control: reopen -1 control: found -1 5.4.0-1 control: forwarded -1 https://github.com/ansible-collections/amazon.aws/pull/1704 control: tag -1 + fixed-upstream Hi, This bug lie in ansible... Reopen this bug and use the patch as fwd field. rouca signature.asc Description: This is a digitally signed message part.
Bug#1013868: nfs-common: Split between Python scripts to separate package
Control: tags -1 patch Control: retitle -1 nfs-common makes Python required on NFS clients On Fri, 25 Aug 2023 16:58:33 +0200 Gioele Barabucci wrote: > > could you please move the three Python scripts included in nfs-common to > > a separate -extras package? > > We can remove nfsconvert.py and revisit this after the bookworm > release. now that nfsconvert.py has been removed (thanks!) [1], do you think it would be possible to move these Python scripts to a separate package? Hi, you can find a MR that moves the Python scripts to a separate package at https://salsa.debian.org/kernel-team/nfs-utils/-/merge_requests/29 Regards, -- Gioele Barabucci
Bug#1054657: Transition ready? (Was: Transition seems to be blocked (Was: Bug#1054657: transition: r-bioc-biocgenerics))
Hi Andreas There are some packages that have still not migrated since the previous r-api-bioc-3.17 transition in July 2023. Links to their tracker pages, which should tell you what is needed, follow: https://tracker.debian.org/pkg/r-bioc-cner https://tracker.debian.org/pkg/r-bioc-dada2 https://tracker.debian.org/pkg/r-bioc-edaseq https://tracker.debian.org/pkg/r-bioc-ioniser https://tracker.debian.org/pkg/r-bioc-megadepth https://tracker.debian.org/pkg/r-bioc-scater https://tracker.debian.org/pkg/r-bioc-shortread https://tracker.debian.org/pkg/r-bioc-tcgabiolinks https://tracker.debian.org/pkg/r-bioc-tfbstools As a bonus, here's another, not related to the transition, but from a similar time: https://tracker.debian.org/pkg/r-cran-dials Regards Graham
Bug#1058870: jq: Got illegal instruction in unit test in i386
The issue only happens when using valgrind. Need to investigate.
--
ChangZhuo Chen (陳昌倬) czchen@{czchen,debian}.org
Key fingerprint = BA04 346D C2E1 FE63 C790 8793 CC65 B0CD EC27 5D5B
signature.asc
Description: PGP signature
Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On Sun, Dec 17, 2023 at 12:34:11AM -0800, Paul Eggert wrote: On 2023-12-16 13:46, Bernhard Voelker wrote: Whether the implementation is race-prone or not is an internal thing. I wasn't referring to the internal implementation. I was referring to cp users. With the newer Coreutils (FreeBSD) behavior, you can reliably write a script to do something if cp -n didn't copy the file because the destination already existed. With the older Coreutils behavior you cannot do that reliably; there will always be a race condition. You can now reliably write a script using the new long option. Changing the behavior of the short option helped nobody.
Bug#1058752: bug#62572: cp --no-clobber behavior has changed
On 16/12/2023 21:46, Bernhard Voelker wrote:
On 12/15/23 21:13, Michael Stone wrote:
On Fri, Dec 15, 2023 at 11:21:06AM -0800, Paul Eggert wrote:
Stlll, Pádraig gave a reasonable summary of why the change was made,
To clarify my summary a little, there I said that -n now _immediately_ fails.
I should have said _silently_ fails. I.e. the complete copy operation
proceeds as before, and only the exit status is at issue here.
despite its incompatibility with previous behavior. (One thing I'd add
is that the FreeBSD behavior is inherently less race-prone.)
Whether the implementation is race-prone or not is an internal thing.
I think we're currently discussing more on a user-perspective level.
IIUC then the question is whether `cp -n` should continue to behave like
the (new) `cp --update=none` which returns EXIT_SUCCESS.
Regardless what other implementations do, when reading the -n description
from a user's point of view:
-n, --no-clobber do not overwrite an existing file (overrides a
-u or previous -i option). See also --update
then I'd expect the tool to just skip existing files like `rsync
--ignore-existing`
does. In that regard I would be surprised if skipping files would result in an
error.
Well, I would understand if there'd be a '--no-clobber=fail' option.
Agreed we should improve the docs a bit for this option.
I'll apply this at least:
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 1f8b356d1..bf0f424d3 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -9057,6 +9057,8 @@ Do not overwrite an existing file; silently fail instead.
This option overrides a previous
@option{-i} option. This option is mutually exclusive with @option{-b} or
@option{--backup} option.
+See also the @option{--update=none} option which will
+skip existing files but not fail.
@item -P
@itemx --no-dereference
diff --git a/src/cp.c b/src/cp.c
index 04a5cbee3..3ccc4c4e6 100644
--- a/src/cp.c
+++ b/src/cp.c
@@ -192,8 +192,8 @@ Copy SOURCE to DEST, or multiple SOURCE(s) to DIRECTORY.\n\
-L, --dereferencealways follow symbolic links in SOURCE\n\
"), stdout);
fputs (_("\
- -n, --no-clobber do not overwrite an existing file (overrides
a\n\
- -u or previous -i option). See also
--update\n\
+ -n, --no-clobber ensure no existing files overwritten, and
fail\n\
+ silently instead. See also --update\n\
"), stdout);
fputs (_("\
-P, --no-dereference never follow symbolic links in SOURCE\n\
As Kamil added the option in 2009, I'd assume that the same patch was already
active in RHEL versions for quite some longer time.
Now changing the exit code feels kind of rough.
Well RHEL 6 came out a bit after (2010), and had the --no-clobber change,
while RHEL 5 before that did not.
Taking about distros, it's worth noting that the change is Fedora 39
which has been released for a month now.
We'll keep a close eye on issues, but haven't heard much as
of yet at least.
Therefore, from a pure user's perspective and regarding many years of
precedence,
I am 80:20 for reverting the exit code change.
Thanks for your thoughts,
appreciated as always.
cheers,
Pádraig
Bug#1058657: python3-apt: undefined symbol: PyAptWarning
This is really bad because it also breaks unattended-upgrades, so I guess the only way out is to run "apt upgrade" by hand (after it's fixed) on each impacted system.
Bug#1058883: RFS: libhx/4.19-1 -- Documentation files for libhx
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "libhx": Package name : libhx Version : 4.19-1 Upstream contact : Jan Engelhardt URL : https://inai.de/projects/libhx/ License : GPL-2+, LGPL-2.1+, WTFPL-2+ Vcs : https://git.jff.email/cgit/libhx.git Section : libs The source builds the following binary packages: libhx32 - C library providing queue, tree, I/O and utility functions libhx-dev - Development files for libhx libhx-doc - Documentation files for libhx To access further information about this package, please visit the following URL: https://mentors.debian.net/package/libhx/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/libh/libhx/libhx_4.19-1.dsc or from git https://git.jff.email/cgit/libhx.git/?h=release%2Fdebian%2F4.19-1 or git (old) https://jff.email/cgit/libhx.git/?h=release%2Fdebian%2F4.19-1 Changes since the last upload: libhx (4.19-1) unstable; urgency=medium . * New upstream release. - Refresh symbols files. * Remove empty debian/libhx-dev.symbols. * debian/rules: - Remove build of libhx-dev.symbols. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1058882: pendulum: Please upgrade to pendulum 3.0 and drop pytzdata
Source: pendulum Version: 2.1.2-4 Severity: wishlist X-Debbugs-Cc: bdr...@debian.org Dear Maintainer, please upgrade pendulum to upstream release 3.0 and then drop pytzdata (see https://github.com/sdispater/pendulum/issues/657). Dropping pytzdata removes one additional timezone data package. -- Benjamin Drung Debian & Ubuntu Developer
Bug#1024311: Bug#1024276: #1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for
On 2023-12-17 03:30, Maytham Alsudany wrote: Hi Drew, We've got a mechanism using debian/watch and debian/copyright to automate removing third_party/pkcs11/* and creating the 0.*.0+dfsg tarball. I suggest making a Merge Request with your fix so we can review that, and then merge it all together. Done, see https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/merge_requests/1 Thanks Maytham. I've made review. Don't erase the existing package history in debian/changelog. I had a small question about the include path for pkcs11.h (how does the build system know about nss? Drew
Bug#1056338: Debian Bug #1056338
Closed, new version available. -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Jörg Frings-Fürst D-54470 Lieser git: https://git.jff.email/cgit/ Skype:jff-skype@jff.email Jami: joergfringsfuerst Telegram: @joergfringsfuerst Matrix: @joergff:matrix.snct-gmbh.de My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#1054012: at: defer placement of systemd unit to systemd's pkgconf file
Hi, Can anyone do a NMU? I have no success in finding free time to work on this and I do not want to delay more this fix. Kind regards Jose M Calhariz On 12/8/23 21:22, Chris Hofstaedtler wrote: Hi at Maintainers, Hi Jose, Ansgar, On Sun, Oct 15, 2023 at 11:15:44AM +0200, Helmut Grohne wrote: We want to move files from aliased directories to /usr (see DEP17). The at package is involved, because it ships a systemd unit in /lib. I propose that instead of hard coding this directory, you may defer the placement to systemd's pkgconf file. The advantage of doing so is that a backport of apt to an older release will automatically revert back to /lib and thus honour the file move moratorium that still applies to bookworm. I'm attaching a patch for your convenience. Is there anything we can do to help you out and get Helmut's patch applied? Thanks for considering, Chris
Bug#1058881: ITP: golang-github-emersion-go-imap-uidplus -- UIDPLUS extension for go-imap
Package: wnpp Severity: wishlist Owner: Maytham Alsudany X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org Control: block 1058875 by -1 * Package name: golang-github-emersion-go-imap-uidplus Version : 0.17.0 Upstream Contact: https://github.com/emersion/go-imap-uidplus/issues * URL : https://github.com/emersion/go-imap-uidplus * License : Expat Programming Lang: Go Description : UIDPLUS extension for go-imap UIDPLUS extension (https://tools.ietf.org/html/rfc4315) for go-imap (https://github.com/emersion/go-imap) Test () build-dependency of golang-github-protonmail-gluon. - Will need a sponsor - Will be maintained in Debian Go Packaging Team Kind regards, Maytham signature.asc Description: This is a digitally signed message part
Bug#1058880: systemd-binfmt.service: unit fails to start when /proc/sys/fs/binfmt_misc is not mounted
Package: systemd Version: 252.19-1~deb12u1 Severity: normal Tags: upstream patch fixed-upstream X-Debbugs-Cc: d...@debian.org Dear maintainers, When /proc/sys/fs/binfmt_misc is not mounted (on purpose), systemd-binfmt.service fails to start: × systemd-binfmt.service - Set Up Additional Binary Formats Loaded: loaded (/lib/systemd/system/systemd-binfmt.service; static) Active: failed (Result: exit-code) since Sat 2023-12-16 14:27:55 UTC; 22h ago Docs: man:systemd-binfmt.service(8) man:binfmt.d(5) https://docs.kernel.org/admin-guide/binfmt-misc.html https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems Main PID: 1408 (code=exited, status=1/FAILURE) CPU: 5ms déc. 16 14:27:54 prokofiev systemd[1]: Starting systemd-binfmt.service - Set Up Additional Binary Formats... déc. 16 14:27:54 prokofiev systemd[1]: systemd-binfmt.service: Main process exited, code=exited, status=1/FAILURE déc. 16 14:27:54 prokofiev systemd[1]: systemd-binfmt.service: Failed with result 'exit-code'. déc. 16 14:27:54 prokofiev systemd[1]: Failed to start systemd-binfmt.service - Set Up Additional Binary Formats. déc. 16 14:27:55 prokofiev systemd[1]: Starting systemd-binfmt.service - Set Up Additional Binary Formats... déc. 16 14:27:55 prokofiev systemd[1]: systemd-binfmt.service: Main process exited, code=exited, status=1/FAILURE déc. 16 14:27:55 prokofiev systemd[1]: systemd-binfmt.service: Failed with result 'exit-code'. déc. 16 14:27:55 prokofiev systemd[1]: Failed to start systemd-binfmt.service - Set Up Additional Binary Formats. This has already been fixed upstream by the following commit, which is in trixie/sid, but not in bookworm: commit f74a7cb45c2458f90de6d37c70fa3afc1a3be279 Author: Yu Watanabe Date: Sat Dec 10 11:46:45 2022 +0900 unit: check more specific path to be written by systemd-binfmt Follow-up for 41807efb1594ae8e71e0255e154ea7d17be2251a. Replaces #25690. Would it be possible to backport this commit to bookworm? Thanks, Aurelien
Bug#1057067: new upstream release (1.65)
Am 17.12.23 um 06:18 schrieb Maytham Alsudany: Hi, Mind if I help out with the new version? Hi Maytham, that would be great, please go ahead! Regards, Tobias OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#999965: shadowsocks-libev: depends on obsolete pcre3 library
Control: tags -1 + patch
Please find attached a patch, build-tested only.
>From a214f32480e417c9bf3358652f96d29d51325560 Mon Sep 17 00:00:00 2001
From: Yavor Doganov
Date: Sun, 17 Dec 2023 14:23:39 +0200
Subject: [PATCH] Port to PCRE2 (#65)
---
debian/changelog | 7 ++
debian/control | 2 +-
debian/patches/pcre2.patch | 157 +
debian/patches/series | 1 +
4 files changed, 166 insertions(+), 1 deletion(-)
create mode 100644 debian/patches/pcre2.patch
diff --git a/debian/changelog b/debian/changelog
index c43a915..20c1f63 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+shadowsocks-libev (3.3.5+ds-11) UNRELEASED; urgency=medium
+
+ * debian/patches/pcre2.patch: New; port to PCRE2 (Closes: #65).
+ * debian/control (Build-Depends): Replace libpcre3-dev with libpcre2-dev.
+
+ -- Yavor Doganov Sun, 17 Dec 2023 14:22:39 +0200
+
shadowsocks-libev (3.3.5+ds-10) unstable; urgency=medium
* Revert the move of systemd service files from /lib/ to /usr/lib/.
diff --git a/debian/control b/debian/control
index c2becba..d944661 100644
--- a/debian/control
+++ b/debian/control
@@ -16,7 +16,7 @@ Build-Depends:
libev-dev,
libjsonparser-dev,
libmbedtls-dev,
- libpcre3-dev,
+ libpcre2-dev,
libsodium-dev,
pkg-config,
xmlto,
diff --git a/debian/patches/pcre2.patch b/debian/patches/pcre2.patch
new file mode 100644
index 000..2691534
--- /dev/null
+++ b/debian/patches/pcre2.patch
@@ -0,0 +1,157 @@
+Description: Port to PCRE2.
+Bug-Debian: https://bugs.debian.org/65
+Author: Yavor Doganov
+Forwarded: no
+Last-Update: 2023-12-17
+---
+
+--- shadowsocks-libev.orig/src/rule.c
shadowsocks-libev/src/rule.c
+@@ -78,14 +78,18 @@
+ init_rule(rule_t *rule)
+ {
+ if (rule->pattern_re == NULL) {
+-const char *reerr;
+-int reerroffset;
++int reerr;
++PCRE2_SIZE reerroffset;
+
+ rule->pattern_re =
+-pcre_compile(rule->pattern, 0, , , NULL);
++pcre2_compile((PCRE2_SPTR)rule->pattern, strlen(rule->pattern),
++ 0, , , NULL);
+ if (rule->pattern_re == NULL) {
+-LOGE("Regex compilation of \"%s\" failed: %s, offset %d",
+- rule->pattern, reerr, reerroffset);
++PCRE2_UCHAR buf[120];
++
++pcre2_get_error_message(reerr, buf, sizeof(buf));
++LOGE("Regex compilation of \"%s\" failed: %s, offset %zu",
++ rule->pattern, buf, reerroffset);
+ return 0;
+ }
+ }
+@@ -97,6 +101,7 @@
+ lookup_rule(const struct cork_dllist *rules, const char *name, size_t
name_len)
+ {
+ struct cork_dllist_item *curr, *next;
++pcre2_match_data *md = NULL;
+
+ if (name == NULL) {
+ name = "";
+@@ -105,10 +110,15 @@
+
+ cork_dllist_foreach_void(rules, curr, next) {
+ rule_t *rule = cork_container_of(curr, rule_t, entries);
+-if (pcre_exec(rule->pattern_re, NULL,
+- name, name_len, 0, 0, NULL, 0) >= 0)
++pcre2_match_data_free(md);
++md = pcre2_match_data_create_from_pattern(rule->pattern_re, NULL);
++if (pcre2_match(rule->pattern_re, (PCRE2_SPTR)name,
++name_len, 0, 0, md, NULL) >= 0) {
++pcre2_match_data_free(md);
+ return rule;
++}
+ }
++pcre2_match_data_free(md);
+
+ return NULL;
+ }
+@@ -128,6 +138,6 @@
+
+ ss_free(rule->pattern);
+ if (rule->pattern_re != NULL)
+-pcre_free(rule->pattern_re);
++pcre2_code_free(rule->pattern_re);
+ ss_free(rule);
+ }
+--- shadowsocks-libev.orig/src/rule.h
shadowsocks-libev/src/rule.h
+@@ -33,17 +33,16 @@
+
+ #include
+
+-#ifdef HAVE_PCRE_H
+-#include
+-#elif HAVE_PCRE_PCRE_H
+-#include
++#ifdef HAVE_PCRE2_H
++#define PCRE2_CODE_UNIT_WIDTH 8
++#include
+ #endif
+
+ typedef struct rule {
+ char *pattern;
+
+ /* Runtime fields */
+-pcre *pattern_re;
++pcre2_code *pattern_re;
+
+ struct cork_dllist_item entries;
+ } rule_t;
+--- shadowsocks-libev.orig/m4/pcre.m4
shadowsocks-libev/m4/pcre.m4
+@@ -82,12 +82,12 @@
+ fi
+ ],
+ [
+- AC_CHECK_PROG(PCRE_CONFIG, pcre-config, pcre-config)
++ AC_CHECK_PROG(PCRE_CONFIG, pcre2-config, pcre2-config)
+ if test "x$PCRE_CONFIG" != "x"; then
+ enable_pcre=yes
+ pcre_base_dir="`$PCRE_CONFIG --prefix`"
+ pcre_include="`$PCRE_CONFIG --cflags | sed -es/-I//`"
+-pcre_ldflags="`$PCRE_CONFIG --libs | sed -es/-lpcre// -es/-L//`"
++pcre_ldflags="`$PCRE_CONFIG --libs8 | sed -es/-lpcre// -es/-L//`"
+ fi
+ ])
+
+@@ -95,7 +95,7 @@
+ AC_MSG_CHECKING([for pcre location])
+ AC_CACHE_VAL(ats_cv_pcre_dir,[
+ for dir in /usr/local /usr ; do
+-if test -d $dir && ( test -f $dir/include/pcre.h || test -f
$dir/include/pcre/pcre.h ); then
++if test -d $dir && ( test -f $dir/include/pcre2.h ); then
+ ats_cv_pcre_dir=$dir
+
