Control: tags -1 moreinfo
On Sun, Mar 17, 2024 at 04:57:54PM +0100, Jörg Frings-Fürst wrote:
> tags 1065193 - moreinfo
> thanks
>
> Hi Tobias,
>
>
>
> Am Sonntag, dem 17.03.2024 um 14:39 +0100 schrieb Tobias Frost:
> > Hi Jörg,
> >
> > "debcheckout libhx" still gives me 4.17-1 as head.
> >
> > After looking at your repo, I think I should point you to DEP-14
> > as a recommended git layout for packaging.
> > As the branch name indicates you are using per-package-revision
> > branches:
> > IMHO It makes little sense to have one branch per debian package
> > version/revision; (I had a similiar discussion on vzlogger lately,
> > so to avoid repetiions: #1064344#28)
> >
> > Please clarify how you want to manage the package in git, as
> > this needs to be reflected in d/control's VCS-* fields correctly.
> > (this is now blocking the upload.)
>
> I have been using Vincent Driessen's branching model and the corresponding git
> extension gitflow-avh for at least 7 years with Debian and for a long time at
> work.
>
> The default branch is master and development takes place in the develop
> branch.
>
> The release candidates are managed in the branch release. The extension
> debian/debian-version is used as a tag during the transfer.
>
> The master branch always contains the last published executable version to
> which
> the git tag in debian/control points.
>
a> The procedure is described in the README.debian.
ok, won't further argue about how to organize your git repo, but I can
only tell the Debian perspective: It is breaking expectations as a
debcheckout libhx does today NOT give me a state that represents the
package in unstable. VCS-Git specifies where the (package)
development is happening [1].
[1] Policy 5.6.26
But as I am not using the git repo as base for the sponsoring, lets put
that topic to rest.
> >
> > (The current fields say the package is maintained in the default branch
> > of your repo. I see a debian/ directory there, but that one is missing
> > released (it is at 4.17-1, while unstable is at 4.19-1.1)
> >
> > The review is based on the .dsc, timestamped on mentors.d.n
> > 2024-03-17 12:00
> >
> > d/changelog is *STILL* changing history for the 4.19-1 changelog
> > block. (This issue must be fixed before upload.)
> >
>
> I think these were artifacts because my changes to the NMU were not adopted.
> Has
> been corrected.
No it has not. I expect old changelog entries to be *identical* to
the ones that have been uploaded, and they still are not, so I fear
we are talking past each other. Please let me know what you think that
you have fixed, so that we can spot the different expectations.
For my perspective:
This is the diff from debian/changelog from the current
version in the archives and the dsc uploaded to mentors at 2024-03-17 14:45
You are still rewriting history (second hunk of this diff), this hunk
should not exists.
diff -Naur archive/libhx-4.19/debian/changelog
mentors/libhx-4.23/debian/changelog
--- archive/libhx-4.19/debian/changelog 2024-02-28 13:48:09.000000000 +0100
+++ mentors/libhx-4.23/debian/changelog 2024-03-17 15:23:31.000000000 +0100
@@ -1,3 +1,17 @@
+libhx (4.23-1) unstable; urgency=medium
+
+ * New upstream release (Closes: #1064734).
+ * Add debian/.gitignore
+ * Remove not longer needed debian/libhx-dev.lintian-overrides.
+ * Fix debian/libhx32t64.lintian-overrides.
+ * debian/copyright:
+ - Add 2024 to myself.
+ * debian/control:
+ - Readd BD dpkg-dev (>= 1.22.5).
+ Thanks to Tobias Frost <t...@debian.org>
+
+ -- Jörg Frings-Fürst <debian@jff.email> Sun, 17 Mar 2024 15:23:31 +0100
+
libhx (4.19-1.1) unstable; urgency=medium
* Non-maintainer upload.
@@ -9,11 +23,8 @@
* New upstream release.
- Refresh symbols files.
- * Remove empty debian/libhx-dev.symbols.
- * debian/rules:
- - Remove build of libhx-dev.symbols.
- -- Jörg Frings-Fürst <debian@jff.email> Sun, 17 Dec 2023 14:44:39 +0100
+ -- Jörg Frings-Fürst <debian@jff.email> Tue, 21 Nov 2023 10:41:07 +0100
libhx (4.14-1) unstable; urgency=medium
