Seeing what has been posted recently in planet.d.o, I would like to share as well my thoughts and work-flow, and tell that I do agree with Joey Hess on many of his arguments. Especially when he tells that Debian fetishises upstream tarballs. We re in 2013, at the age of Internet, and more and more upstream authors are using Git, and more and more they don t care about releasing tarballs. I ve seen some upstream authors who simply stopped doing so completely, as a Git tag is really enough. I also fully agree than disk space and network speed isn t much of a problem these days.
When there are tags available, I use the following debian/gbp.conf:
[DEFAULT] upstream-branch = master debian-branch = debian upstream-tag = %(version)s compression = xz [git-buildpackage] export-dir = ../build-area/On many of my packages, I now just use Git tags from upstream if they are available. To make it more easy, I now nearly always use the following piece of code in my debian/rules files:
DEBVERS ?= $(shell dpkg-parsechangelog sed -n -e 's/^Version: //p')
VERSION ?= $(shell echo '$(DEBVERS)' sed -e 's/^[[:digit:]]*://' -e 's/[-].*//')
DEBFLAVOR ?= $(shell dpkg-parsechangelog grep -E ^Distribution: cut -d" " -f2)
DEBPKGNAME ?= $(shell dpkg-parsechangelog grep -E ^Source: cut -d" " -f2)
DEBIAN_BRANCH ?= $(shell cat debian/gbp.conf grep debian-branch cut -d'=' -f2 awk ' print $1 ')
GIT_TAG ?= $(shell echo '$(VERSION)' sed -e 's/~/_/')
get-upstream-sources:
git remote add upstream git://git.example.org/proj/foo.git true
git fetch upstream
if ! git checkout master ; then \
echo "No upstream branch: checking out" ; \
git checkout -b master upstream/master ; \
fi
git checkout $(DEBIAN_BRANCH)
make-orig-file:
if [ ! -f ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] ; then \
git archive --prefix=$(DEBPKGNAME)-$(GIT_TAG)/ $(GIT_TAG) xz >../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ; \
fi
[ ! -e ../build-area ] && mkdir ../build-area true
[ ! -e ../build-area/$(DEBPKGNAME)_$(VERSION).orig.tar.xz ] && cp ../$(DEBPKGNAME)_$(VERSION).orig.tar.xz ../build-area true
Packaging a new upstream VERSION now means that I only have to edit the debian/changelog, do ./debian/rules get-upstream-source so that I get new commits and tags, then git merge -X theirs VERSION to import the changes, then finally invoke ./debian/rules make-orig-file to create the orig.tar.xz. My debian branch is now ready for git-buildpackage. Note that the sed with the GIT_TAG thing is there because unfortunately, Git doesn t support the ~ char in tags, and that most of the time, upstream do not use _ in version numbers. Let s say upstream is releasing version 1.2.3rc1, then I simply do git tag 1.2.3_rc1 1.2.3rc1 so that I have a new tag which points to the same commit as 1.2.3rc1, but that can be used for the Debian 1.2.3~rc1-1 release and the make-orig-file.
All this might looks overkill at first, but in fact it is really convenient and efficient. Also, even though there is a master branch above, it isn t needed to build the package. Git is smarter than this, so even if you haven t checked out upstream master branch from the upstream remote, make-orig-file and git-buildpackage will simply continue to work. Which is cool, because this means you can store a single branch on Alioth (which is what I do).
phpMyAdmin 4.0-rc1 is out and it's really time to work on translations if you want them to be ready for final release..
So let's look at which translations are at 100% right now (new ones are bold):
Filed under: English Phpmyadmin 0 comments Flattr this!
git fetch and you have the upstream tags, and then pass the
flag --upstream-vcs-tag <tag> to git-import-orig whenever importing
the upstream release tarball. git-import-orig will handle the
construction of the merge commit for you and everything will just work,
exactly like it normally does with git-buildpackage except with a more
complete history.
This support was added in git-buildpackage 0.6.0~git20120324, so it's
available in unstable and testing.
(I was going to update my notes on
Debian packaging with Git to include this information before posting
this, but I see that it will require some restructuring and quite a few
changes to that document and I don't have time tonight. Hopefully soon.)
Today was spent at my apartment with Zoe. Harvey Norman were scheduled to
deliver the fridge, washing machine and TV. Someone from Telstra was
scheduled to come out and monkey with the MDF to get the naked ADSL
happening, and my desk was scheduled to be delivered.
My parents drove us over in the morning, with some of our suitcases. Zoe was
very happy with her new room and bed.
I was going to get a 1 hour advance warning of Harvey Norman coming, so we
all went for a little walk around the neighbourhood to explore. It turns out
there's a convenience store right next door, which is, well extremely
convenient. I won't need to even hop in the car to get last minute bread or
milk or anything like that. Very happy about that. There's also a really
gorgeous little boutique
deli/gourmet grocery that is easily within walking distance. The
neighbourhood is indeed very nice.
Mid-morning, Brent dropped around with his daughter to say hi. Zoe had a
good time playing with her as well, and we went out for lunch at the
Hawthorne Garage. At the end of lunch, Harvey Norman called to say they'd be
an hour away, which was well timed.
Zoe declined to nap again, so we just hung out waiting for the delivery. In
the middle of them delivering, the desk delivery happened as well, and then
as Brent was leaving, the Telstra guy turned up, so it all happened at once.
I set up the TV and DVD player and Zoe happily christened it all by watching
some Play School DVDs, and then my Dad came back and picked us up.
So the apartment is now almost habitable. I just need my bed. That's
scheduled for Saturday. I'm planning on sleeping there on Saturday night.
In the furniture department, I'm still lacking a sofa, a dining table and
something to put the TV on. Leah has volunteered to help me shop tomorrow,
but I'm starting to think I should focus on resolving the lack of a car,
then I can do any further shopping myself.
Nick had set me up with a car wholesaler who was going to search for a used
Subaru Forester for me, but so far he hasn't turned anything up, so I'm
thinking I need to widen my net a little and use some other avenues as well.
I'd really wanted for the car finding to be outsourced as much as possible
so I could focus on other things, but it's not looking like that's going to
be the case, and I really need mobility.
I got a notification from Internode after I'd left today that the Internet
should now be working, so I need to configure the ADSL router when I next
get a chance and confirm that's the case, then I'm all sorted for being
technologically able to work from home.
Puppet is a nice tool but it has a significant problem with passwords:
node "mysqlserver"
package
["mysql-server",
"mysql-client",
"sekred"]:
ensure => installed;
service
"mysqld":
name => "mysql",
ensure => running,
hasrestart => true,
hasstatus => true;
exec
"mysql-set-root-password":
command => "mysqladmin -u root password $(sekred get root@mysql)",
onlyif => "mysql -u root", # Trigger only if password-less root account.
require => [Service["mysqld"], Package["mysql-client", "sekred"]];
And to get the root password for mysql, just login into the node "mysqlserver":
$> sekred get root@mysql Cie8iezaSetting password for SSH-only user This example is quite typical of the broken fully automated scenario with passwords: - you setup a remote host only accessible through SSH - you create a user and set its SSH public key to authorize access - your user cannot access its account because SSH prevent password-less account login! In other word, you need to login into the node, set a password for the user and mail him back.... That defeats a little bit the "automation" provided by puppet. Here is what I do with sekred:
define user::template ()
user
$name:
ensure => present,
membership => minimum,
shell => "/bin/bash",
....
include "ssh_keys::$name"
# Check password less account and set one, if required.
$user_passwd="$(sekred get --uid $name $name@login)"
exec
"user-set-default-password-$name":
command => "echo $name:$user_passwd chpasswd",
onlyif => "test \"$(getent shadow $name cut -f2 -d:)\" = \"!\"",
require => [User[$name], Package["sekred"]];
So the command "test \"$(getent shadow $name cut -f2 -d:)\" = \"!\"" test for a password-less account. If this is the case, it creates a password using sekred get --uid $name $name@login and set it through chpasswd.
Note that $user_passwd use a shell expansion that will be evaluated when running the command only, on the host. The --uid flag of sekred assign the ownership of the password to the given user id.
So now the user (foo) can login into the node and retrieve its password using sekred get foo@login.
Try it!
Sekred was a very short project but I am pretty happy with it. It solves a long standing problem and helps to cover an extra mile of automation when setting up new nodes.
The homepage is here and you can download it here. Feel free to send patches, bugs and feature requests (here, login required).
A few weeks ago I taught a class on Open Source: Contributing to free culture (catalog entry) for Spark, a one-day program put on by the student-run MIT Educational Studies Program. I was fortunate to have two helpful co-teachers, Tyler Hallada and Jacob Hurwitz, who assisted with the lesson plan and the in class lecture.
I've meant to look at Hy since
Paul Tagliamonte started to talk to me about
it, but never took a chance until now.
Yesterday, Paul indicated it was a good time for me to start looking at it,
so I spent a few hours playing.
But what's Hy?
Python is very nice: it has a great community and a wide range of useful
libraries. But let's face it, it misses a great language.
Hy is an implementation of a
Lisp on top of
Python.
Technically, Hy is built directly with a custom made parser (for now) which
then translates expressions using the
Python AST module to generate
code, which is then run by Python. Therefore, it shares the same properties
as Python, and is a Lisp-1 (i.e. with a single namespace for symbols and
functions).
If you're interested to listen Paul talking about Hy during last PyCon US, I
recommend watching his lightning talk. As the name implies, it's only a few
minutes long.
<iframe allowfullscreen="allowfullscreen" class="shadow" frameborder="0" height="374" src="http://www.youtube.com/embed/1vui-LupKJI?wmode=transparent&autohide=1&egm=0&hd=1&iv_load_policy=3&modestbranding=1&rel=0&showinfo=0&showsearch=0#t=16m14s" width="500"></iframe>
Does it work?
I've been cloning the code and played around a bit with Hy. And to my
greatest surprise and pleasure, it works quite well. You can imagine writing
Python from there easily. Part of the syntax smells like
Clojure's, which looks like a good thing since they're
playing in the same area.
You can try a Hy REPL in your Web browser if you
want.
Here's what some code look like:
(import requests)
(setv req (requests.get "http://hy.pault.ag"))
(if (= req.status_code 200)
(for (kv (.iteritems req.headers))
(print kv))
(throw (Exception "Wrong status code")))
('date', 'Wed, 03 Apr 2013 12:09:23 GMT')
('connection', 'keep-alive')
('content-encoding', 'gzip')
('transfer-encoding', 'chunked')
('content-type', 'text/html; charset=utf-8')
('server', 'nginx/1.2.6')
As you can see, it's really simple to write Lispy code that really uses
Python idioms.
There's obviously still a lots of missing features in Hy. The language if
far from complete and many parts are moving, but it's really promising, and
Paul's doing a great job implementing every idea.
I actually started to hack a bit on Hy, and will try to continue to do so,
since I'm really eager to learn a bit more about both Lisp and Python
internals in the process. I've already send a few patches on small bugs I've
encountered, and proposed a few ideas. It's really exciting to be able to
influence early a language design that I'll love to use! Being a recent fan
of Common Lisp, I tend to grab the good stuff from it to add them into Hy.
Daniel Pocock posted
The multiple repository conundrum in Linux packaging.
While a generally good and useful post, which upstream developers
will find helpful to understand how Debian packages their software,
it contains this statement:
If it is the first download, the maintainer creates a new git repository. If it has been packaged before, he clones the repository. The important point here is that this is not the upstream repository, it is an independent repository for Debian packaging.The only thing important about that point is that it highlights an unnecessary disconnect between the Debian developer and upstream development. One which upstream will surely find annoying and should certainly not be bothered with. There is absolutely no technical reason to not use the upstream git repository as the basis for the git repository used in Debian packaging. I would never package software maintained in a git repository upstream and not do so. The details are as follows:
debian directory, and not the upstream source code. With disk
space increasingly absurdly cheap, and the preponderance of development
converging on git, there's no reason for this friction to be allowed to
continue. You might have already noticed that there is Hackweek 9 coming next week. At SUSE we will get pizzas, icecream and other nice stuff, but most importantly we can spend the week on hacking anything we want.
Same as last year, I want to spend most of my Hackweek on Weblate, nice crowdsourcing tool for translations. The major goal is to finish 1.5 release, what should not be that hard. The most challenging bits for new machine translation interface are already implemented, and the rest is pretty much only tweaking of existing code.
Another thing we want to explore is possibility of using Weblate for openSUSE translations. Currently they are mostly kept in SVN, what is blocker for using Weblate, but we will see what can be done there.
Filed under: English Phpmyadmin Suse Weblate 0 comments Flattr this!
Last year, I failed to write and mention that I'd joined the Council of the
Free/Libre Open-Source Software UK group FLOSS UK,
formerly known as the UK UNIX User's Group (UKUUG). As a council-member, I
helped to organise the recent Large Installation Systems Administration
conference that took place in my native Newcastle,
UK.
Five years ago I gave a talk at the (then) UKUUG Linux conference in
Manchester, 2008, about documentation for sysadmins, using ikiwiki. I recently
noticed that I hadn't put the abstract or slides up here, so now I
have.
Let's work through each of the steps in the diagram:
The upstream release
configure.ac(sometimes called configure.in) and tags the code. (Usually this tag is on a dedicated release branch.)
make dist, which puts all the files,
| Attachment | Size |
|---|---|
 release-packaging-workflow.dia | 3.97 KB |
I was going to post this yesterday, but some might have thought that it was a joke. April 1st is always an annoying day to communicate real information. If you have been fond of the way Debian and Ubuntu manage multiple PostgreSQL versions in parallel, you can now have the same on OS X with Homebrew: brew tap petere/postgresql
brew install postgresql-9.2
# etc.
brew install --HEAD postgresql-common
postgresql-common is the same code as in Debian, only mangled a little. Now you have all the client programs symlinked through pg_wrapper, and you can use the server management tools such as: pg_createcluster 9.2 main
pg_ctlcluster 9.2 main start
pg_lsclusters
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="299" src="http://www.youtube.com/embed/1vui-LupKJI?wmode=transparent&autohide=1&egm=0&hd=1&iv_load_policy=3&modestbranding=1&rel=0&showinfo=0&showsearch=0#t=16m14s" width="400"></iframe> With GNOME 3, if you want to override a setting with a new site default,
assuming your app has been updated to use the new gsettings API and doesn't
still use the old gconf one, the best guide on what to do is still Ross
Burton's blog post from two years
ago,
although you can find most of what you need to know buried deep in the
GSettings C API
specification,
which is not the first place I would have looked (lesson learned!)
Note: In this context I'm in the role of systems administrator, rather than
distributor/vendor or software author. Whereas you are generally advised to use
gsettings itself and not poke at the backend (dconf for Linux), the
documentation seems to point sysadmins towards dconf hackery rather than
gsettings. However
gsettings worked for me, and I got nowhere with dconf direct.
Some caveats worth knowing about:
gsettings tool only accepts dotted schemas, not
slash-separated ones.gsettings uses XML for schema files, but a separate ini-style
format for override files. Everybody wins?glib-compile-schemas requires a path argument, so all your schema and
override files must be in the same place. Sites have to lump stuff into
/usr/share/glib-2.0/schemas alongside distribution files, rather than
separated out to (say) /usr/local/share/glib-2.0/schemas.glib-compile-schemas
which non-the-less is broken. The result is gsettings clients, including
the gsettings binary itself, complaining and then segfaulting. Do not
rely on glib-compile-schemas to ensure compliant override files.glib-compile-schemas would appear to read override files in native byte
order, so make sure you name your override so that it sorts after any
distribution-provided overrides. E.g., 20_my_gnome-shell.gschema.override
to sort after 10_gnome-shell.gschema.override.2.1G tar
503M current
414M xz_6e
410M xz_9e
6.3M bz2
40M gz
5.8M xz
After having used mutt for about a decade, I decided it's time I move
away from it, for various reasons that I won't go into here.
I've been evaluating thunderbird^Wicedove now for a few weeks, but I
can already see I won't keep using it forever, because I find too many
issues with it:
Next.