[Pkg-samba-maint] (forw) ANNOUNCE: cifs-utils-4.0rc1 released

Steve Langasek vorlon at debian.org
Mon Mar 1 09:38:11 UTC 2010

On Sun, Feb 28, 2010 at 09:14:36AM +0100, Christian PERRIER wrote:
> Quoting Steve Langasek (vorlon at debian.org):

> > I have to say that at this point, I find the use of subversion unbearable.
> > When we first started importing samba upstream tarballs into svn, this was
> > tolerable because upstream was not using a DVCS.  Now they are, and our
> > manual tarball imports are just busywork.  For samba we have to put up with
> > this (for now!) because we have a lot of package history that we care about
> > preserving, but we shouldn't repeat this dinosaur layout for a new package
> > like cifs-utils.

> > You may know that I'm no fan of git, but while I would prefer bzr for this I
> > would be willing to put up with git if that's what it would take to avoid
> > perpetuating this svn setup.  In contrast, if this does end up being
> > maintained in svn I'm afraid I will have to ask that I not be listed as a
> > comaintainer, because I won't be contributing to it in that form.

> > Please let me know your thoughts on how you think we should proceed.

> I don't have hard opinions on this.

> I did import the source just as we do for other packages
> because.....this is what I currently am able to do: I know the
> process, I am used to it and it works for me....and I don't think I
> need much more.

> OTOH, I understand that people like you (understand those who are not
> plain morons when it comes at understanding code....and those who
> actually *do* work that benefits from DVCS) may prefer working with a
> more versatile tool.

> I'm perfectly OK to avoid perpetuating the SVN setup and work another
> way as long as this another way is know to me and a little bit more
> than "we should work with git|bzr|whatever". This is certainyly saying
> something like "Please setup and document the whole thing, Steve, and
> I'll be delighted to use it"..:-)

> As of now, I can still continue to work in SVN for the cifs-utils
> package preparation work (create debian/rules and other debian/*,
> crossing fingers for the package buildprocess to be dh7-friendly,
> etc.) while preparation of the needed git setup is being done..:)

I've tentatively set up a bzr repo for cifs-utils at
bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils.  Here are the runes for
working with the repo.  Note that this uses 'bzr checkout' instead of
'bzr branch', to simplify the process and make it more svn-like.  If someone
prefers to work with standalone branches (to support things like offline
commits), I'm happy to provide a crib sheet for that as well.

(And once we work out any bugs with this setup, if we decide this is what
we're going to go with, I expect I'll turn this into a blog entry so
there'll be a permanent location to find this info :)

You'll need the packages 'bzr', 'bzr-git', and 'bzr-builddeb' installed for
this.  The bzr package in lenny is too old for the currently recommended bzr
repository format, so you will need to either use the bzr from testing
(2.1.0-1), or use the one from backports.org (2.0.3-1~bpo50+1).  There is
currently no bzr-builddeb package on backports.org, and the ones in both
lenny *and* sid are too old for bzr 2.1.  So for the moment, I recommend
using unstable or testing (perhaps in a chroot) and pulling the bzr-builddeb
package from experimental.  I understand from Jelmer that a new upstream
release of bzr-builddeb should happen soon, which will let this work w/o
pulling from experimental.

For commit notifications, you will also need the package 'bzr-email', but
I'll cover that separately once it's confirmed the basics are working and

Also, as I said, this is a tentative repository, so I'm not opposed to
throwing away the history in here - but in order to make it a useful example
I did put together some preliminary cifs-utils packaging in parallel to the
work you were doing, Christian, and I'd like to make sure the differences in
the packaging are reconciled before this gets uploaded to the archive. 
Whichever way we go, it'll also be simplest to implement if we make a
decision on a VCS as early as possible in the development, so we don't have
a lot of history to migrate.

Setting up your local working directory:

 $ bzr init-repo cifs-utils
 Shared repository with trees (format: 2a)
   shared repository: cifs-utils
 $ cd cifs-utils
 $ bzr co bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk
 $ cd trunk

Committing changes:

 $ debcommit # works the same as for svn... :)

Committing changes that aren't mentioned in the changelog:

 $ bzr commit

Updating references to the upstream git repository (done if you're preparing
to merge a new upstream version, or if we want to cherry-pick a fix from
upstream, or if you just want to browse upstream changes using bzr):

 $ bzr git-import git://git.samba.org/cifs-utils.git \

Merging a new upstream version:

 $ cd cifs-utils
 $ wget ftp://ftp.samba.org/pub/samba/cifs-utils/cifs-utils-$version.tar.bz2
 $ cd trunk
 $ bzr merge-upstream --v3 --version $version_with_epoch \
     ../cifs-utils-$version.tar.bz2 -r tag:cifs-utils-$version \
 No distribution specified, and no changelog, assuming 'debian'
 Committing to: /tmp/tmpbzOVMs/upstream/
 Committed revision 2.
 All changes applied successfully.
 The new upstream version has been imported.
 You should now review the changes and then commit.
 $ bzr diff
 <review changes>
 $ bzr commit -m "merge upstream $version"
 Committing to: bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk
 modified debian/changelog
 Committed revision 50.

Creating a source package (no need to download the upstream tarball -
bzr-builddeb uses pristine-tar):

 $ cd cifs-utils/trunk
 $ bzr bd --source -- -uc -us

Reviewing history:

 $ cd cifs-utils/trunk
 $ bzr log

Creating a new branch (e.g., for backports):

 $ bzr branch bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/trunk \
 $ cd cifs-utils
 $ mkdir branches
 $ cd branches
 $ bzr co bzr+ssh://bzr.debian.org/bzr/pkg-samba/cifs-utils/branches/lenny-bpo

Any questions?  Other operations that you would want to know how to do
before considering this?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-samba-maint/attachments/20100301/33c8a1bb/attachment.pgp>

More information about the Pkg-samba-maint mailing list