Bug#1069265: tzdata: Upgrade from 2023c-2 to 2024 corrupts zoneinfo files
On Thu, 18 Apr 2024 23:39:14 + IvanAbs wrote: > On 2024-04-17 several of my servers running Debian 10 received an > update for the tzdata package via Debian unattended-upgrade. However, > this update resulted in corruption of files within the > /usr/share/zoneinfo directory. I, too, encountered a variation of this issue today while trying to update the tzdata package on my system. I was eventually able to resolve the issue with a little manual intervention. Details follow. > I was using tzdata 2023c-2 package, and originally installed from an > official Debian source In my case, the installed version of the package was tzdata 2023c-5. > I installed tzdata 2023c-2 with dpkg -i, because our severs needs the > last-year updated data, but there were not a release for Debian 10, > until yesterday. Similarly, I had installed tzdata 2023c-5 on what is effectively Debian Bullseye install (though what is actually an unabashed FrankenDevuan install that is mostly composed of packages from Devuan's Chimaera release). My motivation for doing so was similar: I wanted the then-current timezone database and the package in chimaera/bullseye had yet to be updated. I fully acknowledge this course of action is actively frowned upon[1]. [1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian > To resolve this issue, I had to completely remove the tzdata 2023 > version and perform a clean installation of the new tzdata 2024 > version. Here's how I was able to resolve the issue. Using snapshot.debian.org, I downloaded tzdata_2023d-1_all.deb which installed without issue over 2023c-5. Afterward, I was able to install tzdata 2024a-0+deb11u1 without issue. As this issue only manifests on systems in explicitly unsupported configurations, the severity of the bug should probably be reduced from grave, but I will leave that decision to others. I hope this was helpful, -- Plasma
Bug#1066949: slic3r-prusa: Unneeded build dependencies on xvfb, xauth
Source: slic3r-prusa Version: 1.37.1+dfsg2-1 Severity: minor Dear Maintainer, Please drop xvfb and xauth from the build dependencies for slic3r-prusa. Prior to version 1.37.1+dfsg2-1 of slic3r-prusa, the debian/rules file made use of xvfb (and, by extension, xauth), but this is no longer the case. Thanks, -- Plasma
Bug#1064018: Testsuite is not run
On Tue, 27 Feb 2024 11:53:16 +0100 Lukas Märdian wrote: > Hey! How does this patch relate to my proposed changes in the > following MR? > https://salsa.debian.org/debian/libcbor/-/merge_requests/3 It makes the addition of '-DWITH_TESTS=ON' to the dh_auto_configure line in your proposed change no longer necessary. Your remaining proposed changes are unaffected by this patch. In versions 0.10.2-1.1 and earlier of the libcbor package in Debian, the testsuite was not run at build time. The WITH_TESTS CMake variable in the upstream source controlled the running of tests. However, this is not the idiomatic way to control test execution using CMake and the package's rules file did not define that variable. Starting with version 0.10.2-1.2, the package has been modified with my patch to run the testsuite by default. The testsuite can be skipped by running CMake with the '-DBUILD_TESTING=OFF' option. Starting with debhelper version 13.12, dh_auto_configure automatically calls CMake with that option if the DEB_BUILD_OPTIONS environment variable contains 'nocheck'. > I cannot see the tests being run at build-time even with the most > recent upload. Am I missing something? The testsuite should be run automatically starting with version 0.10.2-1.2. Please confirm you have the right version. -- Plasma
Bug#1064018: [PATCH] #1064018: Enable testsuite
Control: tags 1064018 + patch Dear Maintainer, Attached is a debdiff patch which fixes #1064018. Questions/comments welcome. Thanks, -- Plasma diff -Nru libcbor-0.10.2/debian/changelog libcbor-0.10.2/debian/changelog --- libcbor-0.10.2/debian/changelog 2023-10-05 01:47:27.0 -0500 +++ libcbor-0.10.2/debian/changelog 2024-02-12 23:12:22.0 -0600 @@ -1,3 +1,16 @@ +libcbor (0.10.2-1.2) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * d/p/Fix-non-standard-testing.patch: +Enable testing by default and toggle testing based on +BUILD_TESTING CMake variable. (Closes: 1064018) + * d/control: Build-Depend-Arch on debhelper (>= 13.12~) when +build profile is active because the BUILD_TESTING CMake variable is +automatically set to OFF for nocheck builds starting with +debhelper 13.12. + + -- Plasma (David Paul) Thu, 15 Feb 2024 20:46:41 -0600 + libcbor (0.10.2-1.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru libcbor-0.10.2/debian/control libcbor-0.10.2/debian/control --- libcbor-0.10.2/debian/control 2023-10-05 01:47:27.0 -0500 +++ libcbor-0.10.2/debian/control 2024-02-12 23:11:57.0 -0600 @@ -3,6 +3,7 @@ Maintainer: Vincent Bernat Build-Depends: debhelper-compat (= 13), Build-Depends-Arch: cmake, +debhelper (>= 13.12~) , libcmocka-dev , Build-Depends-Indep: dh-sequence-sphinxdoc, doxygen, --- libcbor-0.10.2/debian/patches/Fix-non-standard-testing.patch 1969-12-31 18:00:00.0 -0600 +++ libcbor-0.10.2/debian/patches/Fix-non-standard-testing.patch 2024-02-12 23:12:22.0 -0600 @@ -0,0 +1,52 @@ +Description: Use idiomatic CMake to control testsuite execution. + Rather than creating and relying upon a WITH_TESTS variable in the top-level + CMakeLists.txt file, instead make use of the BUILD_TESTING variable defined + by the included CTest module. Also remove the enable_testing() command + invocation in CMakeLists.txt and instead rely on the one in the CTest module + which gets run whenever the BUILD_TESTING variable is not set to OFF. +Author: Plasma (David Paul) +Bug-Debian: https://bugs.debian.org/1064018 +Forwarded: no +Last-Update: 2024-02-15 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +Index: libcbor-0.10.2/CMakeLists.txt +=== +--- libcbor-0.10.2.orig/CMakeLists.txt libcbor-0.10.2/CMakeLists.txt +@@ -29,11 +29,6 @@ option(CBOR_PRETTY_PRINTER "Include a pr + set(CBOR_BUFFER_GROWTH "2" CACHE STRING "Factor for buffer growth & shrinking") + set(CBOR_MAX_STACK_SIZE "2048" CACHE STRING "maximum size for decoding context stack") + +-option(WITH_TESTS "[TEST] Build unit tests (requires CMocka)" OFF) +-if(WITH_TESTS) +-add_definitions(-DWITH_TESTS) +-endif(WITH_TESTS) +- + option(WITH_EXAMPLES "Build examples" ON) + + option(HUGE_FUZZ "[TEST] Fuzz through 8GB of data in the test. Do not use with memory instrumentation!" OFF) +@@ -97,8 +92,6 @@ else() + add_definitions(-DEIGHT_BYTE_SIZE_T) + endif() + +-enable_testing() +- + set(CTEST_MEMORYCHECK_COMMAND "/usr/bin/valgrind") + set(MEMORYCHECK_COMMAND_OPTIONS "--tool=memcheck --track-origins=yes --leak-check=full --error-exitcode=1") + +@@ -168,12 +161,12 @@ if(use_lto) + set_property(DIRECTORY src PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE) + endif(use_lto) + +-if (WITH_TESTS) ++if (BUILD_TESTING) + add_subdirectory(test) + if(use_lto) + set_property(DIRECTORY test PROPERTY INTERPROCEDURAL_OPTIMIZATION TRUE) + endif(use_lto) +-endif (WITH_TESTS) ++endif (BUILD_TESTING) + + if (WITH_EXAMPLES) + add_subdirectory(examples) --- libcbor-0.10.2/debian/patches/series 1969-12-31 18:00:00.0 -0600 +++ libcbor-0.10.2/debian/patches/series 2024-02-11 16:49:18.0 -0600 @@ -0,0 +1 @@ +Fix-non-standard-testing.patch
Bug#1055022: bullseye-pu: package distro-info-data/0.51+deb11u5
Stefano, Short version: Would you consider modifying this bullseye-pu for distro-info-data/0.51+deb11u5 into a bullseye-pu for a distro-info-data/0.59~deb11u1 instead? Long version: The resulting distro-info-data_0.51+deb11u5_all.deb binary package resulting from your proposed debdiff is identical within a rounding error[1] to the distro-info-data_0.59_all.deb binary package currently in testing and unstable. The 0.51+deb11u4 and 0.58 binary package versions from oldstable and stable are equally similar. Within each pair the respective source packages have diverged somewhat in spite of producing essentially identical binary packages. In my experimentation the distro-info-data 0.59 source package builds flawlessly in a bullseye chroot. I recently independently discovered Debian bug #711238[2] with devscripts and I would would like to see it fixed in unstable and my desired fix of adding to it a Build-Depends on ``` distro-info-data (>= 0.58~) ``` would be made possible by this change and would be a much cleaner fix than the alternative fix of adding Build-Depends on ``` distro-info-data (>= 0.51+deb11u4) , distro-info-data (>= 0.58) | distro-info-data (< 0.51+deb11u+) ```. [1] The only differences being the changelog, the version number, one date range in the copyright file, and any metadata directly generated from those three things, like checksums and file sizes. [2] https://bugs.debian.org/711238 Thanks, -- Plasma
Bug#1053003: mmdebstrap: Support build profile
On Tue, 26 Sep 2023 23:27:20 +0200 Johannes Schauer Marin Rodrigues wrote: > Quoting David (Plasma) Paul (2023-09-26 22:25:47) > > Please accept the attached patch to add support for the > > build profile to mmdebstrap. Please let me know if there's anything > > you'd like me to clarify or change. > > I haven't tried your diff yet, but I've read it and it looks like it > does the right thing. Thank you! > > May I ask in which situation you found yourself wanting to build > mmdebstrap without its manual pages? It's not so much that I necessarily want to build mmdebstrap without its manpages; rather, that I find it useful to document which build dependencies are strictly needed to produce a functional program binary and which are only required to do things like generate documentation or run a testsuite. Build profiles, thus, provide an ideal way of adding this metadata in a easily actionable manner. [...] > > Also, FWIW, the mmtarfilter script contains a section of code > > headed by a comment explaining that it is for compatibility with > > Python versions older than 3.8. As the aforementioned 'match' > > statement makes the script in its current form error out with any > > Python version less than 3.10, this code path may no longer be > > necessary. > > The codepath is still necessary. What is not necessary anymore is to > explicitly pass format=tarfile.PAX_FORMAT because that format became > the default in 3.8. Ok, I wasn't sure. Thanks for confirming. > I adjusted the comment, thank you! Thank you! -- Plasma
Bug#1017377: libstb: incomplete clean target
On Tue, 27 Sep 2022 12:39:17 -0400 Boyuan Yang wrote: > On Mon, 15 Aug 2022 00:54:23 -0500 "David (Plasma) Paul" > wrote: > > Source: libstb > > Version: 0.0~git20210910.af1a5bc+ds-1 > > Severity: minor > > X-Debbugs-CC: davidp...@librem.one ... > > The 'clean' target for the libstb Makefile is incomplete and leaves > > behind two files, stb_c_lexer.c and stb_divide.c, generated by the > > '%.c' target. > > > > I have prepared a patch to correct this. I will submit the patch > > momentarily once I update the changelog entry with the bug number > > created by this report. > > While we will fix this issue in Debian, I am just wondering, have you > reported this issue (possibly together with the patch) to upstream > project? I haven't. Given that my patch is limited to editing a Makefile that is not in the upstream source and is instead added by the Debian packaging, I saw little reason to do so. Upstream is, of course, welcome to incorporate the Makefile into the upstream source tree, but AFAICT the upstream-recommended way of using libstb is to simply copy individual header files into a program source tree as-needed. -- Plasma
Bug#1001831: debhelper: RFC: Parse 'Rules-Requires-Root: no' in debian/control
On Sat, 18 Dec 2021 10:49:14 +0100 Niels Thykier wrote: > Hi, > > I think I am missing a rationale / What problem are you trying to > solve with this change/RFC?. > > Thanks, > ~Niels Let me try to clarify. I was recently locally building a source package that listed 'Rules-Requires-Root: no' in its debian/control file. Seeing that, I attempted, I think not unreasonably, to execute the binary target of the debian/rules file without using root. AKA: ``` $ debian/rules binary ``` This began the debhelper package build sequence which ran until the dh_testroot step which errors out with the message: ``` dh_testroot: error: You must run this as root (or use fakeroot). ``` which is rather at odds with what is stated by the debian/control header. Debian Policy § 5.6.31 lists three categories of values for the 'Rules-Requires-Root:' header: A) 'no' B) 'binary-targets' C) a list of keywords as detailed in Policy § 5.6.31.2 & 5.6.31.3 B simply denotes the existing default behavior of requiring root when calling any of the binary targets of debian/rules (a.k.a. binary-arch, binary-indep, and binary). It is currently identical in function to a complete absence of the 'Rules-Requires-Root:' header altogether. C denotes a dynamic, keyword-based system first alluded to in the original R³ proposal and fully documented in the Debian Policy sections noted previously. Because this new system requires builders to provide a special "gain root command" (detailed in Policy § 4.9.2), builders must opt-in to using this system by setting DEB_RULES_REQUIRES_ROOT and DEB_GAIN_ROOT_CMD environment variables. A on the other hand does not require providing a "gain root command" or implementing any special new behaviour. By design it should just work when the debian/rules file is run without root. However, as I read Policy § 5.6.31, Policy nevertheless mandates that the DEB_RULES_REQUIRES_ROOT environment variable must be set even in this case and dh_testroot currently enforces this. My proposal is to modify both dh_testroot and Policy to remove this requirement from case A. Thoughts? Links: dh_testroot(1) https://manpages.debian.org/bookworm/debhelper/dh_testroot.1 RFC: Support for selective usage of (fake)root during package build (R³) https://lists.debian.org/debian-devel/2017/10/msg00520.html Debian Policy § 4.9.2 debian/rules and Rules-Requires-Root https://www.debian.org/doc/debian-policy/ch-source.html#debian-rules-and-rules-requires-root Debian Policy § 5.6.31 Rules-Requires-Root https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-rules-requires-root -- Plasma
Bug#927387: invesalius: crashes after splash screen
> What is the content of the folder /usr/lib/invesalius/invesalius_cy/ ? ``` $ ls -AlF /usr/lib/invesalius/invesalius_cy/ total 1380 -rw-r--r-- 1 root root 246352 Sep 12 2018 cy_mesh.cpython-36m-x86_64-linux-gnu.so -rw-r--r-- 1 root root 339928 Sep 12 2018 floodfill.cpython-36m-x86_64-linux-gnu.so -rw-r--r-- 1 root root 0 Sep 12 2018 __init__.py -rw-r--r-- 1 root root 370080 Sep 12 2018 interpolation.cpython-36m-x86_64-linux-gnu.so -rw-r--r-- 1 root root 200128 Sep 12 2018 mips.cpython-36m-x86_64-linux-gnu.so -rw-r--r-- 1 root root 247424 Sep 12 2018 transforms.cpython-36m-x86_64-linux-gnu.so ```
Bug#927387: invesalius: crashes after splash screen
Package: invesalius
Version: 3.1.2-2
Severity: grave
Dear Maintainer,
When attempting to run InVesalius for the first time, I am presented
with the first-run language selector followed by the splash screen,
but no window ever appears and the invesalius3 process remains active
until manually terminated. Subsequent run attempts differ only in that
the language selector is not presented and the invesalius3 process
terminates on its own.
The following is the console output:
```
$ invesalius3 -d
/usr/lib/python3/dist-packages/wx/lib/pubsub/__init__.py:25:
wxPyDeprecationWarning: wx.lib.pubsub has been deprecated, plese migrate your
code to use pypubsub, available on PyPI.
wx.wxPyDeprecationWarning)
app.py:234: DeprecationWarning: Yield() is deprecated
wx.Yield()
Could not import dl
/usr/share/invesalius/invesalius/data/transformations.py:1899: UserWarning:
failed to import module _transformations
warnings.warn("failed to import module %s" % name)
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/wx/core.py", line 2228, in Notify
self.notify()
File "/usr/lib/python3/dist-packages/wx/core.py", line 3384, in Notify
self.result = self.callable(*self.args, **self.kwargs)
File "app.py", line 240, in Startup
from invesalius.gui.frame import Frame
File "/usr/share/invesalius/invesalius/gui/frame.py", line 41, in
import invesalius.gui.default_tasks as tasks
File "/usr/share/invesalius/invesalius/gui/default_tasks.py", line 28, in
import invesalius.gui.data_notebook as nb
File "/usr/share/invesalius/invesalius/gui/data_notebook.py", line 40, in
import invesalius.data.slice_ as slice_
File "/usr/share/invesalius/invesalius/data/slice_.py", line 34, in
from invesalius.data.mask import Mask
File "/usr/share/invesalius/invesalius/data/mask.py", line 33, in
from invesalius_cy import floodfill
ImportError: cannot import name 'floodfill' from 'invesalius_cy'
(/usr/lib/invesalius/invesalius_cy/__init__.py)
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/wx/core.py", line 2228, in Notify
self.notify()
File "/usr/lib/python3/dist-packages/wx/core.py", line 3384, in Notify
self.result = self.callable(*self.args, **self.kwargs)
File "app.py", line 123, in Startup2
self.control = self.splash.control
AttributeError: 'Inv3SplashScreen' object has no attribute 'control'
Traceback (most recent call last):
File "app.py", line 264, in OnClose
if self.fc.IsRunning():
AttributeError: 'Inv3SplashScreen' object has no attribute 'fc'
```
-- System Information:
Distributor ID: Devuan
Description:Devuan GNU/Linux 3.0 (Beowulf)
Release:3.0
Codename: beowulf
Architecture: x86_64
Kernel: Linux 4.19.29-gnu (SMP w/16 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages invesalius depends on:
ii invesalius-bin3.1.2-2
ii python3 3.7.2-1
ii python3-gdcm 2.8.8-6
ii python3-nibabel 2.3.2-1
ii python3-numpy 1:1.16.2-1
ii python3-pil 5.4.1-2
ii python3-psutil5.5.1-1
ii python3-scipy 1.1.0-3
ii python3-serial3.4-4
ii python3-skimage 0.14.2-2
ii python3-vtk7 7.1.1+dfsg1-12+b1
ii python3-vtkgdcm 2.8.8-6
ii python3-wxgtk4.0 4.0.4+dfsg-2
invesalius recommends no packages.
invesalius suggests no packages.
-- no debconf information
Bug#916748: dicod: typo in dicodconfig.8
Package: dicod Version: 2.3-2 Severity: minor Dear Maintainer, In dicodconfig.8 in the tarball http://deb.debian.org/debian/pool/main/d/dico/dico_2.3-2.debian.tar.xz line 39 reads ``` ``#include /var/lib/dictd/dictorg-db.list'' ``` but should instead read ``` ``#include /var/lib/dicod/dictorg-db.list'' ``` . This typo is also present in the newer tarball http://deb.debian.org/debian/pool/main/d/dico/dico_2.7-1.debian.tar.xz -- System Information: Distributor ID: Devuan Description:Devuan GNU/Linux 2.0 (ascii) Release:2.0 Codename: ascii Architecture: x86_64 Kernel: Linux 4.18.9-gnu (SMP w/16 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages dicod depends on: ii adduser3.115 ii libc6 2.27-6 ii libdico1 2.3-2 ii libgsasl7 1.8.0-8+b2 ii libldap-2.4-2 2.4.44+dfsg-5+deb9u1 ii libltdl7 2.4.6-2 ii libpam0g 1.1.8-3.6 ii libpcre3 2:8.39-9 ii lsb-base 4.1+devuan2 ii m4 1.4.18-1 ii zlib1g 1:1.2.8.dfsg-5 dicod recommends no packages. Versions of packages dicod suggests: ii dico-doc 2.3-2 -- no debconf information
