Whenever I want to work on some package, I usually clone its git repository, make my changes, then push and upload the Debian package. I don’t keep those repositories around in order to avoid cruft and also to have a 100% clean, up-to-date setup whenever I start working on something.
Everytime I clone such a repository, I struggle with the setup. For example, I usually forget the --pristine-tar flag for gbp-clone. Also, I usually forget to push other branches (working on “debian”, forgetting “upstream”) and, even more often, I forget pushing tags.
I spent some time on this and figured out that one can use the following to make --pristine-tar the default:
cat >> ~/.gbp.conf <EOF [DEFAULT] pristine-tar = True EOF
Avoiding my other pain points is not so easy apparently, so I wrote a little shell function (only tested with zsh!) which uses debcheckout to get the git URL, gbp-clone to actually clone it and a few git config calls to make me able to just “git push” when I am done and not worry about anything:
# Clones the git sources of a Debian package
# needs debcheckout from devscripts and gbp-clone from git-buildpackage
function d-clone() {
local package=$1
if debcheckout --print $package >/dev/null
then
set -- $(debcheckout --print $package)
if [ "$1" != "git" ]
then
echo "$package does not use git, but $1 instead."
return
fi
echo "cloning $2"
gbp-clone $2 || return
# Change to the newest git repository
cd $(dirname $(ls -1td */.git | head -1)) || return
# This tells git to push all branches at once,
# i.e. if you changed upstream and debian (after git-import-orig),
# both upstream and debian will be pushed when running “git push”.
git config push.default matching || return
# This tells git to push tags automatically,
# so you don’t have to use “git push; git push --tags”.
git config --add remote.origin.push "+refs/heads/*:refs/remotes/origin/*" || return
git config --add remote.origin.push "+refs/tags/*:refs/tags/*" || return
echo "d-clone set up everything successfully."
else
echo "debcheckout $package failed. Is $package missing Vcs tags?"
fi
}
With that function, starting work on a package becomes as easy as
“d-clone golang-doc”.
In the past, we have had multiple heated discussions involving systemd. We (the pkg-systemd-maintainers team) would like to better understand why some people dislike systemd.
Therefore, we have created a survey, which you can find at http://survey.zekjur.net/index.php/391182
Please only submit your feedback to the survey and not this thread, we are not particularly interested in yet another systemd discussion at this point.
The deadline for participating in that survey is 7 days from now, that is 2013-05-26 23:59:00 UTC.
Please participate only if you consider yourself an active member of the Debian community (for example participating in the debian-devel mailing list, maintaining packages, etc.).
Of course, we will publish the results after the survey ends.
Thanks!
Best regards,
the Debian systemd maintainers
Recently, I was wondering how many Debian Developers are actively working on RC bugs in some way or another in the time period of the last release (squeeze) to now (shortly? before wheezy).
I therefore grabbed the mailing list archives of debian-bugs-dist@ from gmane, used only those messages whose X-Debian-PR-Message header matches an RC bug (list retrieved from UDD) and then attributed the message counts to the appropriate Debian Developer.
I am sure that there are subtle mistakes in the data I retrieved and that there most likely is a better way to achieve the same results, but this is only to get a trend and should be good enough for that.
So, it turns out that 514 different Debian Developers have sent messages regarding RC bugs since squeeze. That’s about half of our 985 total active Debian Developers.
I would love to show a good histogram of the actual message counts (not sure how well received showing the raw data is…), but I suck at visualizing such data in a compact way. Is there anyone familiar with R (or other free data visualization tools) and willing to help? I can send you the CSV file, just send me an email to stapelberg@.
Previously, my workflow regarding replying to bugreports outside my own packages was very uncomfortable: I first downloaded the mbox archive from the BTS, then imported that in claws-mail, hit reply all, remove submit@, add bugnumber@, then send the email.
Therefore, I decided to hack up a little elisp function to automate this process for notmuch. It first downloads the message from the BTS, adds it to the notmuch database, then calls notmuch-mua-reply on the message and fixes the To: header:
;; Removes submit@bugs.debian.org from the recipients of a reply-all message.
(defun debian-remove-submit (recipients)
(delq nil
(mapcar (lambda (recipient)
(and (not (string-equal (nth 1 recipient) "submit@bugs.debian.org"))
recipient))
recipients)))
(defun debian-add-bugrecipient (recipients bugnumber)
(let* ((bugaddress (concat bugnumber "@bugs.debian.org"))
(addresses (mapcar (lambda (x) (nth 1 x)) recipients))
(exists (member bugaddress addresses)))
(if exists
recipients
(append (list (list (concat "Bug " bugnumber) bugaddress)) recipients))))
;; TODO: msg should be made optional and it should default to the latest message in the bugreport.
;; NB: bugnumber and msg are both strings.
(defun debian-bts-reply (bugnumber msg)
;; Download the message to ~/mail-copy-fs/imported.
(let ((msgpath (format "~/mail-copy-fs/imported/bts_%s_msg_%s.msg" bugnumber msg)))
(let* ((url (format "http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=%s;mbox=yes;bug=%s" msg bugnumber))
(download-buffer (url-retrieve-synchronously url)))
(save-excursion
(set-buffer download-buffer)
(goto-char (point-min)) ; just to be safe
(if (not (string-equal
(buffer-substring (point) (line-end-position))
"HTTP/1.1 200 OK"))
(error "Could not download the message from the Debian BTS"))
;; Delete the HTTP headers and the first "From" line (in order to
;; make this a message, not an mbox).
(re-search-forward "^$" nil 'move)
(forward-char)
(forward-line 1)
(delete-region (point-min) (point))
;; Store the message on disk.
(write-file msgpath)
(kill-buffer)))
;; Import the mail into the notmuch database.
(let ((msgid (with-temp-buffer
(call-process "~/.local/bin/notmuch-import.py" nil t nil (expand-file-name msgpath))
(buffer-string))))
(notmuch-mua-reply (concat "id:" msgid) "Michael Stapelberg <stapelberg@debian.org>" t)
;; Remove submit@bugs.debian.org, add <bugnumber>@bugs.debian.org.
(let* ((to (message-fetch-field "To"))
(recipients (mail-extract-address-components to t))
(recipients (debian-remove-submit recipients))
(recipients (debian-add-bugrecipient recipients bugnumber))
(recipients-str (mapconcat (lambda (x) (concat (nth 0 x) " <" (nth 1 x) ">")) recipients ", ")))
(save-excursion
(message-goto-to)
(message-delete-line)
(insert "To: " recipients-str "\n")))
;; Our modifications don’t count as modifications.
(set-buffer-modified-p nil))))
In case you want to get updates, you can find the latest version of this code in my configfiles git repository.
To add a single message to the notmuch database and get its message ID, I have
written this simple python script (using python-notmuch), located in
~/.local/bin/python-import.py:
#!/usr/bin/env python
# vim:ts=4:sw=4:et
import notmuch
import sys
if len(sys.argv) < 2:
print "Syntax: notmuch-import.py <filename>"
sys.exit(0)
db = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)
(msg, status) = db.add_message(sys.argv[1])
print msg.get_message_id()
If you have any improvements, I’d love to hear about it. If it’s useful for you, enjoy.
I recently worked on the following RC bugs:
By the way, in case anyone needs to reproduce an armhf bug and wants to do so in a chroot with qemu, here are the steps I used:
sudo qemu-debootstrap --arch=armhf --foreign wheezy armhf http://ftp.de.debian.org/debian sudo LC_ALL=C chroot armhf /bin/bash echo 'deb http://ftp.de.debian.org/debian wheezy main' > /etc/apt/sources.list echo 'nameserver 8.8.8.8' > /etc/resolv.conf apt-get update apt-get install clang
Also, here are UDD queries which I prefer to those posted by RichiH. Note that they don’t display all bugs, but ignore those which were created in the last 7 days.
I recently worked on the following RC bugs:
It is getting hard to find RC bugs to work on. If you have access to ia64 hardware, have a look at #694971 — Epiphany browser crashes within JSC::JSArray::increaseVectorLength() or #697172 — sporadic crashes of epiphany browser due to a thread-unsafe favicon database. Both have patches available that just need to be tested.
I just uploaded wit-2.10a to Debian experimental (it has to pass the NEW queue first, though).
WIT (Wiimms ISO Tools) is a set of command-line tools to manipulate Wii and GameCube ISO images and WBFS containers. It is useful (for me) to store backups of my Wii games on a USB hard disk drive. This saves me the optical disc juggling, doesn’t wear off the discs as fast and gives faster load times.
Here is an example session where I format one partition of the USB hard disk with WBFS and then copy my old WBFS image over to it:
$ wwt format -v --force /dev/sde3 wwt: Wiimms WBFS Tool v2.10a r0 x86_64 - Dirk Clemens - 2013-01-02 FORMAT BLOCK DEVICE /dev/sde3 [172 GiB, hss=512] ** 1 file formatted. $ wwt add --part /dev/sde3 /media/sde1/wbfs/The\ Legend\ of\ Zelda\ Skyward\ Sword\ \[SOUP01\]/*.wbfs ***** wwt: Wiimms WBFS Tool v2.10a r0 x86_64 - Dirk Clemens - 2013-01-02 ***** WBFSv1 #1/1 opened: /dev/sde3 - ADD 1/1 [SOUP01] WBFS:/media/sde1/wbfs/The Legend of Zelda Skyward Sword [SOUP01]/SOUP01.wbfs/#0 * WBFS #1: 1 disc added. wwt add --part /dev/sde3 0,02s user 7,66s system 2% cpu 5:02,68 total $ wwt list ID6 1/500 discs (4 GiB) --------------------------------------------------------------------- SOUP01 The Legend of Zelda Skyward Sword --------------------------------------------------------------------- Total: 1/500 discs, 4176 MiB ~ 4 GiB used, 171444 MiB ~ 167 GiB free.
I recently worked on the following RC bugs:
I recently worked on the following RC bugs:
I recently worked on the following RC bugs: