Introductory mail

Hello,

My name is Stéphane Glondu. I've been using Debian for many years, and 
I've been contributing to Debian for one year now. I am DM (and in NM 
process). I work mainly in the Debian OCaml Team¹.

I am interested in this list because I am interested in issues raised by 
packaging, and, more generally, in VCSs. I am familiar with packaging 
with subversion (as member of the OCaml Team) and git. Our team is 
slowly migrating to git packaging². In this context, I've migrated many 
repositories of Debian packages from svn to git with the help of a 
(quite dirty, I must admit) script of my own (I wasn't satisfied enough 
with existing ones). This was also a way to get more acquainted with svn 
and git. I still haven't adopted a clear workflow for my git packaging, 
as I am trying/using several ones.

I am also familiar with cvs (but forgetting  and darcs (neither of 
them for packaging). I still tend to push people into using darcs (if 
they don't use any DVCS). I am a big fan of darcs and git.

¹ http://wiki.debian.org/Teams/OCamlTaskForce
² http://wiki.debian.org/Teams/OCamlTaskForce/GitMigration

Cheers,

--

-- 
Stéphane Glondu

Introduction

Greetings,

I subscribed to the list a while back, but I don't believe I ever got
around to introducing myself.

My name is Chris Larson, but am most well known as Kergoth.  I work in
the embedded Linux field.  I've done work on bootloaders, kernel,
userland, distro, build tools, etc.  I founded the OpenZaurus Linux
distro for the Sharp Zaurus line of PDAs, and created the OpenEmbedded
project, which was originally a portage fork.  It exists because I got
tired of gmake's limitations, and all of the existing distribution
tools were limited, either lacking crosscompilation support, or
expected to run the tools only -on- that distribution.  I wanted a
tool that would run anywhere, and could target any platform, and
support multiple target packaging formats and distributions.  The
metadata repository is shared by multiple embedded distributions and
projects, so in that aspect, the goal was quite similar to that of
vcs-pkg.. collaboration.

I've hacked on debian packages and tools, redhat packages and tools,
and gentoo packages and tools, but never got around to pursuing
actually becoming a developer for any (I know just how much time a
distro can suck up..).

Most of the OE target distros are debian based, as I found most debian
distributionisms (I say that's a word, dangit) to be superior to
redhat ones, and more stable than gentoo ones (i.e. interfaces(5)),
though there are obvious exceptions.  OE can output ipk, deb, or rpm
files.  Originally it could take either our metadata format or a
source rpm as input (with a metadata conversion layer), but I doubt

ANNOUNCE: Project-Builder 0.9.3

Hello,

I want to propose to you some information on a new project I'm working
on since more than one year now and called Project-Builder.org (aka pb)

I just published 0.9.3 version, and think it's maturing slowly but
surely, and may be useful for people on this mailing list.

The goal is to provide a tool to help projects (or packagers) packaging
software, and thus extending their visibility and usability. 

All information on the project build are stored in a VCS (CVS or SVN
currently), and pb builds packages using those + a link to again a CVS
or SVN repo. Everything is there to include other VCS at will. I was
just involved with projects using those 2 only.

A presentation I made during the RMLL 2008 and LinuxDays Geneva 2008 is
available at
http://trac.project-builder.org/browser/devel/pb-doc/pb-presentation.odp

Example of conf files are available at
http://trac.project-builder.org/browser/projects and info on the project
with some detailed (even if now a bit old) example at
http://trac.project-builder.org

I'll be on vacation during the next 2 weeks, so don't expect quick answer
from me on this before early September. But I'm of course highly
interested by your feedbaacks. You can find the tar ball at
ftp://ftp.project-builder.org/src/project-builder-0.9.3.tar.gz and RPMs
pckages under ftp://ftp.project-builder.org/ .deb packages should rrive

topgit 0.2 packaged for Debian

Hi folks,

for those of you who have followed my vcs-pkg presentation yesterday
and/or want to try TopGit, I've uploaded 0.2-1 today. While it's
waiting for NEW queue processing, you can get the package from here:

  http://debian.madduck.net/repo/pool/main/t/topgit/

If you have bug reports or wishlist items, I suggest mailing them to
git <at> vger.kernel.org for now (start the subject with "TopGit:"),
until the package is in Debian proper. Please put me on Cc if it
involves the Debian package.

/usr/share/doc/topgit/README.source explains how I packaged topgit
with TopGit. It's surely still too complex for mass deployment, but
upstream is happy to accept patches.

The Debian package is maintained at

  http://git.debian.org/?p=collab-maint/topgit.git

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

officer, arrest that man! he's whistling a copyrighted song.

TopGit: problem with patch series generation

Hi folks,

I am playing around with TopGit and encountered a (conceptual)
problem. I'd love to hear some input.

I want to use TopGit for distro packaging. Any of my packages have
one or more feature branches, some intended for upstream, some
distro-specific. As I am packaging TopGit for Debian, I encountered
the situation that two branches conflict with each other (they
change the same line), but there is no dependency between the
branches. Thus, when I squash the branches into a series, the
resulting patches will not apply (they both change the same original
line to something else).

Obviously, I can introduce a "fake" dependency to force TopGit to
create one patch based on another. However, this then prevents me
from testing and developing the depending branch in isolation,
meaning that I always have to have the dependent branch applied when
I want to work on the second feature. Furthermore, it's not
trivially possible in this situation to cherry-pick only the second
patch.

I see that this is a hard problem with no obvious solution. The only
thing that comes to my mind is maintaining multiple patches for each
branch. In the above, if B "fake-depends" on A, which depends on
master, then I would have A and B depend on master only, but have
TopGit also manage B2 for me, which is a diff against A.

Doing this for all branches is polynomial, but then again, the
number of independent branches, or rather branch trees, is likely to

streamed vcs-pkg presentation including TopGit in 2 hours

As part of DebConf 8, I will talk about http://vcs-pkg.org in about
2 hours [0], and I intend to introduce TopGit, which was announced here
a week ago [1].

0. https://penta.debconf.org/dc8_schedule/events/233.en.html
1. http://marc.info/?l=git&m=121773329801376&w=2

If you want to tune in and participate via our video streams and IRC
channels, visit http://debconf8.debconf.org.

Please note that I am going into this talk with far less preparation
than I would have liked to do, and I don't claim to know TopGit very
well yet. I will make sure my audience knows this. But if anyone
with more of a clue is around on IRC, it would be helpful.

--

-- 
martin | http://madduck.net/ | http://two.sentenc.es/

it is ok to let your mind go blank,
but please turn off the sound.

spamtraps: madduck.bogus <at> madduck.net

As part of DebConf 8, I will talk about http://vcs-pkg.org in about
2 hours [0], and I intend to introduce TopGit, which was announced here
a week ago [1].

0. https://penta.debconf.org/dc8_schedule/events/233.en.html
1. http://marc.info/?l=git&m=121773329801376&w=2

fwd: [ANNOUNCE] TopGit - A different patch queue manager (from pasky <at> suse.cz)

  crap *this* was the mail I intended to forward at first sorry.

-- 
·O·  Pierre Habouzit
··O                                                madcoder <at> debian.org
OOO                                                http://www.madism.org

  Hi,

  I'd like to announce TopGit v0.1, the first (while also the youngest)
project from my Rhine pipeline (sitting at the river shore, hacking
free of all online distractions; the only catch is that the offline
distractions can be plentiful as well - too many pretty girls tend
to cluster around the water in the hot summer days for some strange
reason.)

  TopGit is meant as a fresh start in the steps of StGIT, quilt-in-git
and others, of course in an attempt to Get It Right this time around.
TopGit is absolutely minimal porcelain layer that will manage your
patch queue for you using topic branches, one patch per branch.
And do _ONLY_ that. Unlike with StGIT, you can actually use the index.

fwd: Re: [ANNOUNCE] TopGit - A different patch queue manager (from pasky <at> suse.cz)

  I've not tested the tool right now, but it feel like solving many of
the concerns manoj had with patches.

-- 
·O·  Pierre Habouzit
··O                                                madcoder <at> debian.org
OOO                                                http://www.madism.org

On Sun, Aug 03, 2008 at 09:27:26AM +0200, Miklos Vajna wrote:
> Heh, no please. I have a porcelain called 'dg'[0] after 'darcs-git', which
> imitates some of the darcs UI, but operating on a git repo. 
> 
> [0] http://tinyurl.com/5lfs5g, http://tinyurl.com/6pb772

Oh, good to know. I was considering naming this 'dg' as a pun on 'cg'
(though only half-seriously ;).

				Petr "Pasky" Baudis
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo <at> vger.kernel.org

[debian] where to document branch layout

Hi all (again),
  with $DVCS the branch layout for a given package can become quite
complex, and AFAICS there is no agreed upon convention on branch layout.
Just the single choice of whether to use branches just for work and then
serialize changes in patch series or not drastically differentiate the
way of using $DVCS for package maintenance.

My question is whether we have a guideline about *where* to document
branch layout for a given package. Regarding Debian,
debian/README.source comes to mind quickly, but its current description
in policy does not make it clear that it is the suitable place where to
document branch layout.

Of the two one: we clarify its description, we describe where else the
branch layout should be documented.

A more general question is whether there is a fixed set of "well known"
branch layouts that can be written down so that we can reference each
layout with a clear name. If this is so, I believe this is the right
place where to attempt defining such a set.

Cheers

PS I've tried a while ago raising this question on the debian-devel
   mailing list, with scarce success (i.e. 0 replies)
   http://lists.debian.org/debian-devel/2008/06/msg00518.html

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/

how to generate patches out of $DVCS branches: best practices?

I'm a happy (Debian) package maintainer which have just switched most of
his packages from svn to git. All nice, finally I can work directly on a
real source code tree instead of fiddling with patch management system.
Nevertheless, patches are separate in topic branches which enable
knowing the conceptual changes applied to upstream sources.

But.

Even though I can declare where my git repository for package management
is, there is still people only playing with the (Debian) source package.
Unfortunately, there all changes are flattened in .diff.gz, with neither
change separation, nor description of which changes have been made.

I know I can use git format-patch to serialize patches into patch series
and make them available with dpatch/quilt/..., and precisely here is my
question. Have I to do that by hand and by myself? Even though I can do
it, I'm convinced there is room for creating a best practice on this, if
not even some tools. Is anybody aware of anything like that?

Specifically for Debian: do we have any guideline on how to do that? If
not it is probably worth to create one ...

And finally, the problem of the problems: how about the situation where
one patch for topic branch is not enough as topic branches have got
intertwined? (I guess this can happen fairly easily with changes
evolution, unless git rebase is used). A guideline/best practice on that
as well would be utterly welcome.

TIA,
Cheers.

Merging changelogs (again)

Hi all,

Pierre posted a Debian changelog-specific merger a couple of months ago.
Bryce just knocked another up from the Merge-o-matic source code not
knowing about Pierre's. You can find it at

  http://people.ubuntu.com/~bryce/scripts/merge_changelog

It's significantly longer, but I'm not sure how else it differs
as I haven't had chance to compare them in detail yet.

Bryce did say that he found this one handled epochs better than
Pierre's.

I can pass any feedback anyone has on.

Thanks,

James