make-theme-image: a script to make yourself an idea of a icon theme

I created some time ago a utils repository on github to publish miscellaneous scripts, but it's only recently that I have started to really populate it. One of my recent work is make-theme-image script, that downloads an icon them package, grabs relevant, user-specifiable, icons, and arrange them in a neat montage. The images displayed are the results of running

~ make-theme-image gnome-icon-theme moblin-icon-theme

This is quite useful to get a good idea of the icons available in a package. You can select the icons you want to display using the -w option. The following command should provide you with a decent overview of the icon themes present in Debian:

apt search -- -icon-theme | grep / | cut -d/ -f1 | xargs make-theme-image

I hope you find it useful ! In any case, it's on github, so feel free to patch and share.

Making oprofile work again with recent kernels

I've been using oprofile for profiling programs for a while now (and especially QSoas, because it doesn't require specific compilation options, and doesn't make your program run much more slowly (like valgrind does, which can also be used to some extent for profiling). It's a pity the Debian package was dropped long ago, but the ubuntu packages work out of the box on Debian. But, today, while trying to see what takes so long in some fits I'm running, here's what I get:

~ operf QSoas
Unexpected error running operf: Permission denied

Looking further using strace, I could see that what was not working was the first call to perf_event_open.
It took me quite a long time to understand why it stopped working and how to get it working again, so here's for those of you who googled the error and couldn't find any answer (including me, who will probably have forgotten the anwser in a couple of months). The reason behing the change is that, for security reason, non-privileged users do not have the necessary privileges since Debian kernel 4.1.3-1; here's the relevant bit from the changelog:

  * security: Apply and enable GRKERNSEC_PERF_HARDEN feature from Grsecurity,
    disabling use of perf_event_open() by unprivileged users by default
    (sysctl: kernel.perf_event_paranoid)

The solution is simple, just run as root:

~ sysctl kernel.perf_event_paranoid=1

(the default value seems to be 3, for now). Hope it helps !

Linux kernels for a macbook pro retina

I was unhappy about the recent Linux (3.14-3.16, and I think 3.17 too) kernels on my Macbook Pro Retina (15'), for a few reasons:

• the nouveau graphics driver was not handling the graphics card very well (hangs when using the DRM after putting the computer to sleep once, garbage screen on various apps, slow 3D rendering), and I could never get the proprietary nvidia drivers to work (would give blank screen at boot time)
• very unstable wireless (at least with my box home, but not with all the ones I've tried)
• and the most painful was the need to recompile the kernel by hand, with the following modifications from stock debian kernel:
  

  -CONFIG_X86_SYSFB=y
  +# CONFIG_X86_SYSFB is not set
  -CONFIG_FB_SIMPLE=y
  +# CONFIG_FB_SIMPLE is not set
  

  Without these modifications, the screen would be garbled some 5-6 seconds after boot (but SSH would still work, as far as I remember).
  

The latest 3.18-trunk kernel fixes essentially all the above problems, which is just great. Kudos to everyone involved ! Hope it helps...

8 months with a macbook pro retina 15''

Back in February, I wanted a new laptop for my work, so I bought a fancy Dell Latitude E6540 laptop. Bad luck, it was giving my sore eyes and horrible headaches, to the point I couldn't work more than a dozen minutes with it. As in my work, we were not allowed to buy PC laptops with any other vendor, my boss convinced me to get a 15'' macbook pro retina (yes that's about as expensive a laptop as you can get). Although quite reluctant at first, I did need a new laptop, so I gave in. Of course, I had to install debian on it. I booted once or twice on macos to leave enough space for Debian and install rEFIt so that I could boot into it. I had to use version 3.9 of linux else it wouldn't boot.

After about 8 month, I must say I'm quite pleased with the beast. The retina display is very neat (a 2880x1800 resolution!), and it is pretty fast. There are two annoyances though:

• I never managed to get either the non-free NVIDIA drivers or the integrated intel graphics to work. The NVIDIA driver give blank screen on X startup, while it doesn't even start with the intel drivers (and I've tried all the tricks I could find around). The fine point is that I don't have any hardware 3D acceleration !
• The wireless network is pretty unstable.

Another point is the update of GRUB: Debian's post-install scripts don't play nice with the EFI setup, so here is what I have to do to update to a newer version of grub, (and it's also what I had to do initially to install GRUB):

# mount /dev/sda1 /mnt
# grub-install --efi-directory=/mnt

The /dev/sda1 partition is the so-called EFI partition. I think it is created by rEFIt and it is essentially empty.

Simply impressive...

... that's what I think of the work of the FTP Team. Three uploads to NEW in one day, all of which processed in less than half a day. Truly impressive !

Many thanks to them !

Newer xorg, missing mouse features and xinput

Recent versions of xorg have seen changes in defaults for the behaviour of mice/touchpads, such as third button emulation or edge scrolling suddenly not working anymore. What is worse now is that the corresponding entries in the xorg.conf are now ignored... Wait, wait, don't go flaming the Xorg maintainers, but keep on looking rather. This is where I found out about xinput, the new way to customize/parametrize input devices for the X server. And, lets face it, it beats any customization that could have been done in xorg.conf ! Here's how to use it.

First, you'll have to install it from its own package (xinput), as it doesn't come bundled with standard X clients. Second, you can find out about the devices connected to your X server using:

~ xinput --list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ SynPS/2 Synaptics TouchPad                id=12   [slave  pointer  (2)]

It is easy to find the device you're interested in (here, say the touchpad entry). Then, you list the properties you can set/get using:

~ xinput --list-props "SynPS/2 Synaptics TouchPad"
[...]
        Synaptics Edge Scrolling (269): 0, 0, 0
 

The list is quite impressive, so I have only shown the one I'm interested in. You see here everything is 0, which probably explains why edge scrolling is disable (I don't have a clue what the actual numbers mean). You can finally change the properties this way:

xinput --set-prop "SynPS/2 Synaptics TouchPad" "Synaptics Edge Scrolling"  6 6 6

This gave me back edge scrolling. I used a similar approach to enable again the third button emulation... What is neat here is that the property names are readable enough, and there's a lot of them to play with. Great !

Call for testers: pmount finally supports mounting image files

I've finally come up with a decent way for pmount to support mounting image files using loop devices. This has required a little more work than I thought, since I had to add support for configuration files for pmount, as loopback mounting is by essence insecure, so the support for it had to be user-configurable. I have tried hard to make the loopback mounting as secure as possible, for instance by ensuring that a user cannot bypass file permissions with it, but of course lookback mount still means that a user has read-write access to a mounted FS which can be used to exploit potential weaknesses in the kernel...

I have uploaded a new version of pmount to experimental. Comments, bug reports, exploits are welcome !

Installing a Canon Pixma MP250

I recently acquired a Pixma MP 250 printer, and as I had some difficulties with setting it up, I wanted to share this here. The printer isn't supported as such by CUPS, so I had to dig a little bit. After quite some time, I found debian packages on the Canon website there. Don't fear the mention of i386, amd64 packages are included too. This link is likely to break when the software is upgraded, you should try your luck in the drivers search page should that happen (or for other models). After installing that, CUPS find the connected printer and proposes the PPD for it. The scanner works out of the box with xsane

As a side note, Canon also provides source for the debian packages (the packaged was ITPed ages ago). However, there are some binary-only blobs and I didn't manage to get it to compile from source.

The java packaging nightmare...

... or why I mutilated your java package in Debian

This post is especially addressed to what we Debian Developers refer to as upstream maintainers, that is the people who write/maintain the software that we package for Debian. It is meant to explain why, in some cases, Debian Developers prefer to mutilate your work rather than upload it to Debian Archives in a state that gives it proper credit. And to apologize.

These opinions are my own, but I have a faint feeling that I'm not the only Debian Developer working like that, and that this few words could help soothe the relation betwenn Debian Developers and Upstream Maintainers, which can be quite tense some times...

It happens unfortunately quite often (too often!) that I disable (or don't enable) features in programs I package. Exact reasons vary, but they essentially fall into two categories:

• A feature requires code that does not comply to Debian Free Software Guidelines, which Debian cannot distribute. This is a no-go.
• A relatively minor feature depends on other software that are not packaged yet, and in which I don't have specific interest, which means I would not be able to maintain them properly (or it would require too much packaging work and so on...).

When a program has features which falls in one of these categories, I have two choices: either I give up packaging the software or I give up some of the features... For packages for which I care, obviously the second option looks better from my point of view as a Debian Developer.

Java packages are especially affected by this problem, for a very simple reason. Java is one of the few (I don't say only because I'll probably be flamed to death) programming languages which allows very easy distribution of binary platform-independent libraries, in the form of JAR files. Many projects simply reuse and embed JAR files published for other projects in their own JAR files, often without precise references to where the source code can be found. Packaging a moderately-sized Java application often rely on dozens of embedded JARs, which we need to remove from the packages we build (as Debian does not distribute binaries without sources for many reasons), and for which we need to hunt down the original source code and often packaging the original project, which might pull in yet other dependencies and so on... A true nightmare ! That's why it is so tempting some times to simply drop some of the code, possibly write patches to disable references to removed libraries, and be done with it.

Therefore, I would wish to publicly apologize to any upstream developer I've offended by stripping down apparently carelessly their beautiful software before uploading to the Debian Archives; I hope they now understand why I've done that.

Note to users: it is not because one of the features of your favorite software has been disabled by its (Debian) maintainer that you need to turn away from Debian ! Rather, file a bug report against the package. You'll get the reasons why the feature was disabled, and you have a chance to convince the maintainer to switch it back on.

Emacs mode for machine-readable copyright files !

Quite a fair amount of time has flown since my decision to implement an emacs mode for the proposed machine-readable format for debian/copyright files. A have to admit that I had left that sleeping for quite a long while. But I took my courage, and rewrote nearly everything I had done so far. I'm quite happy with the results, to be truthful. The debian-mr-copyright-mode features:

• syntax highlighting
• a coverage mode show all files in the package, including the ones not covered by the copyright file
• the coverage mode shows which glob matches a given file
• it provides links to visit files and go to the declaration leading to a given label

The aim of this mode is to provide a quick check for uncovered files in a package, and also means to verify if the license of a file is not misrepresented.

The code can be downloaded from the git repository, accessible using

git clone git://git.debian.org/git/users/fourmond/debian-mr-copyright-mode.git

No debian package is available for the time being, although that could definitely change after lenny is out. I hope this emacs mode will help the new format to be widely adopted.

Another bzr2git example

Today, I tried to switch one of my personal repositories for debian-related scripts from bzr to git, just like I've done for pmount. The trick was that this time, I wanted to only move a part of the repository, not the full repository. I had only been working before with CVS and SVN who have the idea of modules, which is not the case for bzr or git. So I made the mistake of using a single bzr for several projects, which I realize now is not a very good idea...

In any case, I managed to drop some parts and here is how I did it; the trick was precisely to use SVN as an intermediate storage medium, using the following configurations files. First, bzr2svn.conf

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = bzr:source
target = svn:target
start-revision = INITIAL
state-file = tailor.state

[bzr:source]
repository = /home/vincent/debian-devel/bzr/scripts

[svn:target]
repository = file:///tmp/testtai
module = biniou

and svn2git.conf:

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = svn:source
target = git:target
start-revision = INITIAL
root-directory = /home/vincent/tmp/debian-mr-copyright-mode
state-file = tailor.state

[svn:source]
repository = file:///tmp/testtai
module = biniou/debian-mr-copyright-mode

[git:target]
git-command=/usr/bin/git

Then, all that is left to do is to run tailor on the resulting configuration files:

~ tailor -D -c bzr2svn.conf
~ tailor -D -c svn2git.conf

pmount switching to git

I've been neglecting pmount for such a long time I feel ashamed about it. Thanks to tailor and a neat post, I've just switched it to a git repository at git://git.debian.org/git/pmount/pmount.git to get more work done (I don't like bzr too much in the end, don't flame me, it's just a matter of personal taste...). I hope that I'll be able to reduce the amazing number of bugs that have accumulated there...

My lastest fight with udev...

Important note: This post has been modified according to a private remark from Marco d'Itri, thanks to him for his explanations !

I've been trying for a very long while to learn to write udev rules, but I've mostly been unsuccessful, or rather, successful by chance, which is hardly better, as it implies no understanding whatsoever of what I'm doing.

My game, today, was to create a symlink for a loop device (loop7) and set the device's group to cdrom (I might elaborate some time later why I need that). So, here is what I learned:

• at least for the GROUP= directive, the latest item in the /etc/udev/rules.d directory rules
• to test the modifications, the best thing is to generate a synthetic add using the following snippet:

  echo add > /sys/block/loop7/uevent
  

  Many thanks to Marco d'Itri for this information !

With that in mind, the following snippet worked for me, under the name 40-private-loop.rules:

KERNEL=="loop7", SYMLINK="videoloop", GROUP="cdrom"

Enjoy !

vegastrike finally made it to testing !!

There you go, this is a celebration day, vegastrike has finally migrated to testing ! Vegastrike basically never was in testing, excepted apparently by mistake last year... Quite a fair amount of work, I'd say !

Well, now, I'll be able to package the official 0.5 release and take care of excessive dependencies.

Please, pretty please, do not group patches by files, but by topic !

I'm currently working on putting back vegastrike into shape, bringing slightly more recent code (only three years after the last sourceful upload). And I'm fighting with patches (a good dozen), trying to see what does not apply anymore and what still does, why some patch was written in the first place... I have two requests to the community about that (and, please, do flame me if you think differently ;-)...):

• Please do not group patches by file, but by topic: if a patch modifies the name of a save directory, let it be the only patch to do that, even if it modifies files touched by other patches ! It is very annoying to have to go through the patches trying to see which hunk of which patch does what
• As an extension of the first request, please document why patches are there in the first place: a small explanation is very helpful to determine if one needs to fight to refresh the patch and understand it, or if this is a minor, long-gone problem... Of course, you can only give meaningful description if you group the patches by topic.

Great thanks to all patch writers that think about the ones that could possibly follow them !

mk-build-deps: create a dummy package depending on a package's build-deps

When I work on a package, I often find that I want to have build-deps installed in a way that I remember why I did install them in the first place. apt-get build-dep is not a proper solution for me for two reasons:

• It marks the packages as automatically installed (at least, last time I checked, it did), which does not play nice with aptitude, who wants to remove them immediately. Marking them manually installed would not be a solution either (since I would not remember why I did install them).
• It does not work for package whose build-deps changed since the last upload (or that were never uploaded).

As I'm starting to work on vegastrike, who's in great need of tender care, I though time had to find a more decent solution. The answer is mk-build-deps, a small Perl script that takes a control file or a package name and uses equivs to create a dummy package depending on its build-deps. Pretty useful (for me at least). Maybe it would be worth including in the devscipts package ?

Thoughts about statsvn

Some time ago, I packaged statsvn, a pretty neat SVN repository analysis tool based on statcvs. To be truthful, I was quite amazed that no one had packaged it before, as I find it quite handy. It is currently in contrib, as it depends on statcvs that depends on libjfreechart-java that currently only works with Sun's java on AMD64 machines (at least, see the bug report).

A few comments about it: though it can work fine with remote repositories, it is highly recommended that you either take down the number of -threads, as many repositories out there do not like too many concurrent ssh accesses, or you rsync the whole repository to your local hard drive and work from a checkout of the local copy, as it will burn much less bandwidth and server time.

Of course, statistics of this kind are not to be taken too seriously, as they can be seriously biased by commit mistakes for instance, but they give the impression that work is being done, and that is pleasant ;-)...

Flashing a Sony DVD burner

I'm the happy owner of a Sony DRU-800A DVD burner, and I wanted to upgrade the firmware, as I had some little burning problems I hoped the upgrade would fix. Of course, Sony's website provides only Win32 flashers. They run under wine, but they don't actually do anything. Apparently, the way these win32 ioctls are implemented rely on the old hdc=scsi deprecated kernel interface. The trick is that we need a 2.4 kernel to get it working properly. So here are the steps I took:

1. Get a bootable sarge with a 2.4 kernel, and boot it with hdc=scsi(hdc is the device name of your burner). You might need to compile the kernel yourself for it to work properly. In any case, you should see something like that in the output of dmesg

   scsi0 : SCSI host adapter emulation for IDE ATAPI devices
     Vendor: PLEXTOR   Model: DVD-ROM PX-130A   Rev: 1.02
     Type:   CD-ROM                             ANSI SCSI revision: 02
   Attached scsi CD-ROM sr0 at scsi0, channel 0, id 0, lun 0
   sr0: scsi3-mmc drive: 0x/50x cd/rw xa/form2 cdda tray
   

2. Make sure wine is installed, the sarge version worked fine for me (more recent versions compiled by hand did not).
3. Make sure there is an appropriate /etc/fstab entry for the SCSI CDROM device. I have something like:

   /dev/sr0        /media/dvd              auto    defaults        
   

4. Make sure there is an appropriate device symlink in /root/.wine/dosdevices. With the above fstab entry, the following would work:

   ln -s /media/dvd d:
   

5. Run the flasher as root (giving write permissions for all SCSI devices to a normal user does not work)
6. Reboot (to your normal system), and check you firmware version number with

   wodim -scanbus
   

This did work fine for the aforementioned DVD burner. It did not get my DVD reader to get flashed, though. But it's worth a try, and once the sarge boot is setup, you won't lose too much time.

As a conclusion, rush to get a sarge boot before lenny goes out and sarge is removed from the debian mirrors !

Improvements for the machine-readable debian/copyright emacs mode

Since the last post, I have significantly improved debian-mr-copyright-mode, that now provides an interactive function, debian-mr-copyright-scan-files that shows which files are covered by which clause of the debian/copyright file. I've also significantly improved my understanding of font lock and emacs lisp in general...

As a demonstration, the attached picture represents the results of debian-mr-copyright-scan-files on the monsterz source package (Sam's original example). The output clearly shows that some files are not covered yet...

You can get the emacs mode there. Its is starting to be good, but of course, many more improvements are still planned - in particular, quotes for files probably don't work yet. By the way, imenu now works. A debian package should probably come soon.

Emacs mode for machine-readable copyrights

I've been thinking that something that might help a wider adoption of the machine-readable copyright format is a proper emacs major mode for it. Well, at least, it does for me... So I started to write one. It is loosely based on debian-control-mode, although there is hardly any code left from it now. It only features syntax highlighting for now (including warning for licenses which were not on the wiki page at the time of the writing, or were marked as needing more discussions) but, after all, this is only my first emacs major mode...

The code can either be downloaded there, or from my bzr repository, in the debian-mr-copyright-mode directory

bzr branch http://people.debian.org/~fourmond/bzr/scripts

No debian package for that for now, as anyways it really should integrate dpkg-dev when it has matured somehow. Hope this helps !