Your message dated Sat, 5 Apr 2025 11:03:06 +0100
with message-id <[email protected]>
and subject line Re: Bug#1102086: game-data-packager: Not NMU-safe
has caused the Debian Bug report #1102086,
regarding game-data-packager: Not NMU-safe
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 [email protected]
immediately.)
--
1102086: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102086
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: src:game-data-packager
Version: 84
Hello.
While testing a patch for this package, versioned as 85.1,
I got this:
======================================================================
FAIL: test_version_number (__main__.AssertVersionMatches.test_version_number)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/../tests/version.py", line 81, in
test_version_number
self.assertEqual(
~~~~~~~~~~~~~~~~^
changelog.upstream_version,
^^^^^^^^^^^^^^^^^^^^^^^^^^^
GAME_PACKAGE_VERSION,
^^^^^^^^^^^^^^^^^^^^^
)
^
AssertionError: '85.1' != '85'
- 85.1
? --
+ 85
----------------------------------------------------------------------
which I understand we would much prefer not to happen.
btw: This package builds perfectly ok on the AWS machines
with 1 CPU where I tried, but fails to build 80% of the time
on machines with 2 CPUs. I was trying to see if --max-parallel=1
improved things. Unfortunately, it does not, so I will not
be able to propose a patch.
Thanks.
--- End Message ---
--- Begin Message ---
On Fri, 04 Apr 2025 at 22:01:15 +0200, Santiago Vila wrote:
While testing a patch for this package, versioned as 85.1
...
AssertionError: '85.1' != '85'
This package is NMU-safe if you follow the NMU convention that is
documented in devref. `dch --nmu` automates this.
(It seems that it actually fails to build from source right now because
we're having trouble running inkscape non-interactively to generate
icons from their "source code", but that's orthogonal to the version
numbering.)
If you use a version number with only dots and digits for a native
package, then you're claiming to be doing an upstream release, and using
up some of the upstream release namespace which is "owned" by the
package's maintainers. Please use something like 85+nmu1 instead, as
described in devref:
If the package is a native package (without a Debian revision
in the version number), the version must be the version of the
last maintainer upload, plus +nmuX, where X is a counter starting
at 1. If the last upload was also an NMU, the counter should be
increased. For example, if the current version is 1.5, then an NMU
would get version 1.5+nmu1.
—
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#non-maintainer-uploads-nmus
The purpose of tests/version.py is to verify that the version numbering
in debian/changelog and meson.build is consistent, because if we don't
have such a test, it's very easy to make a release that is not internally
consistent (claims to be upstream version 84 but packaged in Debian as
version 85, or similar). However, it's skipped for versions containing
+ or ~, which are assumed to be a distro-specific change.
If you were genuinely preparing a NMU to fix a RC issue after a lack of
maintainer response, it should be based on the version that is actually
in the archive, currently 84 (so it would be 84+nmu1), rather than the
version in git. Or, if you're merely suggesting a patch that you have no
intention of uploading to Debian yourself (effectively an upstream merge
request, but possibly in diff|patch format), there's no need to change
the changelog or version number - and, indeed, it's better if you don't,
because if every MR or patch updates the changelog, that guarantees that
every parallel contribution will have merge conflicts.
smcv
--- End Message ---
