Hi Thomas, On Wed, 26 Nov 2025 15:45:31 +0100 Thomas Dreibholz <[email protected]> wrote: > Hi, > > Den 22.11.2025 10:35, skrev Tobias Frost: > > (Partial review only, as too many undocumented changes. Please let us > > know *why* you are changing stuff in d/changelog.) > > The debian/ folder in HiPerConTracer's Git repository is intended to > work with for different versions of Ubuntu (for Launchpad PPA uploads), > as well as for Debian. To create the Debian version, the builder script > (https://github.com/dreibh/build-tools) should actually fetch the > official Debian changelog of the last Debian upload (1.6.7) and then > create a single, merged changelog entry for the new changes on top. > Something is wrong with this script, and the output contains unwanted > Ubuntu PPA changelog entries instead of the Debian variant. I need to > further debug and fix this.
> > d/changelog: > > - Don't have entries that have not been in Debian. > > - Remove those never uploaded "New upstream release" entries. > > - For the ones in Debian: You're rewriting history: The changelog in the archive is different > > than yours, > > - Interestinly, the changelog in the archives is missing the intial > > upload:https://tracker.debian.org/news/1281874/accepted-hipercontracer-163-1-source-i386-into-unstable-unstable/ > > When fixing the changelog, please make sure to retain the changelog > > entry of the initial upload. > > - There are *LOTS* of undocumented changes, e.g changes to d/control, > > d/copyright and many other files in d/ > > (This makes it very hard to review the package) > > Well, you losing history because of that; dh_installchangelog will truncate the changelog on binary packages ¹, so this workflow is flawed. ¹ thread starting at https://lists.debian.org/debian-devel/2022/08/msg00111.html I'd instead suggestiong adopting DEP14 and have a per-distribution branch for the packageing, maybe combined with automaic changelog generation from commit messages (gbp for example can help you). Ubuntu pulls from Debian - it would probably sense to focus on Debian and then let things flow natually to Ubuntu. I see the chicken-egg problem here, but focusing on a Ubuntu-first workflow will make things more complicated to get is sponsored in Debian - as this RFS clearly shows. So, repeating myself, adopt DEP14, have a dedicated Debian packaging branch. Frankly I'm relucant to sponsor this RFS because your workflow is not Debian focused. IOW, my remarks regarding the changelog are fixed in the term of you are no longer have wrong changelog entries, but you still rewriting history by truncating it. The source package should still contain the whole history. > > - The requested chang fromhttps://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095157#110 > > has not been implemented. The VCS field need to point where the *Debian > > packging* is happening. Regarding the dropping of the VCS field for the Debian package: we should have *more* packages in VCS, not less. (Salsa also allow CI etc, so it would be beneficial to have a copy on salsa. Git allow multiple remotes, so you can definityl have it additionally to your forge.) You package would definitly benefit from using DEP-14. > > d/control: > > - You change binary package names, libary package name, etc. Why? > > You are changeing SONAME - Do you need a library transistion? I > > think you want to target experimental first to clear NEW. (Answering myself) There seems no r-deps, so the renaming of library packages can be done without a transisiton.) > > > > d/lib*.install > > - Use usr/lib/${DEB_HOST_MULTIARCH}/ instead of usr/lib/*/ for > > multiarch paths. > For the next mentors' server upload, I am going to remove the Vcs-* > entries and change the library paths. Thanks for fixing! (I'm not tagging it moreinfo, I'm not happy with the changelog /packaging/VCS strategy, so I won't sponsor this; but if someone else thinks this is ok they still might sponsor.) -- tobi
