debian-watch-file-in-native-package

[malat]

Hi,

  I am looking at the following lintian warning:

http://lintian.debian.org/maintainer/debian-med-packaging@...#gdcm

  but I do not understand why GDCM is now considered a native debian
package. I could not figure out what I did ...

Thanks for suggestion,
--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Paleino]

Mathieu Malaterre wrote:

> Hi,

Hello Mathieu,

>   I am looking at the following lintian warning:
>
> http://lintian.debian.org/maintainer/debian-med-
packaging@...#gdcm
>
>   but I do not understand why GDCM is now considered a native debian
> package. I could not figure out what I did ...

You uploaded it as a native package, indeed.

$ apt-cache showsrc gdcm | grep -A3 Files
Files:
 851a19ca0fc3e8651c493c823b966d0f 1773 gdcm_2.0.13-2.dsc
 fdf50988b722e51cf86291496affa117 3350247 gdcm_2.0.13-2.tar.gz
Uploaders: Mathieu Malaterre <mathieu.malaterre@...>, Andreas Tille
<tille@...>, Steve M. Robbins <smr@...>
$

I would've expected to find a .dsc, an .orig.tar.gz and a .diff.gz.

> Thanks for suggestion,

I suggest you to correctly re-upload your package :)

Kindly,
David

--
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

On Sat, Nov 7, 2009 at 4:13 PM, David Paleino <d.paleino@...> wrote:

> Mathieu Malaterre wrote:
>
>> Hi,
>
> Hello Mathieu,
>
>>   I am looking at the following lintian warning:
>>
>> http://lintian.debian.org/maintainer/debian-med-
> packaging@...#gdcm
>>
>>   but I do not understand why GDCM is now considered a native debian
>> package. I could not figure out what I did ...
>
> You uploaded it as a native package, indeed.
>
> $ apt-cache showsrc gdcm | grep -A3 Files
> Files:
>  851a19ca0fc3e8651c493c823b966d0f 1773 gdcm_2.0.13-2.dsc
>  fdf50988b722e51cf86291496affa117 3350247 gdcm_2.0.13-2.tar.gz
> Uploaders: Mathieu Malaterre <mathieu.malaterre@...>, Andreas Tille
> <tille@...>, Steve M. Robbins <smr@...>
> $
>
> I would've expected to find a .dsc, an .orig.tar.gz and a .diff.gz.
>
>> Thanks for suggestion,
>
> I suggest you to correctly re-upload your package :)

What is wrong with the following steps:

tar -xzf *.orig.tar.gz
cd <source-directory>
cp -a <svn-pkg-dir>/trunk/debian .
rm -rf `find . -type d -name .svn`
pdebuild --auto-debsign --debsign-k 0EA23F2B
dupload /var/cache/pbuilder/result/*gdcm*

Thanks,
--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Paleino]

No need to CC me, thanks :)
Even if I'm not (anymore) active in the team, I follow the mailinglist,
hoping I can find something I would be useful to.

Mathieu Malaterre wrote:

> On Sat, Nov 7, 2009 at 4:13 PM, David Paleino <d.paleino@...> wrote:
>> I suggest you to correctly re-upload your package :)
>
> What is wrong with the following steps:
>
> tar -xzf *.orig.tar.gz
> cd <source-directory>
> cp -a <svn-pkg-dir>/trunk/debian .
> rm -rf `find . -type d -name .svn`

Almost wrong, I'd say. It should work, but it's not as foolproof as one
would expect.

Please, learn to use the SVN property "mergeWithUpstream". In short:

cd trunk/
svn propset mergeWithUpstream 1 debian
svn ci -m "Merge the svn source with upstream"

(I might have missed the correct order for "svn propset" -- I'm using git
now for most of my things)

> pdebuild --auto-debsign --debsign-k 0EA23F2B

After you set mergeWithUpstream, you should do: $ svn-do
This will export your svn debian/ and the original tarball (which usually is
in ../tarballs/) into ../build-area/gdcm-somethingrandom/. There you can
work, and do patches and whatever. As soon as you do "exit", any new/changed
file in gdcm-random/debian/ would be copied over your SVN debian/. This is
to work on the packaging.

To just build for upload, svn-buildpackage is your friend (from the trunk/
directory).

I suggest you to have a look at our policy, in particular:
  http://debian-med.alioth.debian.org/docs/policy.html#id304574

(At other people: since I've been using git for a while, I might have some
tips to ease development with it. Please tell me if you're interested in a
policy paragraph for it :))

> dupload /var/cache/pbuilder/result/*gdcm*

I'd suggest you to only upload *.changes files. *gdcm*ch* could be ok :)

Kindly,
David

--
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Sat, Nov 07, 2009 at 07:06:48PM +0100, David Paleino wrote:
> (At other people: since I've been using git for a while, I might have some
> tips to ease development with it. Please tell me if you're interested in a
> policy paragraph for it :))

This would be *really* interesting.  PLease do so if you would be able
to spend some time on it.  I know that pkg-games team has a quite usual
description in the wiki (as well as others most probably, but I once
followed this description successfully).

Kind regards

     Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Paleino]

Andreas Tille wrote:

> On Sat, Nov 07, 2009 at 07:06:48PM +0100, David Paleino wrote:
>> (At other people: since I've been using git for a while, I might have
>> some tips to ease development with it. Please tell me if you're
>> interested in a policy paragraph for it :))
>
> This would be *really* interesting.

Great!

> PLease do so if you would be able to spend some time on it.

I'm starting on it now, but remember I only have internet access on
weekends, so don't expect messages from me during the week (unless I'm home,
that is).

> I know that pkg-games team has a quite usual description in the wiki (as
> well as others most probably, but I once followed this description
> successfully).

Well, I'm using git for all my personal packages, and I even retired some
packages from team-maintainance because they used SVN (see: wicd from PAPT).
I find that git is far more flexible than SVN, especially regarding branches
:) (extra useful if you have to maintain backports, uploads to p-u,
experimental, [..])

I also have a set of "helper scripts", which let me build each package for:
karmic, jaunty, lenny, squeeze, sid :) (ok, Ubuntu distros might not be of
interest for the team, but are when upstream asks you ;))

I will shortly post a patch to policy.xml for review. I will only write how
to use git for uploads to sid -- and I will post some of my helper scripts
in the thread to see whether they're worth including in the policy.

Kindly,
David

--
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Paleino]

David Paleino wrote:

> I will shortly post a patch to policy.xml for review.

Here's a patch. It's a general guideline, it can be improved (but ENOTIME
right now :))

Regarding my "helper tools", here's an example:

---8<---
$ cat /home/neo/bin/cow-lenny

#!/bin/bash
sudo cowbuilder $* --basepath /usr/src/base-lenny.cow/

$ cat /home/neo/bin/git-pbuilder-lenny

#!/bin/sh
set -e

pdebuild --pbuilder cowbuilder \
        --debbuildopts "-i\.git -I.git $*" -- \
        --basepath /usr/src/base-lenny.cow/
rm ../*_source.changes

$ alias git-b-lenny
alias git-b-lenny='git-b --git-builder=~/bin/git-pbuilder-lenny'
$ alias git-b
alias git-b='git-buildpackage --git-ignore-new'
$
--->8---

Obviously change "lenny" with whatever you wish. Just running "git-b-lenny"
on the master branch, will build the package for lenny (after a "cow-lenny
--update").

If anyone feels like including this in Policy as well.. :)

Kindly,
David

--
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
[git-policy.patch]

---

Index: policy.xml
===================================================================
--- policy.xml (revisione 4319)
+++ policy.xml (copia locale)
@@ -330,6 +330,8 @@
 
  <sect2>
  <title>Injecting a new package</title>
+            <sect3>
+ <title>Subversion</title>
  <para>To inject a new package to the SVN repository, you must have
  write access to it; i.e. you must be a member of the <emphasis>debian-med</emphasis> group on Alioth.</para>
  <para>You can inject a new package only after successfully building
@@ -350,9 +352,102 @@
  debian-med Blend package in SVN. Normally maintainer watch the changes in
  the Debian Med packaging pool but it helps if the maintainer of a
  certain package verifies that everything is in the right place.</para>
- </sect2>
- <sect2>
+ </sect3>
+ <sect3>
+                <title>Git</title>
+                <sect4>
+                    <title>Creating a local repository</title>
+                    <para>Just a few instructions to get you started:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>mkdir</command>
+                            <filename class="directory">package-version</filename>
+                            <option># this is just to make dh_make happy</option>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>cd</command>
+                            <filename class="directory">package-version</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git</command>
+                            <option>init</option>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git import-orig</command>
+                            <filename>/path/to/package_version.orig.tar.gz</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>dh_make</command>
+                        </userinput></para>
+                    </blockquote>
+                    <para>The above steps will create a repository with the appropriate layout for
+                    <command>git-buildpackage</command>, with three branches: <filename>master</filename>
+                    (where the Debian development will happen), <filename>pristine-tar</filename>,
+                    used by the <command>pristine-tar</command> tool during the package build process
+                    to recreate the original tarball, and <filename>upstream</filename>, which will
+                    contain the upstream source.</para>
+                    <para>After you create your <filename class="directory">debian/</filename> (be sure
+                    to commit it!), you should add a <quote>remote</quote> to the repository. A remote is
+                    where the commits will be pushed to, and the default remote is called <quote>origin</quote>.</para>
+                    <para>If you are going to push to our Alioth repository, please do the following inside your
+                    local repository:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git remote add origin</command>
+                            <filename class="directory">git+ssh://alioth.debian.org/git/debian-med/package.git</filename>
+                        </userinput></para>
+                    </blockquote>
+                    <para>The next step is to create the remote repository on Alioth.</para>
+                </sect4>
+                <sect4>
+                    <title>Creating the remote repository</title>
+                    <blockquote>
+                        <para><userinput>
+                            <command>ssh</command>
+                            <filename class="directory">alioth.debian.org</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>cd</command>
+                            <filename class="directory">/git/debian-med</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>./setup-repository</command>
+                            <option>packagename</option>
+                            <option>"Description of the package"</option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>This will create a <filename class="directory">packagename.git</filename> repository on
+                    Alioth, with the proper hooks set up for our team.</para>
+                </sect4>
+                <sect4>
+                    <title>Pushing the package</title>
+                    <para>To push the package (make sure you've added the alioth remote!), do the following:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git push origin master</command>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git push</command>
+                            <option>--all</option>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git push</command>
+                            <option>--tags</command>
+                        </userinput></para>
+                    </blockquote>
+                    <para>For the first push, it's necessary to specify <quote>origin master</quote>. The next time
+                    you will push, a <command>git push</command> will suffice. Remember that this will only push the
+                    <quote>master</quote> branch (and the other two only if master is somehow related to the new
+                    branches), so be sure to also do a run with <option>--all</option>, and one with
+                    <option>--tags</option> (if you obviously changed anything in the other branches/tags).</para>
+                </sect4>
+            </sect3>
+        </sect2>
+        <sect2>
+            <sect3>
  <title>Building the packages</title>
+            <sect4>
+            <title>Subversion</title>
  <para>To build the package, just use the tools that <command>svn-buildpackage</command>
  carries. First of all, we suggest you to define some aliases for the
  most common commands:</para>
@@ -390,9 +485,47 @@
  section), or send the result of svn diff to the
  <ulink url="mailto:debian-med@...">mailing list</ulink>
  (<command>gzip -9</command> it, if it's too large).</para>
+            </sect4>
+            <sect4>
+                <title>Git</title>
+                <para>You should use <command>git-buildpackage</command> to build the
+                packages with git. Be sure to run it from the <quote>master</quote>
+                branch.</para>
+                <para>Unfortunately, by default <command>git-buildpackage</command>
+                builds the package without using any chroot (the same as
+                <command>svn-buildpackage</command>), but it's configurable to run
+                it inside a chroot.</para>
+                <para>You can use this configuration file, <filename>~/.gbp.conf</filename>:</para>
+                <blockquote>
+                    <programlisting>[DEFAULT]
+builder = ~/bin/git-pbuilder
+cleaner = fakeroot debian/rules clean
+pristine-tar = True
+
+[git-buildpackage]
+# use this for more svn-buildpackage like behaviour:
+export-dir = ../build-area/
+tarball-dir = ../tarballs/</programlisting>
+                </blockquote>
+                <para>With this configuration file you're specifying that
+                <command>git-buildpackage</command> will use <filename>~/bin/git-pbuilder</filename>
+                as the builder script. This is an example script you can use:</para>
+                <blockquote>
+                    <programlisting>#!/bin/sh
+set -e
+
+pdebuild --pbuilder cowbuilder --debbuildopts "-i\.git -I.git $*"
+rm ../*_source.changes</programlisting>
+                </blockquote>
+                <para>This will build the package inside the default cowbuilder chroot, while
+                passing any more parameters directly do <command>dpkg-buildpackage</command>.</para>
+            </sect4>
+            </sect3>
  </sect2>
  <sect2>
+            <sect3>
  <title>Tagging packages</title>
+            <sect4>Subversion</sect4>
  <para>It may happen that a package version has been uploaded to Debian
  repositories, and you forgot to tag the last build with</para>
  <blockquote>
@@ -433,6 +566,32 @@
  </userinput></para>
  </blockquote>
  <para>(--svn-no-autodch avoids <filename>debian/changelog</filename> to be marked as UNRELEASED).</para>
+            </sect4>
+                <sect4>
+                    <title>Git</title>
+                    <para>Tagging a release with git is pretty straightforward:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git tag</command>
+                            <option>tagname</option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>The tag names usually follow the scheme <quote>debian/x.y-z</quote>,
+                    this will ensure compatibility with other tools as well (like
+                    <command>git import-dsc</command>).</para>
+                    <para>You can also easily retroactively make tags:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git checkout</command>
+                            <option><commit hash></option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>You're now at the point in history when you released the package.
+                    Just tag it as you would normally do.</para>
+                    <para>After tagging, be sure to <command>git push --tags</command>, so that
+                    other people can benefit from it too.</para>
+                </sect4>
+            </sect3>
  </sect2>
  <sect2>
  <title>Handling patches</title>

---

[David Paleino]

David Paleino wrote:

> David Paleino wrote:
>
>> I will shortly post a patch to policy.xml for review.
>
> Here's a patch.

Sorry, it didn't compile. Fixed one here :)

--
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
[git-policy2.patch]

---

Index: policy.xml
===================================================================
--- policy.xml (revisione 4319)
+++ policy.xml (copia locale)
@@ -330,6 +330,8 @@
 
  <sect2>
  <title>Injecting a new package</title>
+            <sect3>
+ <title>Subversion</title>
  <para>To inject a new package to the SVN repository, you must have
  write access to it; i.e. you must be a member of the <emphasis>debian-med</emphasis> group on Alioth.</para>
  <para>You can inject a new package only after successfully building
@@ -350,9 +352,102 @@
  debian-med Blend package in SVN. Normally maintainer watch the changes in
  the Debian Med packaging pool but it helps if the maintainer of a
  certain package verifies that everything is in the right place.</para>
- </sect2>
- <sect2>
+ </sect3>
+ <sect3>
+                <title>Git</title>
+                <sect4>
+                    <title>Creating a local repository</title>
+                    <para>Just a few instructions to get you started:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>mkdir</command>
+                            <filename class="directory">package-version</filename>
+                            <option># this is just to make dh_make happy</option>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>cd</command>
+                            <filename class="directory">package-version</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git</command>
+                            <option>init</option>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git import-orig</command>
+                            <filename>/path/to/package_version.orig.tar.gz</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>dh_make</command>
+                        </userinput></para>
+                    </blockquote>
+                    <para>The above steps will create a repository with the appropriate layout for
+                    <command>git-buildpackage</command>, with three branches: <filename>master</filename>
+                    (where the Debian development will happen), <filename>pristine-tar</filename>,
+                    used by the <command>pristine-tar</command> tool during the package build process
+                    to recreate the original tarball, and <filename>upstream</filename>, which will
+                    contain the upstream source.</para>
+                    <para>After you create your <filename class="directory">debian/</filename> (be sure
+                    to commit it!), you should add a <quote>remote</quote> to the repository. A remote is
+                    where the commits will be pushed to, and the default remote is called <quote>origin</quote>.</para>
+                    <para>If you are going to push to our Alioth repository, please do the following inside your
+                    local repository:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git remote add origin</command>
+                            <filename class="directory">git+ssh://alioth.debian.org/git/debian-med/package.git</filename>
+                        </userinput></para>
+                    </blockquote>
+                    <para>The next step is to create the remote repository on Alioth.</para>
+                </sect4>
+                <sect4>
+                    <title>Creating the remote repository</title>
+                    <blockquote>
+                        <para><userinput>
+                            <command>ssh</command>
+                            <filename class="directory">alioth.debian.org</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>cd</command>
+                            <filename class="directory">/git/debian-med</filename>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>./setup-repository</command>
+                            <option>packagename</option>
+                            <option>"Description of the package"</option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>This will create a <filename class="directory">packagename.git</filename> repository on
+                    Alioth, with the proper hooks set up for our team.</para>
+                </sect4>
+                <sect4>
+                    <title>Pushing the package</title>
+                    <para>To push the package (make sure you've added the alioth remote!), do the following:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git push origin master</command>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git push</command>
+                            <option>--all</option>
+                        </userinput></para>
+                        <para><userinput>
+                            <command>git push</command>
+                            <option>--tags</option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>For the first push, it's necessary to specify <quote>origin master</quote>. The next time
+                    you will push, a <command>git push</command> will suffice. Remember that this will only push the
+                    <quote>master</quote> branch (and the other two only if master is somehow related to the new
+                    branches), so be sure to also do a run with <option>--all</option>, and one with
+                    <option>--tags</option> (if you obviously changed anything in the other branches/tags).</para>
+                </sect4>
+            </sect3>
+        </sect2>
+        <sect2>
+            <sect3>
  <title>Building the packages</title>
+            <sect4>
+            <title>Subversion</title>
  <para>To build the package, just use the tools that <command>svn-buildpackage</command>
  carries. First of all, we suggest you to define some aliases for the
  most common commands:</para>
@@ -390,9 +485,48 @@
  section), or send the result of svn diff to the
  <ulink url="mailto:debian-med@...">mailing list</ulink>
  (<command>gzip -9</command> it, if it's too large).</para>
+            </sect4>
+            <sect4>
+                <title>Git</title>
+                <para>You should use <command>git-buildpackage</command> to build the
+                packages with git. Be sure to run it from the <quote>master</quote>
+                branch.</para>
+                <para>Unfortunately, by default <command>git-buildpackage</command>
+                builds the package without using any chroot (the same as
+                <command>svn-buildpackage</command>), but it's configurable to run
+                it inside a chroot.</para>
+                <para>You can use this configuration file, <filename>~/.gbp.conf</filename>:</para>
+                <blockquote>
+                    <programlisting>[DEFAULT]
+builder = ~/bin/git-pbuilder
+cleaner = fakeroot debian/rules clean
+pristine-tar = True
+
+[git-buildpackage]
+# use this for more svn-buildpackage like behaviour:
+export-dir = ../build-area/
+tarball-dir = ../tarballs/</programlisting>
+                </blockquote>
+                <para>With this configuration file you're specifying that
+                <command>git-buildpackage</command> will use <filename>~/bin/git-pbuilder</filename>
+                as the builder script. This is an example script you can use:</para>
+                <blockquote>
+                    <programlisting>#!/bin/sh
+set -e
+
+pdebuild --pbuilder cowbuilder --debbuildopts "-i\.git -I.git $*"
+rm ../*_source.changes</programlisting>
+                </blockquote>
+                <para>This will build the package inside the default cowbuilder chroot, while
+                passing any more parameters directly do <command>dpkg-buildpackage</command>.</para>
+            </sect4>
+            </sect3>
  </sect2>
  <sect2>
+            <sect3>
  <title>Tagging packages</title>
+            <sect4>
+            <title>Subversion</title>
  <para>It may happen that a package version has been uploaded to Debian
  repositories, and you forgot to tag the last build with</para>
  <blockquote>
@@ -433,6 +567,32 @@
  </userinput></para>
  </blockquote>
  <para>(--svn-no-autodch avoids <filename>debian/changelog</filename> to be marked as UNRELEASED).</para>
+            </sect4>
+                <sect4>
+                    <title>Git</title>
+                    <para>Tagging a release with git is pretty straightforward:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git tag</command>
+                            <option>tagname</option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>The tag names usually follow the scheme <quote>debian/x.y-z</quote>,
+                    this will ensure compatibility with other tools as well (like
+                    <command>git import-dsc</command>).</para>
+                    <para>You can also easily retroactively make tags:</para>
+                    <blockquote>
+                        <para><userinput>
+                            <command>git checkout</command>
+                            <option><commit hash></option>
+                        </userinput></para>
+                    </blockquote>
+                    <para>You're now at the point in history when you released the package.
+                    Just tag it as you would normally do.</para>
+                    <para>After tagging, be sure to <command>git push --tags</command>, so that
+                    other people can benefit from it too.</para>
+                </sect4>
+            </sect3>
  </sect2>
  <sect2>
  <title>Handling patches</title>

---

[Charles Plessy-12]

Le Sat, Nov 07, 2009 at 10:06:02PM +0100, David Paleino a écrit :
 
> +                        <para><userinput>
> +                            <command>mkdir</command>
> +                            <filename class="directory">package-version</filename>
> +                            <option># this is just to make dh_make happy</option>

> +                        <para><userinput>
> +                            <command>git import-orig</command>
> +                            <filename>/path/to/package_version.orig.tar.gz</filename>
> +                        </userinput></para>

[and much more…]

Hi David,

this will definitely be a nice addition to our group policy, please do not
hesitate to commit it.

I have a few comments:

 - In order to have ones name nicely displayed in the git log, it may be needed
   to do ’git config user.name "$DEBFULLNAME" ; git config user.email
   $DEBEMAIL’, if there is not a more global configuration in place.

 - Instead of ‘mkdir package-version’ we can use the option -p of dh_make.

 - ’git import-orig /path/to/package_version.orig.tar.gz’ will not create
   the pristine-tar branch without --pristine-tar option.

Have a nice day,

--
Charles


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[David Paleino]

Charles Plessy wrote:

> Hi David,

Hi Charles,

> this will definitely be a nice addition to our group policy, please do not
> hesitate to commit it.
>
> I have a few comments:
>
>  - In order to have ones name nicely displayed in the git log, it may be
>  needed
>    to do ’git config user.name "$DEBFULLNAME" ; git config user.email
>    $DEBEMAIL’, if there is not a more global configuration in place.

There is one, ~/.gitconfig, git config --global user.name "Foo Bar" :)

>  - Instead of ‘mkdir package-version’ we can use the option -p of dh_make.

Oh, nice!

>  - ’git import-orig /path/to/package_version.orig.tar.gz’ will not create
>    the pristine-tar branch without --pristine-tar option.

This is what the pristine-tar = True option in the proposed ~/.gbp.conf
should do :-)

Kindly,
David

--
 . ''`.  Debian maintainer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 ----|---- http://snipr.com/qa_page
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[malat]

David,

On Sat, Nov 7, 2009 at 7:06 PM, David Paleino <d.paleino@...> wrote:

> No need to CC me, thanks :)
> Even if I'm not (anymore) active in the team, I follow the mailinglist,
> hoping I can find something I would be useful to.
>
> Mathieu Malaterre wrote:
>
>> On Sat, Nov 7, 2009 at 4:13 PM, David Paleino <d.paleino@...> wrote:
>>> I suggest you to correctly re-upload your package :)
>>
>> What is wrong with the following steps:
>>
>> tar -xzf *.orig.tar.gz
>> cd <source-directory>
>> cp -a <svn-pkg-dir>/trunk/debian .
>> rm -rf `find . -type d -name .svn`
>
> Almost wrong, I'd say. It should work, but it's not as foolproof as one
> would expect.
>
> Please, learn to use the SVN property "mergeWithUpstream". In short:
>
> cd trunk/
> svn propset mergeWithUpstream 1 debian
> svn ci -m "Merge the svn source with upstream"
>
> (I might have missed the correct order for "svn propset" -- I'm using git
> now for most of my things)
>
>> pdebuild --auto-debsign --debsign-k 0EA23F2B
>
> After you set mergeWithUpstream, you should do: $ svn-do
> This will export your svn debian/ and the original tarball (which usually is
> in ../tarballs/) into ../build-area/gdcm-somethingrandom/. There you can
> work, and do patches and whatever. As soon as you do "exit", any new/changed
> file in gdcm-random/debian/ would be copied over your SVN debian/. This is
> to work on the packaging.
>
> To just build for upload, svn-buildpackage is your friend (from the trunk/
> directory).
>
> I suggest you to have a look at our policy, in particular:
>  http://debian-med.alioth.debian.org/docs/policy.html#id304574
>
> (At other people: since I've been using git for a while, I might have some
> tips to ease development with it. Please tell me if you're interested in a
> policy paragraph for it :))
>
>> dupload /var/cache/pbuilder/result/*gdcm*
>
> I'd suggest you to only upload *.changes files. *gdcm*ch* could be ok :)

1. I do not see why using pdebuild vs svn-buildpackage would be a problem
2. I just do not understand how one could use safely svn-buildpackage.
2.a It uses *my* packages instead of whatever buildd machine will be
using to build the package for other platforms.
2.b svn-buildpackage cannot be used, since you'll easily miss
Build-Depends (can only detect using pdebuild)

Ideally I do not even understand why people are doing binary upload
instead of source upload...

Thanks anyway
--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[smr99]

Hi Mathieu,

On Sun, Nov 08, 2009 at 07:55:23PM +0100, Mathieu Malaterre wrote:

> >> On Sat, Nov 7, 2009 at 4:13 PM, David Paleino <d.paleino@...> wrote:
> >>> I suggest you to correctly re-upload your package :)
> >>
> >> What is wrong with the following steps:
> >>
> >> tar -xzf *.orig.tar.gz
> >> cd <source-directory>
> >> cp -a <svn-pkg-dir>/trunk/debian .
> >> rm -rf `find . -type d -name .svn`

That looks OK; but if you're doing it by hand, it will become
error-prone and tedious.  If you are scripting it then, as David has
suggested, you might as well use the scripts others have already
created; e.g. svn-buildpackage.

> > To just build for upload, svn-buildpackage is your friend (from the trunk/
> > directory).
> >
> > I suggest you to have a look at our policy, in particular:
> > ?http://debian-med.alioth.debian.org/docs/policy.html#id304574
> >
> > (At other people: since I've been using git for a while, I might have some
> > tips to ease development with it. Please tell me if you're interested in a
> > policy paragraph for it :))
> >
> >> dupload /var/cache/pbuilder/result/*gdcm*
> >
> > I'd suggest you to only upload *.changes files. *gdcm*ch* could be ok :)
>
> 1. I do not see why using pdebuild vs svn-buildpackage would be a problem

It's not a dichotomy; you can use both:

 $type svn-pdebuild svn-pdebuild-final
 svn-pdebuild is aliased to `svn-buildpackage --svn-dont-purge --svn-lintian --svn-builder="pdebuild --buildresult `pwd`/../build-area"'
 svn-pdebuild-final is aliased to `svn-pdebuild --auto-debsign --svn-tag --svn-noautodch'


> 2. I just do not understand how one could use safely svn-buildpackage.
> 2.a It uses *my* packages instead of whatever buildd machine will be
> using to build the package for other platforms.
> 2.b svn-buildpackage cannot be used, since you'll easily miss
> Build-Depends (can only detect using pdebuild)

Absolutely agree; I would always recommend building in a clean environment
such as with pbuilder.


> Ideally I do not even understand why people are doing binary upload
> instead of source upload...

That's Debian policy.  Essentially, it forces the maintainer to prove
that the package does build from source on at least one system ;-)
This point is debated from time to time; see [1] for a recent post.

[1] http://blog.ganneff.de/blog/2009/10/28/debian-ftpmaster-meeting-we-ar.html

Regards,
-Steve

[malat]

On Sun, Nov 8, 2009 at 11:40 PM, Steve M. Robbins <steve@...> wrote:

> Hi Mathieu,
>
> On Sun, Nov 08, 2009 at 07:55:23PM +0100, Mathieu Malaterre wrote:
>
>> >> On Sat, Nov 7, 2009 at 4:13 PM, David Paleino <d.paleino@...> wrote:
>> >>> I suggest you to correctly re-upload your package :)
>> >>
>> >> What is wrong with the following steps:
>> >>
>> >> tar -xzf *.orig.tar.gz
>> >> cd <source-directory>
>> >> cp -a <svn-pkg-dir>/trunk/debian .
>> >> rm -rf `find . -type d -name .svn`
>
> That looks OK; but if you're doing it by hand, it will become
> error-prone and tedious.  If you are scripting it then, as David has
> suggested, you might as well use the scripts others have already
> created; e.g. svn-buildpackage.
>
>
>> > To just build for upload, svn-buildpackage is your friend (from the trunk/
>> > directory).
>> >
>> > I suggest you to have a look at our policy, in particular:
>> > ?http://debian-med.alioth.debian.org/docs/policy.html#id304574
>> >
>> > (At other people: since I've been using git for a while, I might have some
>> > tips to ease development with it. Please tell me if you're interested in a
>> > policy paragraph for it :))
>> >
>> >> dupload /var/cache/pbuilder/result/*gdcm*
>> >
>> > I'd suggest you to only upload *.changes files. *gdcm*ch* could be ok :)
>>
>> 1. I do not see why using pdebuild vs svn-buildpackage would be a problem
>
> It's not a dichotomy; you can use both:
>
>  $type svn-pdebuild svn-pdebuild-final
>  svn-pdebuild is aliased to `svn-buildpackage --svn-dont-purge --svn-lintian --svn-builder="pdebuild --buildresult `pwd`/../build-area"'
>  svn-pdebuild-final is aliased to `svn-pdebuild --auto-debsign --svn-tag --svn-noautodch'

Now I have the best of svn-buildpackage and pdebuild reunited ! Thanks.

BTW, I am still doing something wrong. I have setup an unstable
pbuilder but still I get:

$ svn-pdebuild is an alias for svn-buildpackage --svn-dont-purge
--svn-lintian --svn-override=origDir=. --svn-ignore
--svn-builder="pdebuild --buildresult `pwd`/../build-area"
...
lintian /home/mathieu/Projects/debian-med/trunk/packages/gdcm/build-area/gdcm_2.0.14-1_amd64.changes
W: gdcm source: newer-standards-version 3.8.3 (current is 3.8.2)
N: 1 tag overridden (1 warning)

why is my lintian not up to date (I did a sudo pbuilder --update earlier)

Thanks,
--
Mathieu


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Andreas Tille-5]

On Thu, Nov 12, 2009 at 11:48:13PM +0100, Mathieu Malaterre wrote:
> lintian /home/mathieu/Projects/debian-med/trunk/packages/gdcm/build-area/gdcm_2.0.14-1_amd64.changes
> W: gdcm source: newer-standards-version 3.8.3 (current is 3.8.2)
> N: 1 tag overridden (1 warning)
>
> why is my lintian not up to date (I did a sudo pbuilder --update earlier)

It might be that not the lintian in the pbuilder unstable environment is
used but rather a local installation (perhaps you are running a testing
system).  I never finally found out but I use to install lintian from
unstable on all my boxes to avoid this.  In any case: Just don't mind
about this warning because it is wrong.

Kind regards

     Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manuel Prinz-3]

Am Freitag, den 13.11.2009, 07:00 +0100 schrieb Andreas Tille:

> On Thu, Nov 12, 2009 at 11:48:13PM +0100, Mathieu Malaterre wrote:
> > lintian /home/mathieu/Projects/debian-med/trunk/packages/gdcm/build-area/gdcm_2.0.14-1_amd64.changes
> > W: gdcm source: newer-standards-version 3.8.3 (current is 3.8.2)
> > N: 1 tag overridden (1 warning)
> >
> > why is my lintian not up to date (I did a sudo pbuilder --update earlier)
>
> It might be that not the lintian in the pbuilder unstable environment is
> used but rather a local installation (perhaps you are running a testing
> system).  I never finally found out but I use to install lintian from
> unstable on all my boxes to avoid this.  In any case: Just don't mind
> about this warning because it is wrong.

svn-buildpackage runs the local lintian. Installing lintian inside the
chroot during build would somewhat violate the "clean build environment"
mantra. (Yes, I know, the probability of lintian introducing side
effects is quite low, but anyway…) So if you do not build on a Sid
system, you have to ensure lintian is up-to-date.

Best regards
Manuel


--
To UNSUBSCRIBE, email to debian-med-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...