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#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#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#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#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#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#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#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#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#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#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#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
LANG = "C"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Setting up 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.aWLaegHN
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)
(bookworm-1021515)root@simurgh:/# LC_TIME=C apt -f install
bash: warning: setlocale: LC_TIME: cannot change locale (en_GB.UTF-8): No such
file or directory
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_AU:en",
LC_ALL = (unset),
LC_TIME = "C",
LANG = "en_AU.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Setting up 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... done.
# (breaking it with a "dpkg -r --force-depends tex-common" so that I could try
# some other things)
(bookworm-1021515)root@simurgh:/# LC_ALL=C apt -f install
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up 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... done.
bash: _powerline_status_wrapper: command not found
bash: _direnv_hook: command not found
--
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
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#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#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.
Bug#994732: python3-whiteboard: Python 2 syntax leads to SyntaxError
Package: python3-whiteboard Version: 1.0+git20170915-6 Severity: serious Justification: crashes on startup; not usable X-Debbugs-Cc: stu...@debian.org Dear Maintainer, Installing python3-whiteboard and running python-whiteboard fails as follows: $ /usr/bin/python-whiteboard Using directory: /usr/share/python-whiteboard Traceback (most recent call last): File "/usr/bin/python-whiteboard", line 24, in if __name__ == '__main__': main() File "/usr/bin/python-whiteboard", line 20, in main import pywhiteboard File "/usr/share/python-whiteboard/pywhiteboard.py", line 4, in from wiimote import Wiimote File "/usr/share/python-whiteboard/wiimote.py", line 93 except bluetooth.BluetoothError, errString: ^ SyntaxError: invalid syntax Quickly fixing that bug reveals that there are more: /usr/share/python-whiteboard/linuxWiimoteLib.py: TabError: inconsistent use of tabs and spaces in indentation Looking at the upstream git repo, there seems to be some more recent commits since this particular git snapshot and they are aimed at PyQt5 and Python 3 compatibility. If possible, this package should be updated in bullseye but I suspect that the release managers will not like the size of the changes required; if that is the case then it should be removed from bullseye, but perhaps it could appear in bullseye-backports instead. thanks Stuart -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (550, 'stable-security'), (500, 'stable-updates'), (500, 'stable-debug'), (500, 'proposed-updates'), (500, 'stable'), (60, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-whiteboard depends on: ii python33.9.2-3 ii python3-bluez 0.23-3 ii python3-cwiid 0.6.91-2+b1 ii python3-numpy 1:1.19.5-1 ii python3-pyqt5 5.15.2+dfsg-3 ii python3-xlib 0.29-1 python3-whiteboard recommends no packages. python3-whiteboard suggests no packages. -- no debconf information
Bug#993955: lintian: Offers incorrect/harmful advice regarding usrmerge
Package: lintian Version: 2.105.0 Severity: serious Justification: unsuitable for release in the release maanger's opinion X-Debbugs-Cc: stu...@debian.org Dear Maintainer, Following up on a conversation in #debian-qa, the current wording of the classification tag "unmerged-usr" is problematic: C: unmerged-usr N: N: The named file is being installed in a legacy location. Modern Debian systems install this file under /usr. N: N: Please move this file to a suitable place under the "merged /usr" scheme. Please consult the provided N: references as to where that might be. N: N: Please refer to https://wiki.debian.org/UsrMerge, https://wiki.debian.org/Teams/Dpkg/MergedUsr, Bug#978636, N: https://lists.debian.org/debian-devel/2020/11/#00232, https://lists.debian.org/debian-devel/2020/12/#00386, N: https://lists.debian.org/debian-devel-announce/2019/03/msg1.html, https://rusty.ozlabs.org/?p=236, N: https://www.linux-magazine.com/Issues/2019/228/Debian-usr-Merge, https://lwn.net/Articles/773342/, and N: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ for details. N: N: Visibility: classification N: Show-Always: no N: Check: files/hierarchy/merged-usr N: This tag is a classification. There is no issue in your package. As noted in the discussion, there are two problems here: * The advice "Please move this file" contradicts the emerging consensus on the correct way to handle the transition. There has been a long discussion on debian-devel about this where more details can be found. This consensus may well change, of course, and then we would want lintian to be opinionated... but the advice given in the tag is contrary to the current position. * The tag is self-contradictory, offering both an instruction to act and also saying "There is no issue in your package." As indicated by a member of the Release Team in the discussion in #debian-qa, the first of these points is a serious problem for the bookworm development cycle and needs fixing. This bug is filed with serious severity in accordance with the BTS definition of serious: "in the release manager's opinion, makes the package unsuitable for release" [1]. [1] https://www.debian.org/Bugs/Developer#severities Classification tags not shown by default but will still pop up and for a problem such as this may cause significant issues with bullseye→bookworm upgrades, it's important to get right. I'm filing this as a bug so that it doesn't accidentally get forgotten and to keep this change out of testing. regards Stuart
Bug#993639: bullseye-pu: package pyx3/0.15-3+deb11u1
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: stu...@debian.org
Dear Release Team,
I would like to update the pyx3 source package in bullseye to fix a nasty
bug in its text layout that makes it more-or-less unusable at present
(#992656).
[ Reason ]
An incompatibility between the pyx3 and texlive in the bullseye release
means that text box alignment is broken in plots generated by pyx. The
result is unreadable plots where, for example, the tick labels are vertically
displaced, with the y-tick labels perhaps being next to the wrong tick
mark, and the x-tick labels being cropped off the bottom of the image.
Upstream reported this bug and even indicated the appropriate patch to
cherry-pick (see #992656).
[ Impact ]
pyx3 in bullseye is not usable with the 'LatexEngine' text engine; the
alternative text engine (typesetting using plain TeX) is fine for some work,
but many users would use LatexEngine as the text engine across all plots.
While it is not the default text engine that it is broken, it widely used
such that it is worth updating in bullseye.
[ Tests ]
PyX has a test suite that is run and passes at build time. However, the test
suite does not check for the visual correctness of the output which is where
this bug lies. I have manually tested the updated packages using the test case
provided by upstream in #992656 to verify that the bug is indeed fixed. I
have also checked other output from the update pyx3 package.
[ Risks ]
This is an upstream patch that was identified by upstream as being appropriate
for the bullseye-pu. The actual change is a single line of LaTeX macro usage
in configuring the text engine.
[ Checklist ]
[✔] *all* changes are documented in the d/changelog
[✔] I reviewed all changes and I approve them
[✔] attach debdiff against the package in (old)stable
[✔] the issue is verified as fixed in unstable
[ Changes ]
Only one change: The LatexEngine configuration is switched to use a different
PyX macro that allows the correct alignment of the text in the output.
[ Other info ]
This bug is already fixed in unstable and testing (version 0.15-4); the only
difference between the version in unstable and the debdiff proposed here is
the changelog entry. My manual testing of this fix was undertaken against both
the 0.15-3+deb11u1 and 0.15-4 packages installed into their respective
releases.
Thanks for your assistance with this bullseye-pu.
Stuart
diff -Nru pyx3-0.15/debian/changelog pyx3-0.15/debian/changelog
--- pyx3-0.15/debian/changelog 2020-03-23 10:05:15.0 +1100
+++ pyx3-0.15/debian/changelog 2021-09-04 12:51:47.0 +1000
@@ -1,3 +1,11 @@
+pyx3 (0.15-3+deb11u1) bullseye; urgency=medium
+
+ * Fix horizontal font alignment issue with texlive 2020. Cherry-pick patch
+from upstream, with thanks to Andre Wobst and Joerg Lehmann
+(Closes: #992656).
+
+ -- Stuart Prescott Sat, 04 Sep 2021 12:51:47 +1000
+
pyx3 (0.15-3) unstable; urgency=medium
* Fix autopkgtest failure due to use of py3versions -i, with thanks to Scott
diff -Nru pyx3-0.15/debian/patches/series pyx3-0.15/debian/patches/series
--- pyx3-0.15/debian/patches/series 2020-03-23 10:05:15.0 +1100
+++ pyx3-0.15/debian/patches/series 2021-09-04 12:51:47.0 +1000
@@ -9,3 +9,4 @@
reproducible-timestamps.patch
reproducible-image-name.patch
reproducible-elements.patch
+texlive2020-horiz-alignment.patch
diff -Nru pyx3-0.15/debian/patches/texlive2020-horiz-alignment.patch
pyx3-0.15/debian/patches/texlive2020-horiz-alignment.patch
--- pyx3-0.15/debian/patches/texlive2020-horiz-alignment.patch 1970-01-01
10:00:00.0 +1000
+++ pyx3-0.15/debian/patches/texlive2020-horiz-alignment.patch 2021-09-04
12:51:47.0 +1000
@@ -0,0 +1,31 @@
+From 82f82028ec5bc166ff2bb5bfa416ed94486b2775 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Andr=C3=A9=20Wobst?=
+Date: Sat, 21 Aug 2021 13:46:28 +0200
+Subject: [PATCH] Make alignment work with texlive 2020
+
+The LaTeX shipout macro has recently been changed in unboxing and
+reboxing the content. This resulted in a misplacment in vertical
+direction by ignoring that PyX sets the height to zero.
+
+This bug has been reported by Thomas Bending.
+---
+ pyx/text.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/pyx/text.py b/pyx/text.py
+index 9ecd0768..68539743 100644
+--- a/pyx/text.py
b/pyx/text.py
+@@ -1202,8 +1202,8 @@ class SingleEngine:
+
"rt=\\the\\PyXDimenHAlignRT,"
+ "ht=\\the\\ht\\PyXBox,"
+ "dp=\\the\\dp\\PyXBox:}%\n"
++ "\\ht\\PyXBox0pt%\n" # baseline alignment (hight to
zero)
+
"\\setbox\\PyXBoxHAligned=\\hbox{\\kern-\\PyXDimenHAlignLT\\box\\PyXBox}%
Bug#992656: python3-pyx: incorrect vertical alignment of text output when using the LatexEngine
Dear Andre and Joerg, Thanks for passing on the bug report and especially for the patch. I've uploaded the fixed package to Debian's 'unstable' distribution, which is the first step in getting it fixed in the bullseye release [1]. regards Stuart [1] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#special-case-uploads-to-the-stable-and-oldstable-distributions -- 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#991549: libpmix-dev: missing Breaks+Replaces: libpmix2 (<< 4.1)
This bug now affects bookworm->sid and (old)sid->sid upgrades. -- 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#985052: python-sympy-doc: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/python-sympy-doc/sympy-live.sh
Control: tags -1 + patch https://salsa.debian.org/science-team/sympy/-/merge_requests/2 -- 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#975672: Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats
Hi Fabian, On Thursday, 14 January 2021 07:29:55 AEDT Fabian Wolff wrote: > On 1/11/21 3:45 AM, Stuart Prescott wrote: > >> In any case, I've changed my upload to a QA upload now and reuploaded > >> it to Salsa and Mentors. > > > > I see bartm beat me to uploading it. > > Are you sure? I didn't receive any emails about an upload, and the > tracker doesn't say anything about a recent upload either... Ah, my mistake, bartm only closed the bug. I assumed he had also uploaded the package. I've now done so (adopting it into Debian Science as you suggest). Thank you for your contribution to Debian! 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#975672: Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats
Hi Fabian > But no, I do not currently intend to adopt this package. I just > thought I'd try and help with the freeze preparation by fixing the RC > bug in this package. No worries. Thanks for taking care of an RC bug :) > The reason I created the repository in the Science Team area is that I > have write access there (unlike in the Debian group) and because it > fits topically. If this is a problem, you can create a repository in > the Debian group, give me "Maintainer" access (so that I can push to > master), and I'll change the Vcs-* fields in d/control. It's quite unusual to include the VCS within a team when the package is not maintained by the team; however, it's probably also better to have a packaging VCS somewhere than to not have one these days. Anyway, I agree with your assessment that the package probably lives best within the Science Team and so I'll adopt the package into the Debian Science Team. Thanks for setting up a VCS for it! > In any case, I've changed my upload to a QA upload now and reuploaded > it to Salsa and Mentors. I see bartm beat me to uploading it. Thank you for your contribution to 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#975672: Bug#979245: RFS: xylib/1.6-0.1 [RC] [NMU] -- Library for reading x-y data from several file formats
Hi Fabian I see you've imported the package into the Debian Science Team area on salsa. Since xylib is orphaned, do you intend to adopt it and maintain it within the Debian Science team? That would be a great outcome. If you update the Maintainer and Uploaders fields in debian/control, close #979256 in the changelog and update the version to 1.6-1, then I can sponsor the maintainer upload to adopt the package :) 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#977355: UserWarning: cannot parse package relationship "i", returning it raw
On Monday, 14 December 2020 21:42:08 AEDT Raphaël Hertzog wrote:
> This is due to a buggy package containing a dependency on "i" (it's
> libmagics++-dev, bug filed already) but I don't see any reason for deb822
> to fail on this dependency. It's a very short package name that we should
> likely not allow in Debian but I don't a reason to not be able to parse
> it (in particular when nothing else in the build machinery choked on that
> dependency, starting with dpkg-gencontrol).
>
> Please update the __dep_RE regex to accept single-character dependencies:
>
>1421 __dep_RE = re.compile(
>1422 r'^\s*(?P[a-zA-Z0-9.+\-]{2,})'
Policy demands that package names be at least two characters long which is
where this requirement originally came from. On the other hand, policy also
demands that the package name start with [a-z0-9] and be all lower case and
this regex doesn't enforce either of those requirements.
https://www.debian.org/doc/debian-policy/ch-controlfields.html#source
This is the classic "should we validate the input?" problem that python-debian
always struggles with. In other places, we've made the strictness of
validation optional, but that doesn't look to be feasible here.
I guess it's reasonable to simply allow a single character to start, as in:
(?P[a-zA-Z0-9][a-zA-Z0-9.+\-]*)
(that still disallows packages to start with . + -)
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#875305: Support for finding changelog.Debian.gz in perl-base
I've rolled the patches attached to this bug into a merge request on salsa (with some minor updates as debfile.py itself has changed slightly since they were submitted). https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/32 However, looking carefully at Policy §12.7, searching in /usr/share/doc/ $source/ would be the wrong thing to do. https://www.debian.org/doc/debian-policy/ch-docs.html#changelog-files-and-release-notes Non-native packages are required to have /usr/share/doc/$package/ changelog.Debian.gz but the directory (or perhaps the file) can be a symlink; this is the case for perl-base that is cited in the bug report. $ dpkg -S /usr/share/doc/perl-base perl-base: /usr/share/doc/perl-base $ ls -l /usr/share/doc/perl-base lrwxrwxrwx 1 root root 4 Nov 10 2017 /usr/share/doc/perl-base -> perl/ $ dpkg -L perl-base | grep changelog /usr/share/doc/perl/changelog.Debian.gz and therefore "/usr/share/doc/perl-base/changelog.Debian.gz" exists, but only via a symlink. The correct approach to finding the changelog is probably not to look at source package names, but to try to follow symlinks within the .deb -- 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#976433: debian-crossgrader: Please include Vcs-* fields in debian/control
Source: debian-crossgrader Version: 0.0.3 Severity: minor Dear Maintainer, The Debian package, via debian/control, can declare where the package is maintained, for example Vcs-Git and Vcs-Browser for this package should indicate that it is maintained on salsa. It's nice to do this so that people can help out, find the most recent versions etc. https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-vcs-fields https://wiki.debian.org/Salsa/Doc#Canonical_URLs (it's also unusual for the VCS on salsa to have a different name to the source package itself: debian-crossgrader vs debian-crossgrading) Thanks for maintaining this interesting package! regards Stuart
Bug#975690: lintian: detect invalid Uploaders fields that are missing separating commas
I think that Debian needs to know what the format of Uploaders is supposed to be, before it is reasonable to hope that lintian can check that it is correct. (well ok, policy often works the other way around, but there needs to be the rough consensus first rather than lintian driving policy) Perhaps there is a rough consensus in these discussions so far: https://bugs.debian.org/401452 https://bugs.debian.org/509935 https://bugs.debian.org/962277 cheers Stuart (who would welcome a resolution too: see https://bugs.debian.org/686638) -- 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#974846: RFS: robot-testing-framework/2.0.1-1 [ITP] -- Robot Testing Framework
Hi Daniele I've not looked carefully at this package at all, but this one stood out: >librobottestingframework-python2 - Robot Testing Framework - > RTF_python library Now is not the time to be introducing things that depend on Python 2, given that Python 2 is almost completely removed from the next release of Debian. Can this package support Python 3 instead? If not, can the Python 2 bindings be omitted? (Perhaps upstream would like some help in porting the code to Python 3?) 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#974131: engauge-digitizer: Please package new upstream version 12.1
Package: engauge-digitizer Version: 10.10+ds.1-1 Severity: wishlist Dear Maintainer, engauge-digitizer has had a few upstream releases which add new functionality. It would be great to see an updated version in bullseye. thanks Stuart
Bug#875306: python-debian: include a type for buildinfo files
Hi Chris On Tuesday, 3 November 2020 00:07:03 AEDT Chris Lamb wrote: > Hi Stuart, > > > > Glancing at the parsed data structures, it would seem like the code is > > > collapsing duplicate environment keys in the returned value of > > > get_environment() as well as throw away the original ordering. > > > > It is deliberate, although inconsistent as you note. I'm happy to be told > > me reasoning is not sound and that different structures would be better > > No, I was mostly just checking; you've clearly thought this through. I > think your various solutions are more than adequate, especially as we > don't really define anywhere what happens if any of our fields contain > duplicates anyway. All good :) I'll get this merged and released soonish. Hopefully people will start using this class, thinking about more things that it could do, reporting bugs and offering patches :) 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#875306: python-debian: include a type for buildinfo files
Hi again I've updated the implementation for consuming buildinfo files: * include a get_changelog() method for the Binary-Only-Changes field * deserialise the environment correctly; dequote \" and handle environment with \n in it https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/29 (and I realised that I had previously pushed an empty branch to salsa so the actual code was not visible... it is now!) Once again comments, suggestions and encouragement gratefully accepted :) 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#875306: python-debian: include a type for buildinfo files
Hi Chris Thanks for having a look and offering some feedback! On Tuesday, 27 October 2020 00:04:03 AEDT Chris Lamb wrote: > Thanks for working on this. I can't think of any additional data that > would be useful right this second. However, I tend to have to use the > library in the 'real world' before I can discover that kind of thing. I completely understand and I'm happy to expand the API once real use tests it out a bit. I might mark it as "experimental" in the documentation just in case real use suggests that some breaking changes are needed too. > > The current code doesn't handle dequoting the environment values and will > > react particularly badly to environment values with newlines in them. > > Do you plan to address this? Would be nice if callsites would be able > to rely on the quoting, as you might imagine. Yes, I think it should do so. I will need to recompletely rewrite that bit of code to accommodate some of the weirder possibilities that are permitted, also checking the code in dpkg that generates the file. > Glancing at the parsed data structures, it would seem like the code is > collapsing duplicate environment keys in the returned value of > get_environment() as well as throw away the original ordering. I would > be okay with this, but we don't do the same for the > installed-build-depends relation. Is this deliberate? It is deliberate, although inconsistent as you note. I'm happy to be told me reasoning is not sound and that different structures would be better: * I chose a dict for the environment as order doesn't matter for the environment and there can't be duplicates in the environment anyway. Python's precedent of using a dict for os.environ felt compelling. We could use an OrderedDict here to explicitly preserve order if that desirable (the dict will accidentally preserve order of course). * I chose a list for the dependencies as that is what is already used for all other package relations within deb822._PkgRelationMixin/deb822.PkgRelation. Ordering of a Depends or Build-Depends may or may not actually matter there as that's down in the weeds of the implementation details of how apt would resolve alternate dependencies. In the case of Installed-Build-Depends, the package list is all-encompassing and should be installable without additional resolution (although I expect that might be simpler to say than do); order shouldn't be an issue there, but I prioritised code reuse and consistent data structures within Deb822 so that existing consumers of the structures from _PkgRelationMixin are usable. The code also only currently consumes these data structures with no provision to edit them via the parsed versions (although the Deb822 super-class would let you edit the raw text and reserialise that to make changes). I've written it on the assumption that dpkg would always be the generator of the file and that python-debian is only providing tools to support analysis. 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#875306: python-debian: include a type for buildinfo files
Hi Holger
Thanks for having a look and suggesting that additional extension!
On Wednesday, 28 October 2020 06:58:55 AEDT Holger Levsen wrote:
> I believe there is a third place: changelog stanzas (aka
> Binary-Only-Changes:) from binNMUs, like the one from
> https://buildinfos.debian.net/ftp-master.debian.org/buildinfo/2020/10/27/dql
> ite_1.6.0-1+b1_amd64.buildinfo
>
> Binary-Only-Changes:
> dqlite (1.6.0-1+b1) sid; urgency=low, binary-only=yes
> .
>* Binary-only non-maintainer upload for amd64; no source changes.
>* Rebuild on buildd
> .
> -- amd64 Build Daemon (x86-grnet-01)
> Tue, 27 Oct 2020 16:00:36
> +
ah, I'd not seen one of these in action. I should go find some additional
buildinfo files to
play with.
Something like:
In [1]: from debian import deb822
In [2]: info = deb822.BuildInfo(open("debian/tests/test_BuildInfo"))
In [3]: changes = info.get_changelog()
where changes is a debian.changelog.ChangeLog object containing 1 ChangeBlock.
https://python-debian-team.pages.debian.net/python-debian/api/
debian.changelog.html#debian.changelog.Changelog
Thinking about the steps:
* If there is no Binary-Only-Changes field, it would just return None
* It would first remove the initial space indent and dots, raising a ValueError
if they
weren't there.
* Creating the ChangeBlock object might raise
debian.changelog.ChangelogParseError or
debian.changelog.VersionError should the changelog be bad in some way.
Like the accessors for environment and Installed-Build-Depends, this would be a
read-
only method, not providing a simple way to edit/insert the changelog into an
existing
buildinfo file.
Is that what you imagined?
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#875306: python-debian: include a type for buildinfo files
Dear reproducible-builds folks,
python-debian has classes to wrap many of Debian's deb822 format files, trying
to use an underlying parser that always exposes the data in more or less the
same key/value way via a dictionary, plus also providing extra syntactic sugar
to help make sense of the values that are included. For example, package
dependencies such as Depends or Build-Depends are split up into a list of
relationships, with the standard syntax that we use everywhere interpreted to
include version restrictions etc.
The .buildinfo files have two places where interpreting the values seems
worthwhile:
Environment: split the lines and extract the key="value" data into a
dictionary in the same format as Python's normal `os.environ`. (Some
dequoting is needed but not currently implemented.)
Installed-Build-Depends: use the standard package-relation code on this
to
return interpret the list of packages.
We could thus do something like:
In [1]: from debian import deb822
In [2]: info = deb822.BuildInfo(open("debian/tests/test_BuildInfo"))
In [3]: info.get_environment()
Out[3]:
{'DEB_BUILD_OPTIONS': 'parallel=4',
'LANG': 'en_AU.UTF-8',
'LC_ALL': 'C.UTF-8',
'LC_TIME': 'en_GB.UTF-8',
'LD_LIBRARY_PATH': '/usr/lib/libeatmydata',
'SOURCE_DATE_EPOCH': '1601784586'}
In [4]: info.relations['installed-build-depends']
Out[4]:
[[{'name': 'autoconf',
'archqual': None,
'version': ('=', '2.69-11.1'),
'arch': None,
'restrictions': None}],
[{'name': 'automake',
'archqual': None,
'version': ('=', '1:1.16.2-4'),
'arch': None,
'restrictions': None}],
[{'name': 'autopoint',
'archqual': None,
'version': ('=', '0.19.8.1-10'),
'arch': None,
'restrictions': None}],
[{'name': 'autotools-dev',
'archqual': None,
'version': ('=', '20180224.1'),
'arch': None,
'restrictions': None}],
[{'name': 'base-files',
'archqual': None,
'version': ('=', '11'),
'arch': None,
'restrictions': None}],
...(trimmed)...
In [5]: for dep in info.relations['installed-build-depends']:
...: print("Installed %s/%s" % (dep[0]['name'], dep[0]['version'][1]))
...:
Installed autoconf/2.69-11.1
Installed automake/1:1.16.2-4
Installed autopoint/0.19.8.1-10
Installed autotools-dev/20180224.1
Installed base-files/11
...(trimmed)...
The standard format for the list of package relationships contains features
that the buildinfo format doesn't need ("foo | bar", architecture and build-
profile restrictions), but it seems better to use exactly the same format as is
used for Packages and Sources. That does however mean there are lots of
single-element lists used, as seen in the `dep[0]` usage above. A bit ugly,
but consistency wins here, I think.
How does this look to you?
Are there additional data that would be nice to extract and interpret in a
structured way?
The current code doesn't handle dequoting the environment values and will
react particularly badly to environment values with newlines in them.
The current work-in-progress code is at
https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/29
Comments, suggestions and encouragement gratefully accepted :)
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
Bug#934273: python3-debian: please support parsing Source: package (version)
Control: tags -1 patch
Hi David
Returning to your excellent idea in #9334273, how does the following seem? It
adds an accessor for the the `source` and `source_version` to the classes
generated by the deb822.Packages class:
In [1]: from debian import deb822
In [2]: def whatmade(name, cat):
...: p = [pkg for pkg in cat if pkg['Package'] == name][0]
...: print("Source %s/%s made binary %s/%s" % (
...: p.source,
...: p.source_version,
...: p['Package'],
...: p.get_version(),
...: ))
In [3]: cat = list(deb822.Packages.iter_paragraphs(open('/var/lib/apt/lists/
deb.debian.org_debian_dists_sid_main_binary-amd64_Packages')))
In [4]: whatmade('gcc-10', cat)
Source gcc-10/10.2.0-15 made binary gcc-10/10.2.0-15
In [5]: whatmade('gcc-10-base', cat)
Source gcc-10/10.2.0-15 made binary gcc-10-base/10.2.0-15
In [6]: whatmade('gcc', cat)
Source gcc-defaults/1.189 made binary gcc/4:10.2.0-1
https://salsa.debian.org/python-debian-team/python-debian/-/merge_requests/28
Does that provide the sort of API that you were hoping to have?
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#942942: debian-reference: Python2 removal in sid/bullseye
Control: tags -1 + patch Porting the tools in debian-reference to Python 3 and making the package build only use Python 3 is accomplished in https://salsa.debian.org/debian/debian-reference/-/merge_requests/6 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
