Search Results: "tar"

13 July 2011

Torsten Werner: Certified Scrum Master

I ve passed the CSM exam of the Scrum Alliance today after having a 2 day training last week! That means that I am really agile now. The training was really good.

Steve McIntyre: Project Harmony?

So, the "Harmony Project" launched their set of contributor agreements and tools last week. Colour me unimpressed... There's a claim on their website that they are a "community-centered group", but I don't see any list of people and organisations who contributed to this work. That bothers me. Regarding their aim to "assist organisations which use contribution agreements", I don't think that there is anything of value here for the Free Software community at all. Free Software developers don't need contribution agreements, and in my opinion encouraging their use like this is only going to cause further splintering of the community. We've managed for a very long time without them, why start now? As a developer, I personally don't believe in contribution agreements at all. If I contribute code to a project, it will be under the terms of a good Free Software license or not at all. That's all that's needed. There's a fair body of opinion out there on this - see pieces from Bradley Kuhn, Richard Fontana and Dave Neary for more discussion. What do you think?

Kai Wasserb ch: Vim: How to prevent trailing whitespaces

As the local geek I get all sorts of (Linux) questions asked, like "How can you delete the nth line with Sed?" or "Is there a way to search for the following in a file?" (the latter being a request to construct a regular expression for grep). And while I'm pretty sure, you can find answers for such questions quickly with $SEARCH_ENGINE I find myself generally typing the answer into the IM session. This, and just seeing Bernd's post about Vim on Planet Debian, prompted me to start a little, irregular series of posts, to which I can point people, whenever I get asked such questions. I start this off with a tip for Vim, a very powerful text editor. The problem is simple: you get (source code) files with trailing whitespaces (sometimes accumulated in "empty" lines). This makes diffing (and merging) difficult. Thus the question is: how do I prevent that from happening? How do I notice, that I have whitespaces at the end of a line? The solution consists of two lines in your .vimrc:

:highlight TrailWhitespace ctermbg=red guibg=red
:match TrailWhitespace /\s\+$\  \+\ze\t/

If you just want this functionality if syntax highlighting is also active, then you should use

:autocmd Syntax * syn match TrailWhitespace /\s\+$\  \+\ze\t/

instead of the :match line. The regular expression used in both cases matches trailing whitespaces and whitespaces in front of tabs. Of course there are several other options on how to do this or what you might want to highlight, but that would be beyond the scope of this little post.

Jaldhar Vyas: A Dance With Dragons (No Spoilers)

Somehow, even though I'd know about it for the longest time, I had never get around to reading George R.R. Martins A Song of Ice and Fire series until I heard about the Game of Thrones HBO series. Then I thought I had better hurry up and read the books as TV adaptations tend to be inferior. (I must say HBO did a pretty good job though.) I was instantly hooked and finished all four books in a week. Today the long-awaited fifth installment called A Dance with Dragons and I immediately got myself a copy. (Nowadays I mostly do my recreational reading with the Kindle app on my Android smartphone.) As before, I'm spellbound. I'm already about 25% through it and loving it. What I love about Martin is that he really gets how traditional, "pagan", "feudal" societies work. Take religion for instance. A lot of Sci-Fi/Fantasy authors if they deal with the subject at all usually give a cartoon version of polytheism that owes more to Christian canards and Dungeons & Dragons than any existing human religion. But in Westeros, one can be simultaneously devout, amoral, superstitious, and cynical in a way that makes a lot of sense to me as a Hindu. Or class. Being a peasant in Martins' world is horrible. Your life is completely at the mercy of Lords and Ladies and can end in an instant. But the upper class despite its wealth and power is trapped in its own way too. They must constantly protect their status from jealous competitors and a reversal of political or military fortune can destroy an ancient noble family just as suddenly as a bad harvest can destroy a family of farmers. Like the other books in the series, this one has a huge cast of characters whose stories weave in and out with each chapter told mainly from one characters viewpoint. This is a tactic which I for one found helpful to keep my attention from flagging but it means you can't really enjoy it unless you've read the previous volumes in order first. I definitely think it's worth the effort though.

12 July 2011

John Goerzen: First Look at Google Plus

Seems like everybody s writing Google+ reviews these days, but most of the ones I ve found seem to be fluff pieces. I haven t used it long, but have some initial impressions to share. First, an analogy. Facebook reminds me of the sleazy guy selling stuff from his car down the street. They do things like change privacy defaults when they think it s good for Facebook, rather than good for you. Google+ reminds me of an Apple product. It s beautiful, easy to learn, but locks everything down and is lacking some critical features. So here goes with the details. The good I think that this can be best summed up by: it s not Facebook. Facebook has, perhaps, set an incredibly low bar but still, this holds. Facebook is the only website I can ever remember using that changes things so much, so often, and so completely that I keep having this feeling of not knowing how to do things. Try maintaining a Facebook page or two and you ll especially feel my pain then. But even the basics: how many times have I accidentally posted a partial comment because I pressed Enter to start a new paragraph (that has only been the button used for that for, hmm, let s see now, decades), and instead it posted the comment. Principle of least surprise, anyone? Google+ has a simple and, on the surface anyway, intuitive interface. However, it does get muddy; more on that below. I m going to spend a lot more space on the bad below, but don t let that diminish my excitement about having a viable alternative to Facebook. I am keen to get rid of that monster. The Bad I ll start of this section with the fact that Google+ is a tightly-controlled walled garden. There is no way to take a copy of your status updates, comments, etc. and back them up with your own devices. If your Google account goes away, so do all your updates about your kids first words. Facebook does have this feature these days. It has broken half the time, but it exists, works, and I use it. Twitter doesn t have the feature built in, but its API makes it pretty easy; you could easily use my twidge program to do this, for instance. But whatever you put in G+ stays in G+. There is no autoposting it to twitter or Facebook, ~~no backups~~, nothing. I m disappointed in that, given Google s prior attitude about openness to individual data ownership. (Update 7/12/2011: There is a way to get a backup, which I hadn t noticed; see comments below.) Almost as bad, there s also no way to get data in. So I now have identi.ca, twitter, Facebook, and now also G+ accounts. When I post an item in identi.ca, it autoposts to twitter, and then it autoposts from twitter to Facebook. Handy one place to notify people of my public activities. My uploads to Flickr and blog posts also auto-post to Facebook, so people I m friends with there get a picture of what I m doing outside of Facebook without me manually having to link it in. Not so with G+. There is no way to even add an RSS feed for my blog to auto-post to G+ as there is with Facebook. If you use G+, the only way to get stuff into it is with a keyboard. Poor integration with other Google apps is also an issue. G+ is nowhere near Google s first social app. They also have Blogger, Google Reader, Buzz, Gmail, etc. So here s the rub. These aren t integrated well, and when they have tried to integrate them, they ve done an exceedingly poor job of it. As an example: Buzz is a twitter-like service for posting updates. Very similar to what G+ does, right? Well, the best you can do is link your Buzz account to a separate tab on your profile. You can t even have your Buzz updates flow straight into G+, from what I can see. You have a separate list of followers in Buzz from G+. Reader is even worse; it has a sharing feature, but it s not G+ aware, so it goes to a reader inbox. But what takes the cake is the integration with Gmail Contacts. Sounds easy? Not entirely. When you add someone to G+, apparently it sometimes links the record with their entry in Contacts. And the help gives you the handy warning that when you remove them from G+, you have the option of removing them from Contacts, which could impact what you see on a mobile device. It is unclear what happens when it doesn t link the record, or how it decides which record to link (some people have more than one person in a family sharing phone numbers and email addresses, for instance.) One very nice feature of G+ is you can add email addresses, even if they aren t G+ members. Then when you post updates to the circle you ve added them to, G+ offers to send them an email with an update. Very handy. Except the undocumented part is that if you select Your circles (meaning all your circles), rather than individually ticking the box by each circle, they don t get the email. And they also don t get it if you set it Public. You have to select their specific circle, which is a significant difference from how people with G+ accounts are treated. And that s just an example. There are a ton of things that work one way 95% of the time, but have non-obvious exceptions. Some of these exceptions are documented in the help, and some aren t. I m still confused about the integration with Picasa. G+ help says that you can upload unlimited numbers of photos for free (though they will be downscaled at a certain point). Picasa has definite storage limits. But G+ uploads are showing up in Picasa. Do I really get free storage by uploading to the same place via a different tool? Very odd. And finally, a gripe about web standards. I ve been using Firefox/Iceweasel 3.5, which came out in Debian squeeze and is still supported there. It is also pretty darn new by corporate IT standards. And Google Plus refuses to let me log in with it, saying it s incompatible. Perhaps it can t do some fancy animation, but then again I don t really care. Seems Google has forgotten the old RFC adage: be liberal in what you accept and conservative in what you generate. If you can detect that my browser won t animate something right, then you could give me a stripped-down version of the page rather than an error message.

Bernd Zeimetz: re-indenting files with vim

Sometimes projects with a long history of committers tend to collect various styles of indentation. Unfortunately not for all programming languages exist specialized tools like indent for C/C++, so we need to find a different way to mass-indent files properly. Using vim is one of them. First you need to create a file (let's call it /tmp/indent.vim) including all the vim commands you want to run on your code. The following piece is a good start:


gg=G
:x!

Now run vim on your source code files, using the created vim script file. The following example reindents all .php files in the current folder and subfolders


find . -name '*.php' -exec vim -s /tmp/indent.vim   \;

If you don't like the result it might be that the indentation settings in you .vimrc don't suit your needs. Of course you are able to add other fancy vim commands to modify your files - like adding or modifying copyright headers.

Jaldhar Vyas: Google^wBraincells Summer^wChaturmasa of Code

Barring a miracle, it looks like I won't be going to Debconf 11 this year which is a shame as that is a part of the world I have yet to visit. Anyway it got me thinking, I've neglected a lot of my Open Source activities this past year or so what with struggling to stay in good financial shape. As Chaturmasa started today in which we take up additional religious duties, I thought it might be a good time to recommit to getting all my projects up to speed again. So during the next four months I aim to (in no particular order)

Get a fully DFSG-complient Adobe Flex SDK package into Debian either by myself or preferebly by helping someone like Joey who owns the ITP. This will have the additional benefit of finally letting me fix the problems with the yui package and let me move on to yui3.
Fix up all problems in my CPAN modules and bring them up to the latest standards. Open Source any other bits of perl code I've written where possible.
Finally getting around to adding the RSS/Atom support to debbugs that I promised to do after Debconf 10. (Yes I've been sitting on this for almost a year. Sorry Don.)
The book Debian: TFM. Write it.
Get Debian GNU/Minix into enough shape that other people can hack on it because if it is left to my tender mercies it will never get done. Recent good news is that Minix upstream finally got around to replacing their anemic libc with NetBSD libc so I am holding out hope that things like dpkg will actually work now.
Make my roguelike game So You Think You Can Dance...ON MY GRAVE? 1. actually playable. 2. "Interesting" in some yet undefined way.

Hopefully by writing this down here in public, I will be able to shame myself into getting most if not all of this done.

11 July 2011

Michael Prokop: Creating 32bit Debian packages in 64bit environments

i386 systems are dying off and therefore building 32bit Debian packages in 64bit environments is important if you still need packages for i386. For some recent projects I had to set up 64bit-only environments with the need to provide 32bit packages for i386 as well as according i386 Linux kernel packages. 1) Common Debian packages Just prepend the linux32 command to the build commands and use the -a386 option of dpkg-buildpackage(1). So use linux32 dpkg-buildpackage -ai386 , linux32 git-buildpackage -ai386 , linux32 debuild -ai386 , or whatever build tool you prefer to work with. I personally like using git-buildpackage -S together with cowbuilder. When using cowbuilder it s easy to get i386 Debian packages:

# create initial cow base directory, needs to be executed just once:
cowbuilder --create --basepath /var/cache/pbuilder/wheezy32.cow \
   --architecture i386 --distribution wheezy --mirror http://ftp.de.debian.org/debian
# the "debbuildopts -b" says I want a binary-only build, see dpkg-buildpackage(1):
linux32 cowbuilder --build --basepath /var/cache/pbuilder/wheezy32.cow \
   ~/foobar_0.42.dsc --debbuildopts "-b"

2) Debian Kernel packages If you re building your own kernel images you might be aware of setting ARCH for the common make targets, like:

ARCH=i386 make oldconfig

To build a linux-image Debian package you can use upstream s deb-pkg target, like:

ARCH=i386 make deb-pkg

This should provide you according linux-headers, linux-firmware-image, linux-libc-dev and linux-image i386 Debian packages. But if you need the according source and doc packages as well you might prefer make-kpkg of kernel-package instead, using options like:

DEB_HOST_ARCH=i386 setarch i386 make-kpkg --revision "$KERNELVERSION" \
  --cross-compile - --arch=i386 --us --uc --initrd \
  --rootcmd fakeroot kernel-image kernel-headers kernel-doc kernel-source

3) Debian linux-2.6 kernel packages If you re interested in building Debian kernel images the same way as the Debian kernel team does (AKA linux-2.6) make sure to check out the kernel-handbook. After installing essential software packages I had to set up some symlinks for building:

apt-get install build-essential fakeroot devscripts fakeroot
apt-get build-dep linux-2.6
ln -s /usr/bin/gcc-4.4 /usr/bin/i486-linux-gnu-gcc-4.4
ln -s /usr/bin/ld /usr/bin/i486-linux-gnu-ld
ln -s /usr/bin/ar /usr/bin/i486-linux-gnu-ar
ln -s /usr/bin/objcopy /usr/bin/i486-linux-gnu-objcopy
ln -s /usr/bin/nm /usr/bin/i486-linux-gnu-nm
ln -s /usr/bin/objdump /usr/bin/i486-linux-gnu-objdump
ln -s /usr/bin/strip /usr/bin/i486-linux-gnu-strip

Then executing:

apt-get source linux-2.6
cd linux-2.6*
debuild -ai386 -us -uc

provided the according Debian packages (linux-doc, linux-headers, linux-image, linux-libc-dev, linux-manual, linux-patch-debian, linux-source, linux-support and linux-tools). 4) Out-of-tree kernel module packages If you want to build external modules which are available as $MODULENAME-source in Debian (e.g. tp-smapi-source) using module-assistant then use the DEB_HOST_ARCH environment variable, like:

DEB_HOST_ARCH=i386 m-a -v --text-mode -k /home/mika/linux-$KERNELVERSION -l $KERNELVERSION build tp-smapi

If the external module is not available for use with module-assistant then compile the module running:

make -C /lib/modules/$KERNELVERSION/build M=$(pwd)

whereas /lib/modules/$KERNELVERSION/build is pointing to the build directory of your 32bit kernel.

Thorsten Glaser: [Update] Hilfe gesucht: Mitarbeiter berwachung

Deutsche Version dieses Postings read the English Version instead Der Leiter der Abteilung Systemadministration einer Firma, welche in diesem Artikel ungenannt bleiben soll, wo der Zufall es will, da ich f r sie arbeite, m chte uns Mitarbeiter dazu zwingen, das Feature der persistenten Historie (also einen niedergeschriebenen Verlauf der abgesetzten Befehle) der Shell (Kommandozeile) auf allen Systemen zu benutzen. Nun hat die mksh dies vern nftigerweise, w hrend immer noch verf gbar, standardm ig aus Gr nden der Privatsph re deaktiviert, und ich finde, dies sollte sich nicht ndern. Es kann ja nicht sein, da man mir beim Arbeiten ber die Schulter guckt; was kommt als n chstes, Video berwachung der B ros? (Seine Argumentation l uft darauf hinaus, da er nachvollziehen/verstehen kann, wie ich (ha! ich! nicht die anderen, nein, ich!) ein Problem das letzte Mal gel st habe; es ist aber nichts anderes als rekonstru eren zu k nnen, wer wann was eingetippt/gemacht hat. Naja, Argumentationen sind eh relativ, andere jagen Flugzeuge in ihre eigenen Verteidigungsministerien, welche gerade zuf llig umgebaut werden ) Ich habe dies nat rlich in die F hrungsetage eskaliert, und unser Gesch ftsf hrer versteht meine Bedenken und m chte nun ein Gespr ch anraunen, um eine L sung zu finden. Die meisten meiner Kollegen im Bereich Systemadministration denken leider nichtmals dr ber nach, obschon ich in anderen Bereichen Gleichgesinnte gefunden habe. Einen Betriebsrat haben wir auch gro er Fehler, ich wei nicht (aber ich s e eh nicht drin, ich hasse Politik jeder Art). Dies l t mich in dringender Not, Argumente wider diese Total berwachung aller (insbesondere auf der Kommandozeile arbeitenden also besonders mich) Kollegen zu finden, idealerweise solche, die durch deutsches Recht gest tzt sind. Wenn ihr solche habt, bitte mailt die schnell an meine eMail-Adresse, welche da nicht junk@mirbsd.org lautet, sondern mit einem tg vor dem Klammeraffen (dies dient der Abwehr unerw nschter Werbemails). Vielen Dank bereits im Voraus! Update 12.07.2011: Wir haben geredet, und wie viele kommentierten keine L sung auf rechtlicher Ebene gefunden, sondern stattdessen, nachdem wir festgestellt hatten, da mir dieses Problem sehr am Herzen liegt, nach anderen L sungen f r das eigentliche Ziel des Chefadmins gesucht; dies z hlt als ein Entgegenkommen auf Seiten der Firma. Ich habe zugestimmt, meine L sungen in kleine Skripte zu verpacken und ins VCS zu committen f r das Herausfinden, wann was auf einem Server ge ndert wurde, im Fehlerfall, denken wir uns gerade ohnehin was aus. Danke an alle, die kommentiert haben!

Thorsten Glaser: [Update] Big Brother , or: Help wanted arguments against monitoring employees

English version of this posting lese stattdessen die deutsche Version The head system administrator of a henceforth unnamed company I happen to be employed at wants to force us to use the shell s persistent history feature disabled by default in mksh as is sensible, for privacy reasons on all systems, so he can retrace what we do (of course, his wording was more like, so he can reconstruct how I fixed a problem the last time it occurred yeah, sure). Now I ve escalated this to the boss, since this just cannot happen, what ll be next, video monitoring our offices or what and the boss said he sees my concerns and would like a meeting to get an agreement between all parties involved. Most sysadmin coworkers actually don t even think about this, they are sheeple, really; but my project manager (for when I m not a sysadmin but a programmer) and the leaderess of our QA department agree with me, luckily. Now I m in dire need of arguments, especially German-Legalese, to fight this total surveillance of employees, mostly targetted at these who use the command line almost exclusively, which I m a prime example of. Please mail me at my address, which is not junk@mirbsd.org but with tg instead of the waste part here to catch address grabbers (sending mail to that address yields a 24-hour total blacklist of your IPv4 address I ve yet to get enough spam via IPv6 to say filtering it is worth the cost). Thanks in advance!

Update 2011-07-12: We talked, and it was agreed to not force a shell history; instead I will now put problem solutions into smallish scripts and commit them into the sysadmin SCM. It was not solved using legal arguments, as many people commented would have been difficult; instead, they acknowledged that I was concerned with this, and we searched for a different solution to the head sysadmin s original concerns (apparently, to figure out how to fix things without reinventing the fix every time, and to find out what was changed on a server in case it breaks).

Thorsten Glaser: Yugoslawia, I ll be back

Agreement to pay from company
Going to drive with some apparently speed-loving brits
Registration accepted
Dienstreiseantrag prepared
Sent that beast to the office ticket queue

So yes, this means I m going to DebConf 11

to what used to be Yugoslawia when I was there the last time, although in the Pore region of Istria, Hrvatska. Thanks to my my boss who s sending me there.

Paul Wise: Looking at the logos of Debian derivatives

The logos of the Debian derivatives registered in the derivatives census are overwhelmingly stored in PNG format, with a handful of JPEG and GIF images. One derivative (LMDE) doesn't have a logo registered in the census. Half of the logo image files have some embedded indication of which program was used to create them or which program they passed through last. Just over half of these were created with some proprietary Adobe or Macromedia program. The one that surprised me was Emdebian's logo indicating it was created in Adobe Photoshop 3.0, but to be fair it looks like several of the Debian logo files were also created in Adobe Photoshop 3.0 so that might just be copied from the Debian logos. Two of the logos have an easter-egg reminding everyone who looks about the obsession some part of Adobe has with rubber ducks. Just under half of them were created using Free Software, with most of those being produced in the GIMP and a few in Inkscape. One of them looks like a derivative work of the KDE logo. Two of them incorporate the Debian swirl indicating their Debian heritage. Two of them in some way incorporate the Tux Linux mascot indicating that they use Linux. One of the logos contains the word Debian and one contains "sid". Three of the logos mention both GNU and Linux and another mentions only GNU. One of them mentions the government organisation sponsoring the distro (LinEx). A few logos consist solely of text and a few have no text, but most combine both elements. Three have some indication of a URL in them. Several of them have some sort of indication of what the distribution's focus is. One has Adobe's XMP XML cruft embedded in it indicating document identifiers and two logos have an embedded ICC profile. One logo has the author's name in it.

Raphaël Hertzog: 7 tips to file useful Debian bug reports and get your problem solved

Filing bug reports is the most common way for users to contribute. Even if it s not too difficult, I ll give you some advice to improve the quality of your reports. After all, when you go out of your way to report a bug, it is in the hope to see it fixed so let s see how we can make this more likely. 1. Try to reproduce the bug If you can t reproduce the bug, it s next to impossible to find the root cause and thus to fix it. In that case, I would suggest you to wait until you experienced the bug multiple times. Maybe you ll be able to find something that triggers it (or that makes it more likely to encounter it). If the application has a debug/verbose mode, it might be a good idea to enable it until you experience the bug a second time. The generated log might be helpful for the developer to understand what happens exactly. So don t file bug reports straight away unless you can reproduce it. The exception to the rule is when the application gives some useful information like a core-dump, a back-trace or an error message. Obviously if the bug happens during an upgrade, it s difficult to reproduce it (unless you have multiple computers) but you should still report it. Be sure to include all the relevant information (versions of packages before and after the upgrade, logs of the upgrade, etc.). 2. Do your best to identify the faulty package When you report a bug to Debian, you must assign it to a package. While there are pseudo-packages useful for problems which are not directly attributable to a real package, in most of the cases you should report a bug against the specific package that seems to be the cause of the problem you encountered. In turn this often requires you to attribute the problem to a file (for example the executable of the application that triggers the bug). Once you have a filename you can use dpkg -S to identify the corresponding package.

$ dpkg -S /usr/bin/hamster-time-tracker
hamster-applet: /usr/bin/hamster-time-tracker

Note that reportbug accepts a filename as parameter and will do the above conversion for you. If you only know the name of the application (but not the filename of the associated executable), you can use dpkg -S with a pattern to let it return all possible matches:

$ dpkg -S hamster
hamster-applet: /usr/share/applications/hamster-applet.desktop
hamster-applet: /usr/share/gnome/help/hamster-applet/es/statistics.page
[ ]
hamster-applet: /usr/bin/hamster-time-tracker
[ ]

Or you can also verify in the list of installed packages:

$ dpkg -l "*hamster*"
Desired=Unknown/Install/Remove/Purge/Hold
  Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
 / Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
 / Name            Version         Description
+++-===============-===============-==============================================
ii  hamster-applet  2.32.1-1        time tracking applet for GNOME

3. Verify that the bug is not already reported and/or fixed If there s a newer version of the software available, it s a good idea to try to reproduce the problem with this version too. Because the developers tend to care only about the latest version, they will want to reproduce it with this version, and they will be annoyed if the problem that you reported is already fixed. That s why bug reports of users of testing/unstable tend to be more useful than bug reports of stable users. In any case, you want to verify that the bug has not yet been reported: filing a duplicate bug is useless and only generates more work for the developers to merge both bugs together. On the opposite, it s highly appreciated to add supplementary information to an existing bug report, even a simple confirmation that the bug still exists on a newer version is useful. Note that reportbug will automatically show you the list of open bugs before allowing you to submit a new one. 4. Use reportbug While the Debian bug tracking system allows anyone to submit a new bug with a simple mail, you should really use a dedicated program like reportbug (or reportbug-ng) because it will automatically include lots of useful information in the generated report (version of dependencies, current architecture, etc.) and will assist you in all the steps.

5. Describe the problem so that the developer can reproduce it Ideally your report should include everything required so that the developer can reproduce the problem on his system. If a given document triggers the bug, attach it. Describe the steps required to reproduce the bug in great details just like you would explain it to your grand-ma. Explain how you expected the program to react and what happened instead. You can learn much more on how to draft a good bug report in this article: How to report bugs effectively. It s a bit long but well worth it if you intend to report bugs and thus interact with developers. 6. Be kind and willing to help When you draft a bug report, keep in mind that you re writing to a volunteer free software developer and not to a customer service. You should be respectful and follow the usual rules of courtesy. Developers attention is scarce and should not be wasted. Be willing to help, if the developer starts investigating your problem, he might need your help to get supplementary information (in particular if he can t reproduce it) and you should be ready to provide it. Thus it s important to keep whatever you need to reproduce the problem. In some cases, the Debian maintainer might be overworked and you can offer your help to forward the bug to the upstream bug tracker, it s always appreciated. If you re reasonably confident that the problem is not Debian-specific, you can do it straight away and set the forwarded field to the URL of the upstream bug report (for example with bts forwarded <bug> <url>). 7. Use the correct severity The Debian bug tracking system lets you set the initial severity of the bug report (in decreasing severity: critical, grave, serious, important, normal, minor, wishlist). Pick the correct severity according to the official definitions but don t misread them. In particular, don t over-inflate the severity: for instance if you lost some data due to a misuse of the software, it s not critical (i.e. rm -rf * doesn t warrant a critical bug against rm). If you use only a tiny part of a software, and that part doesn t work, the package might be unusable for you but it s not unusable for everybody, so it doesn t warrant the grave severity. The important severity is often a good choice in those cases. Do not under-estimate the severity either, if a problem is important enough that it must be fixed before the next stable release (for example a regression compared to the previous release), pick a release-critical severity (i.e. at least serious ). The maintainer and the release manager can always lower the severity if they do not agree with your initial judgment. And now, happy bug-reporting!

Follow me on Identi.ca, Twitter and Facebook. Or subscribe to this blog by RSS or by email.

6 comments Liked this article? Click here. My blog is Flattr-enabled.

Vincent Bernat: Rewriting my .zshrc

Ten years ago, I started to use ZSH, a shell designed for interactive use but which is also powerful for scripting usage. I had a fairly comprehensive .zshrc file splitted in several parts. I have decided to rewrite it for several reasons:

I did not take advantage of several features of ZSH, like some advanced parameter expansion, arrays, arithmetic expressions and other built-in features. There were a lot of head, awk, sed that could be replaced by some ZSH machinery (something easier to read like $ $ (f)~~"$(</etc/hosts)" %%\#* ).
It contained a lot of hacks to make things work on some odd/old setups. I was not really sure that those hacks are useful anymore. It also contained a lot of conditionals where some parts of the code were executed depending on the hostname.

I have discovered oh-my-zsh, a nice project trying to provide a generic and flexible ZSH configuration:

A community-driven framework for managing your zsh configuration. Includes 40+ optional plugins (rails, git, OSX, hub, capistrano, brew, ant, macports, etc), over 80 terminal themes to spice up your morning, and an auto-update tool so that makes it easy to keep up with the latest updates from the community.

The idea of such a project is to fork it and make the changes that you need. I was previously hacking around Phil! s ZSH Prompt for my prompt. oh-my-zsh contains a close theme (jonathan). Neat. However, I decided to write my .zshrc from scratch (but with some snippets stolen from oh-my-zsh). Why? Mostly because I want to precisely configure ZSH. Even with its plugin architecture and its override mechanism, oh-my-zsh provides some features (options, aliases, functions) that I do not want. Of course, thanks to git, you can fork and make any local changes you want but since I would have modified most of the files, it seemed easier to just start from scratch. I have published the result on GitHub. You can use it as is, fork it or (better) steal and adapt some snippets for your own usage. Here is the mandatory screenshot for the prompt (no much space left for the commands): My ZSH prompt

Here is a short snippet used to select a sensible EDITOR depending on what is available. It uses anonymous functions (to restrict the scope of local variables), arrays and flags in parameter expansion. For another example, take a look on how I select a valid locale.

()  
    local -a editors
    local editor
    editors=(
        "emacs23 -Q -D -nw" # Fast emacs
        "jove" "mg" "jed"   # Emacs clone
        "vim" "vi"          # vi
        "editor")           # fallback
    for editor in $editors; do
        (( $+commands[$editor[(w)1]] )) &&  
            export EDITOR=$editor
            break
         
    done

Enjoy! UPDATED: Anonymous functions were introduced in ZSH 4.3.7. Older versions do not support them. A workaround is to use a classic function instead:

__()  
    local -a editors
    local editor
    ...
  && __

10 July 2011

NeuroDebian: NeuroDebian@HBM2011.ca

NeuroDebian@HBM2011.ca On June 26-30 the annual meeting of the Organization for Human Brain Mapping (HBM2011) took place in Quebec City, Canada. Encouraged by our positive experience at last year s SfN in San Diego and enthusiasm of our scientific adviser, James V. Haxby, we hosted another NeuroDebian booth. The setup was pretty much the same as last year: Some chairs and tables, lots of people, our tri-fold flyers, a Debian mirror and some virtual machine images to show Debian in action. This time we also had an LCD display attracting visitors with the package swarm, some demos, and our recent paper. We had many curious people have their first exposure to Debian, long-time users expressing their gratitude to Debian, and our upstream developers getting together to discuss various topics. Having registered the booth as NeuroDebian , we had the additional pleasure of explaining visitors the concept of a project inside Debian, in contrast to a derived distribution. But that is nothing new really, so let s talk about the differences from last year s booth. First of all, we had more people at the booth. Dominique Belhachemi volunteered to help us out and that was very much appreciated. Although HBM has only about a tenth of the attendees that SfN has, we had significantly more traffic. While last year people were primarily interested in knowing about the project, this time many of them wanted to give it a try immediately. People came with their laptops, got the VM images and started playing with Debian. After a day or so, some came back and asked for recommendations on particular software after having been exposed to the wealth of the Debian archive. What also had increased was the number of developers, or rather research labs developing neuroimaging software that came to the booth to discuss how to get their software into Debian and how to arrange ongoing maintenance of these future Debian packages. As we have our plates already quite full, we have been spending some time on mentoring interested developers to learn the art of Debian packaging and making them familiar with Debian s procedures and standards (e.g. working on #609820 with Yannick Schwartz, upstream, at the booth). ../../_images/BusyBooth216.jpg

Two promising new developments need to be mentioned. First, we were approached by companies that develop hardware for brain-imaging and psychophysics research. They were curious to learn about Debian as an integrated platform that offers free software solutions that an increasing amount of their customers demands (e.g. PsychoPy). Apparently, the movement towards open research software has finally made it into the business plans of companies, as they seem to start perceiving compatibility with free software systems as a competitive advantage. We explained how software gets into Debian, and how its release cycle is managed. To foster their motivation we also pointed them to the existing open-source software that is already available or even present in Debian. Let s see whether we see more Debian-certified research products in the future. Lastly, we started talking with folks from the INCF to explore possibilities of collaborating on INCF projects using Debian as the integration and development platform. The INCF is an OECD-funded organization that develops collaborative neuroinformatics infrastructure and promotes the sharing of data and computing resources to the international research community. At least one INCF project is already relying on the efforts of the NeuroDebian project. We are going to continue this discussion during a workshop in September. A report will follow...

Debian people at the booth (f.l.t.r): Michael Hanke, Yaroslav Halchenko, Stephan Gerhard, Dominique Belhachemi. Not shown: Swaroop Guntupalli.

Acknowledgments This booth has been made possible by the generous support of Prof. James V. Haxby (Dartmouth College, New Hampshire, USA).

Christian Perrier: Cheese and Wine party for DebConf 11, aka C&W7

Do I need to explain what is the Cheese and Wine (C&W) party? Still, if some of you need more information, please feel free to ask. The C&W7 wiki page now exists on DebConf wiki. Information will come there until the day of the C&W, which is scheduled for Tuesday July 26th, so the day before the planned daytrip, if I'm correct. C&W orga details are currently very vague, but the most important point is: start planning what YOU will be bringing for the event. Remember that the event is only successful when many of us manage to bring good stuff to share (preferrably cheese, wine...or other ethanol-improved beverages). If you think about something *else* than cheese, please feel free to bring it: just try to have it representative of your part of the world...or a part of the world you love. Any further questions can be asked in the debconf-discuss mailing list or in #debconf channel on irc.debian.org

James Morrison: Code reviews

I'm reading through http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/. So, I'll make my comments here since I expect they will be long. As a caveat, I still work at Google and have done a lot of code reviews. I've made a lot of mistakes while code reviewing, I've had difficult code reviews, but my biggest problems were non-code reviews. The caveat is for most of the code reviews, I know the code being changed better than the person changing the code.

I'll reply to sections as I come across them: "Given a problem, there are usually a dozen different ways to solve it. Andgiven a solution, there's a million ways to render it as code. As a reviewer, your job isn't to make sure that the code is what you would have written - because it won't be.". I disagree with this. There are many times where code is first written in a (1) Ignorant way (2) Sloppy way (to try to save trivial amounts of work). I agree that the code probably won't be the way the reviewer wrote it, but it is good to comment on how it could have been written. Many times the reviewee isn't familiar (or ignores) with the idiomatic style of a larger bit of code.

"The second major pitfall of review is that people feel obligated to say something.". It's fine to say something, but if that's what you say most of the time then you are wasting the reviewee's time. If you do a first pass and don't find anything, you should go back and read the code and be sure that you understand it. Most times I've seen people say nothing is that they don't want to know what the new (or changed) code does.

The last section is about speed. For speed there are two types of code reviews, one which is quick, small and fixes something important. Those should only take one round and typically only need the reviewer to ask for tests. Then there is everything else, which includes small and unimportant. For those, it's ok to take more time to start the review, but each iteration should get smaller and faster.

For anyone that's gotten this far, I guess I can say my comments about Mark's blog post are purely bike shedding, but that's something with code reviews, it's ok to say you think the bike shed should be neon pink as long as you don't force the reviewee to paint the bike shed neon pink.

9 July 2011

Wouter Verhelst: Freedom, continued

Okay, so the story continues: Joe Brockmeier has posted a rebuttal to Nina Paley's post that I commented on earlier today. Basically, Joe says that Culture is not the same things as Software, and gives a lot of arguments as to why this would be true. But I can't agree with him. Let's see why. His first argument is "One of these things is not like the other". As in,

But it's far more reasonable and sensible to discuss Perl scripts and software written in assembler embedded on a chip together, and the rights that they come with, than to try to talk about rights to modify sculpture and essays.

I don't see how one could combine a perl script with an embedded assembler program, except perhaps over a network, or by using exec() two cases in which the FSF would consider that they are not even derivatives anymore, they are "at arm's length", and it would be legal to do something like this if one bit was released under the GPL while the other was not. At the same time, it's possible to engrave (part of) an essay into a statue, for example. Or make a technical apparatus which looks like a statue but which will play music if you come near it. Both would be valid cases of some artist combining two separate and (at first sight) distinct things into one work.

Sure, you could crowdsource sculpture, but I doubt it will have much practical application. (And certainly difficult over the Internet, but I digress...)

It's called RepRap, and it's very much possible over the Internet. Joe moves on, with 'Unintended consequences of forkable prose'.

Take the GNU Manifesto, for example. If you could "fork" the manifesto, I could easily see variant versions modified to justify open source instead of free software.

This argument had been brought forward during the discussions which Debian had on the GFDL vote, and has been seriously debunked there. In short: the ability and right to fork someone's prose does not, in any way, give you the right to misrepresent them. While I believe it should be okay for someone to base a theoretical Open Source Manifesto on the GNU Manifesto, I do not believe it should be okay for them to still keep calling it the GNU Manifesto. It's not the same thing anymore, so that should be clear. This is true within Free Software as well: if you fork, you give it a new name, so it becomes clear that you're not the original anymore. Moreover, I doubt the kind of prose found in the GNU Manifesto is the same kind of prose that Nina would like to see in a free culture movement. Not because the GNU Manifesto is a bad piece of writing it isn't but because Free Culture likely focuses on other things than manifestos. Next, we get "Solving a problem that doesn't exist"

The spark that fired off the GNU revolution was a legitimate problem because of non-free code, a user was unable to make use of hardware they (or their university) legitimately owned.

(...)

While Paley and others may want the same freedoms to go with cultural works, it is not a real problem in the same sense.

Pardon ye me? I am a musician. Not a very brilliant one, mind you, but I play the flute with much enthusiasm, and have done so in a number of places. If you've been to any debconf since 2007, surely you must've heard me play. Also, I've been singing in choirs since I was sixteen which, I just realized, means I've now been singing for more than half my lifetime. Time flies, it must be said. One of the orchestra that I've been playing in was an extended flute choir with a rather unusual instrumentarium: apart from 30-something flautists, the orchestra also had a piano and drummer, a number of guitar players, and a bass guitar. Such an unusual set of music means you have three options: you play original music, written specifically for your group; you play something written for a different set of instruments, without changing anything, and hope nobody notices that it doesn't actually sound very well; or you make modifications. You make a derivative work of the music, so you can actually play it. There, I've said the word. This isn't just true for music; I've yet to see the first theatre performance that is true, word-for-word, to the original script. Also, movies use music all the time. When they do, there are usually two options: either they have original pieces of music written specifically for their movie (as is the case for most Hollywood blockbusters), or they take a piece of existing music, and adapt it so it fits the events in the movie better. By, say, shortening it, so it doesn't run into the next scene. Or by repeating the refrain an extra time, so the words line up nicely with the action. Or by having a group of musicians record a version of that piece specifically for your movie, which is the same thing in everything except the speed so that the feet of the actor walking on the big screen hit the ground in sync with the music. Or... well. You get the idea. By claiming that artists have no need to modify and derive from others, the only thing Joe accomplishes is to show that he really, really, really doesn't know what the fuck he's talking about. Artists have a need to modify other artists' works all the time. The only difference with free software is that they either need to invoke the fair use clause, or need to pay big bucks to the original rightsholder. Sound familiar? Joe finishes up with stating that despite all of that, Free Culture is still possible. And:

That doesn't mean that free culture is impossible. It simply means that different standards apply.

Exactly: different standards apply. And why? There is no good reason for that. Because people make money from cultural works? Well, money is made from software, too, that has never been a good enough reason. Because Culture is not functional? How many in the Free Software movement would even be willing to only be doing software all the time, and not ever do anything remotely related to Culture? None, I would say. Culture is just as functional as Software, it just serves different functions. In the comments, Joe clarifies that he isn't against people preferring not to use the ND clause in the CC licenses they select, he's just against demanding that others do the same. That argument would make sense if not for the fact that the FSF demands, mostly, that Software Should Be Free!!1!. By not complaining about the GNU Manifesto, but complaining about Paley's "Rantifesto", which basically complains about the lack of such an environment in the free culture movement, Joe just makes a fool of himself. Anyway, 'nuff said.

Wouter Verhelst: On Software (and Cultural) Freedom

Nina Paley, author/actor/director/animatrist of the excellent sita sings the blues, blogs about the FSF's double standards when it comes to freedom. To the FSF, Software Should Be Free!!1!, and it is willing to go to great lengths to accomplish that. For example, the FSF will create dracionian requirements on their Hardware endorsement criteria, that will most likely render it unusable, just for the remote possibility that they might convert a single soul to their religion. They will add propaganda to their documentation, and slap on a license that makes it illegal for anyone to modify or remove that propaganda. They will claim to make an update to that license, just to make their friends happy, but then do not make any effort to finish the job. Most of all, the FSF is led by a person who deserves our respect for jumpstarting a movement that has made all this free software even possible, but whose atypical behaviour might be interfering with his message these days. I have stated before that I'm not a member of the FSF, and that 'I have my reasons'. In case you were wondering: the above are my reasons. I can't be a member of, or be supporting of, any organization that uses such double standards in anything. In the case of Debian, it took us a long time to come to the conclusion that the GNU FDL is a non-free license. And though we came to that conclusion through other arguments than "Culture should be free, too" (specifically, the arguments boiled down to "if it's digital, it's software, and software should be free"), I have since come to the conclusion that there is nothing special about 'digital stuff' that should mean it should be more free than 'non-digital stuff'. If I hand you a piece of music on a sheet of paper, why should you not have the right to redistribute and/or modify that, while you should have the exact same right if I were to hand you the exact same paper on a digital medium? That makes no sense. So, in short, I agree with you, Nina: there is no Free Culture movement, and that's a shame; and while it would be nice if the FSF were to take a lead role in guiding such a movement, I find it highly unlikely that they will. The FSF may claim they care about Freedom, that doesn't mean they do; they care about Software Freedom. And while that certainly was an issue thirty years ago, when the FSF was formed, it isn't so much anymore today. There can only be one conclusion: the FSF is obsolete.

Wouter Verhelst: CUPS: ghaaah!

So I have a postscript color printer. This is nice, because I can just throw postscript at it, and it will provide me with a hardcopy of whatever that postscript describes. Since postscript is what Unix-like systems like most, that's great. Today, I needed to print something. It had been a while, and apparently some things in sid that are related to printing had changed, because it did not work anymore. I don't print every day (I absolutely don't print every day), so it had been, well, "a fair while" since I last used it. Of course it didn't work. Of course, it is not the first time this happens. Every so often, my printer loses track with the cups installation on my server, and then I have to prod it a bit usually by restarting the printer or the CUPS server, or both and then it works again. The usual CUPS failure mode is that the printer was not available when I tried to print something, which causes CUPS to mark the printer as 'offline' or something, resulting in it being 'disabled'. The 'cupsenable' command is supposed to fix this, except that once in a blue moon it doesn't. I've learned to live with it. But today was different. Rather than the printer being disabled, something in the printer stack would just discard print jobs. That is, they would show up in the cups queue for a moment, and then disappear. I wouldn't get a piece of paper with something useful on it. I would just get nothing at all. This featureful printer supports syslog, and so I told it to send syslog messages to a useful system somewhere on the network. But that didn't produce anything interesting. It would tell me when the system had been powercycled, sure, but not why something would fail. After trying many things for about an hour, sick of it all, I purged CUPS off my system and reinstalled it, then had it search for a printer again. It did find the printer through zeroconf messages, and I allowed the autoconfiguration stuff do things as it saw fit. When I asked it to print the exact same postscript file again, something came out of the printer. Finally, I thought, "success"! Except it wasn't. Instead, the printer just produced gibberish. It turned out that cups had decided that my HP 2550n network-enabled postscript laserprinter was instead a HP 9xx-something USB-only PCL printer. Going back to the configuration interface and telling it to use the 2550n ppd file instead got me back to square one: the print job would appear in the print queue for a few seconds, then magically disappear. At this point I was using 'tail -F' to monitor any logfile that might remotely be related. /var/log/cups/*, /var/log/syslog, /var/log/daemon.log, you name it. But nothing gave me any remote clue what was happening with the postscript that I'd been throwing at cups. So I used netcat. This printer supports LPR, but will also accept postscript on port 9100 (I forgot what HP calls it), so a simple 'nc printer 9100 < foo.ps' should in theory just produce a printed page. And since someone told me that a "modern" (yeah, right) Linux printing system uses pdf throughout rather than postscript (for what, I don't know), I thought it might've been possible that something somewhere was just mangling the postscript in a way that things would not work anymore. I was right, ut I never expected to e right in this manner.

Did you think this would be listed in the cups logs somewhere? Of course not! That would be too easy! But then of course fixing this was fairly easy: just throw the original file from which this postscript was generated through a different postscript-generating program, and try again. Magic: suddenly the printer prints what I want! And it only took me 90 minutes. Sometimes I wonder what the "userfriendly" police is smoking. Oh well.

Next.

Previous.