Re: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
On Thu, 27 Feb 2025 at 11:02:46 +, Simon McVittie wrote:
> On Thu, 27 Feb 2025 at 10:49:04 +0100, Andreas Tille wrote:
> > gi.RepositoryError: Typelib file for namespace 'xlib', version '2.0' not
> > found
>
> Is the new upstream version perhaps not generating that dependency?
>From the build logs and history on Salsa, I think this is a regression in
https://salsa.debian.org/science-team/v-sim/-/commit/ec9b6f88c88eb2b5e44b13bf0f5bd1355a97f863
"Switch from cdbs to dh" rather than anything to do with the new upstream
version specifically.
Now that this package is no longer using /usr/share/cdbs/1/class/gnome.mk,
there is no longer anything to say that it should use the "gir"
debhelper sequence or run dh_girepository, so... it doesn't. As a result,
the ${gir:Depends} and ${gir:Provides} are not populated and the
dependencies are missing.
Please add "Build-Depends: dh-sequence-gir" if you prefer the declarative
style (I would personally recommend this), or run dh as "dh $@ --with gir"
if you prefer the imperative style.
Looking at the build log from Salsa-CI, you probably also want
"Build-Depends: dh-sequence-python3", or "dh $@ --with gir,python3".
A way to avoid this problem in future would be: when you are doing major
build-system surgery, I would suggest doing a build with the old build
system first and moving it to a reference directory, then doing a build
with the proposed change, running debdiff on the two builds, and repeating
until all the differences look intentional or non-problematic.
In this case I think you would see that all the Depends for gir1.2-*
packages would have disappeared, and that's what is causing the autopkgtest
failure.
Another way to avoid this problem in future would be to check the build log
and see whether the warnings issued by dpkg-gencontrol can be explained
away as not being a real problem. In this case, the warnings that tell you
you're missing some dh sequences are:
dpkg-gencontrol: warning: Depends field of package python3-v-sim:
substitution variable ${python3:Depends} used, but is not defined
dpkg-gencontrol: warning: Depends field of package gir1.2-v-sim-1.0:
substitution variable ${gir:Depends} used, but is not defined
I hope this helps,
smcv
Re: Bug#1075614: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
* Alexandre Detiste [250227 12:39]: > I ve my own take on this: I would MBF the (expected few) remaining users of > /usr/share/cdbs/1/class/gnome.mk > and then get rid of this one cdbs module. > > I did similar analysis for the python3-distutils.mk (not sure about the > name) using Debian Code Search and there were only 3 users left. https://codesearch.debian.net/search?q=%2Fusr%2Fshare%2Fcdbs%2F1%2Fclass%2Fgnome.mk&literal=1 reports 8 occurences, two of them in comments/changelogs. Seems possible for a motivated person. Chris
Re: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
On Thu, 27 Feb 2025 at 10:49:04 +0100, Andreas Tille wrote:
> autopkgtest [08:21:22]: test autodep8-python3: set -e ; for py in
> $(py3versions -r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with
> $py:" ; $py -c "import gi.overrides.v_sim; print(gi.overrides.v_sim)" ; done
...
> import gi.overrides.v_sim; print(gi.overrides.v_sim)
...
> gi.RepositoryError: Typelib file for namespace 'xlib', version '2.0' not found
The problem here seems to be that the proposed version of gir1.2-v-sim-1.0
is unable to find xlib-2.0.typelib. That should come from gir1.2-xlib-2.0,
which is the systematic name for the package from which you can import
a GObject-Introspection typelib with namespace xlib and version 2.0. In
fact gir1.2-xlib-2.0 happens to be a virtual package, provided by the
real package gir1.2-freedesktop.
I'm a little confused by this, because python3-v-sim depends on
gir1.2-v-sim-1.0, and all the versions of gir1.2-v-sim-1.0 that I can
see in apt-cache *do* have that dependency: in the original upload of 3.7.2-9
Package: gir1.2-v-sim-1.0
Source: v-sim
Version: 3.7.2-9
...
Depends: gir1.2-freedesktop, ...
(because older versions of the GObject-Introspection toolchain generated a
dependency on the real package)
and in the recent binNMU
Package: gir1.2-v-sim-1.0
Source: v-sim (3.7.2-9)
Version: 3.7.2-9+b1
...
Depends: gir1.2-cairo-1.0, ..., gir1.2-xlib-2.0, ...
(because newer versions of the GObject-Introspection toolchain generate a
dependency on each of the systematically-named virtual packages, which apt
will resolve by installing the single real package that Provides them)
Is the new upstream version perhaps not generating that dependency? That
could indicate a regression in the new upstream version, or it could
indicate that dh_girepository is failing to parse the typelib or generating
the wrong dependencies or something. A build log for the new/proposed
version would be useful, perhaps attached to a "new upstream release"
bug report.
Or is the test perhaps installing mismatched versions of the relevant
packages, or versions that are not of the architecture combination that you
would expect?
If an urgent workaround is required, hard-coding a Depends on
gir1.2-xlib-2.0 would not be the worst thing.
Looking at the build log for the recent binNMU, I see some warnings:
> dh_girepository -pgir1.2-v-sim-1.0
> dh_girepository: warning: Missing Build-Depends: gir1.2-gl-1.0-dev (ideally
> with )
> dh_girepository: warning: Missing Build-Depends: gir1.2-gmodule-2.0-dev
> (ideally with )
> dh_girepository: warning: Missing Build-Depends: gir1.2-gobject-2.0-dev
> (ideally with )
> dh_girepository: warning: Missing Build-Depends: gir1.2-gtk-3.0-dev (ideally
> with )
> dh_girepository: warning: Missing Build-Depends: gir1.2-cairo-1.0-dev
> (ideally with )
> dh_girepository: warning: Missing Build-Depends: gir1.2-xlib-2.0-dev (ideally
> with )
> dh_girepository: warning: /usr/lib/girepository-1.0/v_sim-3.7.typelib should
> be installed into /usr/lib/x86_64-linux-gnu/girepository-1.0
The missing Build-Depends are non-critical in practice, but it would be a
good bit of future-proofing to add them. You can ignore the part
about if this is a package that is unlikely to be interesting to
cross-compile.
The typelib should ideally be installed into the multiarch directory,
/usr/lib/${DEB_HOST_MULTIARCH}/girepository-1.0, instead of into the
legacy directory. I can't help wondering whether this could be triggering
a bug in dh_girepository that doesn't apply when the recommended directory
is used, or something like that.
I also notice that the name of the GIR package doesn't match its contents:
the package name claims to contain v_sim version 1.0, but the typelib is
v_sim version 3.7. This is the GObject-Introspection equivalent of making
sure that the package that contains libfoo.so.37 is libfoo37, or at least
Provides libfoo37.
This could be at least partially resolved without needing NEW by adding
Provides: ${gir:Provides} to the package containing the typelib. Ideally
also add the same Provides to whichever package contains the GIR XML (a
.gir file) - in this case that seems to be v-sim - which should result
in it having "Provides: gir1.2-v-sim-3.7-dev (= ${binary:Version})".
The advantage of having dh_girepository generate the Provides, instead of
hard-coding them, is that they will continue to be correct over time,
even if the API version of the typelib changes.
(And if you were to implement the nogir build-profile for easier
cross-compiling, they would automatically disappear in builds where the
GIR XML and typelib were not included - but that's probably not worth it
for this particular package.)
smcv
Re: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
On Thu, 27 Feb 2025 at 12:38:16 +0100, Alexandre Detiste wrote: > I ve my own take on this: I would MBF the (expected few) remaining users of > /usr/share/cdbs/1/class/gnome.mk > and then get rid of this one cdbs module. In general I'm in favour of conversion of packages from cdbs to dh, but if my analysis was correct, it was the conversion to dh that triggered this issue, not gnome.mk: the problem is that it wasn't immediately obvious what functionality gnome.mk was providing, so it wasn't immediately obvious when that functionality was lost during the conversion. Many of the few remaining users of cdbs (outside the Haskell team) are in undermaintained packages, and when a contributor converts a package they are not necessarily fully familiar with to a different packaging style, I think it's extra-important to double-check the result (debdiff, lintian, looking for warnings in the build log, etc.) to make sure nothing important was lost in that process. smcv
Re: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
El 27/2/25 a las 12:15, Simon McVittie escribió: Please add "Build-Depends: dh-sequence-gir" [...] Thanks a lot. I confirm that this makes the autopkgtests to work again. Additionally, there was a wrong declaration which made the build for i386 to fail, but it was easy to fix. I've pushed several commits for 3.8.0-1 and will tag & upload if they pass CI tests. Thanks.
Re: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
Hi, Am Thu, Feb 27, 2025 at 01:31:53PM +0100 schrieb Santiago Vila: > El 27/2/25 a las 12:15, Simon McVittie escribió: > > Please add "Build-Depends: dh-sequence-gir" [...] > I've pushed several commits for 3.8.0-1 and will tag & upload > if they pass CI tests. I'm super happy about Simon's and Santiago's commits (and for sure Sudip's inital push to fix the RC bug). Very nice team work. Finally we managed to get rid of one more cdbs package. ;-) BTW, I'm actively working on this except for Haskell. Kind regards Andreas. -- https://fam-tille.de
Re: Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
Hi Simon, Am Thu, Feb 27, 2025 at 11:58:12AM + schrieb Simon McVittie: > Many of the few remaining users of cdbs (outside the Haskell team) are > in undermaintained packages, and when a contributor converts a package > they are not necessarily fully familiar with to a different packaging > style, I think it's extra-important to double-check the result > (debdiff, lintian, looking for warnings in the build log, etc.) to make > sure nothing important was lost in that process. I fully subscribe this and thus I asked for help when I realised that not everything is working. Thank you again Andreas. -- https://fam-tille.de
jinja2 moved to DEP-14 layout
Hi,
as part of preparing a security update for jinja2/bookworm, I decided to move
the packaging layout to DEP-14 [0] (as this makes my life easier). This means a
few branches have been renamed:
master-> debian/latest
upstream -> upstream/latest
{stretch,buster-backports, bullseye-backports} -> debian/\1
Please update your local git repo and the tracking branches.
Greetings,
Lee
[0] https://dep-team.pages.debian.net/deps/dep14/
Please cancel NMU of v-sim + help needed for autopkgtest of new upstream version
Hi Sudip,
it seems I was to optimistic in fixing v-sim as quickly as expected so
I'm not sure whether it will hit the archive before the NMU. To avoid
changing the history in Git it would help if you would cancel the NMU.
Unfortunately I observed in Salsa CI that the autopkgtest is failing[1]
(in contrast to my test in local pbuilder). I have no clue how to fix:
autopkgtest [08:21:22]: test autodep8-python3: set -e ; for py in $(py3versions
-r 2>/dev/null) ; do cd "$AUTOPKGTEST_TMP" ; echo "Testing with $py:" ; $py -c
"import gi.overrides.v_sim; print(gi.overrides.v_sim)" ; done
autopkgtest [08:21:22]: test autodep8-python3: [---
Testing with python3.13:
Traceback (most recent call last):
File "", line 1, in
import gi.overrides.v_sim; print(gi.overrides.v_sim)
^
File "/usr/lib/python3/dist-packages/gi/overrides/v_sim.py", line 48, in
v_sim = get_introspection_module('v_sim')
File "/usr/lib/python3/dist-packages/gi/module.py", line 267, in
get_introspection_module
module = IntrospectionModule(namespace, version)
File "/usr/lib/python3/dist-packages/gi/module.py", line 114, in __init__
repository.require(namespace, version)
~~
gi.RepositoryError: Typelib file for namespace 'xlib', version '2.0' not found
autopkgtest [08:21:22]: test autodep8-python3: ---]
BTW, the autopkgtest was never run before, thought. So it would not be
a regression and thus not preventing testing migration. However, I
would prefer to document this issue and rather de-activate the test
providing some comment than just leaving it as is.
and I'm hereby asking for help in the Python team. Its perfectly
fine for me if you push a fix to Salsa and do some team upload -
no need to NMU.
Kind regards
Andreas.
[1] https://salsa.debian.org/science-team/v-sim/-/jobs/7166447
--
https://fam-tille.de
Re: Request to join the team
Hey, Arnaud Rebillout wrote on 27/02/2025 at 08:26:33+0100: > Hello team, > > I'd like to join in order to fix the recently introduced pyric package: > https://salsa.debian.org/python-team/packages/pyric/. > > There's an error with the version, this package has a version of > 0.1.6.3-2, however it's the 0.1.6 upstream tag that was imported. > > I already did some minor package updates in the Python team, usually > sponsored by Sophie (CC). > > My salsa login is arnaudr, and I'm also a DD arna...@debian.org. > > I have read > https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst > and I accept it. Welcome to the team! -- PEB signature.asc Description: PGP signature
silx autopkgtest failure
Hello, I am trying to solve this issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1099038 My question is why pytest try to create a file in the modules system library ? Thanks for your help. Fred
