vcs-pkg/ planet

This planet aggregates posts related to version control and distro packaging.
Please refrain from using it as a discussion forum.

You can add your own feed to the list of feeds.

madduck's vcs-pkg-related blog posts DistroSummit 2010

Linux.conf.au 2010 has come to an end and I am looking back at an intense week of conferencing. A big shout out to the organisers for their excellent work. I think LCA (as well as DebConf) just keeps getting better every year. This does not at all discredit previous organisers, because they were the best at their times and then passed on the wisdom and experience to help make it even better in the following year.

The week started off with the DistroSummit, which Fabio and I organised. Slides are forthcoming, as I failed to get them off the speakers right after their talks — it’s interesting how stress levels and adrenaline can cause one to forget the most obvious things. This is where experience comes in. I’ll be there again next year, I hope, to do things better.

The theme of the day was cross-distro collaboration, and we started the day a little bit on the Debian-side with Lucas Nussbaum telling us about quality assurance in Debian, alongside an overview of available resources. We hoped to give people from other distros pointers, and solicit feedback that would enable us to tie quality assurance closer together.

Next up was Bdale Garbee who talked about the status of the Linux Standard Base. While I am really interested in such standardisation efforts, I realised during his talks that I had considerable difficulties paying attention because as organiser of the conference, I had all sorts of other things occupying my thoughts.

I proceeded to tell the audience — the room was mostly filled throughout the day with an estimated 40–50 folks, and I’d say about half of them stayed throughout, while the other half came in and left the room between talks. I could not get the projector to work with my laptop after the upgrade to Kernel Mode Setting, and thus used the whiteboard to give a brief introduction to vcs-pkg.org, talk about the current state of affairs, summarise the trends in discussions around patch management and collaboration, give an outlook of what’s up next, and solicit some discussion.

Sadly, just like during Bdale’s talk, I found myself worrying over the organisation of the day, rather than actually taking in most of the discussion. Fortunately, others have written about the most important points, so I defer to them.

Michael Homer then told us about GoboLinux’s Aliens system, which is a way to integrate domain-specific packages with distro-specific package maintenance — e.g. how to get APT to handle CPAN directly, or how to let YUM manage Python packages. The ensuing discussion was interesting, and we carried it over to the next slot, because Scott, the next speaker, was stuck in traffic. To summarise briefly: scripting languages have a lot of NIH-style solutions because it works for them, but these are a nightmare to distro packagers. One symptom of the status quo is that complex software packages like Zimbra are forced to distribute all required components in their installation packages, which make distro packaging, quality assurance, and security support even harder. I don’t think we found a solution, other than the need for further standardisation (like the LSB), but the road seems to be a long and windy one.

Laszlo Peter introduced the audience to SourceJuicer, a new build system used by OpenSolaris. The idea is that contributors submit packages via a web interface, kicking off a workflow incorporating discussion and vetting, and only after changes have been signed-off are packages forwarded to auto-builders and eventually end up in the package repository. This is very similar to upload ideas I’ve had a while ago, which I’ve started to (finally) implement. Unfortunately, SourceJuicer seems very specific to OpenSolaris, as well as non-modular, so that I probably won’t be able to reuse e.g. the web interface on top of a Debian-specific package builder.

After the break, Dustin Kirkland stepped up to tell us about his user experience of Launchpad. Unfortunately, I found his talk a bit too enthusiastic. Launchpad undoubtedly has some very cool features and ideas, but it’s just one of the available solutions.

The dicussion of Launchpad also dominated the next talk, in which Lucas Nussbaum told us about the Debian-Ubuntu relationship. While his presentation showed that the relationship was improving (Matt Zimmerman made the point that there are rather many relationships, rather than one relationship), I was a bit disturbed by the comments of Launchpad developers in the room, ranging from “Debian is declining anyway” to “Just use Launchpad if you want to collaborate with others and not go down”. There was a slight aura of arrogance in their comments which tainted my experience of the otherwise constructive discussions of the day.

Overall I had a great time. Debian and Ubuntu made up the vast majority of attendants, with only a handful of representatives from other distros present. I wonder why that would be. One reason might be that around 70% of LCA attendants declared themselves Debian or Ubuntu users, and so there weren’t many other distros around. Another might be that I still haven’t spread the word enough. Let’s hope to do better next year!

Thanks to all the speakers. We may have organised the day, but you made it happen and interesting!

Slides and recordings of the talks will be linked from the archived website when they become available (yes, the archive page does not exist yet either).

Update: Jelmer informed me that the people who spoke up against Debian during and after the Launchpad talk were not officially affiliated with Launchpad. It’s a shame that this negatively reflected upon Launchpad for some of the attendees (not just myself).

Posted Thu 28 Jan 2010 04:34:19 UTC Tags: ?madduck
buxy's SCM and packaging related blog posts Debian related goals for 2010

Here’s stuff that I’d like to do this year, more or less by decreasing order of importance:

All of this probably doesn’t fit in my free time (being a father since last month does not help increasing my free time :-) ), so if you’re interested in seeing one or more of those projects completed, and if you know some person/company that could sponsor them, get in touch with me!

Partagez cet article / Share This Posted Sat 09 Jan 2010 20:14:36 UTC Tags: ?buxy
Robert Collins' packaging related blog posts Debianising with bzr-builddeb

Bzr build-deb is very nice, but it can be very tricky to get started. I recently did a fresh debianisation of a project that is in bzr upstream, and I thought I’d record the recipe to make it work (at least until the various bugs making it hard re fixed).

Assuming that the upstream uses bzr, it goes like this:

  1. Start with a branch that is close to the code you want to Debianise. E.g. if the release was off trunk, 3 commits back: bzr branch trunk -r -3 debian
  2. Debianise as normal: put the tarball with the right name in the parent dir,  add a debian directory and fiddle until you build a package you’re happy with. Don’t commit while doing this.
  3. Build a source package- debuild -S, or bzr builddeb -S
  4. Revert your changes – bzr revert.
  5. Import the dsc – bzr import-dsc ../*.dsc
  6. Now, you may find that some dot files, such as .bzrignore have been discarded inappropriately (there is a bug open on this). If that happened, keep going. Otherwise, you’re done: you can now use merge-upstream on future upstream releases, and debcommit etc.
  7. bzr uncommit
  8. bzr revert .bzrignore (and any other files that you want to get back)
  9. debcommit
  10. All done, see point  6 for details.

Hope-this-helps


Posted Sat 19 Dec 2009 04:34:16 UTC Tags: ?lifeless
Robert Collins' packaging related blog posts Why upstreams should do distribution packaging

Software comes in many shapes and styles. One of the problems the author of software faces is distributing it to their users.

As distributors we should not discourage upstreams that wish to generate binary packages themselves, rather we should cooperate with them, and ideally they will end up maintaining their stable release packages in our distributions. Currently the Debian and Ubuntu communities have a tendancy to actively discourage this by objecting when an upstream software author includes a debian/ directory in their shipped code.  I don’t know if Redhat or Suse have similar concerns, but for the dpkg toolchain, the presence of an upstream debian directory can cause toolchain issues.

In this blog post, I hope to make a case that we should consider the toolchain issues bugs rather than just-the-way-it-is, or even features.

To start at the beginning, consider the difficulty of installing software: the harder it is to install a piece of software, the more important having it has to be for a user to jump through hoops to install it.

Thus projects which care about users will make it easy to install – and there is a spectrum of ease. At one end,

checkout from version control, install various build dependencies like autoconf, gcc and so on

through to

download and run this installer

Now, where some software authors get lucky, is when someone else makes it easy to install their software, they make binary packages, so that users can simply do

apt-get install product

Now some platforms like MacOSX and Microsoft Windows really do need an installer, but in the Unix world we generally have packaging systems that can track interdependencies between libraries, download needed dependencies automatically, perform uninstalls and so on. Binary packaging in a Linux distribution has numerous benefits including better management of security updates (because a binary package can sensibly use shared libraries that are not part of the LSB).

So given the above, its no surprise to me to see the following sort of discussion on #ubuntu-motu:

  1. upstream> Hi, I want to package product.
  2. developer> Hi, you should start by reading the packaging guide
  3. (upstream is understandably daunted – the packaging guide is a substantial amount of information, but only a small fraction is needed to package any one product.)

or (less usefully)

  1. upstream> Hi, I want to package product.
  2. developer> If you want to contribute, you should start with existing bugs
  3. upstream> But I want to package product.

Another conversation, which I think is very closely related is

  1. developer> Argh, product has a debian dir, why do they do this to me?!

The reasons for this should be pretty obvious at this point:

Now, why should we encourage this, rather than ask the upstream to delete their debian directory?

Because it lets us, distributors, share the packaging effort with the upstream.

Upstreams that are making packages will likely be doing this for betas, or even daily builds. As such they will find issues related to new binaries, libraries and so on well in advance of their actual release. And if we are building on their efforts, rather than discarding them, we can spend less time repeating what they did and more packaging other things.

We can also encourage the upstream to become a maintainer in the distro and do their own uploads: many upstreams will come to this on their own, but by working with them as they take their early steps we can make this more likely and an easier path.


Posted Fri 18 Dec 2009 11:23:56 UTC Tags: ?lifeless
madduck's vcs-pkg-related blog posts Distro Summit 2010: schedule finalised

It took us a bit longer than planned, but we are happy to announce the schedule for the Distro Summit at the upcoming LCA2010 conference. We focused on cross-distro aspects, and we hope that you are as excited as we are about the result.

The schedule is displayed on the Distro Summit homepage and I best refrain from duplicating it here.

Posted Sun 13 Dec 2009 12:14:07 UTC Tags: ?madduck
buxy's SCM and packaging related blog posts New source formats allowed in testing/unstable

The ftpmasters merged my dak branch last week during their meeting and have enabled the support of new source formats “3.0 (quilt)” and “3.0 (native)” in testing, unstable and testing-proposed-updates. I have uploaded 3 packages using the new formats already: logidee-tools using “3.0 (native)”, quilt and ftplib using “3.0 (quilt)”. The latter is arch any and has been successfully built on all architectures even those that still use an old version of sbuild (it looks like the fears that the old version would not cope with the new format were unfounded). For logidee-tools I built it with “-Zbzip2” in order to use bzip2 compression on the native tarball.

I have updated the wiki page and the release goal page with latest information. Feel free to convert some of your packages to give it a try. For ftplib, it led me to discover a Debian specific patch that I completely missed when I took the package over. This is precisely the kind of benefit that I expect from generalizing this format, it will encourage us to have separate documented patches instead of keeping everything hidden inside the usual .diff.gz. Combined with DEP-3 (patch tagging guidelines), we have a better infrastructure to share our patches with the rest of the free software community.

The next step is to fix all bugs listed here and make dpkg-source use the new source formats by default (#553928). Feel free to help by preparing patches (and offering NMUs), it’s a release goal to have all packages buildable with new source formats.

Partagez cet article / Share This Posted Mon 02 Nov 2009 18:33:40 UTC Tags: ?buxy
buxy's SCM and packaging related blog posts 3-way merge of Debian changelog files

I’ve been considering for some time now to create a merge tool specifically suited for debian/changelog files. My goal was to let Git use it automatically thanks to gitattributes.

I’ve just gone ahead, so let me introduce you git-merge-dch. Grab it with git clone git://git.debian.org/~hertzog/git-merge-dch.git, you can build a package if you wish. Beware, you need to have a dpkg-dev 1.15.5 that is not yet published (so you need to build dpkg from its git repository, git clone git://git.debian.org/dpkg/dpkg.git) as I rely on features that I introduced recently… you will also need the libalgorithm-merge-perl package.

Using it in a git repository requires two changes:

Now you can safely maintain two branches of a package with changelog files evolving separately and merge one into the other without creating undue conflicts. Suppose you created an experimental branch for version 2.28 (you use a version 2.28-1~exp1) when 2.26.2 was current stable in the master branch. In the mean time, 2.26.3 got out and was packaged in master. Next time you merge stable into experimental, the changelog entries for 2.28 and 2.26.3 won’t collide despite being at the same place in the changelog file compared to the common ancestor.

Let’s continue with this example, 2.28 is out. Instead of adding a new changelog entry with « New upstream release » without further changes, you keep the current changelog entry and simply change the version into 2.28-1. While preparing this you discover a branch with fixes that was based on 2.28-1~exp1, if you merge it it will reintroduce a 2.28-1~exp1 entry that you don’t want. Fortunately you can use the --merge-prereleases (-m) option of git-merge-dch so that it strip the prerelease part of the version string and considers 2.28-1~exp1 and 2.28-1 to be the same entry really.

The only limitation is that this merge tool will remove any lines which are not parsed by Dpkg::Changelog (and which in theory are not supposed to be there).

Feel free to test, share your comments, report bugs and send patches!

Partagez cet article / Share This Posted Thu 08 Oct 2009 19:39:22 UTC Tags: ?buxy
madduck's vcs-pkg-related blog posts Distro Summit 2010: extended call for papers

Today, Fabio and I extended the deadline of the call for papers of the upcoming Distro Summit until 18 October 2009. We have already received a number of great proposals, but not enough to complete the schedule. So if you have anything to say on the topic of distributions (such as, but not limited to the various Linux distributions), and especially on cross-distro collaboration, please launch your mailer and compose a message as detailed in the instructions.

Distro Summit will take place as part of LCA 2010 in Wellington, New Zealand. Yes, that is on the Southern Hemisphere, and yes, that is far away from where many of you live, but it’s well worth a visit, if you’ll take my word for it. Unfortunately, we are unable to provide sponsorship for speakers, so talk to your employer or your distro now and get the ball rolling. You have a little more than a week to get your bids in!

What are you waiting for? This is a once-in-a-lifetime chance: Distro Summit, LCA, and Wellington, all-in-one. It doesn’t get much better than that. Let’s hear your proposal!

PS: I loved Wellington (and its people) so much that I picked up my very own pet Wellingtonian!

Posted Wed 07 Oct 2009 14:13:40 UTC Tags: ?madduck
madduck's vcs-pkg-related blog posts Team-maintained packaging with DVCS

The other day, Romain shared his concerns about using Git for team-maintained packaging. His comment system is currently broken, so I wrote an e-mail reply, which I would like to share.

I agree with Romain that the design decision to not support subtree checkouts like SVN is not without problems. As opposed to a single SVN repo with components in subdirectories that you can individually check out, you might end up with a hundred Git repos, and the same change to all then requires one to iterate all 100.

I’d like to make the distinction between trivial changes (e.g. s/© 2008/&-2009/g) and those that might not be (e.g. Standards-Version, or something even more elaborate).

In case of the former, there’s no question, it can be painful to operate across a hundred repos. Tools like mr make that a bit easier, but it’s still far from optimal.

The latter, however — updating Standards-Version and adding the appropriate changelog entry — is not really comparable. Neither would be e.g. changing a file location in 100 different repos. In those cases, every single package needs manual intervention, and if only for quality reasons and testing. In this sense, I actually think that a single SVN checkout with all the subtrees and the possibility to easily commit the result of a recursive action is counter-productive.

On the other hand, I don’t say that I am pleased with the workflow Git (or any other DVCS for that matter) imposes. It’s sometimes quite painful, as Romain says. We are missing higher-level tools that allow for easier and more intuitive bulk operations. I think that they should be implemented outside of the VCS-tool though, true to the Unix principles. SVN integrates it all into a monolithic piece of software, and that often isn’t ideal either (think size and slowness, or backup weight, or chance of corruption, or granular access control, or the impossibility to properly track files across subtrees).

mr is a step in the right direction, and we need more tools along those lines. First, however, I think that people need to figure out how exactly to use DVCS for packaging, such that there is any chance of consolidating workflows across a larger number of packages; if everyone does it their own, slightly unique way, then that goal is inifinitely far. This is the reason I started vcs-pkg.org, and even though we’re still far from anywhere, I am quite pleased with what we’ve done so far.

If you’re at Debcamp or DebConf, maybe you could join the discussion.

Romain also mentioned that distributed VCS don’t allow for the same sort of centralisation as SVN does. I disagree: you can use Git in exactly that way, as a centralised repo from which packages are built. The nice advantage over SVN (one which svk tried to close) is the ability for everyone to easily branch/fork, or work offline.

Once you start down that path, it somehow inherently becomes everyone’s own responsibility to ensure that one’s changes end up in the central repository (where commit hooks might verify the build-ability, ensure that the test suite still passes, or run simple format/consistency checks).

This sort of workflow is very different from the one with a self-appointed benevolent dictator at the top, who (like Linus, or Junio for Git) sometimes forget to include patches due to overflooding. The question is really: Given that you need some sort of centralised release coordination, do you want a human or a repo to be the central entity (and single point of failure)?

I really prefer the repo, since that places the sole responsibility on the leafs, on the contributors, who need to see their code through all the way.

It’s a whole lot more rewarding to commit/push, get a rejection, pull, merge, commit/push, and be done, rather than to send a patch to upstream, wait, reping, notice that it’s not in in the new release, ask, ping, change, reping, get angry, ping, hope, wait, ping, wonder why the heck you are still doing this, write angry email but don’t send it, reping, ask, and finally notice that it’s been accepted after all.

NP: Deep Purple: Made in Japan

Posted Fri 19 Jun 2009 06:28:01 UTC Tags: ?madduck
Manoj Srivastava's SCM and packaging related blog posts Manoj: Ontologies: Towards a generic, distribution agnostic tool for building packages from a VCS

This is a continuation from before. I am digressing a little in this post. One of the things I want to get out of this exercise is to learn more about Ontologies and Ontology editors, and on the principle that you can never learn something unless you build something with it (aka bone knowledge), so this is gathering my thoughts to get started on creating an Ontology for package building. Perhaps this has been done before, and better, but I’ll probably learn more trying to create my own.

Also, I am playing around with code, an odd melange of my package building porcelain, and gitpkg, and other ideas bruited on IRC, and I don’t want to blog about something that would be embarrassing in the long run if some of the concepts I have milling around turn out to not meet the challenge of first contact with reality.

I want to create a ontology related to packaging software. It should be general enough to cater to the needs any packaging effort in a distribution agnostic and version control agnostic manner. It should enable us to talk about packaging schemes and mechanisms, compare different methods, and perhaps to work towards a common interchange mechanism good enough for people to share the efforts spent in packaging software.

The ontology should be able to describe common practices in packaging, concepts of upstream sources, versioning, commits, package versions, and other meta-data related to packages.

vcs-pkg concept diagram

I am doing this ontology primarily for myself, but I hope this might be useful for other folks involved in packaging software.

So, here follow a set of concepts related to packaging software, people who like pretty pictures can click on the thumbnail on the right:

Posted Thu 23 Apr 2009 04:21:27 UTC Tags: ?manoj
Manoj Srivastava's SCM and packaging related blog posts Manoj: Looking at porcelain: Towards a generic, distribution agnostic tool for building packages from a VCS

This is a continuation from before.

Before I go plunging into writing code for a generic vcs-pkg implementation, I wanted to take a close look at my current, working, non-generic implementation: making sure that the generic implementation can support at least this one concrete work-flow will keep me grounded.

One of the features of my home grown porcelain for building package has been that I use a fixed layout for all the packages I maintain. There is a top level directory for all working trees. Each package gets a sub-directory under this working area. And in each package sub-directory, are the upstream versions, the checked out VCS working directory, and anything else package related. With this layout, knowing the package name is enough to locate the working directory. This enable me to, for example, hack away at a package in Emacs, and when done, go to any open terminal window, and say stage_release kernel-package or tag_releases ucf without needing to know what the current directory is (usually, the packages working directory is several levels deep — /usr/local/git/debian/make-dfsg/make-dfsg-3.91, for instance.

However, this is less palatable for a generic tool – imposing a directory structure layout is pretty heavy. And I guess I can always create a function called cdwd, or something, to take away the tedium of typing out long cd commands.

Anyway, looking at my code, there is the information that the scripts seem to need in order to do their work.

So, if I do away with the whole working area layout convention, this can be reduced to just requiring the user to:

Hmm. One user specified directory, where the results are dumped. I can live with that. However, gitpkg has a different concept: it works purely on the git objects, you feed it upto three tree objects, the first being the tree with sources to build, and the second and third trees being looked at only if the upstream tar archive can not be located, and passes the trees to pristine tar to re-construct the upstram tar. The package name and version are constructed after the source-tar archive is extracted to the staging area. I like the minimality of this.

This is continued here.

Posted Sun 19 Apr 2009 04:07:32 UTC Tags: ?manoj
Manoj Srivastava's SCM and packaging related blog posts Manoj: Towards a generic, distribution agnostic tool for building packages from a VCS

I have been involved in vcs-pkg.org since around the time it started, a couple of years ago. The discussion has been interesting, and I learned a lot about the benefits and disadvantages of serializing patches (and collecting integration deltas in the feature branches and the specific ordering of the feature branches) and maintaining integration branches (where the integration deltas are collected purely in the integration branch, but might tend to get lost in the history, and a fresh integration branch having to re-invent the integration deltas afresh).

However, one of the things we have been lax about is getting down to brass tacks and getting around to being able to create generic packaging tools (though for the folks on the serializing patches side of the debate we have the excellent quilt and the topgit packages).

I have recently mostly automated my git based work-flow, and have built fancy porcelain around my git repository setup. During IRC discussion, the gitpkg script came up. This seems almost usable, apart from not having any built-in pristine-tar support, and also not supporting git submodules, which make is less useful an alternative than my current porcelain.

But it seems to me that we are pretty close to being able to create a distribution, layout, and patch handler agnostic script that builds distribution packages directly from version control, as long as we take care not to bind people into distributions or tool specific straitjackets. To these ends, I wanted to see what are the tasks that we want a package building script to perform. Here is what I came up with.

  1. Provide a copy of one or more upstream source tar-balls in the staging area where the package will be built. This staging area may or may not be the working directory checked out from the underlying VCS; my experience has been that most tools of the ilk have a temporary staging directory of some kind.
  2. Provide a directory tree of the sources from which the package is to be built in the staging area
  3. Run one or more commands or shell scripts in the staging area to create the package. These series of commands might be very complex, creating and running virtual machines, chroot jails, satisfying build dependencies, using copy-on-write mechanisms, running unit tests and lintian/puiparts checks on the results. But the building a package script may just punt on these scripts to a user specified hook.

The first and third steps above are pretty straight forward, and fairly uncontroversial.

The upstream sources may be handled by one of these three alternatives:

  1. compressed tar archives of the upstream sources are available, and may be copied.
  2. There is a pristine-tar VCS branch, which in conjunction with the upstream branch, may be used to reproduce the upstream tr archive
  3. Export and create an archive from the upstream branch, which may not have the same checksum as the original branch

The command to run may be supplied by the user in a configuration file or option, and may default based on the native distribution, to dpkg-buildpackage or rpm. There are a number of already mature mechanisms to take a source directory and upstream tar archive and produce packages from that point, and the wheel need not be re-invented.

So the hardest part of the task is to present, in the staging area, for further processing, a directory tree of the source package, ready for the distribution specific build commands. This part of the solution is likely to be VCS specific.

This post is getting long, so I’ll defer presenting my evolving implementation of a generic vcs-pkg tool, git flavour, to the next blog post.

This is continued here.

Posted Thu 16 Apr 2009 21:52:36 UTC Tags: ?manoj
Manoj Srivastava's SCM and packaging related blog posts Manoj: The glaring hole in most git tools, or the submodule Cinderella story

There are a lot of little git scripts and tools being written by a lot of people. Including a lot of tools written by people I have a lot of respect for. And yet, they are mostly useless for me. Take git-pkg. Can’t use it. Does not work with git submodules. Then there is our nice, new, shiny, incredibly bodacious “3.0 (git)” source format. Again, useless: does not cater to submodules.

I like submodules. They are nice. They allow for projects to take upstream sources, add Debian packaging instructions, and put them into git. They allow you to stitch together disparate projects, with different authors, and different release schedules and goals, into a coherent, integrated, software project.

Yes, I use git submodules for my Debian packaging. I think it is conceptually and practically the correct solution. Why submodules? Well, one of the first things I discovered was that most of the packaging for my packages was very similar – but not identical. Unfortunately, the previous incarnation of my packages with a monolithic rules file in each ./debian/ directory, it was easy for the rules files in packages to get out of sync – and there was no easy way to merge changes in the common portions an any sane automated fashion. The ./debian/ directories for all my packages package that they are instrumental in packaging. So, since I make the ./debian/ directories branches of the same project, it is far easier to package a new package, or to roll out a new feature when policy changes – the same commit can be applied across all the branches, and thus all my source packages, easily. With a separate debian-dir project, I can separate the management of the packaging rules from the package code itself.

Also, I have abstracted out the really common bits across all my packages into a ./debian.common directory, which is yet another project, and included in as a submodule in all the packages – so there is a central place to change the common bits, without having to duplicate my efforts 30-odd times.

Now people are complaining since they have no idea how to clone my package repositories, since apparently no one actually pays attention to a file called .gitmodules, and even when they do, they, and the tools they use, have no clue what to do with it. I am tired of sending emails with one off-cluebats, and I am building my own porcelain around something I hope to present as a generic vcs-pkg implementation soon. The firs step is a wrapper around git-clone, that understands git submodules.

So, here is the browsable code (there is a link in there to the downloadable sources too). Complete with a built in man page. Takes the same arguments as git-clone, but with fewer options. Have fun.

Posted Thu 16 Apr 2009 03:47:05 UTC Tags: ?manoj
Manoj Srivastava's SCM and packaging related blog posts Manoj: A day in the life of a Debian hacker

I have been meaning to write this up for a long time now, since I Packaging activity diagram vaguely made a promise to do so last Debconf. I have also been wondering about the inefficiencies in my work-flow, but I kept postponing my analysis since there were still large gaps in my packaging automation since I moved off Arch as my SCM of choice. However, recently I have taken a sabbatical from Debian, so I’ve had time to complete bits and pieces of my package building framework, enough so that I could no longer justify putting off the analysis. I tried writing it up, but the result confused even me; so I instead recorded every shell command during a recent series of packaging tasks, and converted that into a nice, detailed, activity diagram that you see over here. This is as efficient a work-flow as I have been able to come up with.

details here

Along with a git commit hook script, that parses the commit log and adds pending tags to bugs closed in the commit, the figure above represents my complete work-flow – down to the details of every cd command I executed. I think there are too many steps still.

Feedback and commentary would be appreciated, as well as any suggestions to improve efficiency.

Posted Wed 25 Feb 2009 06:55:03 UTC Tags: ?manoj
zack's vcs related blog posts debcheckout hacking

New features for debcheckout, … now with TopGit support!

Today I’ve spent some time hacking on debcheckout, which for weird reasons happens to be at the bottom of a stack of chained things that I need to do in the forthcoming days. Also, I had neglected debcheckout for a while, and the other devscripts folks where ready to shout at me because of that :-) .

Well, it has been fun, and beside having fixed all the outstanding bugs, debcheckout has grown some cute new features:

Enjoy!

(ah, of course all this is not uploaded yet, but you can grab a preview from devscripts’ VCS or, better, doing debcheckout devscripts which is soooo bootstrapy. SCNR.)

Posted Fri 31 Oct 2008 00:31:47 UTC Tags: ?zack
madduck's vcs-pkg-related blog posts RRR Interview on Debian and cross-distro collaboration

During LCA2008, Ed Borland of Melbourne-based Triple R FM Byte Into It show took me aside for an interview and asked some good questions about Debian and my work on cross-distro collaboration. The interview was recorded and is now available as Ogg Vorbis file from the 14 May 2008 issue of Byte Into It.

I am looking forward to any feedback.

Thanks to Ed and Phil Wales for their time and help.

NP: Mono: You Are There

Posted Tue 20 May 2008 16:31:28 UTC Tags: ?madduck
madduck's vcs-pkg-related blog posts vcs-pkg work session in Extremadura, 2nd try

We were given another chance to meet in Extremadura to discuss vcs-pkg issues, after the first opportunity was too short notice.

Currently, the tentatively scheduled dates are 2-7 September 2008. You can get the details from the wiki page. If you’re interested, please reserve those dates and add yourself to the list of participants.

NP: Hooverphonic: The Magnificent Tree

Posted Sun 18 May 2008 13:16:57 UTC Tags: ?madduck
Manoj Srivastava's SCM and packaging related blog posts Manoj: Schemes for packaging using Git: An analysis

“Are you rebasing or merging?” seems to be the 64 thousand dollar question over in vcs-pkg discussions. Various people have offered their preferences, and indeed, several case studies of work flows have been presented, what is lacking is an analysis of the work-flow; an exploration of which methodology has advantages, and whether there are scenarios in which the other work flow would have been better.

Oh, what are all these work flows about, you ask? Most of the issues with packaging software for distributions have a few things in common: there is a mainline or upstream source of development. There are zero or more independent lines of development or ongoing bug fixes that are to be managed. And then there is the tree from which the distribution package is to be built. All this talk about packaging software work flows is how to best manage asynchronous development upstream and in the independent lines of development, and how to create a coherent, debuggable, integrated tree from which to build the distributions package.

The rebasing question goes to the heart of how to handle the independent lines of development using git; since these lines of development are based off the main line of development, and must be periodically synchronized. Here is a first look at a couple of important factors that will have bearing on that question, and packaging software for a distribution using Git in general. This is heavily geared towards git (nothing else does rebases so easily, I think), but some of the concepts should be generic. I am not considering the stacked set of quilt patches source controlled with Git in this article (I don’t understand that model well enough to do an analysis)

As a teaser, there is a third answer: neither. You can just add an independent line of development, and just let it sit: don’t rebase, and don’t merge; and in some circumstances that is a winning strategy.

Posted Fri 04 Apr 2008 19:48:10 UTC Tags: ?manoj
Manoj Srivastava's SCM and packaging related blog posts Manoj: Migrating to Git

I have been using Arch to package my Debian packages since 2003; which means that Arch has had a good long run as my SCM of choice. I have been using CVS for a few years before I moved to arch, and the migration took me about six months, since it involved a while new philosophy of packaging; I am hoping that migrating to git would not involve such a major paradigm shift, and thus be less disruptive and time consuming. What follows is a narrative of my efforts to get educated about Git.

This article is meant to be an annotated, selective, organized set of links to information about Git. How does it differ from the myriad of other link collections about Git proliferating on the web? Well, the value add is in the annotations and the organization: while not quite a narrative of my exploration, this is an idealized version of what I think my discovery process should have been, to be most effective. Staging the information is important; google finds one lots of information that is incomprehensible to someone just coming to Git. This selection of links is actually selective; I have included only pointers to resources that fed me information at the level that I could handle at that stage, and I have eliminated links to information that was not new at that point. I have tried to select the best (in terms of information and clarity) of breed for each kind of information source I have come across so far.

There is a caveat: while still a beginner, though I am able to better judge now what is confusing to a beginner than I shall be when I have become more familiar with the system, I am still enough of a novice not to trust my judgement on what really is best practice. I can fix the latter as I gain experience, but then I’ll need to be careful not to overload on complexity too early in the learning curve.

On the down side, this selection is subjective, and probably shall be even in the long term: I include what appealed to me, and will probably miss loads of pointers to information that I have not yet come across. However, I hope this will make it easier for other people to reach the same goal: use git for their version control needs.

Have fun.

Posted Wed 02 Apr 2008 04:17:27 UTC Tags: ?manoj
jelmer's vcs-pkg related blog posts Using bzr-builddeb as a svn-buildpackage replacement

This slightly evil hack to bzr-svn allows using bzr-builddeb as a drop-in replacement for svn-buildpackage, making it recognize the “mergeWithUpstream” property svn-buildpackage uses.

cp: Jeff Healey - Mess O’ Blues

Posted Wed 26 Mar 2008 15:21:20 UTC Tags: ?jelmer

Entries are updated every 48 */3 * * * (yes, this is cron).