Packaging an apparently unreleased Git repository
Hi, I'd like to package rust-mode (cf. https://github.com/rust-lang/rust-mode). There is a version number in the source code (i.e., 0.2.0), but I haven't been able to find any releases or tags. I'd like to know if there are any best practices for handling the .orig.tar and the version number. I've tentatively created a tar archive of the latest Git revision (minus the .git directory) and named it elpa-rust-mode_0.2.0.orig.tar.gz. I have also set the package version to 0.2.0-1. Does anyone have a better suggestion? -- Matt
Re: Packaging an apparently unreleased Git repository
did you try to run the command "origtargz"? cheers, G. Il Giovedì 28 Gennaio 2016 9:02, Matt Kraai ha scritto: Hi, I'd like to package rust-mode (cf. https://github.com/rust-lang/rust-mode). There is a version number in the source code (i.e., 0.2.0), but I haven't been able to find any releases or tags. I'd like to know if there are any best practices for handling the .orig.tar and the version number. I've tentatively created a tar archive of the latest Git revision (minus the .git directory) and named it elpa-rust-mode_0.2.0.orig.tar.gz. I have also set the package version to 0.2.0-1. Does anyone have a better suggestion? -- Matt
Re: Packaging an apparently unreleased Git repository
On Wed, Jan 27, 2016 at 11:33:49PM -0800, Matt Kraai wrote:
> Hi,
>
> I'd like to package rust-mode
> (cf. https://github.com/rust-lang/rust-mode). There is a version
> number in the source code (i.e., 0.2.0), but I haven't been able to
> find any releases or tags. I'd like to know if there are any best
> practices for handling the .orig.tar and the version number.
>
> I've tentatively created a tar archive of the latest Git revision
> (minus the .git directory) and named it
> elpa-rust-mode_0.2.0.orig.tar.gz. I have also set the package version
> to 0.2.0-1. Does anyone have a better suggestion?
Please ask the upstream maintainers to create a release tag. If you can not
convince them you could package a specific git commit, but first try to get
a release tag.
Otherwise you should not just name the package 0.2.0-x but make sure that
you include the git commit id like:
0.2.0~git20160116.1.fa5b38f-1
This version will sort before a real 0.2.0 version:
% dpkg --compare-versions 0.2.0~git20160116.1.fa4b38f-1 lt 0.2.0-1 && echo
"true"
true
Parts of that version are defined like this:
0.2.0 is the version that will eventually be released
~ makes it sort before an actual 0.2.0 release
git is just to make it human readable that git is involved
20160616 date of the commit in the upstream repository in sortable order
1 version of upstream on that date (if you want to package another
commit from the same date for hotfixes for example)
fa5b38f shortened git commit hash
-1debian revision
This will allow you to properly package later upstream version when new
commits occur. I came up with this suggestion after I had a look at the
versions of packages installed on my system:
% dpkg -l|awk '{ print $3 }'|grep git|sort -u
Best regards
Jan
--
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD
https://jan.dittberner.info/
signature.asc
Description: Digital signature
Re: Packaging an apparently unreleased Git repository
Hi, On Thu, Jan 28, 2016 at 08:41:49AM +, Gianfranco Costamagna wrote: > did you try to run the command > "origtargz"? No, I didn't know that program existed. Thanks for the suggestion. Unfortunately, it wasn't able to find anything. -- Matt
Re: Packaging an apparently unreleased Git repository
Hi,
On Thu, Jan 28, 2016 at 09:46:41AM +0100, Jan Dittberner wrote:
> On Wed, Jan 27, 2016 at 11:33:49PM -0800, Matt Kraai wrote:
> > Hi,
> >
> > I'd like to package rust-mode
> > (cf. https://github.com/rust-lang/rust-mode). There is a version
> > number in the source code (i.e., 0.2.0), but I haven't been able to
> > find any releases or tags. I'd like to know if there are any best
> > practices for handling the .orig.tar and the version number.
> >
> > I've tentatively created a tar archive of the latest Git revision
> > (minus the .git directory) and named it
> > elpa-rust-mode_0.2.0.orig.tar.gz. I have also set the package version
> > to 0.2.0-1. Does anyone have a better suggestion?
>
> Please ask the upstream maintainers to create a release tag. If you can not
> convince them you could package a specific git commit, but first try to get
> a release tag.
>
>
> Otherwise you should not just name the package 0.2.0-x but make sure that
> you include the git commit id like:
>
> 0.2.0~git20160116.1.fa5b38f-1
>
> This version will sort before a real 0.2.0 version:
>
> % dpkg --compare-versions 0.2.0~git20160116.1.fa4b38f-1 lt 0.2.0-1 && echo
> "true"
> true
>
> Parts of that version are defined like this:
>
> 0.2.0 is the version that will eventually be released
> ~ makes it sort before an actual 0.2.0 release
> git is just to make it human readable that git is involved
> 20160616 date of the commit in the upstream repository in sortable order
> 1 version of upstream on that date (if you want to package another
> commit from the same date for hotfixes for example)
> fa5b38f shortened git commit hash
> -1debian revision
>
> This will allow you to properly package later upstream version when new
> commits occur. I came up with this suggestion after I had a look at the
> versions of packages installed on my system:
>
> % dpkg -l|awk '{ print $3 }'|grep git|sort -u
Thanks for the information! I'll ask upstream to create a release tag
and, if they don't, follow the version number convention you
specified.
Thanks again,
--
Matt
Again about Multi-Arch and Pre-Depends
Hi,
i need advise about
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020
where Matthias Klose asks me to add
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
to debian/control.
I have asked here about this topic a few months ago
https://lists.debian.org/debian-mentors/2015/09/msg00403.html
and understood from the replies that i should not have these
lines in debian/control. See my message links in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020#15
Did i get the answers wrong ?
Does Matthias have a point which was not considered in september ?
Is there reason not to fulfill his wish ?
Have a nice day :)
Thomas
Re: Again about Multi-Arch and Pre-Depends
Hi, Gianfranco Costamagna wrote: > Seems you already got your answer :) Is this an encrypted "No" to > > Is there reason not to fulfill his wish ? Have a nice day :) Thomas
Re: Again about Multi-Arch and Pre-Depends
Seems you already got your answer :)
cheers,
G.
Il Giovedì 28 Gennaio 2016 18:03, Thomas Schmitt ha scritto:
Hi,
i need advise about
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020
where Matthias Klose asks me to add
+Multi-Arch: same
+Pre-Depends: ${misc:Pre-Depends}
to debian/control.
I have asked here about this topic a few months ago
https://lists.debian.org/debian-mentors/2015/09/msg00403.html
and understood from the replies that i should not have these
lines in debian/control. See my message links in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020#15
Did i get the answers wrong ?
Does Matthias have a point which was not considered in september ?
Is there reason not to fulfill his wish ?
Have a nice day :)
Thomas
Re: Again about Multi-Arch and Pre-Depends
It is a... Read the bug report and look for doko's answer :) G. Sent from Yahoo Mail on Android On Thu, 28 Jan, 2016 at 18:18, Thomas Schmitt wrote: Hi, Gianfranco Costamagna wrote: > Seems you already got your answer :) Is this an encrypted "No" to > > Is there reason not to fulfill his wish ? Have a nice day :) Thomas
Re: Packaging an apparently unreleased Git repository
Hello Tiago, > Although you did suggested a pretty detailed version string, this is > really needed at all? > > [...] > > If you need to invent a version string, use the MMDD format > such as 20110429 as upstream version. [...] > > This approach is simpler, work as intended and is documented on one > of our official guidelines for packaging. Since git is a distributed VCS, a given date might not be sufficient to get the exact version, because some developer might edit the source off -line, and push changes on a later date to the remote repo, but the commits will carry the date when developer committed the changes to her local repo. Therefore, adding the commit sha is the only way to be sure that you correctly reference the source tree used to create a package. And adding a "git" somewhere in the version string makes sure that one knows how to interpret the version string properly :) Best, Gert
Re: Packaging an apparently unreleased Git repository
On Thu, 2016-01-28 at 11:40 -0700, Sean Whitton wrote: > An alternative that is perhaps worth considering is the output of > git-describe(1). > This requires at least one tag, without any tags it returns: > git describe --tags > fatal: No names found, cannot describe anything. Best, Gert
Re: Packaging an apparently unreleased Git repository
Jan, On 28 January 2016 at 06:46, Jan Dittberner wrote: > Otherwise you should not just name the package 0.2.0-x but make sure that > you include the git commit id like: > > 0.2.0~git20160116.1.fa5b38f-1 > > This version will sort before a real 0.2.0 version: > > (...) > > This will allow you to properly package later upstream version when new > commits occur. I came up with this suggestion after I had a look at the > versions of packages installed on my system: Although you did suggested a pretty detailed version string, this is really needed at all? The Debian New Maintainers' Guide states[1] that: "... If you need to invent a version string, use the MMDD format such as 20110429 as upstream version. This ensures that dpkg interprets later versions correctly as upgrades. If you need to ensure smooth transition to the normal version scheme such as 0.1 in future, use the 0~YYMMDD format such as 0~110429 as upstream version, instead." This approach is simpler, work as intended and is documented on one of our official guidelines for packaging. Regards, Tiago. [1]: https://www.debian.org/doc/manuals/maint-guide/first.en.html#namever -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
Re: Again about Multi-Arch and Pre-Depends
+++ Thomas Schmitt [2016-01-28 18:04 +0100]:
> Hi,
>
> i need advise about
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813020
> where Matthias Klose asks me to add
> +Multi-Arch: same
> +Pre-Depends: ${misc:Pre-Depends}
> to debian/control.
The pre-depends is no longer needed. It was a transitionary measure for
upgrading from squeeze.
Adding the "Multi-Arch: same" field to libraries (and making them install in
the arch-specific localtions) is good.
So yes, apply doko's patch, and just remove the Pre-Depends: line as it is no
longer needed.
Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: Digital signature
Re: Packaging an apparently unreleased Git repository
An alternative that is perhaps worth considering is the output of git-describe(1). -- Sean Whitton signature.asc Description: PGP signature
Bug#812922: RFS: classic-theme-restorer/1.4.6.1-1 [ITP] -- customize the new Iceweasel look
On Thu, Jan 28, 2016 at 09:18:25PM +0100, Jakub Wilk wrote: > I don't intend to sponsor this package, but here's a quick review: Thanks for the review. > * Sean Whitton , 2016-01-27, 14:43: > >http://mentors.debian.net/debian/pool/main/c/classic-theme-restorer/classic-theme-restorer_1.4.6.1-1.dsc > > The Homepage field looks broken: > > $ grep-dctrl -ns Homepage '' debian/control | xargs wget -nv > https://addons.mozilla.org/en-US/firefox/addon/classic-theme-restorer/: > 2016-01-28 21:14:54 ERROR 404: NOT FOUND. Fixed, thanks. > Please consider using amo-changelog(1) for generating a less dummy > upstream changelog. Done -- nice tool! > Typos: positiom -> position ootion -> option overriden -> overridden These are all in comments in upstream's code; I don't think it's worth submitting patches upstream for these non-user-visible typos. > Why is debian-watch-may-check-gpg-signature overridden? (You can > answer by adding a comment to the override file.) Comment added (signatures not provided; request made to upstream). -- Sean Whitton signature.asc Description: PGP signature
Bug#810921: RFS: rep-gtk/1:0.90.8.2-1 [ITA] -- GTK+ binding for librep
Sorry for taking a long time to reply, adding my delay I had email problems. On Thu, Jan 14, 2016 at 12:13:29AM +, Mattia Rizzolo wrote: > On Wed, Jan 13, 2016 at 07:12:38PM +, Jose M Calhariz wrote: > > * Package name: rep-gtk > > ok, let the party begin! :) > > * you removed a old transition package. > + \o/ yay less cruft in the archive! > + FYI, I confirmed by `dak rm -Rbn rep-gtk-gnome` that it is a leaf > package. > + also please remove debian/rep-gtk-gnome.NEWS Done > * debian/control: > + a version costriction in a Suggest is really useless. As in, you > have no assurances *at all* that it'll be followed. > But then, you build-dep on librep >= $version, so you'll get a > depends on that version, so not all might be lost :) > tl;dr: you don't need to do anything here, but be aware that > versioned Suggests are meaningless. > + the build-dep on autotools-dev is useless, please remove it. Done > + I still get vcs-field-not-canonical by lintian. indeed Vcs-Git is > wrong (there is a /git/ too much in the middle). otherwise, you > might want to use https:// for Vcs-Git too instead of the dumb > git://. As you prefer. Done > + I have a extended-description-is-probably-too-short, please fix. I don't know what to add to the description so requested the help of Upstream. > * debian/changelog: > + 2 trailing whitespaces at line 4. Done > + "remove upstream debian directory" ??? what's this? > + "New localization of files for package rep-gtk." and this? > + "Replace sed command by dh_listpackages." this is not there anymore > + "Merge the packaging work of Christopher Roy Bratusek." be more > verbose in this. short dh, compat 9, dep5, blablabla Done > + s/read ability/readability/ maybe? Done > + mention the removal of rep-gtk-gnome. Done > + you need to target experimental, unstable won't be able to satisfy > the dependency on librep until the transition start (where you'll > need to re-upload the packages on unstable. actually it would be > enough to have them ready, bug given that there are a lot of > changes, and you are a sponsored person where there are reviews > going on, better have them in experimental, and re-upload them in > unstable later). Done > * debian/rules: > + override_dh_configure is unneed. as I said with librep, those flags > are already exported in compat 9. > - also , there is trailing whitespace here, but if you remove the > whole line... > + override_dh_install just to call dh_install ? ;) Need to cleanup gtk.la as is needed because of https://bugs.debian.org/684443 > + override_dh_installexamples => be aware you can also write the > directory name in debian/examples (up to you if you prefer small > files in debian/ or lines in d/rules) No preference, so I am going for lines in d/rules > + don't DH_VERBOSE need to be exported to work? > * you're building static libraries. Do you really need them? In Debian > we don't like static libraries. Given that this is a standard autofoo > package, --disable-static to configure should do the trick. > + this will also get rid of unstripped-static-library and > non-empty-dependency_libs-in-la-file lintian tags. See https://bugs.debian.org/684443 > * something to say about https://bugs.debian.org/680449 ? > No longer makes sense with the new version. When this rep-gtk and sawfish hit experimental I will ask user to try again. Kind regards Jose M Calhariz -- -- Cerveja? Serve já! signature.asc Description: Digital signature
Bug#812922: RFS: classic-theme-restorer/1.4.6.1-1 [ITP] -- customize the new Iceweasel look
I don't intend to sponsor this package, but here's a quick review: * Sean Whitton , 2016-01-27, 14:43: http://mentors.debian.net/debian/pool/main/c/classic-theme-restorer/classic-theme-restorer_1.4.6.1-1.dsc The Homepage field looks broken: $ grep-dctrl -ns Homepage '' debian/control | xargs wget -nv https://addons.mozilla.org/en-US/firefox/addon/classic-theme-restorer/: 2016-01-28 21:14:54 ERROR 404: NOT FOUND. Please consider using amo-changelog(1) for generating a less dummy upstream changelog. Typos: positiom -> position ootion -> option overriden -> overridden Why is debian-watch-may-check-gpg-signature overridden? (You can answer by adding a comment to the override file.) -- Jakub Wilk
Re: Packaging an apparently unreleased Git repository
Gert, On 28 January 2016 at 15:49, Gert Wollny wrote: > Hello Tiago, > > Since git is a distributed VCS, a given date might not be sufficient to > get the exact version, because some developer might edit the source off > -line, and push changes on a later date to the remote repo, but the > commits will carry the date when developer committed the changes to her > local repo. > > Therefore, adding the commit sha is the only way to be sure that you > correctly reference the source tree used to create a package. And > adding a "git" somewhere in the version string makes sure that one > knows how to interpret the version string properly :) You're completely right. I've not considered the "late push" use case, which can happen even in a perfect-linear-and-rebased tree, resulting in "newer" (at least appearing to be most recent in the tree) commits with older dates. Thanks, Tiago. -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://br.linkedin.com/in/myhro Montes Claros - MG, Brasil
