Bug#1084906: ITP: python-pyinstaller -- bundle a Python application and all its dependencies into a single package
Hi Soren On 11/10/2024 06:26, Soren Stoutner wrote: This package is a dependency of the current version of python-libusb1. I indend to maintian it under the Debian Python team umbrella. pyinstaller is a very unusual dependency to have either for a package in Debian. It's designed to build redistributable packages and can do so for various operating systems; that's not a feature that is needed as a build-depends for Debian packaging because we already have a redistributable format - the .deb - and we already have the tooling to make that. pyinstaller is also not something that would be needed at runtime. I had a look at python-libusb1 [1] because I was curious how it might use pyinstaller. The only use I can see is in making it possible for other projects to use python-libusb1 more easily in their own pyinstaller projects by advertising a plugin entry-point [2][3]. That's not something that we need to worry about in Debian, and it's also neither a runtime nor buildtime dependency. [1] https://github.com/vpelletier/python-libusb1 [2] https://pyinstaller.org/en/stable/hooks.html [3] https://setuptools.pypa.io/en/latest/userguide/entry_point.html I think you can save yourself from packaging pyinstaller for Debian; given that pyinstaller includes all manner of things you'd need to build for other operating systems, that's probably a good thing to avoid. It's likely to be horrible to package. I'm not sure if there's a reason to just package pyinstaller without this specific motivation, since it's one of those tools where you almost always need the newest version and it is mostly installed via pip in a venv for the purposes of building a redistributable. regards Stuart (Also, I learned about these pyinstaller hooks and now know how to help a couple of upstream projects that are using pyinstaller to simplify how they are doing it - good news!) -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1082955: ghostscript: txtwrite device broken, produces jibberish
Package: ghostscript
Version: 10.04.0~dfsg-1
Severity: important
X-Debbugs-Cc: stu...@debian.org
Dear Maintainer,
The txtwrite device in the most recent upload of ghostscript is broken;
this causes src:plastex to FTBFS as it uses the device in its test
suite.
The following is a simple reproducer based on a unit test from plastex.
(The necessary test3.pdf is also attached).
/-
$ cat test3.tex
\documentclass{article}
\begin{document}
\thispagestyle{empty}
a.b
\end{document}
$ lualatex test3
[...]
Output written on test3.pdf (1 page, 2719 bytes).
### In bookworm
$ gs --version
10.00.0
$ gs -q -sDEVICE=txtwrite -o %stdout% test3.pdf
a.b
### In sid
$ gs --version
10.04.0
$ gs -q -sDEVICE=txtwrite -o %stdout% test3.pdf
X#
-/
The tool pdftotext from poppler-utils also correctly extracts the text
from the test file.
This problem does not extend to all PDFs; in fact it seems to be
confined to PDFs generated by lualatex while pdflatex is OK.
Unfortanately for modern fonts and UTF-8, users are encouraged to use
lualatex these days, and the plastex test suite does so. As seen below,
lualatex picks different fonts and encodes them differently - that seems
to be what ghostscript is getting wrong.
$ pdffonts test3-lualatex.pdf
name type encoding emb sub
uni object ID
- --- ---
--- -
VFSMBO+LMRoman10-Regular CID Type 0C Identity-H yes yes
yes 4 0
$ pdffonts test3-pdftex.pdf
name type encoding emb sub
uni object ID
- --- ---
--- -
ZKXRNQ+CMR10 Type 1Builtin yes yes
yes 4 0
regards
Stuart
test3.pdf
Description: Adobe PDF document
Bug#1075393: pocl: ftbfs with GCC-14
Hi Andreas > That was a llvm-17 regresssion that got fixed today ;-) > pocl just got built successfully on arm64 ;-) brilliant news - thanks for the update Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1075393: pocl: ftbfs with GCC-14
Hi pocl maintainers! Another month has passed - is there something that others can help with here? regards Stuart On 10/08/2024 17:05, Stuart Prescott wrote: Hi pocl maintainers! I see that 6.0-2 has failed to build on arm64 and therefore can't migrate. It is also waiting for gcc-defaults to migrate. This bug doesn't really exist in testing (at least not until gcc-defaults migrates) but the BTS and therefore britney think that it does; britney therefore thinks pocl should be removed from testing along with everything that depends upon it. Perhaps tweaking the metadata on this bug is also useful? thanks Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1075393: pocl: ftbfs with GCC-14
Hi pocl maintainers! I see that 6.0-2 has failed to build on arm64 and therefore can't migrate. It is also waiting for gcc-defaults to migrate. This bug doesn't really exist in testing (at least not until gcc-defaults migrates) but the BTS and therefore britney think that it does; britney therefore thinks pocl should be removed from testing along with everything that depends upon it. Perhaps tweaking the metadata on this bug is also useful? thanks Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1073418: sasview/sasdata loader test failure
sasview 5.0.6-4 and sasdata 0.8.1-5 should fix these bugs for both testing and unstable and permit migration. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1035782: nuitka: Nuitka should hard-depend on an earlier python version and thus be uninstallable
Hi Kay I see that an updated nuitka has still not made it to Debian and so nuitka has not been available in testing (or working in unstable) for over 15 months. Do you have a firm plan for a nuitka upload? Would it make sense for nuitka to be team maintained so that others can work on the package in your absence? nuitka is a test-dependency of pyside6 and it would be better to have those tests run in the packaging than carry around lots of (fragile) patches to disable or xfail them. In one of messages to this bug you had asked for advice on how to update the dependencies for nuitka. I'm not sure of the nuances of your question, but it seems that since nuitka is very tightly linked to individual interpreter versions, it would be reasonable to not have "Depends: python3" and instead have "Depends: python3.12" (for whatever version of python it was built for). For the purposes of making generalisable packaging, a using `py3versions -d` in debian/rules and in a substvar for the Depends might be a reasonable approach. The main aim is to have it appear in the transition tracker rather than the failure appear in a later rebuild. Focusing the Debian packaging on Debian (rather than supporting the matrix of derivatives and versions) would also simplify the packaging substantially which might make it simpler to work with. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 OpenPGP_0xBBC17EBB1396F2F7.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1073418: sasview/sasdata loader test failure
For both sasview and sasdata, there's a loader test failing due to changes in libxml2. (The code moved from sasview to sasdata upstream but there's no release removing it from sasview yet, hence the duplication) The upstream tests fail with libxml2 from unstable (2.12). The patched tests fail with libxml2 in testing (2.9). The migration autopkgtests therefore fail because they are not attempted with the newer libxml2. libxml2 also doesn't look like it will migrate any time soon (#1073508). The xsd [1] for recognising partly broken cansas files is to blame - the multiple xsd:any entries in it make it ambiguous. [1] sasdata/dataloader/readers/schema/cansas1d_invalid_v1_0.xsd A test to run outside of the test harness is: xmllint --noout \ --schema sasdata/dataloader/readers/schema/cansas1d_invalid_v1_0.xsd \ test/sasdataloader/data/cansas1d_notitle.xml A namespace warning is OK; a "content model is not determinist" error or a "Schemas validity error" is not. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1072142:
Same issue here, fixed by installing libnvidia-egl-wayland1 and rebooting, should some part of the driver depend on this package?
Bug#1062800: RFP: pyside6 -- Qt6 for Python
Control: retitle 1062800 ITP: pyside6 -- Qt6 for Python There is substantial work towards packaging at: https://salsa.debian.org/qt-kde-team/qt6/pyside6 The package is built for Qt 6.6 which is in experimental; the package is approximately ready for upload to NEW. Maintainers who know the Qt stack and understand the details of how pyside works are desperately needed. Please join the Qt/KDE packaging team (if not already a member) and add yourself to d/control! -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1070479: gaupol: Please package new upstream release (1.14.1)
Source: gaupol Version: 1.11-2 Severity: wishlist X-Debbugs-Cc: stu...@debian.org Dear Maintainer, There have been a few upstream releases of gaupol in the last two years. There are small changes to the handling of subtitle files in python3-aeidon which translate-toolkit upstream has already adjusted to; I therefore either need to back-out some of these changes from translate-toolkit in order for it to work with the older python3-aeidon, or get python3-aeidon updated. Piotr, are you happy for a Team Upload of the new version of gaupol? Anything to watch out for? translate-toolkit appears to be the only reverse-dependency to check. regards Stuart
Bug#1069357: cpp-httplib: FTBFS on arm64: dh_auto_test: error: cd obj-aarch64-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test --timeout-multiplier=3 --test-arg
Hi Andrea Gentle ping on this bug - there are a few packages lined up for autoremoval and/or can't migrate due to this bug. Looking at the test suite, there seems to be three tests (all within SSLClientServerTest) that now hang on multiple architectures. I don't think this is simply a matter of increasing the timeout on the test as these seem to sit for 15 minutes with no CPU activity. The tests fail not only on arm64 as reported in this bug but also on amd64 and i386, both on salsa-ci and tested locally by me. Skipping these tests by extending the test filter in d/rules is enough to get the package to build; I have not investigated what is leading to these tests failing. --gtest_filter=-*_Online:*ClientCertPresent*:*TrustDirOptional*:*CustomizeServerSSLCtx* Of course skipping failing tests may well build a broken package — I don't know this package well enough to make a judgement call on that, hence I have not NMUd to skip the tests. Please let me know if you think it is indeed appropriate and would like me to NMU the above change. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1068390: src:translate-toolkit: unsatisfied build dependency in testing: python3-levenshtein
Update: - python3-levenshtein is now fixed in unstable - python-levenshtein can't migrate because of a long chain that gets back to #1069357 (cpp-httplib: FTBFS on arm64). -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1070215: python-qtpy: Please support qtpy abstraction in packaging
Source: python-qtpy Version: 2.4.1-2 Severity: normal X-Debbugs-Cc: stu...@debian.org Dear Maintainer, The qtpy description says "Abstraction layer for PySide2/PySide6/PyQt5/PyQt6" however the packaging for python3-qtpy is optimised only for applications using PyQt5, declaring Depends on all the python3-pyqt5 packages. An application that uses qtpy and any library other than pyqt5 needs to have pyqt5 installed in addition to what is actually required. As a concrete example, the next version of sasview will need PySide6 for Qt6 while using qtpy (via superqt widgets). The current packaging of qtpy means that 'apt install sasview' will end up installing PySide6 and Qt6 via sasview's own dependencies plus also PyQt5 and Qt5 via python3-qtpy's dependencies. One possible solution to this would be for src:python-qtpy to include the following packages: Package: python3-qtpy Depends: python3-packaging Contains: everything Package: python3-qtpy-pyqt5 Depends: python3-qtpy, python3-pyqt5, python3-pyqt5.* Contains: probably nothing Package: python3-qtpy-pyqt6 Depends: python3-qtpy, python3-pyqt6, python3-pyqt6.* Contains: probably nothing Package: python3-qtpy-pyside6 Depends: python3-qtpy, python3-pyside6.* Contains: probably nothing Another solution is for python-qtpy to declare at most Suggests on any of the pyqt/pyside packages and leave it to the application to declare dependencies on the toolkit packages it needs. The application package knows what toolkit and libraries are required while, by design, qtpy does not. This would also provide better support for the split toolkit packages given that Qt5 and Qt6 are modularised - the application can depend on only what is needed rather than having all the split packages installed just in case. PySide6 will hit NEW soon-ish and sasview will need the updated packaging for qtpy soon after. I'm happy to do a Team Upload to implement whichever agreed strategy you prefer. thanks! Stuart
Bug#1069738: python-bumps: please package v0.9.2 and remove the python3-six dependency
Hi Alexandre The only user of bumps in Debian is sasview and their releases tend to be coordinated. I tend to avoid upgrading them in Debian independently of each other. However SasView 6 is still some way off and will be even further off in Debian due to its dependency on pyside6 (which is a beast that is half-packaged and ftbfs still) I'll look at whether old-sasview and new-bumps will be happy with each other. Most of the 0.9.x releases of bumps are compatibility patches for numpy/scipy/matplotlib that we're already carrying as patches in the Debian package anyway. thanks for your contribution to removing six! Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1065327: ITA: python-levenshtein
On Fri, 15 Mar 2024 14:21:17 + Julian Gilbey wrote: > On Fri, Mar 15, 2024 at 10:03:44AM -0400, Louis-Philippe Véronneau wrote: > Quick update, having taken a peek at the package: the version > currently in unstable is quite old - it is a version that did not > require rapidfuzz. So I will leave it as-is until rapidfuzz makes it > into testing (which may be some time), and then it can be updated. I see rapidfuzz has cleared NEW. In the interest of making some progress towards the autoremovals that are queued up behind levenshtein's removal from testing, I've updated levenshtein in git as a Team Upload and uploaded the package to experimental. It now needs to clear NEW itself (since it has grown a -doc package now that it has more extensive documentation via sphinx). Once levenshtein has cleared NEW and landed in experimental, we'll be able to see how rdeps go with the new version too, prior to pushing such a big update to unstable. Prior to landing in unstable, it should get some humans listed in Uploaders too. I wasn't sure who really wanted their name in there and since no-one had done so in git yet, I didn't make assumptions about who that would be. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1064180: RM: virtaal -- ROM; Not developed upstream and very broken
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: virt...@packages.debian.org, stu...@debian.org Control: affects -1 + src:virtaal The virtaal source package has not seen upstream development for a few years. There was a flurry of work to try to update it to Python 3 and gtk3 that was never really completed. A mostly-working preview was uploaded in 2019 but changes in gtk3 since then leave it as a mostly-non-working version. It's time to say farewell to virtaal - at least for the time being. If upstream development restarts, then it's easy to reintroduce it. For users looking for alternatives: - poedit is a capable desktop application - weblate is a capable web app regards Stuart
Bug#1063935: stac-validator: Vcs-Git field points to wrong repo
Source: stac-validator Version: 3.3.2+ds-2 Severity: wishlist X-Debbugs-Cc: stu...@debian.org Dear Maintainer, The Vcs-Git/Vcs-Browser fields in debian/control for this package point to the upstream development repository. They should instead point to the Debian packaging repository: https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-vcs-fields Vcs-Browser: https://github.com/stac-utils/stac-validator Vcs-Git: https://github.com/stac-utils/stac-validator.git vs https://salsa.debian.org/debian-gis-team/stac-validator/ regards Stuart
Bug#1060876: latexmk: Homepage has moved
Package: latexmk Version: 1:4.79-1 Severity: minor X-Debbugs-Cc: stu...@debian.org Dear Maintainer, The web site listed in the Homepage field of latexmk indicates that the project has moved: > On July 28, 2023, the Personal web server was retired as a service. This > change aligns with the retirement of the PASS service upon which it depended > to store web content. > > ACTION: Please update your bookmarks before July 28, 2025. The page offers a new URL for the site that is incorrect. The new site is: https://www.cantab.net/users/johncollins/latexmk/index.html The URL in d/watch will also need updating. regards Stuart
Bug#1060699: qt6-base-dev: Qt6ExampleIconsPrivateConfig.cmake relies on files missing from package
Package: qt6-base-dev Version: 6.6.1+dfsg-5 Severity: normal X-Debbugs-Cc: stu...@debian.org Dear Maintainer, The two cmake files: /usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateConfig.cmake /usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateTargets.cmake contain references to files that do not exist within any packages, the result being that cmake errors out if trying to use them: --- 8< --- 8< --- 8< --- 8< --- CMake Error at /usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateTargets.cmake:116 (message): The imported target "Qt6::ExampleIconsPrivate_resources_1" references the file "/usr/lib/x86_64-linux-gnu/objects-None/ExampleIconsPrivate_resources_1/.rcc/qrc_example_icons.cpp.o" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/x86_64-linux-gnu/cmake/Qt6ExampleIconsPrivate/Qt6ExampleIconsPrivateConfig.cmake:62 (include) /usr/lib/x86_64-linux-gnu/cmake/Qt6/Qt6Config.cmake:166 (find_package) sources/pyside6/qtexampleicons/CMakeLists.txt:15 (find_package) --- 8< --- 8< --- 8< --- 8< --- (discovered while playing around with pyside6 6.6.1 as you can see from that trace) The files it is looking for are in unusual directories so I'm not sure if there is more to it than just missing the files from the package. I noticed that Gentoo has the same issue which also seems to be unresolved. https://bugs.gentoo.org/915587#c6 cheers Stuart
Bug#1059978: rosegarden: team uploading and git committed changes
Hi Gianfranco On 08/01/2024 23:01, Gianfranco Costamagna wrote: I've prepared an Team upload for rosegarden (versioned as 1:22.12.1-2) and uploaded it to DELAYED/15. Please feel free to tell me if I should delay it longer. Excellent - many thanks for the patch, commit to git, and upload! cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1059076: duplicity: --version returns $version, instead of an actual version
Package: duplicity Version: 2.1.4-1 Severity: normal X-Debbugs-Cc: stuart.a.hayhu...@gmail.com Dear Maintainer, Running 'duplicity --version' returns 'duplicity $version', causing packages that rely on this to detect the version to fall over (e.g. deja-dup) Only occurs since the latest update to sid Thanks, Stuart -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages duplicity depends on: ii gnupg 2.4.3-2 ii libc6 2.38-3 ii librsync2 2.3.4-1 ii python3 3.11.6-1 ii python3-fasteners 0.18-2 ii python3-setuptools-scm 8.0.4-1 ii python3.11 3.11.7-2 Versions of packages duplicity recommends: ii python3-oauthlib 3.2.2-1 ii python3-paramiko 2.12.0-2 ii python3-pexpect 4.8.0-4 ii python3-urllib3 1.26.18-1 ii rsync 3.2.7-1 Versions of packages duplicity suggests: pn lftp pn ncftp pn par2 pn python3-boto ii python3-pip 23.3+dfsg-1 pn python3-swiftclient pn tahoe-lafs -- no debconf information
Bug#1058934: apt install ./foo.deb re-downloads the package
Package: apt Version: 2.7.7 Severity: normal X-Debbugs-Cc: stu...@debian.org,umlae...@debian.org Dear Maintainer, It was observed in #debian pointed out today that "apt install ./foo.deb" was downloading the .deb again from the mirror: $ apt download hello $ sudo apt install ./hello_2.10-3_amd64.deb Reading package lists... Done Building dependency tree... Done Reading state information... Done Note, selecting 'hello' instead of './hello_2.10-3_amd64.deb' The following NEW packages will be installed: hello 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 53.1 kB of archives. After this operation, 284 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian sid/main amd64 hello amd64 2.10-3 [53.1 kB] Fetched 53.1 kB in 0s (1,899 kB/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package hello. (Reading database ... 184783 files and directories currently installed.) Preparing to unpack .../hello_2.10-3_amd64.deb ... Unpacking hello (2.10-3) ... Setting up hello (2.10-3) ... Processing triggers for man-db (2.12.0-1) ... On the test machine, apt is using a proxy server whose logs confirmed that apt redownloaded the file even though it was supposed to use the local file. This is a regression since bookworm. I don't know how apt decides that the remote file is the better one to use (presumably the usual hash of certain fields?). When manually repacking the .deb for testing (and getting a different sized .deb as a result), apt no longer attempted to download and instead used the local version: Get:1 /tmp/pkgs/hello/hello_2.10-3_amd64.deb hello amd64 2.10-3 [53.0 kB] (I've repacked hello with a modified file and reused the version string just for the perversity of the test.) regards Stuart
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#1057878: qa.debian.org: UDD upload_history has truncated email addresses
Package: qa.debian.org Severity: normal X-Debbugs-Cc: stu...@debian.org The 'maintainer' and 'maintainer_email' columns of the upload_history table in UDD have truncated email addresses. Somewhere the 'maintainer' data is being truncated and then the maintainer_email is consequently broken. udd=> SELECT maintainer, maintainer_email FROM upload_history WHERE maintainer_email LIKE '%=' LIMIT 10; maintainer | maintainer_email +-- Maintainers of GStreamer packages https://lists.debian.org/debian-devel-changes/2007/12/msg00466.html udd=> SELECT maintainer, maintainer_email FROM upload_history WHERE maintainer_email LIKE '%=' AND source = 'libxml-rss-perl' AND version = '1.31-3'; maintainer | maintainer_email +- Debian Perl Group
Bug#1057432: python3-aiostream: Package still contains coverage output
Package: python3-aiostream Version: 0.5.2-1 Severity: important X-Debbugs-Cc: stu...@debian.org Dear Maintainer, In version 0.5.2-1, there is an attempt to remove coverage outputs from the binary package. Unfortunately, this is ineffective when there is more than one Python interpreter in the archive. The coverage output is originally in an interpreter-specific directory debian/*/usr/lib/python3.x/dist-packages, and then dh_python3 moves it to debian/*/usr/lib/python3/dist-packages/ only if the files are identical. If the files differ for each interpreter, then dh_python3 complains loudly and leaves them where they are. execute_after_dh_python3: # Drop cov-generated files rm -fv debian/*/usr/lib/python3/dist-packages/.coverage rm -fvr debian/*/usr/lib/python3/dist-packages/htmlcov When python3-all started to include python3.12 as a supported interpreter, these files came back, for example: 2 usr/lib/python3.12/dist-packages/htmlcov/d_880e183adc9afb61___init___py.html 3 usr/lib/python3.12/dist-packages/htmlcov/d_880e183adc9afb61_advanced_py.html 4 usr/lib/python3.12/dist-packages/htmlcov/d_880e183adc9afb61_aggregate_py.html 5 usr/lib/python3.12/dist-packages/htmlcov/d_880e183adc9afb61_combine_py.html Widening the removal pattern to be 'python3*' is sufficient. (Perhaps dh_python3 should add these directories to its list of well-known directories to not include in the package.) Thanks to Paul Gevers for noticing this in various tests with britney to include reproducibility output in migrations.
Bug#1055919: python-ansible-pygments: please make the build reproducible
Control: clone 1055919 -1
Control: reassign -1 dh-python 5.20230130+deb12u1
Making a clone of this bug for dh-python to track it getting fixed
there; MR to come.
Context:
On Thu, 16 Nov 2023 17:33:58 +1100 Stuart Prescott
wrote:
> tldr: smells like a dh-python bug - I'll look at it more and reassign
> etc later.
>
>
> Staring at some build logs some more:
>
> * the dirs are generated always
> * they get copied from .../.pybuild to ../debian/$package/ always
> * they are supposed to get removed by dh_python3
> * that removal is not always working
>
> A common theme of the failures is that there are _two_
> /usr/lib/python3.11/dist-packages/.foo directories to remove and only
> one of them is being removed. For python-ansible-pygments, .pytest_cache
> was being removed by dh-python3 but .test-results was not.
>
> Adding in PYBUILD_VERBOSE=1 and some breakpoints into dh-python
> (specifically /usr/share/dh-python/dhpython/fs.py), I think there's a
> subtle bug about altering `dirs` while inside a loop from `os.walk`:
>
> for name in dirs:
> if name in ('test', 'tests') or name.startswith('.'):
> log.debug('removing dist-packages/%s', name)
> rmtree(join(root, name))
> dirs.remove(name)
>
> Removing `name` from `dirs` means that the next item is accidentally
> skipped. A classic "don't change the object you're iterating through
> while you are iterating through it" issue:
>
> In [1]: L = list(range(0, 10))
>
> In [2]: for i in L:
> ...: print(i)
> ...: L.remove(i)
> ...:
> 0
> 2
> 4
> 6
> 8
>
> Which item is not processed in the next iteration by dh_python3 now
> depends on the order in which `os.walk` lists the directories. That is
> presumably dependent on all manner of things (filesystem? collation?
> luck?). On the r-b setup and building by hand I get different results to
> within sbuild (and on the buildd).
>
> In sbuild on ext4, `find -type d` (I have memory that this reflects disk
> order?) has an order in
> ./debian/python3-ansible-pygments/usr/lib/python3.11/dist-packages of:
>
> .test-results ansible_pygments .pytest_cache
>
> while building by hand on tmpfs, I get
>
> ansible_pygments .test-results .pytest_cache
>
> For the former, accidentally skipping the directory after the one that
> gets removed isn't an issue, but for the latter it is.
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1055919: python-ansible-pygments: please make the build reproducible
tldr: smells like a dh-python bug - I'll look at it more and reassign
etc later.
Staring at some build logs some more:
* the dirs are generated always
* they get copied from .../.pybuild to ../debian/$package/ always
* they are supposed to get removed by dh_python3
* that removal is not always working
A common theme of the failures is that there are _two_
/usr/lib/python3.11/dist-packages/.foo directories to remove and only
one of them is being removed. For python-ansible-pygments, .pytest_cache
was being removed by dh-python3 but .test-results was not.
Adding in PYBUILD_VERBOSE=1 and some breakpoints into dh-python
(specifically /usr/share/dh-python/dhpython/fs.py), I think there's a
subtle bug about altering `dirs` while inside a loop from `os.walk`:
for name in dirs:
if name in ('test', 'tests') or name.startswith('.'):
log.debug('removing dist-packages/%s', name)
rmtree(join(root, name))
dirs.remove(name)
Removing `name` from `dirs` means that the next item is accidentally
skipped. A classic "don't change the object you're iterating through
while you are iterating through it" issue:
In [1]: L = list(range(0, 10))
In [2]: for i in L:
...: print(i)
...: L.remove(i)
...:
0
2
4
6
8
Which item is not processed in the next iteration by dh_python3 now
depends on the order in which `os.walk` lists the directories. That is
presumably dependent on all manner of things (filesystem? collation?
luck?). On the r-b setup and building by hand I get different results to
within sbuild (and on the buildd).
In sbuild on ext4, `find -type d` (I have memory that this reflects disk
order?) has an order in
./debian/python3-ansible-pygments/usr/lib/python3.11/dist-packages of:
.test-results ansible_pygments .pytest_cache
while building by hand on tmpfs, I get
ansible_pygments .test-results .pytest_cache
For the former, accidentally skipping the directory after the one that
gets removed isn't an issue, but for the latter it is.
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1055919: python-ansible-pygments: please make the build reproducible
Hi Chris, Whilst working on the Reproducible Builds effort [0], we noticed that python-ansible-pygments could not be built reproducibly. This is because the binary package included .pytest_cache and .test-results directories. Patch attached that removes these after running the tests. I see those directories in the packages built on the r-b machines, but I don't see them in the package in the archive or when rebuilding the package locally. The files exist within the build tree but in /.pybuild/cpython3_3.11/build/ which does not get them installed. Is there something about the r-b setup that would cause these directories to be created and appear in the package? thanks Stuart $ apt download -t sid python3-ansible-pygments $ dpkg-deb --fsys-tarfile python3-ansible-pygments_0.1.1-6_all.deb | tar t ./ ./usr/ ./usr/lib/ ./usr/lib/python3/ ./usr/lib/python3/dist-packages/ ./usr/lib/python3/dist-packages/ansible_pygments/ ./usr/lib/python3/dist-packages/ansible_pygments/__init__.py ./usr/lib/python3/dist-packages/ansible_pygments/lexers.py ./usr/lib/python3/dist-packages/ansible_pygments/styles.py ./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/ ./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/METADATA ./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/RECORD ./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/WHEEL ./usr/lib/python3/dist-packages/ansible_pygments-0.1.1.dist-info/entry_points.txt ./usr/share/ ./usr/share/doc/ ./usr/share/doc/python3-ansible-pygments/ ./usr/share/doc/python3-ansible-pygments/changelog.Debian.gz ./usr/share/doc/python3-ansible-pygments/copyright ./usr/share/doc/python3-ansible-pygments/examples/ ./usr/share/doc/python3-ansible-pygments/examples/lexer_test.py -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Hi Hilmar On 08/11/2023 08:36, Hilmar Preuße wrote: On 10/30/23 11:52, Hilmar Preuße wrote: Hi Stuart, I was told not to use that URL, so here is a new one https://freeshell.de/~hille42/debian_1054218/ Did you find the time to test the fix? Hilmar Thanks for the upload — I've been able to test it, having been autobuilt on the buildd, and I confirm it solves the bug on s390x. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1054594: Downgrade to normal
Apols misread the severity, please downgrade to normal as only happens so far with the Speex plugin.
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Control: notfound -1 2020.20200327.54578-7+deb11u1 I don't recall if annotating as above actually helps the BTS at all... but for reference, since I was already fiddling about with schroot on zelenka.d.o, I tested this out in a bullseye s390x chroot and text extraction works fine. I suppose that in some way narrows it down to a regression somewhere between texlive 2020 and texlive 2022. That's probably not particularly 'narrow' but might help. regards Stuart (bullseye_s390x-dchroot)stuart@zelenka:~$ gs -q -sDEVICE=txtwrite -o %stdout% test.pdf |od -c 000 h 020 i \r \n 023 -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1054295: RFP: python-iconify -- Python wrapper for the Iconify API to load standard icons
Package: wnpp Severity: wishlist X-Debbugs-Cc: stu...@debian.org * Package name: python-iconify Version : 0.1.5 Upstream Contact: Talley Lambert https://github.com/tlambert03 * URL : https://github.com/pyapp-kit/pyconify * License : BSD 3-clause Programming Lang: Python Description : Python wrapper for the Iconify API to load standard icons Iconify is a versatile icon framework that includes 100+ icon sets with more than 100,000 icons from FontAwesome, Material Design Icons, DashIcons, Feather Icons, EmojiOne, Noto Emoji and many other open source icon sets. This package provides a simple Python wrapper around the Iconify API that fetches and caches icons for use by GUI applications. This package is an optional dependency of the most recent version of superqt; the QIconifyIcon class provides a QIcon that is backed by the specified iconify icon.
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Control: found -1 2022.20220321.62855-5.1+deb12u1 Well, assuming that it is a fault of the binary, I'd rather assign it to texlive-binaries: hille@debian:~$ ls -l /usr/bin/pdflatex lrwxrwxrwx 1 root root 6 Oct 8 22:00 /usr/bin/pdflatex -> pdftex hille@debian:~$ ls -l /usr/bin/pdftex -rwxr-xr-x 1 root root 2380944 Sep 14 23:27 /usr/bin/pdftex hille@debian:~$ dlocate /usr/bin/pdftex texinfo: /usr/bin/pdftexi2dvi texlive-binaries: /usr/bin/pdftex Ah, sure. I'd not spotted that detail of the packaging. Sorry for the confusion. Upstreams source code of texlive-binaries did not change since March. Since I've also shown that this bug is present in bookworm, I'll add the version of texlive-binaries from bookworm to the metadata to help future analysis see that this is not a more recent regression. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Control: found -1 2022.20230122-3 Hi Hilmar On 20/10/2023 01:13, Preuße, Hilmar wrote: On 19.10.2023 14:20, Stuart Prescott wrote: Hi Stuart, The unittests of the 'plastex' package run pdflatex to generate some figures, and then extract the text from the figures to verify that various implementation details of the package are working. These tests pass on all release architectures except s390x. They also fail on ppc64. The common feature of the failures is that the architecture is big-endian. As you opened the issue for texlive-latex-base I'm wondering if the issue caused by the latest texlive-latex-base upgrade. Do you remember if it worked 2 weeks ago? my assignment to texlive-latex-base was just on the basis of that shipping /usr/bin/pdflatex. I'm not familiar enough with the texlive packaging to know if it would be better assigned elsewhere, so please feel free to reassign. As for versions, I had only tested with the version in sid because that was where I was seeing the FTBFS. Testing with the quick reproducer (test.tex attached to the bug report) and texlive in bookworm shows the bug is also present there: (bookworm_s390x-dchroot)stuart@zelenka:~$ gs -q -sDEVICE=txtwrite -o %stdout% test.pdf |od -c 000 \0 020 \0 \r \n 023 (should be "hi" not "\0\0") I've added the bookworm version to the bug metadata. plastex 3.0 (now in sid) has a better test coverage than version 2.4 (that is in bookworm). I think the bug exists in the previous pdflatex version too (and I would guess that it has probably been there for a long time!) but we're only just seeing the test failure now because of the better test suite in the new plastex. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1054218: texlive-latex-base: pdflatex failures on big-endian architectures (s390x)
Package: texlive-latex-base
Version: 2023.20231007-1
Severity: normal
X-Debbugs-Cc: stu...@debian.org
Dear Maintainer,
The unittests of the 'plastex' package run pdflatex to generate some
figures, and then extract the text from the figures to verify that
various implementation details of the package are working. These tests
pass on all release architectures except s390x. They also fail on ppc64.
The common feature of the failures is that the architecture is
big-endian.
The failures are all similar to:
AssertionError: 'hi' != '\x00\x00'
i.e. the text that is found in the PDF (either by gs or pdftotext) is
the same number of bytes as the original text, but is all \0. The
extraction is platform-independent — the attached s390x.pdf yields \0\0
for its text no matter what arch pdftotext or gs is run on.
The PDFs all _look_ OK in any PDF viewer, it's just the text extraction
that fails.
If the pdf is generated via latex followed by dvipdf then the extracted
text is correct (up to whitespace); if the pdf is generated by lualatex
then he extracted text is correct.
It seems that pdflatex is mishandling embedding the text on big endian
systems. Speculating wildly... it looks a bit like pdflatex is taking
the wrong byte out of a multibyte character representation, and ending
up with \0 rather than the byte of interest, but I don't know how
pdflatex is representing the characters internally or how it is encoding
them into the PDF.
While I don't expect that there are many direct users of pdflatex on s390x,
testing migration within Debian now requires successful completion of
unittests on s390x, and so arch-specific bugs on s390x become relevant.
Attached:
test.tex (one of the little .tex files plastex generates in its tests)
amd64.pdf (output of "pdflatex test.tex" on amd64)
s390x.pdf (output of "pdflatex test.tex" on s390x)
(access to s390x and ppc64 courtesy of Debian's porter boxes
zelenka.debian.org and perotto.debian.net)
regards
Stuart
amd64.pdf
Description: Adobe PDF document
s390x.pdf
Description: Adobe PDF document
\nonstopmode\AtBeginDocument{\thispagestyle{empty}}\documentclass{article}\usepackage{microtype}\DisableLigatures{encoding
= *, family = *}\begin{document}\newif\iffoo\footrue\iffoo hi\else
bye\fi\end{document}
Bug#1051781: python3-h5py: where is the egg files
Control: reopen -1
Hi Drew
On Thu, 28 Sep 2023 16:47:27 +0200 Drew Parsons wrote:
> Source: h5py
> Followup-For: Bug #1051781
>
> I'm reorganising the package with separate distinfo metadata for the
> different variants. I think this will fix your problem
I can't see the fixed files for this dist-info metadata in the updated
package:
$ dpkg-query -W python3-h5py
python3-h5py 3.9.0-1
$ dpkg -L python3-h5py
/.
/usr
/usr/share
/usr/share/doc
/usr/share/doc/python3-h5py
/usr/share/doc/python3-h5py/README.Debian
/usr/share/doc/python3-h5py/README.rst
/usr/share/doc/python3-h5py/changelog.Debian.gz
/usr/share/doc/python3-h5py/copyright
I *think* the issue is that the code to move the dist-info into this
package is within the "override_dh_auto_install-arch" target, but the
python3-h5py package is arch:all and so that target is never called on
the buildd.
Once this is fixed in trixie, can the fix for just this problem be
shipped as a stable-update? It potentially breaks plugin loading in lots
of places that want to address h5py by a string name rather than doing
`import h5py`.
BTW a simple test that it is all working is:
python3 -c "from importlib.metadata import distribution;
distribution('h5py')"
that currently fails in bookworm, trixie, and sid, but works fine if
h5py is installed via pip, and I think that is the crux of what Frederic
found in the discussion about silx.
regards
Stuart
Bug#1052991: apt: Missing Release File
Package: apt Version: 2.2.4 Severity: important X-Debbugs-Cc: stu...@gmail.com Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** My release Debian 11.7 sudo apt update - gives The repository 'http://archive.raspbian.org/raspbian stretch Release' no longer has a release file As I have a current version do not expect a missing file *** End of the template - remove these template lines *** -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "armhf"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::LastInstalledKernel "6.1.21-v8+"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Architectures ""; APT::Architectures:: "armhf"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir:
Bug#1052146: UDD: broken data from bugs-binpkgs-pts CGI script
On 18/09/2023 17:30, Paul Wise wrote: $ curl -sL https://udd.debian.org/cgi-bin/bugs-binpkgs-pts.cgi | grep -vP '^(?:src:)?[-a-z0-9.+]+ [0-9]+ [0-9]+ [0-9]+ [0-9]+ [0-9]+$' 115.2.0esr-1severity: 0 1 0 0 0 criticalupdate 0 1 0 0 0 firefox-esr version: 0 1 0 0 0 ng/dl. debian 0 1 0 0 0 trixie's 0 1 0 0 0 I don't think the BTS or UDD are broken here, I think that's just #1052073 which has some very interesting metadata that might take some time to clean up... -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1044062: python-mistletoe: Please upgrade to new upstream version (1.1.0)
Source: python-mistletoe Version: 0.8.2-1 Severity: wishlist X-Debbugs-Cc: stu...@debian.org Dear Maintainer, The package translate-toolkit has recently picked up mistletoe as a dependency; it unfortunately needs a newer version of mistletoe than is currently available in Debian, which prevents upgrading translate-toolkit. Please consider uploading python-mistletoe 1.1.0 to Debian. Thanks Stuart
Bug#1042806: libllvm14: SIGILL Illegal Instructions on POWER5 in libLLVM-14.so
Package: libllvm14 Version: 1:14.0.6-12 Severity: critical Justification: breaks unrelated software Hello, I think the libLLVM-14 contains some instructions not found on IBM POWER5+ (gs) -- vxor is not found in it's IBM reference manual: https://www.ibm.com/docs/en/ssw_aix_72/assembler/assembler_pdf.pdf Maybe this library was built for more recent CPUs but the debian ppc64 support goes back to POWER5 AFAIK(?) $ objdump --disassemble /lib/powerpc64-linux-gnu/libLLVM-14.so.1 |grep vxor As a result there is some difficulty running applications linked to libLLVM, for example rust installation fails with SIGILL, there are likely other affected programs. Thank you Stuart -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: ppc64 Kernel: Linux 5.15.123 (SMP w/2 CPU threads) Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8), LANGUAGE=en_NZ:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libllvm14 depends on: ii libc6 2.37-6 ii libedit23.1-20221030-2 ii libffi8 3.4.4-1 ii libgcc-s1 13.2.0-1 ii libstdc++6 13.2.0-1 ii libtinfo6 6.4+20230625-2 ii libxml2 2.9.14+dfsg-1.3 ii libz3-4 4.8.12-3.1 ii zlib1g 1:1.2.13.dfsg-1 libllvm14 recommends no packages. libllvm14 suggests no packages. -- no debconf information
Bug#1037083: wget: man page lists 'metalink' options but binary not compiled with metalink support
Package: wget Version: 1.21.3-1+b2 Severity: minor X-Debbugs-Cc: stu...@debian.org Dear Maintainer, A user in #debian on irc.debian.org was asking about how to use wget to download from metalink files. The man page describes the following metalink options: --input-metalink=file --metalink-over-http --metalink-index=number but the binary doesn't know about them: wget: unrecognized option '--input-metalink' because it hasn't been compiled with metalink support: wget --version … -metalink … Please update the documentation to match the package compilation options. Thanks! Stuart -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing-proposed-updates'), (500, 'testing-debug'), (500, 'testing'), (60, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-9-amd64 (SMP w/4 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wget depends on: ii libc6 2.36-9 ii libgnutls30 3.7.9-2 ii libidn2-0 2.3.3-1+b1 ii libnettle83.8.1-2 ii libpcre2-8-0 10.42-1 ii libpsl5 0.21.2-1 ii libuuid1 2.38.1-5+b1 ii zlib1g1:1.2.13.dfsg-1 Versions of packages wget recommends: ii ca-certificates 20230311 wget suggests no packages. -- no debconf information
Bug#932957: Please migrate Release Notes to reStructuredText
Hi Holger Thanks for working on this :) - The list of archs is hardcoded in the Makefile for now. The following might provide you with some useful way of not hard-coding such information: curl -s 'https://api.ftp-master.debian.org/suite/bookworm' (pipe that into « jq -r '.architectures[]' » to get just the archs as plain text) You might want to make that a 'maintainer-run' step rather than is run occasionally as part of preparing a release, rather than as a build time step. That is, the maintainer runs that from a machine with internet access to find the list of archs that should be used; this is then cached in the repo until it is next refreshed. There is precedent for this 'maintainer-run' step in various "make dist' mechanisms (from the autotools world) and how the dh-python packages prepares a cache of known python modules in the archive for later module→package translation. There has been talk for a while about how we might avoid baking in internal metadata in packages and there might be more inspiration on how to do this in other parts of the project: https://wiki.debian.org/SuitesAndReposExtension (there are already a couple of entries there for the release notes) cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1034077: debian-security-support: Lots of noise about DEBIAN_VERSION 12 being invalid when upgrading bullseye→bookworm
Following up the conversation in #d-release... Looking at some released versions of /usr/bin/check-support-status: - buster (10.13, 1:10+2022.08.23) has DEB_NEXT_VER_ID=11 - bullseye (11.6, 1:11+2022.08.23) has DEB_NEXT_VER_ID=11=11 - bookworm (to be 12.0, 1:12+2023.03.17) has DEB_NEXT_VER_ID=12 Looking at older releases (prior to the change in versioning scheme) is a bit harder; the value of DEB_NEXT_VER_ID also seems to increment several times during the life of a release, which perhaps muddies the analysis. Backporting the entire package and incrementing that number during the life of the release would also be why this has not been seen in the past, I guess. Based on the comment "# Version ID for next Debian stable", my assumption is that this should be the version number of the release that follows the stable release in which d-s-s is found. That is to say, the comment and code makes it look like DEB_NEXT_VER_ID=12 would have been right for bullseye and DEB_NEXT_VER_ID=13 would be right for bookworm. Incrementing to DEB_NEXT_VER_ID=12 in the next bullseye point release seems reasonable to me; also incrementing in bookworm to DEB_NEXT_VER_ID=13 would be logical. Rather than having base-files predepend on d-s-s, I suspect apt could be convinced to upgrade them in the right order by having base-files conflict (or perhaps break?) the 1:11+2022.08.23 version of d-s-s, with a fixed version in bullseye or the upgraded version in bookworm both being OK. I haven't looked at the code paths to check if this warning is 'only' cosmetic or if it also causes d-s-s to stop working. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1029727: python-debian: please depend on zstd
Hi folks On 27/01/2023 06:17, Jelmer Vernooij wrote: On Thu, Jan 26, 2023 at 07:49:28PM +0100, Gianfranco Costamagna wrote: Hello, I see dh-cmake FTBFS in Ubuntu due to this: An update from the python-debian side - in git, all the packages that were in Recommends were moved to Suggests. Libraries recommending packages has always been something I thought was odd - a library is always being driven by some calling code that knows whether it needs certain features and so it needs to take responsibility for ensuring that optional dependencies are present. In the case of dh-cmake, it feels to me like dh-cmake knows that it is going to manipulate .deb files and for that, the optional dependencies to do so should be installed too (zstd). In the same way something that knows it wants to check gpg signatures on Release files should ask for gpgv to be installed so that the deb822 module can oblige. Asking dpkg to do the decompression rather than zstd would also be plausible (based on dpkg-deb --fsys-tarfile and --ctrl-tarfile). However, I think that would be a substantial rewrite of the way the DebPart class is built and, for the purposes of portability, we'd want the pure python methods to still work (except Ubuntu deb files). I'd be happy to see a patch that tried but I suspect it would be too invasive for bookworm at this stage. It's hard to see a way of avoiding a delta somewhere between Debian and Ubuntu, either by having dh-cmake or python3-debian drag in zstd. My suggestion is that it should be with dh-cmake since that is what needs zstd, not all the myriad other uses of python3-debian. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1029731: libglapi-mesa: Apps fail with 'DRM_IOCTL_MODE_CREATE_DUMB failed: Cannot allocate memory' after upgrade from 22.3.2-1 to 22.3.3-1
Hi All, Just a note that it looks like this patch got picked up in the 22.3.6 release that just went out. On Thu, 23 Feb 2023 at 06:03, Diederik de Haas wrote: > Control: tag -1 upstream fixed-upstream patch > > On Tue, 31 Jan 2023 01:19:54 +0300 Andrey Skvortsov > wrote: > > Here is link to created upstream issue. > > https://gitlab.freedesktop.org/mesa/mesa/-/issues/8198 > > In https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21330 this > issue > got fixed upstream and I've attached the patch/diff to this message. > > When adding it to debian/patches and adding it to debian/patches/series > and > running `debian/rules patch`, it applies cleanly (which is not the case > for > all of them): > > ``` > me@laptop:~/dev/debian/salsa/xorg-team/lib/mesa$ debian/rules patch > dh patch --with quilt \ > --builddirectory=build/ \ > --buildsystem=meson >dh_quilt_patch -O--builddirectory=build/ -O--buildsystem=meson > Applying patch 07_gallium-fix-build-failure-on-powerpcspe.diff > patching file src/gallium/include/pipe/p_config.h > > Applying patch path_max.diff > patching file src/util/tests/cache_test.cpp > Hunk #1 succeeded at 82 (offset 1 line). > patching file src/util/tests/process_test.c > patching file src/gallium/auxiliary/pipe-loader/pipe_loader.c > Hunk #1 succeeded at 42 (offset -1 lines). > > Applying patch src_glx_dri_common.h.diff > patching file src/glx/dri_common.h > Hunk #1 succeeded at 57 (offset 2 lines). > > Applying patch bug102973-lima.diff > patching file src/gallium/drivers/lima/lima_resource.c > > Now at patch bug102973-lima.diff > ``` > > HTH -- Stuart Young (aka Cefiar)
Bug#1031162: task-gnome-desktop: Libreoffice is configured to open all text documents on default gnome desktop
Package: task-gnome-desktop Version: 3.71 Severity: normal Dear Maintainer, After a fresh install of bullseye from di-bookworm-alpha1 netinst, all text documents on the system (such as README.Debian, or .ssh/config) open with Libreoffice Writer by default. This doesn't seem desirable, I think it used to be gedit. I'm also not sure how to change this globally. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages task-gnome-desktop depends on: ii gnome-core1:42+8 ii task-desktop 3.71 ii tasksel 3.71 Versions of packages task-gnome-desktop recommends: ii gnome 1:42+8 ii hunspell-en-us 1:2020.12.07-2 ii hyphen-en-us2.8.8-7 ii libreoffice-calc4:7.4.5-2 ii libreoffice-gnome 4:7.4.5-2 ii libreoffice-help-en-us 4:7.4.5-2 ii libreoffice-impress 4:7.4.5-2 ii libreoffice-writer 4:7.4.5-2 ii mythes-en-us1:7.5.0-1 ii network-manager-gnome 1.30.0-2 ii synaptic0.91.2 task-gnome-desktop suggests no packages. -- no debconf information
Bug#1030572: ITP: python-countrynames -- Map country names to ISO codes
On 05/02/2023 20:46, Edward Betts wrote: * Package name: python-countrynames Version : 1.14.1 Upstream Author : Friedrich Lindenberg * URL : https://github.com/occrp/countrynames * License : MIT Programming Lang: Python Description : Map country names to ISO codes This library helps with the mapping of country names to their respective two or three letter codes. The idea is to incorporate common names for countries, and even some limited misspellings, as they occur in source data. . There is also support for fuzzy matching, which uses a heuristic based on Levenshtein distance. I plan to maintain this package as part of the Python team. I wonder if this upstream and pycountry would be interested in cooperating. Keeping multiple databases like these up to date is awkward. https://github.com/flyingcircusio/pycountry (pycountry uses Debian's iso-codes package for its data) regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1030008: virtaal: Should not be included in bookworm
Package: virtaal Version: 0.7.1+git20191021+ds1-2 Severity: serious Justification: Not in a fit state for bookworm X-Debbugs-Cc: stu...@debian.org Changes within gtk or its python bindings have left bookworm in a non-working state. Upstream activity is very limited and there is little prospect of the package being fixed in time for bookworm. This bug is to allow autoremovals to remove virtaal from bookworm and can be closed with the upload of a new upstream release that gets it back into shape.
Bug#1029816: wifi: mt76: mt7612u/mt7610u - 6.1.x hard locking systems
Source: linux Version: 6.1.4-1 Severity: important Dear Maintainer, My Netgear A6210 (Mediatek MT7612U) hard locks the system on login. If I instead log in via console, the first network access (such as ping) results in a kernel panic. I found this upstream bug report: http://lists.infradead.org/pipermail/linux-mediatek/2022-December/054010.html However it is unclear to me if or when the fix will be applied to the kernel. Best, Stuart -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Hi Diederik! On 27/01/2023 21:23, Diederik de Haas wrote: I did deliberately use 'version', while I'd normally use 'release' for these type of bugs ;-) :) Your suggestion is entirely sensible and it does no harm to start with the updated version as you say. I'm not sure there's any functionality in recent commits to help with the mass conversion you describe, but it does no harm. In order to adopt 'id3lib' (src:id3lib3.8.3): 1) I need to learn about Subversion, which hopefully is a bit easier *for me* as I had used and set up a Subversion server myself ... but that was certainly >10 YEARS ago, possibly close to 20. 2) I had rightly *guessed* there was an archive and 'muon' kindly pointed me to it ... the 'collab-maint' archive was (ofc) ~880 MB in size. ick. I pulled some things out of largeish svn repos for other teams and that was an unpleasant experience. 7) Actually do the conversion my experience was that this was not easy in itself with quite a few repos that were broken in some way, such as tags not being on branches, main not being continuous in strange ways. Almost every time I've tried it out, I've ended up running the process several times to improve the config or the options used, or the git post-processing. For a couple of packages, I decided to just ditch the svn repo and instead create a fresh git repo with all the historical uploads using gbp import-dscs --debsnap. There are some people who did some mass conversions of repos (python team, qt team for instance) - perhaps it is worth reaching out to them to find out how they did it and if their scripts are available. That might give you a head start. I don't recall who did these conversions but mailing list discussions from around the time of the move to salsa might help there, or just asking around on IRC. So I've now concluded that it's probably best to propose a mass-migration of the Alioth repos which haven't been converted yet (and uploaded to salsa). And that the Debian QA group is likely the best place to propose that. Hopefully there are also ppl there with more current Subversion knowledge and maybe even with converting SVN to Git. That's a huge task! That's definitely something to discuss on the mailing list before you get too far into it. It would be worth considering what to do with packages that are no longer in Debian at all, for instance. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1029743: svn-all-fast-export: New upstream version (1.0.18+git20221225)
Hi Diederik! On 27/01/2023 09:17, Diederik de Haas wrote: Package: svn-all-fast-export Version: 1.0.18+git20200501-1 Severity: wishlist It would be great if the latest version could be packaged for Debian. I recently had the need to retrieve a repo from the alioth archive and convert it to git. And this sounds like a great tool for that where upstream has even worked on the code in the last couple of years ;-) Anything that could make that task easier would be appreciated and a newer version of svn-all-fast-export may just help. Upstream doesn't often make releases and so the "new upstream" notification from the watch file is only about new commits being made to the upstream repo, not a new version being available. Most of the recent upstream activity has been about CI on GitHub and not actual changes to the package. Is there anything in the recent commits that would help you? I hadn't seen anything to justify updating the package but if there's something specific, please say and we can do it. regards Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1029513: xss-lock: crashes with core dump on activation
I think it's quite possible and even likely that this was the first time
running 0.3.0+git20220214.adafe4-2 I don't think I have logs going back far
enough to check the messages from the old version.
This all makes sense and failing to set the idle hint might actually
explain an issue I've been having where my monitor intermittently doesn't
go into power saving mode after the screen has been locked for hours.
I think the upstream pull request you made to update the example systemd
service file is probably the right way to go, maybe with an additional
comment in there saying you'll need to do `systemctl --user
import-environment XDG_SESSION_ID` in .xsessionrc or some other init file
that runs in your wm/de.
--
Stuart
On Wed, Jan 25, 2023 at 4:09 PM Ian Campbell wrote:
> On Mon, 2023-01-23 at 17:28 -0500, Stuart Freeman wrote:
> > I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the
> > issue after reading through #994762
> >
> > xss-lock had been working for over a year until as recently as a
> > couple days ago when I experienced a prolonged power outage that
> > forced a reboot, so I'm not sure if it was broken by some other
> > package updating and just hadn't been restarted until then or what.
>
> It is possible that the reboot caused you to actually run xss-lock
> 0.3.0+git20220214.adafe4-2 for the first time, even if as you say the
> upgrade might have been a long while before.
>
> It looks like the new upstream includes:
>
> https://github.com/wavexx/xss-lock/commit/7b0b4dc83ff3716fd3051e6abf9709ddc434e985
>
> Which adds the assert you are seeing triggered.
>
> In earlier versions the inability to connect to logind would have been
> ignored, you just wouldn't get the hints set.
>
> > It does seem to work after re-adding the XDG_SESSION_ID and
> > `systemctl --user import-environment XDG_SESSION_ID` but that doesn't
> > explain why it suddenly stopped being able to get the session id
> > (presumably from dbus).
>
> It looks like without -s the `GetSessionByPID` dbus method is called
> and with it `GetSession` is used instead (passing the value of the
> argument). You logs have:
>
> > GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not
> belong to any known session.
>
> Which seems to suggest GetSessionByPID was used and didn't work. I
> can't see anything different around that end of things. I suppose it is
> possible that this was never working for you, just previously it would
> silently not set the idle hint with logind and now it errors out.
>
> Do your systemd/journald arrangements mean you have logs from when you
> were running 0.3.0-10 or sooner? If so you might see that you had that
> message back then too, it was just non fatal. Actually I think #994762
> was about exactly that on an older version too.
>
> I think `systemctl --user import-environment XDG_SESSION_ID` is likely
> the right thing to be doing, at least for now, since it will result in
> you connecting to the logind session.
>
> The alternative would be to request that upstream revert the change I
> pointed to earlier or to otherwise make the requirement for logind
> optional somehow, although I'm not really sure what the implications of
> not giving hints to logind are...
>
> Ian.
>
Bug#1029513: xss-lock: crashes with core dump on activation
I actually added the `-s ${XDG_SESSION_ID}` while trying to debug the issue
after reading through #994762 <994...@bugs.debian.org>
xss-lock had been working for over a year until as recently as a couple
days ago when I experienced a prolonged power outage that forced a reboot,
so I'm not sure if it was broken by some other package updating and just
hadn't been restarted until then or what.
Without the `-s ${XDG_SESSION_ID}` I still get the core dump (that prompted
me to attempt adding it):
× xss-lock.service - X Session Lock
Loaded: loaded
(/home/stuart/.config/systemd/user/xss-lock.service; enabled; preset:
enabled)
Active: failed (Result: core-dump) since Mon 2023-01-23 17:05:52
EST; 16s ago
Duration: 3min 17.814s
Process: 3389 ExecStart=xss-lock -n /usr/libexec/xsecurelock/dimmer
-l -- xsecurelock (code=dumped, signal=ABRT)
Main PID: 3389 (code=dumped, signal=ABRT)
CPU: 121ms
Jan 23 17:02:35 gamera systemd[1469]: Started X Session Lock.
Jan 23 17:02:35 gamera xss-lock[3389]: Error getting session:
GDBus.Error:org.freedesktop.login1.NoSessionForPID: PID 3389 does not
belong to any known session
Jan 23 17:05:52 gamera xss-lock[3389]: xss-lock: ./src/xss-lock.c:469:
logind_session_set_locked_hint: Assertion `logind_session' failed.
Jan 23 17:05:52 gamera systemd-coredump[6948]: [🡕] Process 3389
(xss-lock) of user 1000 dumped core.
Stack trace of thread 3389:
#0 0x7fba5e596ccc
__pthread_kill_implementation (libc.so.6 + 0x8accc)
#1 0x7fba5e547ef2
__GI_raise (libc.so.6 + 0x3bef2)
#2 0x7fba5e532472
__GI_abort (libc.so.6 + 0x26472)
#3 0x7fba5e532395
__assert_fail_base (libc.so.6 + 0x26395)
#4 0x7fba5e540df2
__GI___assert_fail (libc.so.6 + 0x34df2)
#5 0x56156371cff7 n/a
(xss-lock + 0x3ff7)
#6 0x56156371d6cc n/a
(xss-lock + 0x46cc)
#7 0x56156371d8ee n/a
(xss-lock + 0x48ee)
#8 0x7fba5e78867f
g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f)
#9 0x7fba5e788a38 n/a
(libglib-2.0.so.0 + 0x54a38)
#10 0x7fba5e788cef
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#11 0x56156371c7e2 main
(xss-lock + 0x37e2)
#12 0x7fba5e53318a
__libc_start_call_main (libc.so.6 + 0x2718a)
#13 0x7fba5e533245
__libc_start_main_impl (libc.so.6 + 0x27245)
#14 0x56156371caf1
_start (xss-lock + 0x3af1)
Stack trace of thread 3393:
#0 0x7fba5e6080af
__GI___poll (libc.so.6 + 0xfc0af)
#1 0x7fba5e7889ae n/a
(libglib-2.0.so.0 + 0x549ae)
#2 0x7fba5e788acc
g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#3 0x7fba5e788b11 n/a
(libglib-2.0.so.0 + 0x54b11)
#4 0x7fba5e7b2cfd n/a
(libglib-2.0.so.0 + 0x7ecfd)
#5 0x7fba5e594fd4
start_thread (libc.so.6 + 0x88fd4)
#6 0x7fba5e61566c
__clone3 (libc.so.6 + 0x10966c)
Stack trace of thread 3396:
#0 0x7fba5e6080af
__GI___poll (libc.so.6 + 0xfc0af)
#1 0x7fba5e7889ae n/a
(libglib-2.0.so.0 + 0x549ae)
#2 0x7fba5e788cef
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#3 0x7fba5e9e4996 n/a
(libgio-2.0.so.0 + 0x118996)
#4 0x7fba5e7b2cfd n/a
(libglib-2.0.so.0 + 0x7ecfd)
#5 0x7fba5e594fd4
start_thread (libc.so.6 + 0x88fd4)
#6 0x7fba5e61566c
__clone3 (libc.so.6 + 0x10966c)
ELF object binary
architecture: AMD x86-64
Jan 23 17:05:52 gamera systemd[1469]: xss-lock.service: Main process
exited, code=dumped, status=6/ABRT
Jan 23 17:05:52 gamera systemd[1469]: xss
Bug#1029513: xss-lock: crashes with core dump on activation
Package: xss-lock
Version: 0.3.0+git20220214.adafe4-2
Severity: grave
Justification: renders package unusable
Calling `xdg-screensaver activate` causes xss-lock to dump core.
Output of `systemctl --user status xss-lock:
× xss-lock.service - X Session Lock
Loaded: loaded (/home/stuart/.config/systemd/user/xss-lock.service;
enabled; preset: enabled)
Active: failed (Result: core-dump) since Mon 2023-01-23 09:53:05 EST;
3min 55s ago
Duration: 17.084s
Process: 8434 ExecStart=xss-lock -s ${XDG_SESSION_ID} -n
/usr/libexec/xsecurelock/dimmer -l -- xsecurelock (code=dumped, signal=ABRT)
Main PID: 8434 (code=dumped, signal=ABRT)
CPU: 114ms
Jan 23 09:52:48 gamera systemd[1481]: Started X Session Lock.
Jan 23 09:52:48 gamera xss-lock[8434]: Error getting session:
GDBus.Error:org.freedesktop.login1.NoSessionForPID: Caller does not belong to
any known session.
Jan 23 09:53:05 gamera xss-lock[8434]: xss-lock: ./src/xss-lock.c:469:
logind_session_set_locked_hint: Assertion `logind_session' failed.
Jan 23 09:53:05 gamera systemd-coredump[8576]: [🡕] Process 8434 (xss-lock)
of user 1000 dumped core.
Stack trace of thread 8434:
#0 0x7f615a9d5ccc
__pthread_kill_implementation (libc.so.6 + 0x8accc)
#1 0x7f615a986ef2
__GI_raise (libc.so.6 + 0x3bef2)
#2 0x7f615a971472
__GI_abort (libc.so.6 + 0x26472)
#3 0x7f615a971395
__assert_fail_base (libc.so.6 + 0x26395)
#4 0x7f615a97fdf2
__GI___assert_fail (libc.so.6 + 0x34df2)
#5 0x55967f985ff7 n/a
(xss-lock + 0x3ff7)
#6 0x55967f9866cc n/a
(xss-lock + 0x46cc)
#7 0x55967f9868ee n/a
(xss-lock + 0x48ee)
#8 0x7f615abc767f
g_main_context_dispatch (libglib-2.0.so.0 + 0x5467f)
#9 0x7f615abc7a38 n/a
(libglib-2.0.so.0 + 0x54a38)
#10 0x7f615abc7cef
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#11 0x55967f9857e2 main
(xss-lock + 0x37e2)
#12 0x7f615a97218a
__libc_start_call_main (libc.so.6 + 0x2718a)
#13 0x7f615a972245
__libc_start_main_impl (libc.so.6 + 0x27245)
#14 0x55967f985af1
_start (xss-lock + 0x3af1)
Stack trace of thread 8438:
#0 0x7f615aa470af
__GI___poll (libc.so.6 + 0xfc0af)
#1 0x7f615abc79ae n/a
(libglib-2.0.so.0 + 0x549ae)
#2 0x7f615abc7acc
g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#3 0x7f615abc7b11 n/a
(libglib-2.0.so.0 + 0x54b11)
#4 0x7f615abf1cfd n/a
(libglib-2.0.so.0 + 0x7ecfd)
#5 0x7f615a9d3fd4
start_thread (libc.so.6 + 0x88fd4)
#6 0x7f615aa5466c
__clone3 (libc.so.6 + 0x10966c)
Warning: The unit file, source configuration file
or drop-ins of xss-lock.service changed on disk. Run 'systemctl --user
daemon-reload' to reload units.
Stack trace of thread 8440:
#0 0x7f615aa470af
__GI___poll (libc.so.6 + 0xfc0af)
#1 0x7f615abc79ae n/a
(libglib-2.0.so.0 + 0x549ae)
#2 0x7f615abc7cef
g_main_loop_run (libglib-2.0.so.0 + 0x54cef)
#3 0x7f615ae23996 n/a
(libgio-2.0.so.0 + 0x118996)
#4 0x7f615abf1cfd n/a
(libglib-2.0.so.0 + 0x7ecfd)
#5 0x7f615a9d3fd4
start_thread (libc.so.6 + 0x88fd4)
#6 0x7f615aa5466c
__clone3 (libc.so.6 + 0x10966c)
ELF object binary
architecture: AMD x86-64
Jan 23 09:53:05 gamera systemd[1481]: xss-lock.servic
Bug#1029116: hw-detect: check-missing-firmware fails will attempting to reload kernel module on MT7922 WiFi card
Source: hw-detect Version: 1.152 Severity: important X-Debbugs-Cc: stuart.a.hayhu...@gmail.com Running "Detect network interfaces" hangs the installer, and with a bit of troubleshooting, it's caused when check-missing-firmware removes and loads the kernel module for my WiFi chip (mt7921e driver) check-missing-firmware: removing and loading kernel module mt7921e Jan 17 21:16:49 check-missing-firmware: installing firmware package /media/firmware/firmware-misc-nonfree_20221214-3_all.deb Jan 17 21:16:53 check-missing-firmware: removing and loading kernel module mt7921e Jan 17 21:16:53 kernel: [ 1290.681036] [ cut here ] Jan 17 21:16:53 kernel: [ 1290.681044] WARNING: CPU: 0 PID: 6956 at kernel/workqueue.c:3066 __flush_work.isra.0+0x270/0x280 Jan 17 21:16:53 kernel: [ 1290.681066] Modules linked in: nls_ascii nls_cp437 vfat fat mt7921e(-) mt7921_common mt76_connac_lib mt76 mac80211 libarc4 cfg80211 rfkill isofs cdrom dm_mod sd_mod uas usb_storage scsi_mod scsi_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_acp6x_pdm_dma snd_soc_acp6x_mach snd_intel_sdw_acpi snd_soc_dmic snd_hda_codec snd_soc_core nvme snd_hda_core snd_compress snd_pci_acp6x snd_hwdep nvme_core snd_pcm xhci_pci sdhci_pci snd_timer t10_pi snd_pci_acp5x cqhci xhci_hcd hid_sensor_custom snd_rn_pci_acp3x crc64_rocksoft snd crc64 snd_acp_config sdhci hid_multitouch video snd_soc_acpi crc_t10dif hid_sensor_hub hid_generic usbcore mmc_core crc32_pclmul evdev i2c_hid_acpi snd_pci_acp3x usb_common soundcore i2c_hid crct10dif_common battery wmi hid Jan 17 21:16:53 kernel: [ 1290.681174] CPU: 0 PID: 6956 Comm: modprobe Tainted: GE 6.1.0-1-amd64 #1 Debian 6.1.4-1 Jan 17 21:16:53 kernel: [ 1290.681180] Hardware name: LENOVO 82QF/LNVNB161216, BIOS K5CN35WW 09/23/2022 Jan 17 21:16:53 kernel: [ 1290.681183] RIP: 0010:__flush_work.isra.0+0x270/0x280 Jan 17 21:16:53 kernel: [ 1290.681191] Code: 8b 04 25 c0 fb 01 00 48 89 44 24 40 48 8b 73 30 8b 4b 28 e9 e3 fe ff ff 40 30 f6 4c 8b 3e e9 21 fe ff ff 0f 0b e9 3a ff ff ff <0f> 0b e9 33 ff ff ff e8 b4 40 95 00 0f 1f 40 00 0f 1f 44 00 00 55 Jan 17 21:16:53 kernel: [ 1290.681195] RSP: 0018:aab880e8fc20 EFLAGS: 00010246 Jan 17 21:16:53 kernel: [ 1290.681199] RAX: RBX: 9a00d4257bd8 RCX: Jan 17 21:16:53 kernel: [ 1290.681202] RDX: 0001 RSI: RDI: aab880e8fc68 Jan 17 21:16:53 kernel: [ 1290.681204] RBP: 9a00d4257bd8 R08: R09: Jan 17 21:16:53 kernel: [ 1290.681206] R10: R11: 0001 R12: Jan 17 21:16:53 kernel: [ 1290.681207] R13: aab880e8fc20 R14: 0001 R15: c082c108 Jan 17 21:16:53 kernel: [ 1290.681210] FS: 7fd893d77740() GS:9a03afc0() knlGS: Jan 17 21:16:53 kernel: [ 1290.681213] CS: 0010 DS: ES: CR0: 80050033 Jan 17 21:16:53 kernel: [ 1290.681215] CR2: 7fd893e569f0 CR3: 00010171 CR4: 00750ef0 Jan 17 21:16:53 kernel: [ 1290.681218] PKRU: 5554 Jan 17 21:16:53 kernel: [ 1290.681220] Call Trace: Jan 17 21:16:53 kernel: [ 1290.681224] Jan 17 21:16:53 kernel: [ 1290.681233] __cancel_work_timer+0xff/0x190 Jan 17 21:16:53 kernel: [ 1290.681242] rfkill_unregister+0x3c/0xe0 [rfkill] Jan 17 21:16:53 kernel: [ 1290.681256] wiphy_unregister+0x66/0x3b0 [cfg80211] Jan 17 21:16:53 kernel: [ 1290.681315] ? _raw_spin_lock_irqsave+0x23/0x50 Jan 17 21:16:53 kernel: [ 1290.681323] ? _raw_spin_unlock_irqrestore+0x23/0x40 Jan 17 21:16:53 kernel: [ 1290.681327] ? skb_dequeue+0x6e/0x80 Jan 17 21:16:53 kernel: [ 1290.681334] ieee80211_unregister_hw+0xd4/0x100 [mac80211] Jan 17 21:16:53 kernel: [ 1290.681391] mt7921_pci_remove+0x44/0x110 [mt7921e] Jan 17 21:16:53 kernel: [ 1290.681401] pci_device_remove+0x36/0xa0 Jan 17 21:16:53 kernel: [ 1290.681409] device_release_driver_internal+0x1b2/0x230 Jan 17 21:16:53 kernel: [ 1290.681417] driver_detach+0x44/0x90 Jan 17 21:16:53 kernel: [ 1290.681420] bus_remove_driver+0x55/0xe0 Jan 17 21:16:53 kernel: [ 1290.681428] pci_unregister_driver+0x2a/0xb0 Jan 17 21:16:53 kernel: [ 1290.681434] __do_sys_delete_module+0x1d5/0x320 Jan 17 21:16:53 kernel: [ 1290.681442] do_syscall_64+0x5b/0xc0 Jan 17 21:16:53 kernel: [ 1290.681449] ? do_syscall_64+0x67/0xc0 Jan 17 21:16:53 kernel: [ 1290.681453] ? syscall_exit_to_user_mode+0x17/0x40 Jan 17 21:16:53 kernel: [ 1290.681457] ? do_syscall_64+0x67/0xc0 Jan 17 21:16:53 kernel: [ 1290.681460] ? do_syscall_64+0x67/0xc0 Jan 17 21:16:53 kernel: [ 1290.681464] ? fpregs_assert_state_consistent+0x22/0x50 Jan 17 21:16:53 kernel: [ 1290.681471] ? exit_to_user_mode_prepare+0x3c/0x1c0 Jan 17 21:16:53 kernel: [ 1290.681474] entry_SYSCALL_64_after_hwframe+0x63/0xcd Jan 17 21:16:53 kernel: [ 1290.681479] RIP: 0033:0x7fd893e838f7 Jan 17 21:16:53 kernel: [ 1290.681
Bug#1028576: RFA: malai -- Malai software architecture pattern in Java
Package: wnpp Severity: normal X-Debbugs-Cc: stu...@debian.org Control: affects -1 src:malai I request an adopter for the malai package. The package description is: libMalai is a Java implementation of the Malai architectural design pattern. Malai can be viewed as an major step beyond MVC where the controller has been completely rethought to consider modern evolutions of the interactivity of systems. Malai can also be viewed as MVP architecture focusing on modern concerns: - More and more interactivity in software systems (with more and more post-WIMP interactions) - Multi-platform development thanks to its modularity There's a new version of malai (and the main package that uses it, latexdraw) that need quite some work to get into Debian. These tools need someone who knows java, scala and their packaging ecosystems better than me. I'm quite happy to help new maintainers and sponsor uploads if needed. Stuart
Bug#1028575: RFA: latexdraw -- vector drawing program for LaTeX using PSTricks
Package: wnpp Severity: normal X-Debbugs-Cc: stu...@debian.org Control: affects -1 src:latexdraw I request an adopter for the latexdraw package. The package description is: LaTeXDraw is a free PSTricks code generator or PSTricks editor for LaTeX. It has the usual drawing tools (lines, rectangles, circles, Bezier curves) and can resize, rotate, move and join objects using vector transformations. LaTeXDraw uses SVG as its file format and figures can be exported as PSTricks code, pdf, eps, jpg, bmp, png, ppm. . PSTricks is an extension of LaTeX which allows the creation of drawings, diagrams and graphs in 2D or 3D. There's a new version of latexdraw (and the library it uses, malai) that need quite some work to get into Debian. These tools need someone who knows java, scala and their packaging ecosystems better than me. I'm quite happy to help new maintainers and sponsor uploads if needed. Stuart
Bug#969516: Please support installing onto f2fs root filesystem
Is there any update to this? I can't find the source anywhere to test it myself either.
Bug#1024718: Fwd: Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
-- Forwarded message - From: Stuart Date: Fri, Dec 23, 2022 at 1:53 PM Subject: Re: Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep To: Salvatore Bonaccorso Well it seems as of this message, it won't be accepted upstream due to their policy on not accepting quirks for issues fixed in firmware https://lore.kernel.org/all/20221221083102.ga23...@lst.de/ On Wed, Nov 23, 2022 at 7:55 PM Salvatore Bonaccorso wrote: > Hi Stuart, > > Thanks for the report! > > On Wed, Nov 23, 2022 at 06:31:48PM +, Stuart Hayhurst wrote: > > Source: linux > > Version: 5.19.6-1 > > Severity: important > > Tags: patch upstream > > X-Debbugs-Cc: stuart.a.hayhu...@gmail.com > > > > Dear Maintainer, > > > > The Samsung PM9B1 misreports its NID when resuming from sleep, > > causing the root filesystem to be unmounted, and the system left in > > an unstable state. Mostly this results in the device crashing, but > > if the device somehow continues running, it's incredibly unstable, > > where basically nothing works. It's an OEM drive found in some newer > > laptops (like my Lenovo Yoga 7 Gen 7) > > There's a bug report and patch upstream for this, but personally I > > think it might be a good idea to include it in Debian until it's > > accepted, as machines with this drive are near-unusable. > > Upstream issue: > https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ > > I've tested the patch against the current Debian 6.1-rc5 kernel on > > my laptop, and this fixes the problem without any other issues. > > On the other hand, we only should include it once we are fairly > confident that upstream accepts the fix and will include. > > Can you ping this bug once upstream maintainers have acked the change > and queued it? > > If you have tested the patch, then you can as well reply to the thread > mentioning you sucessfully tested the patch adding a Tested-by tag. > > Regards, > Salvatore >
Bug#987017: recommends 3 different ways to find obsolete packages, pick one
pend on whether the sources.list has been edited; we see that quite frequently in #debian, where someone has edited the sources.list for the upgrade and is then freaked out by absolutely every single package suddenly being 'not available'. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1024299: pythonmagick: b-d on python3-all-dev, but not built for all supported Python3 versions
Control: block -1 by 1025658 On Fri, 18 Nov 2022 17:53:28 +0200 Stefano Rivera wrote: > That's an easy fix. However... the resulting binary fails to import > under Python 3.11. That needs more debugging. Given the Build-Depends on libboost-python-dev, the failure to import will be #1025658 again. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025658: libboost-python1.74-dev: Python 3.11 changes break loading of boost-python using extensions
Package: libboost-python1.74-dev Version: 1.74.0-17+b2 Severity: serious Tags: patch Justification: Breaks reverse dependencies with Python 3.11 X-Debbugs-Cc: stu...@debian.org, debian-pyt...@lists.debian.org Dear Maintainer, Python 3.11 has changed some details around types and GC; boost's enum.cpp needs modifying to cope. The result of this change is that trying to load an extension compiled with Debian's boost 1.74 results in a C++ exception being thrown and, since not properly handled, the following rather obscure error: SystemError: initialization of $module raised unreported exception Further details courtesy of Alastair McKinstry's debugging work are to be found at https://bugs.debian.org/1024911#14 So far, we've spotted this problem in: cctbx: https://bugs.debian.org/1024859 ecflow: https://bugs.debian.org/1024911 python-pgmagick: https://bugs.debian.org/1023909 The attached patch is a (trivial) backport of the upstream change for this: https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 I've verified that the attached patch solves the Python 3.11 incompatibility of python-pgmagick, allowing it to successfully build, meaning that it is now able to load its boost-python extensions for the test suite. regards Stuart Description: Tweak enum for python 3.11 compatibility Backport upstream patch for compatibility with python 3.11 Origin: https://github.com/boostorg/python/commit/a218babc8daee904a83f550fb66e5cb3f1cb3013 --- a/libs/python/src/object/enum.cpp +++ b/libs/python/src/object/enum.cpp @@ -119,7 +119,6 @@ #if PY_VERSION_HEX < 0x0300 | Py_TPFLAGS_CHECKTYPES #endif -| Py_TPFLAGS_HAVE_GC | Py_TPFLAGS_BASETYPE, /* tp_flags */ 0, /* tp_doc */ 0, /* tp_traverse */
Bug#1022469: python-pint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13
Hi Michael
On 04/12/2022 03:50, Michael Banck wrote:
[...]
Looks like they got a work-around here in (since closed) PR #1401:
https://github.com/hgrecco/pint/commit/eb4e13428a3ede09148b76c71bc5b8cddb169176.patch
I was somewhat concerned that upstream abandoned that work rather than
merging it. I have a feeling all it does is fix the test failure without
actually fixing the underlying problems.
If I stick this (also attached) patch in, the testsuite passes fine.
I don't think it's enough for users of pint like superqt, however. The
superqt test suite's failures seem to need a newer pin to pick up other
compatibility changes with babel.
8< 8<
_ ERROR collecting
.pybuild/cpython3_3.11_superqt/build/tests/test_quantity.py _
/usr/lib/python3/dist-packages/pint/registry.py:575: in load_definitions
rbytes = importlib.resources.read_binary(__package__, file)
/usr/lib/python3.11/importlib/resources/_legacy.py:18: in wrapper
warnings.warn(
E DeprecationWarning: read_binary is deprecated. Use files() instead.
Refer to https://importlib-resource
s.readthedocs.io/en/latest/using.html#migrating-from-legacy for
migration advice.
During handling of the above exception, another exception occurred:
tests/test_quantity.py:3: in
from superqt import QQuantity
:1231: in _handle_fromlist
???
superqt/__init__.py:51: in __getattr__
from .spinbox._quantity import QQuantity
superqt/spinbox/_quantity.py:21: in
UREG = UnitRegistry()
/usr/lib/python3/dist-packages/pint/registry.py:143: in __call__
obj._after_init()
/usr/lib/python3/dist-packages/pint/registry.py:1976: in _after_init
super()._after_init()
/usr/lib/python3/dist-packages/pint/registry.py:305: in _after_init
self.load_definitions("default_en.txt", True)
/usr/lib/python3/dist-packages/pint/registry.py:588: in load_definitions
raise ValueError("While opening {}\n{}".format(file, msg))
E ValueError: While opening default_en.txt
E read_binary is deprecated. Use files() instead. Refer to
https://importlib-resources.readthedocs.io/en/
latest/using.html#migrating-from-legacy for migration advice.
8< 8<
cheers
Stuart
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025183: silx: (autopkgtest) needs update for python3.11: Segmentation fault
It appears that src:silx FTBFS at present too. The failure is during
building the docs with python3.10, meaning that this failure predates
python3.11.
The failing line is:
# build the documentation
pybuild --build -s custom -p 3.10 --build-args="cd doc && env
PYTHONPATH={build_dir} http_proxy='127.0.0.1:9' xvfb-run -a
--server-args=\"-screen 0 1024x768x24\" {interpreter} -m sphinx -N
-bhtml source build/html"
I: pybuild base:240: cd doc && env
PYTHONPATH=/build/silx-pvssnu/silx-1.1.0+dfsg/.pybuild/cpython3_3.10_silx/build
http_proxy='127.0.0.1:9' xvfb-run -a --server-args="-screen 0
1024x768x24" python3.10 -m sphinx -N -bhtml source build/html
Running Sphinx v4.5.0
[...snip...]
reading sources... [ 92%] modules/sx
qt.qpa.xcb: could not connect to display :109
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even
though it was found.
This application failed to start because no Qt platform plugin could be
initialized. Reinstalling the application may fix this problem.
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl,
offscreen, vnc, xcb.
Aborted (core dumped)
--
Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025114: python-parameterized: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Control: reassign -1 python3-nose Control: forcemerge 1024235 -1 The test failure «AttributeError: module 'inspect' has no attribute 'getargspec'» is coming from nose, a fix for which is pending. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1024908: django-cte: (autopkgtest) needs update for python3.11: module 'inspect' has no attribute 'getargspec'
Control: reassign -1 python3-nose Control: forcemerge -1 1024235 The test failure «AttributeError: module 'inspect' has no attribute 'getargspec'» is coming from nose, a fix for which is pending. -- Stuart Prescott http://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025164: lintian: missing-prerequisite-for-pyproject-backend tag needs to check Build-Depends-Indep too
Hi Scott, On 01/12/2022 02:16, Scott Kitterman wrote: Package: lintian Version: 2.115.3 Severity: normal X-Debbugs-Cc: debian-pyt...@lists.debian.org The missing-prerequisite-for-pyproject-backend check appears to only look for the prerequisite packages in Build-Depends, but since they aren't needed for clean, they could be in Build-Depends-Indep, leading to false positives. Scott K I contemplated filing a similar the other day but in writing it up, I realised that lintian was correct. Policy requires that the 'clean' target be functional with only the Build-Depends (and Build-Conflicts) satisfied, and pybuild + the build-backend dependencies are involved in the cleaning step. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025107: python-limits: (autopkgtest) needs update for python3.11: AssertionError
Upstream's approach to py3.11 seems to be to just skip those tests for the time being: https://github.com/alisaifee/limits/commit/8f868882f018263b3cd1e4dedb128f447ac8b315 'not (asyncio and (memcached or mongodb))' There is a new upstream version too but there aren't many changes other than skipping tests. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1024956: manuel: (autopkgtest) needs update for python3.11AssertionError: output looks slightly different
Control: forwarded -1 https://github.com/benji-york/manuel/issues/30 This is in the upstream bug-tracker but no patch is to be found there at this stage. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1025061: RM: python-azure-devtools -- ROM; dead upstream, no more rdeps, broken with Python 3.11
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: stu...@debian.org The python-azure-devtools pacakge no longer has any reverse dependencies and is 'archived' upstream. It doesn't support Python 3.11 and now is the time to remove it from Debian. Thanks! Stuart
Bug#1024718: linux: Samsung PM9B1 NVMe fails changes NID when resuming from sleep
Source: linux Version: 5.19.6-1 Severity: important Tags: patch upstream X-Debbugs-Cc: stuart.a.hayhu...@gmail.com Dear Maintainer, The Samsung PM9B1 misreports its NID when resuming from sleep, causing the root filesystem to be unmounted, and the system left in an unstable state. Mostly this results in the device crashing, but if the device somehow continues running, it's incredibly unstable, where basically nothing works. It's an OEM drive found in some newer laptops (like my Lenovo Yoga 7 Gen 7) There's a bug report and patch upstream for this, but personally I think it might be a good idea to include it in Debian until it's accepted, as machines with this drive are near-unusable. Upstream issue: https://lore.kernel.org/all/20221116171727.4083-1-...@augustwikerfors.se/ I've tested the patch against the current Debian 6.1-rc5 kernel on my laptop, and this fixes the problem without any other issues. Thanks :) -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1022469: python-pint: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p 3.10 returned exit code 13
pint is incompatible with babel > 2.8; unfortunately, Debian now has babel 2.10. So far, upstream has only noted the compatibility with version pinning. https://github.com/hgrecco/pint/issues/1219 Upstream tests for newer releases of pint also now fail due to this same reason. (and we should enable autopkgtest tests for pint and then this would have been caught as soon as babel > 2.8 was uploaded) -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar
Hi Michał, Thanks for the intriguing report. The error is coming from the invocation of dpkg-deb which runs ["tar", "-x", "-m", "-f", "-", "--warning=no-timestamp"] Do I take it that on your system dpkg-deb exists but is entirely non-functional because it can't actually work with any archives? If that's the case, I guess the real solution is fixing dpkg-deb. In the meantime, I'll need to think about how the test can navigate its way around a broken dpkg-deb being installed — at present, it assumes that the tools it finds are not broken. regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1023635: reportbug: Add p11kit support for PIV LUKS encryption
Package: systemd Version: 252-3 Severity: wishlist Dear Maintainer, I'm trying to use PIV to encrypt a partition using LUKS, which, from my understanding, depends on p11kit being enabled for systemd. According to the most recent build logs for sid, p11kit is disabled. This was previously requested in #1007268, but it appears that only fido2 and tpm support were added. Stuart
Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package
Control: retitle -1 Make python-debian (more) portable Control: tags -1 + pending There's a lot of work in git that should make python-debian portable across platforms (operating systems, distributions, etc). The next release will address this bug, so tagging as 'pending'. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1021515: tex-common: user locale settings can cause postinst to fail
Hi Norbert On Monday, 10 October 2022 17:44:56 AEDT Norbert Preining wrote: > @@ -76,11 +76,14 @@ dhit_build_format () > tempfile=$(mktemp -p /tmp fmtutil.) > # save LANG > LANGSAVE=$LANG > +LCALLSAVE=$LCALLSAVE > LANG=C > +LC_ALL=C > printf "Building format(s) $*.\n\tThis may take some time... " > if $FMTUTIL "$@" > $tempfile 2>&1 ; then > rm -f $tempfile > LANG=$LANGSAVE > +LC_ALL=$LCALLSAVE > echo "done." > else > exec >&2 almost -- LC_ALL needs to be exported too, otherwise it won't get passed to the child process unless it already happens to be exported, and it isn't exported in my environment. LANG should probably also be exported. Alternatively, the temporary environment setting could go into the "if" statement with no need for the saving, exporting, and undoing steps. The environment modification is only needed for the fmutil call, not the other steps: tempfile=$(mktemp -p /tmp fmtutil.) printf "Building format(s) $*.\n\tThis may take some time... " if LANG=C LC_ALL=C $FMTUTIL "$@" > $tempfile 2>&1 ; then rm -f $tempfile echo "done." else [... etc ...] regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1021515: tex-common: user locale settings can cause postinst to fail
Hi Norbert,
On Monday, 10 October 2022 16:23:25 AEDT Norbert Preining wrote:
> What happens if you only feed LANG=C? Does it break?
LANG=C seems to make no difference to solving the problem (it's already
protected in the code as you say), likewise LANGUAGE=C makes no difference.
The only other LC_* item I have in my environment is LC_TIME and setting that
to LC_TIME=C solves the issue.
> I am just wondering what other locale vars are necessary, back then
> we thought (and it worked bakc then) that LANG is enough.
LC_TIME seems to fix it - details below - I'm not sure if it's just because
LC_TIME is special to fmutil in some way or if other LC_* would also break it.
Setting LC_ALL=C seems to be an adequate workaround as that overrides all LC_*
environment variables in one step.
To help, a reproducer below.
cheers
Stuart
# current locale-relevant environment:
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en
LC_TIME=en_GB.UTF-8
# full locale
$ locale
LANG=en_AU.UTF-8
LANGUAGE=en_AU:en
LC_CTYPE="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME=en_GB.UTF-8
LC_COLLATE="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_PAPER="en_AU.UTF-8"
LC_NAME="en_AU.UTF-8"
LC_ADDRESS="en_AU.UTF-8"
LC_TELEPHONE="en_AU.UTF-8"
LC_MEASUREMENT="en_AU.UTF-8"
LC_IDENTIFICATION="en_AU.UTF-8"
LC_ALL=
$ sudo env http_proxy=http://localhost:3142/ debootstrap --arch=amd64 --
variant=minbase bookworm /srv/chroots/tmp/bookworm http://deb.debian.org/
debian
$ cat /etc/schroot/chroot.d/bookworm-1021515
[bookworm-1021515]
description=Debian bookworm (testing)
type=directory
directory=/srv/chroots/tmp/bookworm
users=stuart
root-users=stuart
profile=desktop
# I'm letting schroot preserve the environment (-p) here, that's deliberate
# to provoke the bug. Perl also bleats about this icky configuration but it's
# non-fatal.
$ schroot -c bookworm-1021515 -p -q -u root -- apt install --no-install-
recommends texlive-base
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
[...]
Do you want to continue? [Y/n]
[...]
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_AU:en",
LC_ALL = (unset),
LC_TIME = "en_GB.UTF-8",
LANG = "en_AU.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
debconf: delaying package configuration, since apt-utils is not installed
[...]
Setting up texlive-base (2022.20220722-1) ...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEDIST...
mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN...
mktexlsr: Updating /var/lib/texmf/ls-R...
mktexlsr: Done.
tl-paper: setting paper size for dvips to a4: /var/lib/texmf/dvips/config/
config-paper.ps
tl-paper: setting paper size for dvipdfmx to a4: /var/lib/texmf/dvipdfmx/
dvipdfmx-paper.cfg
tl-paper: setting paper size for xdvi to a4: /var/lib/texmf/xdvi/XDvi-paper
tl-paper: setting paper size for pdftex to a4: /var/lib/texmf/tex/generic/tex-
ini-files/pdftexconfig.tex
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line
78.)
debconf: falling back to frontend: Readline
Processing triggers for tex-common (6.17) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line
78.)
debconf: falling back to frontend: Readline
Running mktexlsr. This may take some time... done.
Running updmap-sys. This may take some time... done.
Running mktexlsr /var/lib/texmf ... done.
Building format(s) --all.
This may take some time...
fmtutil failed. Output has been stored in
/tmp/fmtutil.jbVdJmwu
Please include this file if you report a bug.
dpkg: error processing package tex-common (--configure):
installed tex-common package post-installation script subprocess returned
error exit status 1
Errors were encountered while processing:
tex-common
E: Sub-process /usr/bin/dpkg returned an error code (1)
# Poking at a few environment variables to see what the response would be
# follows. In turn,
# - apt -f install [fails]
# - LANG=C apt -f install [fails]
# - LANGUAGE=C apt -f install [fails]
# - LANG=C LANGUAGE=C apt -f install[fails]
# - LC_TIME=C apt -f install[works]
# - LC_ALL=C apt -f install [works]
(bookworm-1021515)root@simurgh:/# apt -f install
Reading package lists... Done
Building dependency tree... Done
Reading state inform
Bug#1021515: tex-common: user locale settings can cause postinst to fail
Package: tex-common Version: 6.17 Severity: normal X-Debbugs-Cc: stu...@debian.org Dear Maintainer, The postinst for tex-common is sensitive to the locale settings from the environment and so can fail in strange ways. Users can end up with odd locale settings in a chroot (as I did, where my login environment had leaked into the chroot but the specified locale was not installed), when connecting over ssh (the remote system's locale settings are applied to the remote session), or through simple misconfiguration. While the particularly odd locale seettings that I had in the chroot were my fault, the postinst should be robust to such failures. - 8< - Setting up tex-common (6.17) ... debconf: falling back to frontend: Readline Running mktexlsr. This may take some time... done. Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.YvPIYmjZ Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 - 8< - The log file mentioned ends with the following lines: - 8< - fmtutil [ERROR]: running `luahbtex -ini -jobname=luahbtex -progname=luahbtex luatex.ini From a Debian perspective, tex-common depending on the locales package is not a nice thing to do; it's also not sufficient to solve this bug, since installing the locales package is not the same as configuring the particular locale required. Adding some locale overrides to the postinst would be better, but it might mean that users do not get error messages displayed to them in their preferred language. regards Stuart
Bug#1021393: closed by Thomas Ward ()
Ok I guess I should have been more clear. This is a debian package issue in that the debian package is linking the default site default -> /etc/nginx/sites-available/default Which contains 2 listen lines as I listed before listen 80 default_server; listen [::]:80 default_server; After digging further into this I discovered it was IPv6 line that was causing the issue. listen [::]:80 default_server; We disable IPv6 on our servers. I did not run into this on Ubuntu 18.04. It appears there was a lot of changes to how debian packaged nginx between the 2 OS releases. With these changes there appears to be a lot of changes to the default. I suggest not trying to link the default and not attempting to do a restart. Just a suggestion though. Now I am trying to find a way to get passed this issue as we build an entire server via debian packages. I can not have a package error out in my build process. On 10/7/2022 11:45 AM, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the nginx-common package: #1021393: error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 22.04 with default enabled site. It has been closed by Thomas Ward. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Thomas Ward by replying to this email.
Bug#1021393: error in package nginx-common_1.18.0-6ubuntu14.2_all.deb for ubuntu 22.04 with default enabled site.
Package: nginx-common Version: 1.18.0-6ubuntu14.2 This is for ubuntu 22.04. The default site file contains : listen 80 default_server; listen [::]:80 default_server; This is an error and causes the entire nginx install to fail. Commenting out one of listen lines corrects the issue.
Bug#1020290: apt incorrectly prefer usr-is-merged
On Thu, 22 Sep 2022 08:59:17 +1000 Craig Sanders wrote: > > Maybe you can provide a minimal reproducer (based on a minimal chroot). > > Making a stable VM and then upgrading it to sid should show it. Nope. If it were that easy to reproduce and the package were that buggy, it would never have been uploaded. (Please offer a tiny bit of respect to your fellow developers!) You might be unaware that stable→sid upgrades are tested automatically, and that the problem can't be reproduced there either. https://piuparts.debian.org/stable2sid/source/i/init-system-helpers.html https://piuparts.debian.org/stable2sid/pass/init-system-helpers_1.65.2.log Understanding what provoked apt to pick the wrong package on your particular system is needed here. Quite obviously no-one else can reproduce it (or, once again, it wouldn't have been uploaded). Also obviously, if there are no details, it won't be fixed except perhaps by accident. The output of « apt list '~o' » and « apt-cache policy » might have useful clues still. > But it's too late, I've lost interest and I have no more energy to deal with > the hostility and dog-piling. Please re-read your initial bug report and then please don't try taking the high moral ground about the tone of the discussion. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1017499: mesa: Updates to 22.2 RCs cause artifacts on nouveau and blank screen on VirtIO
There's been no new RC release from Mesa since rc3, which was 4 weeks ago. I think they're overdue for one. On Fri, 16 Sept 2022 at 02:03, Leandro Cunha wrote: > Hi, > > Yes, I reported it to upstream and it's an issue that went undetected > until I take action like this. And the upload (I don't know if it was > accidental) to an unstable version of rc (release candidate) helped to > discover that there were issues that needed attention. Thanks to Karol > who took the necessary attention to solve the problem. And fixed > upstream and upstream tags are already added. Upload only for pending > fix now. I have no information if a new version of rc has been > released. > > -- > Cheers, > Leandro Cunha > > -- Stuart Young (aka Cefiar)
Bug#1016950: RFP: libcrypt-openssl-ca-perl - module to issue X509 certificates and certificate revocation lists (CRL)
Package: wnpp Severity: wishlist Package name : libcrypt-openssl-ca-perl Version : 0.91 Upstream Author : ? URL : https://metacpan.org/pod/Crypt::OpenSSL::CA License : perl_5 Programming Lang : Perl Description : Crypt::OpenSSL::CA - The crypto parts of an X509v3 Certification Authority We seem to have all the other bits of Crypt::OpenSSL, except this one.
Bug#1013015: projecteur: ftbfs with GCC-12
Control: tags -1 + upstream patch Control: forwarded -1 https://github.com/jahnf/Projecteur/pull/183 Looks to be a trivial patch that is already sorted upstream; a new upstream release (0.9.3) with the patch looks set to be released soon so we can see if that comes fast enough for gcc-12 in Debian. https://github.com/jahnf/Projecteur/issues/181 -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1011937: python-debian: Please consider moving deb822 to a standalone distro-independent Python package
Hi Stephan,
On Friday, 27 May 2022 20:09:29 AEST Jelmer Vernooij wrote:
> On Fri, May 27, 2022 at 12:01:17PM +0200, Stephan Lachnit wrote:
> > I'm not an expert on python-debian and I don't use other distros than
> > Debian, so I can only forward you some bug reports from
Thanks! I'd spotted one of these in the past but not others.
> > https://github.com/fsfe/reuse-tool/issues/466:
I'd definitely rather make python-debian more portable than have projects
forking bits of it into local vendored versions. Vendoring code creates
technical debt and is somewhat antithetical to the idea of making code more
reusable.
> > - https://github.com/fsfe/reuse-tool/issues/425: `apt_pkg.Error:
> > W:Unable to read /etc/apt/apt.conf.d/ - DirectoryExists (2: No such
> > file or directory), E:Unable to determine a suitable packaging system
> > type`
As already noted, python-debian works fine without python-apt installed; the
unexpected situation here is that python-apt is installed but non-functional
in some way. I'm not sure whether the bug is really that a non-functional
python-apt is installed, but if we can work around it, then even better.
I have a feeling that we can change the way we use apt_pkg these days and that
we can avoid generating that error. I need to talk to the python-apt people
about that, but also I also need a way of reproducing an environment where a
non-functional python-apt is installed so that I can test this out.
From https://salsa.debian.org/python-debian-team/python-debian/-/
merge_requests/85
> > Since Alpine really doesn't offer anything, a lot of fail because of
> > missing `bin/ar`, which is an excellent test for a non-Debian-standard
> > environment. Not sure how this should be handled best though: maybe
> > something similar to the `have_apt_pkg` variable?
This is only the tests and in particular, it's making the test data -- ArFile
and DebFile are actually much more portable (except for the zstd compressed
.debs where there remain portability problems because of the requirement for a
zstd binary). It's only the tests that need the 'ar' binary and nothing in the
module code itself.
There's a few options here:
* require that ar be installed for the purposes of testing just as we do in
Debian; this is an explicit dependency in Debian, not something that happens
to be there because more batteries are included. The binutils package gives us
ar and is listed in debian/control, it's just that Python hasn't come up with
a way of expressing such dependencies in setup.py or similar. For alpine, ar
is in the binutils package and there are a few different versions available
for windows, such as via a gcc package from choco.
* use something else to make the .deb files for the test suite. I could imagine
a fallback for missing ar(1) that uses a pure python ar implementation that
can be installed via pip on these other platforms. The arpy module can't make
ar files at present which is a shame; the `unix_ar` or `ar` modules look
promising for that, there might be others.
https://github.com/getninjas/unix_ar
https://github.com/vidstige/ar
* skip the tests that need ar; in practice, that's probably all the tests from
debian/tests/test_debfile.py, and so a module level skip might be appropriate,
with something like
```
pytestmark = pytest.mark.skipif(not shutil.which("ar"), reason="...")
```
I'm cautious about automatically skipping tests because that's a route to non-
determinism, accidentally skipping tests, and therefore missing problems.
However, we do that for python-apt already, so there's precedent already in
the code; I'd be fine with that as a short term solution in advance of
something better.
Thanks in advance for your contribution to python-debian :)
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1009079: mdtraj: autopkgtest timeout on arm64 (downloading pdb file?)
Source: mdtraj
Version: 1.9.7-2
Severity: important
X-Debbugs-Cc: stu...@debian.org
Dear Maintainer,
The autopkgtest tets for mdtraj attempts to download a pdb file and then use
that in calculations. This is failing (either all the time or intermittently)
with a timeout:
https://ci.debian.net/data/autopkgtest/unstable/arm64/m/mdtraj/20581005/log.gz
except Empty:
> raise Exception(
'Timeout (%.1f) when executing the following %s cell: "%s"'
%
(TIMEOUT, cell.cell_type, cell.source.strip()))
E Exception: Timeout (60.0) when executing the following code
cell: "# pull a random protein from the PDB
E # (The unitcell info happens to be wrong)
E traj = md.load_pdb('http://www.rcsb.org/pdb/files/2MI7.pdb')
E
E # just for example, use the first frame as the 'native'
conformation
E q = best_hummer_q(traj, traj[0])"
rscb.org is not fast to serve up the pdb files, but I'm not sure if that is
the cause, whether the download is failing entirely, or whether the computation
that follows is just slow.
If this is an isolated use of a single pdb file in the tests, perhaps the
Debian package could carry that pdb file as some test data and patch the test
to use the local file instead.
An internest using test should also be marked as "needs-internet".
regards
Stuart
Bug#1005471: translate-toolkit: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.10 3.9" returned exit code 13
A fixed pyparsing has now been uploaded which should let pyparsing and translate-toolkit both migrate together. Hopefully. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1004618: cantata: FTBFS with ffmpeg 5.0
Control: forwarded -1 https://github.com/CDrummond/cantata/pull/1764 Control: tags -1 + patch -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1002073: src:tryton-modules-country: Tests fail with new iso-codes
FYI a new version of pycountry has now been released upstream and it includes the iso-codes 4.8.0 data which presumably makes the tests fail upstream. tryton upstream seem to want to be reactive rather than proactive in dealing with this problem, so now is the time for them act, I guess. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#1003405: misses dependency on python3-pmw
Control: severity -1 wishlist Control: retitle -1 consider devendoring pmw module The bkchem package is functional without a separate python3-pmw package as it is carrying its own vendored version of pmw: $ dpkg -L bkchem|grep -i pmw /usr/share/bkchem/bkchem/Pmw.py /usr/share/bkchem/bkchem/PmwBlt.py /usr/share/bkchem/bkchem/PmwColor.py Bundling pmw into the application is one of the intended modes of use of this module, with the pmw sources including a "bundlepmw.py" script that generates the files included in bkchem. For bkchem we can then either: 1. carefully check through the quite large divergence between pmw upstream and bkchem's vendored version of pmw (some 41 commits in bkchem git) 2. package python3-pmw 3. wait for it to go through NEW 4. devendor pmw (note that is not just a matter of deleting the files) 5. depend on the python3-pmw package instead or 1. do nothing to bkchem. (that doesn't preclude updating python3-pmw for #886617 anyway, just that bkchem wouldn't use it) There is one other potential user of a python3-pmw package in Debian and that is the auto-07p package. Like bkchem, the auto-07p git history shows modification of the bundled pmw making devendoring hard. regards Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#998565: Errors due to changes in iso-codes data
On Wednesday, 24 November 2021 18:05:57 AEDT Stuart Prescott wrote: > I've looked at them and fixed most of the tests locally without issues. I > guess I should push that somewhere so that it is visible. I'll start a > draft PR with upstream for it. Now done: https://github.com/flyingcircusio/pycountry/pull/86 My preference would be to upload a new upstream version of iso-codes with these improvements included, giving review and acceptance that these changes are appropriate. If I can't do that in a timely fashion then backporting that PR is possible. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#998565: Errors due to changes in iso-codes data
Hi Scott > > The tests look easy enough to fix, so it's worth trying to do that. (and > > it's in the Debian group on salsa to make that easy :) I've looked at them and fixed most of the tests locally without issues. I guess I should push that somewhere so that it is visible. I'll start a draft PR with upstream for it. > > I'm a bit surprised by some of the data changes though -- apparently > > England is no longer a part of the UK. Yes, that's quite complicated, but > > the ISO-3166-2 info does still list ENG and EAW. As the pycountry tests > > highlight, those divisions disappeared from iso_3166-2.json with the > > switch over to a different data harvester. > > > > https://www.iso.org/obp/ui/#iso:code:3166:GB > > > > Is that correct and intended? > > Good question. I not sure how to adapt one test to the new data, so I'll > leave it on to you to deal with. I'm happy to look for alternate sets of divisions to replace these UK ones in the test if that's appropriate. I guess I need the input from Tobias to know whether the pycountry test failure has found a bug in the pycountry test code or a bug in the iso-codes data. The test failures regarding AL-BU look like an intended data change that needs a fix in the pycountry data. Finding a different second level division and then coming back to the national and first level divisions is needed... Tobias might have a suggestion there, otherwise I'll trawl the ISO database to find a different test case. https://www.iso.org/obp/ui/#iso:code:3166:AL https://en.wikipedia.org/wiki/ISO_3166-2:AL > Please address this before it gets auto-removed. Yes, will do. (and just discussing this bug keeps resetting the autoremoval timer, of course!) cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#998565: Errors due to changes in iso-codes data
Hi Scott & Tobias On Monday, 15 November 2021 21:13:09 AEDT Dr. Tobias Quathamer wrote: > On Sun, 14 Nov 2021 20:30:06 -0500 Scott Kitterman > > wrote: > > I looked at this a bit today and it looks like the test failures are due > > to > > updates in the iso-codes data used by the tests, not any real failures. I > > think disabling the failing tests for now would be a reasonable way to > > keep > > this in testing (I'm interested to avoid transitive removal of xml2rfc). > > > > Unless there's some objection to this, I will probably NMU later in the > > week. > > > > Scott K > > Hi Scott, > > iso-codes maintainer here -- I've just seen this bug and your mail. Your > analysis is correct, from my point of view, you should go ahead with the > NMU. The tests look easy enough to fix, so it's worth trying to do that. (and it's in the Debian group on salsa to make that easy :) I'm a bit surprised by some of the data changes though -- apparently England is no longer a part of the UK. Yes, that's quite complicated, but the ISO-3166-2 info does still list ENG and EAW. As the pycountry tests highlight, those divisions disappeared from iso_3166-2.json with the switch over to a different data harvester. https://www.iso.org/obp/ui/#iso:code:3166:GB Is that correct and intended? cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#997772: python-cogent: FTBFS: You must configure the bibtex_bibfiles setting
Hi Andreas
On Wednesday, 3 November 2021 19:00:05 AEDT Andreas Tille wrote:
[...]
> File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 182, in
> write_pkg_file license = rfc822_escape(self.get_license())
> File "/usr/lib/python3.9/distutils/util.py", line 476, in rfc822_escape
> lines = header.split('\n')
> AttributeError: 'list' object has no attribute 'split'
looking at setup.py, it has
license=["BSD"],
https://salsa.debian.org/med-team/python-cogent/-/blob/master/setup.py#L62
while the documentation for the setup() function indicates that licence should
be a string. That would certainly be consistent with the exception that is
raised with the output of get_license().
https://packaging.python.org/guides/distributing-packages-using-setuptools/
#license
I've not checked that this is indeed the problem, but patching setup.py to
have instead
license="BSD",
would be the next thing I'd try.
Incidentally, I see that upstream for cogent has ripped out setup.py entirely
and now has a flit based build system which will require a few changes to the
packaging in the future.
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#997772: python-cogent: FTBFS: You must configure the bibtex_bibfiles setting
Hi Andreas > > > Extension error: > > > You must configure the bibtex_bibfiles setting > > > make[2]: *** [Makefile:40: html] Error 2 this is sphinxcontrib-bibtex saying that you need to add the following to doc/conf.py: bibtex_bibfiles = "path/to/references.bib" However I can't see a .bib file anywhere in the source. I also can't see any code in the rst files or the docstrings that would actually use sphinxcontrib- bibtex so I'm not sure how this extension is actually used in these documents. Perhaps it isn't actually needed at all. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#997857: python-debian 0.1.42 broken with Python 3.5/3.6
Thanks again Evgeni. Looking at the problem and contemplating how we might address this, it is, of course, quite simple to protect touching T.__doc__. The test output for debfile.py / test_debfile.py shows there are many uses of pathlib.Path that don't work until Python 3.6 (in particular, builtin open and os.path functions). This can be addressed by sprinkling 15ish str() calls through the code. The output of shutil.make_archive also appears to not be reproducible in Python 3.6 meaning that another test needs tweaking to not assume a file order within the control.tar.gz file. After these three sets of changes, the test suite passes with Python 3.5 from stretch (at least for the non-RTS parser code: python3 -m pytest --doctest-modules --verbose lib/ \ --ignore lib/debian/tests/test_repro_deb822.py \ --ignore lib/debian/_deb822_repro/ Given how simple these changes are, it is probably worth making them. -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#984824: dh-python: pybuild needs to support toml (PEP517/PEP518) builds with no setup.py
I won't go as far as to tag this bug with "patch"... but a draft of a pybuild plugin that can work with the PEP517 interfaces is available for discussion and improvement at: https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/20 -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
Bug#991226: json2po: The message-context for a string occurring multiple times is always the same
Control: tags -1 + moreinfo Hi Daniel, I don't think I quite understand the situation that is described in this bug report. Would you be able to point me at a specific json file and invocation of json2po that fails? Or even better, provide a minimal (non-)working example? thanks Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 signature.asc Description: This is a digitally signed message part.
Bug#991224: json2po: Misses import pkg_resources
Control: tags -1 + moreinfo unreproducible Hi Daniel, I'm unable to reproduce this issue locally and json2po successfully smoke- tests in the autopkgtest tests; I wonder if it is actually just another symptom of #991225. I've just uploaded a new version of translate-toolkit to unstable (3.4.1-1). If you could test that version and let me know if that fixes the problem (or not!) then that would be much appreciated. thanks Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 signature.asc Description: This is a digitally signed message part.
