ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM'
Dear Mentors, I am looking for help on vtk-dicom package. Current issue is here (1), repeated here: autopkgtest [23:14:01]: test autodep8-python3: set -e ; for py in $(py3versions -d 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c "import vtkdicom; print(vtkdicom)" ; done autopkgtest [23:14:01]: test autodep8-python3: [--- Testing with python3.10: Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/vtkdicom/__init__.py", line 1, in from .vtkDICOM import * ModuleNotFoundError: No module named 'vtkdicom.vtkDICOM' I did talk with upstream and I am using the correct python module name. Indeed from my current sid64 schroot: % python3 Python 3.11.1 (main, Dec 31 2022, 10:23:59) [GCC 12.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import vtkdicom >>> print(vtkdicom) with % apt-cache policy python3-vtk-dicom python3-vtk-dicom: Installed: 0.8.14-3 Candidate: 0.8.14-3 Version table: *** 0.8.14-3 500 500 http://deb.debian.org/debian sid/main amd64 Packages 100 /var/lib/dpkg/status autopkg test seems to be using python *3.10* while the python module is built using *3.11*: [...] /usr/lib/python3/dist-packages/vtkdicom/vtkDICOM.cpython-311-x86_64-linux-gnu.so [...] What am I missing here ? My understanding of python module is quite limited. Thanks ! (1) https://ci.debian.net/data/autopkgtest/testing/amd64/v/vtk-dicom/30492694/log.gz
Re: How to create multi-source tarball with different submodules for scipy
On Mon, 16 Jan 2023 at 16:06, Andreas Tille wrote: > > Hi, > > I tried to create a multi-source tarball for scipy in its experimental > branch[1]. Upstream includes a set of git submodules in its build > process. I intended to merge all these submodules in a single > scipy_1.10.0.orig-submodules.tar.gz. This tarball is created with a > script[2] which makes sure that the exact directory structure as it is > used by upstream is conserved. This directory layout is needed in the > build process. Unfortunately `dpkg-source -x` extracts the content of > the submodules tarball into a subdirectory submodules/. > > Is there any trick to unpack this tarball right into the root? > Otherwise I need to do some symlinks workaround in d/rules to provide > all files where these are needed. When I packaged firmware-microbit-microbit I wasn't aware of any tricks, so I resorted to overriding dh_auto_build to move the extracted components into their expected paths before building: https://salsa.debian.org/python-team/packages/firmware-microbit-micropython/-/blob/debian/master/debian/rules Not sure if this useful, but I thought I'd pass it along in case it helps. Cheers, Nick
Re: filename case policy inside /usr/bin ?
Ok, thanks! Le lundi 16 janvier 2023, 21:36:55 CET The Wanderer a écrit : > On 2023-01-16 at 15:04, Fab Stz wrote: > > Hello, > > > > Is there any policy for the filename case for the executables > > installed in /usr/bin ? Most are lowercase. > > > > The package I maintain uses mixed uppercase & lowercase. For example: > > /usr/bin/FreeFileSync > > I'm not aware of any specific policy just offhand, and I'm certainly not > an expert or an authority, but: > > $ apt-file search /usr/bin/ | grep [A-Z] | wc -l > 2094 > > There appear to be *rather a lot* of files under /usr/bin/ whose names > include uppercase letters... > > $ apt-file search /usr/bin/ | grep [A-Z] | cut -d ':' -f 1 | uniq -c | wc -l > 524 > > ...and also rather a lot of packages which include such files. > > My guess is that this would be just fine. > > > Please, leave me in copy of your answer. > > In turn, please do not reply to me directly, only via the list. (Unless > you specifically want to draw my attention to that specific message, and > you think I won't get, or will miss noticing, the message otherwise.)
Re: help with python3 depends < 3.11
Piuparts tests, among other things, upgrades. So, it tries installing the old version, upgrading to the current version, and checking for errors during that process. In your case, as the old version is uninstallable, you can ignore this as a known problem. On Tuesday, January 17, 2023 6:45:52 AM MST Stephen Sinclair wrote: > If that's the case, I feel like I can just ignore this and when it's > uploaded the problem will fix itself. Does this mean that it's just a > problem with how piuparts works, or how Salsa is configured for it? > If so I will try to find how to report it. > > thanks, > Steve -- Soren Stoutner so...@stoutner.com signature.asc Description: This is a digitally signed message part.
Bug#1029091: marked as done (RFS: boxbackup/0.13~~git20221201.g166b3fa-1 -- client for the BoxBackup remote backup system)
Your message dated Tue, 17 Jan 2023 18:54:48 +0100 with message-id and subject line Re: RFS: boxbackup/0.13~~git20221201.g166b3fa-1 -- client for the BoxBackup remote backup system has caused the Debian Bug report #1029091, regarding RFS: boxbackup/0.13~~git20221201.g166b3fa-1 -- client for the BoxBackup remote backup system to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 1029091: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029091 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "boxbackup": * Package name : boxbackup Version : 0.13~~git20221201.g166b3fa-1 Upstream contact : Ben Summers * URL : http://boxbackup.org * License : GPL-2+, BSD-3-Clause or GPL-2+, BSD-4-Clause, GPL-3, ISC or BSD-4-Clause, BSD-3-Clause, ISC, Expat * Vcs : https://salsa.debian.org/debian/boxbackup Section : utils The source builds the following binary packages: boxbackup-server - server for the BoxBackup remote backup system boxbackup-client - client for the BoxBackup remote backup system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/boxbackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/b/boxbackup/boxbackup_0.13~~git20221201.g166b3fa-1.dsc Changes since the last upload: boxbackup (0.13~~git20221201.g166b3fa-1) unstable; urgency=medium . * New upstream version 0.13~~git20221201.g166b3fa * debian/control: bump Standards-Version to 4.6.2 (no changes) * debian/copyright: update debian copyright year to 2023 add common-licenses paths * debian/patches: refresh existing patches add correct-apos-in-manpages.diff to allow correct apostrophe format in manpages add description header to openssl_provider.diff * debian/source/lintian-overrides: add to remove false positive warnings * debian/watch: remove gpgmode=none update to version 4 Regards, -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature --- End Message --- --- Begin Message --- Thanks for the update.--- End Message ---
Bug#1027919: RFS: dinit/0.16.0-1 -- [ITP] Service monitoring / "init" system
Control: tags -1 moreinfo When you have created the ITP please untag moreinfo from this bug.
Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding
Package: sponsorship-requests Severity: wishlist Xchroot 2.7.4 has also come with many new features. Dbus session creation and /dev/shm mounting satisfy the need even of exigent GUI programs like the Otter browser. It has a /media and subdirectory automounter which is especially useful for mirroring mounts of removable media. It is even possible to run a whole desktop session like KDE, Gnome or Xfce in an xchroot container. Desktop link creation for the GUI menu is included. The program has evolved much since Debian fellows have initially persuaded me to make the program open source. That time there was interest in the development of xchroot regarding Debian.
Bug#1029091: RFS: boxbackup/0.13~~git20221201.g166b3fa-1 -- client for the BoxBackup remote backup system
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "boxbackup": * Package name : boxbackup Version : 0.13~~git20221201.g166b3fa-1 Upstream contact : Ben Summers * URL : http://boxbackup.org * License : GPL-2+, BSD-3-Clause or GPL-2+, BSD-4-Clause, GPL-3, ISC or BSD-4-Clause, BSD-3-Clause, ISC, Expat * Vcs : https://salsa.debian.org/debian/boxbackup Section : utils The source builds the following binary packages: boxbackup-server - server for the BoxBackup remote backup system boxbackup-client - client for the BoxBackup remote backup system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/boxbackup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/b/boxbackup/boxbackup_0.13~~git20221201.g166b3fa-1.dsc Changes since the last upload: boxbackup (0.13~~git20221201.g166b3fa-1) unstable; urgency=medium . * New upstream version 0.13~~git20221201.g166b3fa * debian/control: bump Standards-Version to 4.6.2 (no changes) * debian/copyright: update debian copyright year to 2023 add common-licenses paths * debian/patches: refresh existing patches add correct-apos-in-manpages.diff to allow correct apostrophe format in manpages add description header to openssl_provider.diff * debian/source/lintian-overrides: add to remove false positive warnings * debian/watch: remove gpgmode=none update to version 4 Regards, -- Ileana Dumitrescu GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354 OpenPGP_0x6570EA01146F7354.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: help with python3 depends < 3.11
Thanks very much for the response.
On Mon, Jan 16, 2023 at 10:47 AM Adam Borowski wrote:
>
> On Sun, Jan 15, 2023 at 04:20:35PM +0100, Stephen Sinclair wrote:
> > I have been trying to make an update to my package "siconos".
> > However, in the Salsa build, which nicely runs all tests, it fails on
> > "piuparts".
>
> > I am confused, because it fails with the following error:
> >
> > > The following packages have unmet dependencies:
> > > python3-siconos : Depends: python3 (< 3.11) but 3.11.1-1 is to be
> > > installed
> >
> > However, debian/control uses ${python3:Depends} and does not mention
> > version 3.11 anywhere, so I cannot understand where it's getting this
> > "< 3.11" constraint from.
>
> The package was build for 3.10 only. Then, python3 defaults got changed,
> and now packages are supposed to build 3.11 instead.
>
> Thus, all packages have been rebuilt. But alas:
> https://buildd.debian.org/status/package.php?p=siconos
> is quite red. You'd need to investigate why it fails to build, and upload a
> fix.
Yes, that is why I am working on it. I do have a fix ready, but I am
waiting to upload it because it fails on the Salsa piuparts test.
To be clear, Salsa is rebuilding the package, and giving this error
while testing the build. After inspecting the logs a bit longer, I
realized that what is happening is that piuparts is installing the old
version of the package while testing, and I do not know why.
Basically piuparts tries to install the binary packages one by one of
the new version, 4.4.0+dfsg-2, and it seems that during this process
apt is trying to install the old packages 4.0.0+dfsg-1. These of
course contain constraints on packages that are no longer available in
unstable and so it fails.
I thought it could be because I had not yet marked it for unstable (it
was UNRELEASED), so I ran "dch -r". This changed the error message,
but it simply fails for a different binary package now. (Bullet
instead of Python.)
https://salsa.debian.org/science-team/siconos/-/jobs/3810484
If that's the case, I feel like I can just ignore this and when it's
uploaded the problem will fix itself. Does this mean that it's just a
problem with how piuparts works, or how Salsa is configured for it?
If so I will try to find how to report it.
thanks,
Steve
Re: Packaging a header-only library with frequent breaking changes
Hello, On 2023-01-17 15:04, David Kalnischkies wrote: I would suggest talking to maintainers of similar packages, they can probably give you more practical advice in this matter. I maintain a couple of similar header-only packages. Developers unwilling to provide stable API are a challenge, but usually not much can be done about it. I usually package such headers in libfoo-dev binary packages without versions in their names. Whenever a new upstream version arrives, I use ratt to rebuild all reverse dependencies to detect possible API breaks. If found, I bug the upstreams of such reverse dependencies to adjust to the API changes. Best, Andrius
Re: Packaging a header-only library with frequent breaking changes
Hi, On Sun, Jan 15, 2023 at 01:21:59PM +, Matthew Fennell wrote: > I'm looking into whether it is feasible to package EnTT [1], a header-only C++ > library with breaking API changes every few releases / months. As I use it in a private toy-project I can certify that it is breaking API (and ABI) all the time, if header-only wasn't a strong hint already… I doubt this will change as it is clearly not a goal, so I am just skipping over the usual suggestion of talk to upstream first. > 2) Create a virtual package libentt-dev which depends on the latest binary >package: > > Package: libentt-dev > Depends: libentt3.12-dev Borderline nitpick, but this would be a "metapackage" and not a virtual package. A "virtual package" is what conceptionally happens if you have a "Provides: foobar (= 42)" assuming there exists no real package foobar. Real-world examples would be mail-transport-agent or awk. > 3) Have each new binary package version Conflict with all previous versions, > to >prevent users from trying to install the same headers from multiple > versions? > > Package: libentt3.12-dev > Conflicts: libentt3.11-dev, libentt3.10-dev, (...) You are borderline violating policy with this (packages in main are not supposed to conflict with each other except for good reason), but more importantly, what is it that you want to gain by doing this? (yes, this is a trick question) > Additionally, would I only then remove old versions from the archive when > there > are no more reverse-dependencies left for that version of the package in > stable > and testing? While your steps would certainly work and are what is basically happening for the big guys like python, gcc, clang and co (except that those are at least co-installable) this tends to be a giant pain in the buttocks (excuse my french) for everyone involved and you would involve a couple of people from ftpmasters (accepting new packages) to release team (for frequent transitions) and everyone in between for a rather small special-interest package. So, your steps might be sound, but in practice it sounds to me like you are throwing the baby out with the bathwater (see trick question). Dear ImGui (src:imgui) is in pretty much the same boat, somewhat likely to be another dependency of tools/games depending on EnTT, and is handled in a (seemingly, I haven't looked closely and I don't maintain it, not even using the package yet, so I could be all wrong) simpler way: It is just packaged as src:imgui and the binary libimgui-dev (containing the headers and a static library). The individual versions aren't co-installable obviously, but that was what you wanted to prevent with 3) anyhow in your scheme. Many automatic tools will be of no help as header-only means there is no (obvious) record of which version of EnTT a binary package was build against (yeah, buildinfo, but that isn't commonly used/available in an obvious way so far), so it is somewhat in your responsibility to ensure your reverse dependencies are updated rather than e.g. just waiting for FTBFS to come in from archive-wide rebuild efforts. I would suggest talking to maintainers of similar packages, they can probably give you more practical advice in this matter. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding
Package: sponsorship-requests Severity: wishlist Dear Bart Martens, Dear mentors, I have now applied the necessary changes for package "xchroot" to get sponsored: https://mentors.debian.net/package/xchroot dget -xu https://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.7.5-1.dsc Changes since the last upload: The changelog now contains only one entry with reference to making the ITP bug #721447 closed. Version number is -1 as required. version 2.7.5 has a more robust xauth mechanism and fixes a fallacy when X-authorization is given on a per user or local basis rather than by a MIT-MAGIC-COOKIE-1: Now xchroot can generate the cookie on the fly if none is encountered: https://www.elstel.org/ViewRSS.php?guid=7470#7470 Regards, Elmar Stellnberger
