Manuel,
Perhaps it would be helpful to talk about typical package maintenance workflows. These workflows show how it is easy to maintain two separate repositories, one for your upstream work and the other for your Debian work, and easily import the new upstream code with each release. Keeping these separate is important for Debian packaging. As I mentioned in a previous workflow, I personally like to maintain my upstream repository on my own Git server and the Debian packaging repository on Salsa.
1. You will always use two separate workflows for your release. The first workflow for your upstream release. The second workflow for your Debian packaging (which will be started after finishing the upstream workflow).
2. There are many, many, many workflows used by Debian Developers, often varying by the way upstream is organized, the language the software is written in, and developer preference. This is not an attempt to describe them all or tell you which is best for a particular scenario. But rather, to describe two of the common ones so you get the idea.
a. Old-school uscan.
Your Debian packaging repository contains one branch. This branch contains the current upstream and the debian directory. A release workflow is as follows.
a1. After finishing the upstream release workflow, you move to the local copy of your packaging repository and run uscan, which goes out and checks the upstream repository for the latest version, downloads the tarball to the parent directory, creates an orig.tar.gz link to it (so that Debian can find it under the expected name), unpacks it, and replaces everything in your repository except the debian directory with the content of the new upstream tarball. uscan is the magic sauce that makes this easy.
a2. Run dch to add a new changelog entry. Edit the version number to be correct and add an entry that says “New upstream release.” Make any other needed changes to the Debian directory and document them in the changelog.
a3. Build the package using sbuild or your building command of choice. Review the output of the build, including lintian, autopkgtests, and piuparts if sbuild is configured to run them. The build process automatically creates a debian.tar.xz that contain the contents of the debian directory.
a4. Use debsign to sign the source.changes file created during the build process. This automatically signs each of the files listed in the source.changes file.
a5. Use dput to upload the source.changes file. This automatically uploads all the files listed in source.changes, including the orig.tar.gz and debian.tar.xz.
a6. Push your changes to the git repository with git push.
The Debian buildds then check the signatures on all the files, unpack orig.tar.gz and debian.tar.xz and combine them, and build the binary packages. Note that when uploading to the NEW queue you sign and upload the amd64.changes, which includes the binary files as well. But otherwise, you only sign and upload the source.changes file.
So, in summary, the commands you would run for your Debian workflow (ignoring things like git commit and such):
uscan
dch
sbuild
debsign ../<packagename>_source.changes
dput ../<packagename>_source.change
git push
An example repository that uses this workflow is:
https://salsa.debian.org/fonts-team/fonts-adobe-sourcesans3
b. git-buildpackage.
git-buildpackage (gbp) is a more sophisticated packaging workflow. It has three branches in your packaging repository: master, upstream, and pristine-tar. Master is the same as the single repository described in the uscan workflow described above. Upstream just contains the upstream code. Pristine-tar can regenerate the orig.tar.gz.
You can read more about gbp at the following URL, including how to set it up. My purposes here will be just to document a basic workflow.
https://wiki.debian.org/PackagingWithGit
b1. After finishing the upstream release workflow, you move to the local copy of your packaging repository and run gbp import --uscan, which goes out and checks the upstream repository for the latest version, downloads the tarball to the parent directory, creates an orig.tar.gz link to it (so that Debian can find it under the expected name), unpacks it, replaces everything in your master branch except the debian directory with the content of the new upstream tarball, replaces the content of your uptream branch and tags it, and stores the original tarball delta in pristine-tar.
b2. Run dch to add a new changelog entry. Edit the version number to be correct and add an entry that says “New upstream release.” Make any other needed changes to the Debian directory and document them in the changelog. (Note that there is a gbp dch command, but I personally choose not to use it. You can read more about it by running man gbp dch.)
b3. Build the package using gbp buildpackage, which calls your building command of choice (I have it set to run sbuild). Review the output of the build, including lintian, autopkgtests, and piuparts if it is configured to run them. The build process automatically creates a debian.tar.xz that contain the contents of the debian directory.
b4. Use debsign to sign the source.changes file created during the build process.
b5. Use dput to upload the source.changes file.
b6. Run gbp tag. This adds a tag for the release to master.
b7. Run gbp push. This pushes master, upstream, and pristine-tar as well as the tags on master and upstream.
So, in summary, the commands for this workflow are (ignoring things like git commit and such):
gbp import --uscan
dch
gbp buildpackage
debsign ../<packagename>_source.changes
dput ../<packagename>_source.change
gbp tag
gbp push
gbp has some nice advantages. For example, if someone else needs to build your package (like for an NMU) they can simply run gbp buildpackage and it will generate the orig.tar.gz from pristine-tar instead of downloading it using uscan.
An example repository that uses this workflow is:
https://salsa.debian.org/soren/privacybrowser
There is significant danger is posting any description about workflows to Mentors. If you get 3 Debian Developers in a room together they will have 17 different opinions about the best workflow, which means this is likely to generate a lot of responses about how each individual step could be improved. My purpose isn’t to try to say these are the only or best ways to do things, but rather to demonstrate the type of workflow that makes it easy to maintain separate upstream and Debian packaging repositories and easily get the new upstream data into the Debian package with each release.
Soren
Soren
I really want to use only Salsa, but i cant raise the release tags in debian/watch using Salsa, was easy in Github but for any reason i cant configure properly the debian/watch file using Salsa and for that reason i need to push the files two times to both vcs salsa and github
The lintian tag "no-debian-changes" is solved adding a debian/patches directory but an empty directory is unable to upload to the repository
Please i wait for your suggestions, thanks!
Manuel
El lun, 29 de jul. de 2024 19:54, Soren Stoutner <soren@debian.org> escribió:
Manuel,
On Monday, July 29, 2024 3:18:33 PM MST Manuel Guerra wrote:
> Soren
>
> I see in your output version 1.0.55, actual version is 1.0.57, please use
> the repository at https://github.com/manuwarfare/baby.git
>
> By this way I actually build good using sbuild
>
> I (re)moved the package files from Salsa to Github :-(
I’m curious as to why you decided to do this (see more discussion below).
> Please advise me if the issues was solved. Thanks!
This did resolve the build problem. However, it introduced a new problem.
W: baby source: no-debian-changes
N:
N: This non-native package makes no changes to the upstream sources in the
N: Debian-related files.
N:
N: Maybe a mistake was made when the upstream tarball was created, or maybe
N: this package is really a native package but was built non-native by
N: mistake.
N:
N: Debian packaging is sometimes maintained as part of upstream, but that is
N: not recommended as best practice. Please make this package native, if the
N: software is only for Debian. Otherwise, please remove the debian
directory
N: from upstream releases and add it in the Debian packaging.
N:
N: Format 1.0 packages are subject to the restriction that the diff cannot
N: remove files from the debian directory. For Format 3.0 packages, the
N: debian directory is automatically purged during unpacking.
N:
N: Visibility: warning
N: Show-Always: no
N: Check: files/artifact
N: Renamed from: empty-debian-diff
Basically, a non-native package like yours should not contain a debian
directory in the orig.tar.gz. That directory should only exist in the
debian.tar.xz. That means that uscan needs to point to a repository or a
tarball that doesn’t contain a debian directory.
There are several ways you can do this (the following is probably not an
exhaustive list).
1. Use a separate branch in your upstream repository for the Debian
packaging.
2. Use a separate repository on github for the Debian packaging.
3. Handle the Debian packaging on Salsa.
For the purposes of sponsoring your package, it doesn’t matter to me which of
these solutions you choose. For me personally, where I am both upstream and
the package maintainer, I have gone with option 3.
https://gitweb.stoutner.com/?p=PrivacyBrowserPC.git;a=tree
https://salsa.debian.org/soren/privacybrowser
However, it is fine if you decide not to use Salsa for any reasons that are
important to you.
Soren
--
Soren Stoutner
soren@debian.org
-- Soren Stoutner soren@stoutner.com
Attachment:
OpenPGP_0x2D48F45A7EBE8C12.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature