[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: anna_1.68_source.changes ACCEPTED into unstable


Cyril Brulebois <kibi@debian.org> wrote:
> Hello,
> Here are some answers. Feel free to (re)organize them in a wiki page
> under the DebianInstaller namespace. :)

If have documented the l10n-uploading procedere on the wiki, to be found at 


> Holger Wansing <hwansing@mailbox.org> (2018-08-10):
> > Yes, and I didn't read anything about that in the several
> > packaging/uploading docu. So that's mostly best practice, but no
> > strict packaging rule or the like?
> > 
> > Also, I don't know anything about tagging.  So, I need to know
> > something more about this tagging:
> > 
> > When do we use it?
> > Just for every new uploaded version, as it seems...
> > More circumstances, where to set tags?
> I think most if not all packaging teams create tags when they upload a
> given revision of a source package; this even existed prior to git! :)
> This makes it possible to identify what revision of source code was
> (probably, no absolute guarantee) used to create a given package,
> which limits the need for downloading entire history of source
> packages using debsnap and friends.
> > Which tags do we use? The lightweighted or the annotated ones?
> > Looking at the existing tags, it seems that's annotated ones, but
> > without GPG signatur. Right?
> I tend to use this when releasing:
>   git commit -am 'releasing version $copied_from_changelog'
>   git tag -sm 'tagging version $copied_from_changelog' $copied_possibly_adapted_from_changelog
> If you don't have a GPG key handy (but then how would you debsign your
> upload?), you might want to use “git tag -am” instead of “git tag -sm”,
> which indeed creates an annotated tag, which still contains meta data
> like the tagger, a message, etc.; except for the GPG signature part.
> Interesting points:
>  - you can mention the real/complete version in there;
>  - you can verifiy the GPG signature if you ever doubt the repository
>    (remember we have rather broad access with many many users on
>    alioth first and on salsa now);
>  - “git describe” doesn't use lightweight tags by default, one needs
>    to pass “--tags”, so annotated/signed tags are better for that as
>    well.
> What about those versions?
>  - $copied_from_changelog: hopefully self-explanatory :)
>  - $copied_possibly_adapted_from_changelog: there are special
>    characters that can be used in Debian version numbers, but cannot
>    be used directly in git (like ':' and '~'), so we have to adjust
>    for those.
> Examples for ':' include apt-setup, busybox, tzsetup; depending on the
> habits of the person who uploads them, the epoch part (N:) is
> sometimes removed entirely (there can be a single version in the
> Debian archive of a given package, regardless of the epoch part,
> anyway). Usual replacement character is '%'.
> Examples for '~' include all packages we backport using the usual
> scheme: $unstable_version~deb9u1. Usual replacement character is '_'.
> People might use git-buildpackage which has some tagging options,
> but I tend to find the command line overly long, and it prefixes
> tags with a debian/ string, which we doesn't really make sense in a
> d-i context since most packages are Debian-specific anyway. We could
> arguable ship a configuration file in all packages, but I'm not sure
> we need more administrativia…
> Maybe we should just have a tagging script in the scripts/ directory?
> I used to use “xsf-tag” in the X Strike Force:
>   https://salsa.debian.org/xorg-team/debian/xsf-tools/blob/master/xsf-tag
> What do you think?
> Cheers,
> -- 
> Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
> D-I release manager -- Release team member -- Freelance Consultant

Created with Sylpheed 3.5.1 under 
	D E B I A N   L I N U X   9   " S T R E T C H " .

Registered Linux User #311290 - https://linuxcounter.net/

Reply to: