Update

There is an easier method to do all this using gbp-clone as described here. Ah !

Then to build the package, you just need to suggest git-buildpackage where to find the pristin-tar :

git-buildpackage --git-upstream-branch=upstream/master

or you could simply describe (as suggested) the layout in debian/gbp.conf.

Easy !!!

I’ve found a lot of different recipes and howtos about git debian packaging, but I failed to find one simple recipe to create a debian package from scratch when upstream is using git. Of course the following is a big patchwork from many different sources.

First we need to do a bit of administrative work to setup the repository :

mkdir yourpackage
cd yourpackage
git init --shared

Then, since I’m interested in tracking upstream development branch I’m going to add a remote branch to my repo:

git remote add upstream git://the.url/here.git

at this point I need to fetch upstream and create a branch for it.

git fetch upstream
git checkout -b upstream upstream/master

Now in my repo I have a master branch and an upstream branch. So far, so good. Let’s add the debian branch based on master:

git checkout master
git checkout -b debian master

It’s in the debian branch where I’m going to keep the debian related files. I’m finally read for hacking git add / git commit / git remove ...

When I’m done, I can switch to master, merge the debian branch into it and use git-buildpackage to build the package.

git checkout master
git branch 
  debian
* master
  upstream

git merge debian
git-buildpackage

Suppose I want to put everything on gitourious for example. I’ll create an acocunt, set up my ssh pub key and then I’ve to add an origin ref in my .git/config . Something like :

[remote "origin"]
       url = git@gitorious.org:debian-stuff/yourpackage.git
       fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
       remote = origin
       merge = refs/heads/master

The only thing left to do is to push everything on gitourious. the —all is important.

git push --all

People willing to pull your work from girourious have to follow the following script :

$git clone git@gitorious.org:debian-stuff/yourpackage.git
$cd yourpackage
$git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/debian
  remotes/origin/master
  remotes/origin/upstream
$git checkout -t origin/debian
$git checkout -t origin/upstream
$git branch -a
  debian
  master
* upstream
  remotes/origin/HEAD -> origin/master
  remotes/origin/debian
  remotes/origin/master
  remotes/origin/upstream
$git checkout master
$git-buildpackage

Maybe there is an easier way to pull all remote branches at once, but I’m not aware of it. Any better way ?

And this is all True !!! well, for the 5 people reading this blog, I assure you, I’m not selling your data or tracking you in any way :)

At COMPANY _ we value your privacy a great deal. Almost as much as we value the ability to take the data you give us and slice, dice, julienne, mash, puree and serve it to our business partners, which may include third-party advertising networks, data brokers, networks of affiliate sites, parent companies, subsidiaries, and other entities, none of which we’ll bother to list here because they can change from week to week and, besides, we know you’re not really paying attention.

We’ll also share all of this information with the government. We’re just suckers for guys with crew cuts carrying subpoenas.

Remember, when you visit our Web site, our Web site is also visiting you. And we’ve brought a dozen or more friends with us, depending on how many ad networks and third-party data services we use. We’re not going to tell which ones, though you could probably figure this out by carefully watching the different URLs that flash across the bottom of your browser as each page loads or when you mouse over various bits. It’s not like you’ve got better things to do.

Each of these sites may leave behind a little gift known as a cookie — a text file filled with inscrutable gibberish that allows various computers around the globe to identify you, including your preferences, browser settings, which parts of the site you visited, which ads you clicked on, and whether you actually purchased something.

Those same cookies may let our advertising and data broker partners track you across every other site you visit, then dump all of your information into a huge database attached to a unique ID number, which they may sell ad infinitum without ever notifying you or asking for permission.

Also: We collect your IP address, which might change every time you log on but probably doesn’t. At the very least, your IP address tells us the name of your ISP and the city where you live; with a legal court order, it can also give us your name and billing address (see guys with crew cuts and subpoenas, above).

Besides your IP, we record some specifics about your operating system and browser. Amazingly, this information (known as your user agent string) can be enough to narrow you down to one of a few hundred people on the Webbernets, all by its lonesome. Isn’t technology wonderful?

The data we collect is strictly anonymous, unless you’ve been kind enough to give us your name, email address, or other identifying information. And even if you have been that kind, we promise we won’t sell that information to anyone else, unless of course our impossibly obtuse privacy policy says otherwise and/or we change our minds tomorrow.

We store this information an indefinite amount of time for reasons even we don’t fully understand. And when we do eventually get around to deleting it, you can bet it’s still kicking around on some network backup drives in somebody’s closet. So once we have it, there’s really no getting it back. Hell, we can’t even find our keys half the time — how do you expect us to keep track of this stuff?

Not to worry, though, because we use the very bestest security measures to protect your data against hackers and identity thieves, though no one has actually ever bothered to verify this. You’ll pretty much just have to take our word for it.

So just to recap: Your information is extremely valuable to us. Our business model would totally collapse without it. No IPO, no stock options; all those 80-hour weeks and bupkis to show for it. So we’ll do our very best to use it in as many potentially profitable ways as we can conjure, over and over, while attempting to convince you there’s nothing to worry about.

(Hey, Did somebody hold a gun to your head and force you to visit this site? No, they did not. Did you run into a pay wall on the home page demanding your Visa number? No, you did not. You think we just give all this stuff away because we’re nice guys? Bet you also think every roomful of manure has a pony buried inside.)

This privacy policy may change at any time. In fact, it’s changed three times since we first started typing this. Good luck figuring out how, because we’re sure as hell not going to tell you. But then, you probably stopped reading after paragraph three.

(Source : http://www.itworld.com/print/129778 )

Sometimes I think I’m a bit lazy to change my habits.

I’ve been looking at tiling window managers for a while, but I always failed to adopt one because of the big shift in habits it would have implied. This time, thanks to zack’s applet I decided to jump on the awesome bandwagon. And I’ve to say that I’m really happy about it. Since now I had never noticed how annoying was to move windows around. It is true that in the last year I’ve used guake as main console. Since it is a drop down and tabbed console, effectively it saved me the stress of placing a new window all the time I needed a new console. However there were still a lot of applications that were popping windows everywhere and I had no choice to find a place for them.

Awesome solves all these problems. Windows are positioned automatically. You can easily change from one layout to another using a key combination, it is very flexible (it’s configuration file is a program written in lua !!) and now thanks to zack’s applet is perfectly integrated with my gnome desktop. It basically replaces out of the box metacity (the default gnome window manager) just doing what awesome was meant to do : the window manager. You can disable all the extra features like the awesome panel and menus from the panel, and keep using gnome for everything else.

The other great tool I’ve just discovered thanks to an article on arstechnica is gtg . This is also a very handy tool. I’ve been using sticky notes for quite a while (both electronic and real ) but I’m far to be satisfied with it. I refuse to use tomboy as it uses mono and I prefer to avoid it (on religious grounds) . GTG follows the Get Things Done GTD methodology. At the end is just a friendly note taking tool with a lot plug-ins designed to be used with a keyboard. I’ve just started to use it and despite it already crashed on me few times I like it a lot.

Third and last (for this blog post) tool is a mind mapping tool. I’ve done mind mapping for a while : let’s say that I’m not a compulsive mind mapper but I enjoy putting things in place when I’ve time. In the past I’ve used freemind that is nice, but it crashed on me too many times. Alas, is written in java, and given my allergy to this language, I think this is just bad karma flowing in both directions… A couple of weeks ago I stumbled upon another mind mapping tool vym that is much more stable and a real pleasure to use. It didn’t crash once yet, it is very usable from the keyboard (essential when you are taking notes !) and it has a nice look & feel and a rich feature set. I’m happy it it.

I tried out chromium in the last 3 weeks. It is clearly faster then iceweasel/firefox . One one hand this is because of the architecture of chromium itself. People at google worked very hard to develop a competitive and lean browser. On the other hand, I think because on the firefox side I use a lot of extensions that can cripple performances and make the comparison a bit unfair. I should try yo start from scratch with with iceweasel using a clean profile and see how it goes.

Since everybody is trumpeting about this new browser I felt obliged to give it a try. Well… it doesn’t cut it for me.

• The first big problem for me is that there is no easy way to clean up the cache, browsing history, cookies, etc on exit. Call me paranoid, but I think this is an essential feature for a browser. Yes, it is true that this can be done manually and there is even a (windows-only) extension to clean up everything for you, but I find ridiculous that this simple feature cannot be added by default. The people at google are justifing this saying that since chrome has a very aggressive cache strategy, cleaning up the cache every time can lead to a slower user experience. Granted, this can be true, but I think an option should be there nonetheless and let the user choose if they want a clean start every time or the want to leave cookies and stuff lying around the disk. Other people simply say that google doesn’t want such a feature in the browser as it would cripple google tracking tools and lower their advertising revenue. I can see that this can be true, and I hope the community will step and patch (if not fork) the main trunk to add more sensible defaults. For a while I’ve solved this browsing in incognito mode, but this adds other nuisances…

• The second problem I’ve encountered is the lack of a good ads blocker. There are few around, but none of them are still up to speed with the quality of the ads blocker in the firefox world. I lived in an ads free world for a while and getting back to the horribly blinking and colorful websites where finding the information you are looking for is more difficult than to navigate a maze, is not acceptable for me.

• Third problem is the Cntl-F problem. there is a feature request that is marked as WontFix just because the forward slash (that for me is the more natural way yo search in a page) conflicts with gmail. Again. It’s a choice. But adding the possibility to change the default behavior would be the most sensible thing to do instead of marking the request as a won’t fix and ignore the outcry of the community.

• Then there is the lack of extensions. Well, to be fair, the extensions that I was looking for maybe are not very google friendly. In particular on firefox there is a google anonymity that does a nice job removing all sort of cookies and avoiding tracking thought the google services. Another extension that I’m missing is Ubiquity, that despite being abandoned by the mozilla labs, I find extremely useful and powerful to speed up my contextual searches.

In conclusion I think chromium is not there for me yet. There are too many downside to justify the move. I’m sure I would reconsider my position in 6 months and I really hope that the google developers will show a bit more of support for the community.

This is the second post about distcheck. I want to give a quick overview of the differences between edos-distcheck and the new version. First despite using the same sat solver and encoding of the problem, Distcheck has been re-written from scratch. Dose2 has several architectural problems and not very well documented. Adding new features had become too difficult and error-prone, so this was a natural choice (at least for me). Hopefully Dose3 will survive the Mancoosi project and provide a base for dependency reasoning. The framework is well documented and the architecture pretty modular. It’s is written in ocaml, so sadly, I don’t expect many people to join the development team, but we’ll be very open to it.

These are the main differences with edos-debcheck .

Performances

distcheck is about two times faster than edos-debcheck (from dose2), but it is a “bit” slower then debcheck (say the original debcheck), that is the tool wrote by Jerome Vouillon and that was then superseded in debian by edos-debcheck. The original debcheck was a all-in-one tool that did the parsing, encoding and solving without converting the problem to any intermediate format. distcheck trades a bit of speed for generality. Since it is based on Cudf, it can handle different formats and can be easily adapted in a range of situation just by changing the encoding of the original problem to cudf.

Below there are a couple of test I’ve performed on my machine (debian unstable). The numbers speak alone.

$time cat tmp/squeeze.packages | edos-debcheck -failures > /dev/null
Completing conflicts...                                            * 100.0%
Conflicts and dependencies...                                      * 100.0%
Solving                                                            * 100.0%

real    0m19.515s
user    0m19.193s
sys 0m0.276s

$time ./distcheck.native -f deb://tmp/squeeze.packages > /dev/null

real    0m10.859s
user    0m10.669s
sys 0m0.172s

Input

The second big difference is about different input format. In fact, at the moment, we have two different tools in debian, one edos-debcheck and the other edos-rpmcheck. Despite using the same underlying library these two tools have different code bases. distcheck basically is a multiplexer that convert different inputs to a common format and then uses it (agnostically) to solve the installation problem. It can be called in different ways (via symlinks) to behave similarly to its predecessors.

At the moment we are able to handle 5 different formats

deb:// Packages 822 format for debian based distributions

hdlist:// a binary format used by rpm based distribution

synth:// a simplified format to describe rpm based package

repositories

eclipse:// a 822 based format that encoded OSGi plugings metadata

cudf:// the native cudf format

distcheck handles gz and bz2 compressed file transparently . However if you care about performances, you should decompress your input file first and the parse it with distcheck and it often takes more time to decompress the file on the fly that run the installability test itself. There is also an experimental database backend that is not compiled by default at them moment.

Output

Regarding the output, I’ve already explained the main differences in an old post. As a quick reminder, the old edos-debcheck had two output options. The first is a human readable - unstructured output - that was a handy source of information when running the tool interactively. The second was a xml based format (without a dtd or a schema, I believe) that was used for batch processing.

distcheck has only one output type in the YAML format that aims to be human and machine readable. Hopefully this will cater for both needs. Moreover, just recently I’ve added the output of distcheck a summary of who is breaking what. The output of edos-debcheck was basically a map of packages to the reasons of the breakage. In addition to this information distcheck gives also a maps between reason (a missing dependency or a conflict) to the list of packages that are broken by this problem.This additional info is off by default, but I think it can be nice to know what is the missing dependency that is responsible for the majority of problems in a distribution…

For example, calling distcheck with —summary :

$./distcheck.native --summary deb://tests/sid.packages 
backgroud-packages: 29589
foreground-packages: 29589
broken-packages: 143
missing-packages: 138
conflict-packages: 5
unique-missing-packages: 52
unique-conflict-packages: 5
summary:
 -
  missing:
   missingdep: libevas-svn-05-engines-x (>= 0.9.9.063)
   packages:
    -
     package: enna-dbg
     version: 0.4.0-4
     architecture: amd64
     source: enna (= 0.4.0-4)
    -
     package: enna
     version: 0.4.0-4
     architecture: amd64
     source: enna (= 0.4.0-4)
 -
  missing:
   missingdep: libopenscenegraph56 (>= 2.8.1)
   packages:
    -
     package: libosgal1
     version: 0.6.1-2+b3
     architecture: amd64
     source: osgal (= 0.6.1-2)
    -
     package: libosgal-dev
     version: 0.6.1-2+b3
     architecture: amd64
     source: osgal (= 0.6.1-2)

Below I give a small example of the edos-debcheck output compared to the new yaml based output.

$cat tests/sid.packages | edos-debcheck -failures -explain
Completing conflicts...                                            * 100.0%
Conflicts and dependencies...                                      * 100.0%
Solving                                                            * 100.0%
zope-zms (= 1:2.11.1-03-1): FAILED
  zope-zms (= 1:2.11.1-03-1) depends on missing:
  - zope2.10
  - zope2.9
zope-tinytableplus (= 0.9-19): FAILED
  zope-tinytableplus (= 0.9-19) depends on missing:
  - zope2.11
  - zope2.10
  - zope2.9
...

And an extract from the distcheck output (the order is different. I cut and pasted parts of the output here…)

$./distcheck.native -f -e deb://tests/sid.packages
report:
 -
  package: zope-zms
  version: 1:2.11.1-03-1
  architecture: all
  source: zope-zms (= 1:2.11.1-03-1)
  status: broken
  reasons:
   -
    missing:
     pkg:
      package: zope-zms
      version: 1:2.11.1-03-1
      architecture: all
      missingdep: zope2.9 | zope2.10
 -
  package: zope-tinytableplus
  version: 0.9-19
  architecture: all
  source: zope-tinytableplus (= 0.9-19)
  status: broken
  reasons:
   -
    missing:
     pkg:
      package: zope-tinytableplus
      version: 0.9-19
      architecture: all
      missingdep: zope2.9 | zope2.10 | zope2.11
...

Future

The roadmap to release version 1.0 of distcheck is as follows:

add background and foreground package selection. This feature will

allow the use to specify a larger universe (background packages), but check only a subset of this universe (foreground packages). This should allow users to select packages using grep-dctrl and then pipe them to discheck . At the moment we can select individual packages on the command line or we can use expression like bash (<= 2.7) to check all version of bash in the universe with version greater than 2.7.

code cleanup and a bit of refactoring between distcheck and

buildcheck (that is a frontend for distcheck that allow us to report broken build dependencies)

consider essential packages while performing the installation test.

Here there are few things we have to understand, but the idea would be to detect possible problems related the implicit presence of essential packages in the distribution. At the moment, distcheck performs the installation test in the empty universe, while ideally, the universe should contain all essential packages.

finish the documentation. The effort in underway and we hope to

finalize shortly to release the debian package in experimental.