Mandriva

I'm currently writing an application that has two backends.

• In live mode, I acquire images from several cameras.
• In replay mode, I read pre-recorded images from the hard drive.

As I want to switch between these 2 backends transparently, I thought of using two implementations of a custom GSource. It seemed to be what I need: a way to send and react to asynchonous events. In my case, I want to notify the application that the images are in the memory, and ready to be processed.

However I'm a still a bit puzzled about how GSource works, and I found the documentation a bit obscure to people unfamiliar with the arcanes of the glib main loop. The timeout and idle sources don't give me enough information. The other examples use polling of file descriptors, but I have nothing to poll here. I've even checked out The Official GNOME 2 Developper's Guide, but no GSource there. I had not much result in the gtk-apps-devel mailing list, nor the french GTK forums.

I'm at the point where I'm not even sure that GSource meets my needs, but I wanted to avoid as much as possible exposing the acquisition backend. There will be multi-threaded stuff for live acquisition (the cameras I'm using only provide a blocking API, sigh..), but they're not required for the replay mode.

Do you think a custom GSource is the way to go ? It seems it's the only way I can connect to glib's main loop to receive asynchronous events (excepted from timeout and idle sources). Could someone please explain me a bit in which case(s) using GSource is recommended ? Thanks for reading.

PulseAudio
I guess most people already know about it but after two weeks of tests, we (Mandriva engineering team) have decided to switch next Mandriva Linux release (2008 Spring, scheduled in April 2008) to PulseAudio. We are hoping it will help to fill the gap and fixes the issues our users have sometime, some may be caused by the cross desktop nature of our distribution (we don't want to favor one desktop environment over another). Switch has started on cooker, we will still need to fix some issues, but things are progressing nicely, thanks to Colin Guthrie hard work.Display calibration
Thanks to everybody who commented on my post about choosing a display calibration device. Unfortunately, nobody reported test for Huey Pantone calibrator. So I decided to go ahead and buy one (in a shop where I could return it for any reason, I'm not completely crazy).

First, a funny fact : there was a sticker translating in french product description and you could read "For Windows 2000 and XP, Mac OS X 10.3 or OS more efficient (in English, real text is "or higher operating system". I guess we can say Linux is more efficient ;)

Second, I tried to build lprof from CVS but I could get it to recognize the device (since Lprof maintainers commented on my previous post, it would be nice to do a new development snapshot, guys ;) but I didn't spend too much time on it (I'll investigate later this week). So, I switched to Argyllcms 0.70 beta 7 (no Mandriva package yet, I'll create one soon). It recognized the device (nice) but couldn't talk with it.. After a little debugging, Huey device is a "false" HID device so kernel decided to handle it with usbhid module. Unloading usbhid module fixed this issue and Argyllcms was able to communicate with calibrator and I was able to tune my monitor !!

I'll have to ask Pascal to add Huey to HID ignore list, just like the fix he did two weeks ago to fix Wacom tablets (this fix was originally done by Frederic Lepied, XFree86 wacom initial driver author and who used to be Mandriva CTO sometime ago) years ago in kernel 2.4 and it was forgotten in Linux usb 2.6 stack and nobody noticed until today :(

So, if you are looking for a cheap display calibration device which doesn't require any additional firmware, I suggest Pantone Huey.Ogg on Maemo
Hub, check Tuomas work, he has reported good progress on Ogg support in built-in media player on IT2008. Still some issues but it is really encouraging.

I've done a crazy thing. I installed the development versions of Mandriva Linux (Cooker) and Fedora (Rawhide) back to back on the same laptop and compared the results. I was very surprised with the results, so I spent several hours trying to make them legible to others. They are biased, personal, and hardware-specific, but if you're interested in the state of rpm-based linux distros, do check out Rawhide vs. Cooker.

Far too much hacking on a school night.... I've been putting a fair amount of time into getting PulseAudio (http://www.pulseaudio.org/) integrated cleanly on Mandriva (http://www.mandrivalinux.com/) of late and it's going pretty well. Obviously, not everyone has had a happy experience with pulse but even those that were initially against it seem to come round a bit once they start playing and see how genuinely useful it actually is! There have been a fair few bugs with quite a lot of apps in Mandriva but myself and Fred are squashing most of them and things are shaping up quite nicely. Concentrating on the Ear Candy has meant that I've neglected my other favourite: Eye Candy!!!! I've now landed Compiz 0.7.0 into Cooker after enabling XCB in our libx11 package last week. The fall out from that was fairly minimal so I've pushed ahead. I've had to cherry pick a few commits from compiz git master to deal with some more recent changes in the Compiz Fusion git repo (which I need to ship for everything to be vaguely compatible). It's a little annoying that things aren't just a little more gelled there but it doesn't really matter too much as it's not that hard to piece things together. Well, I hope that those among you will like the latest stuff, I've been running it for a week and it's pretty nice, although the infamous emerald crashing bug is still not squashed and I caught it leaking a lot (well about 20Megs) of pixmap memory earlier so it may be that there is still some way to go before an official fusion release comes out to match the compiz one (if they even have one before 0.8....). Unfortunately, there is very little chance that I'll get to go to FOSDem. I've never actually been and would have loved to go this year but poor planning has meant that transport is pretty steep and seeing as I have to get my roof repaired in the near future as well as paying stupid road tax and other such nasties, I can't really justify the expenditure :( It's a shame as there are a lot of people I'd dearly like to have met that will be going, but such is life. Hope you all have a blast!

A few of us on vendor-sec have decided to pull some cross-vendor resources and we’ve put together a new informal organization, similar to vendor-sec, but for a more “general public”. It’s primarily a wiki of various security-related information and a mailing list for OSS vendors and authors to be able to discuss public security issues. The concept is moderately similar to full-disclosure or bugtraq, but is aimed particularly at OSS vendors and authors. Because of the sensitivity of some issues on vendor-sec (pre-disclosure issues, etc.) having a large number of people on vendor-sec isn’t really viable, so oss-security aims to fill that gap by allowing those interested in security (and not necessarily members of vendor security teams) to discuss public issues, coordinate audits, or whatever. The aim is to have a stronger OSS security community and to allow people with interest and expertise to get involved, without having to adhere to the strict “code” associated with vendor-sec.

Many thanks to the Openwall Project for offering to provide the infrastructure to host this thing. The wiki is up at oss-security.openwall.org and while it’s still rather small at the moment, the hope is that various vendors and authors will get on board and provide the information we’re looking for. Particularly, the wiki is a place where people who have found a security issue in something or are want to figure out where, for example, Mandriva or SUSE advisories get posted, can easily do so. It’s mostly a dictionary of links right now, although I believe the goal is to have some “best practices” type information and other pertinent info to help vendors and such.

Should be interesting stuff. =)

[EN] This week, one of my colleague gave me his Qtek mobile device under Windows Mobile in order to find a way to synchronized his agenda with his Linux system. I must admit that since the beginning, I always try to avoid dealing with theses kind of issues. However it's true that I will have to find a way to deal with device synchronization.
The situation under linux is very complex and not very good and/or userfriendly. You have OpenSync, Synce, but it's hard to know which one is working the best with your device.
However I'm glad to see that Adam Williamson is taking care of the synchronization features under Mandriva. Presently Adam is testing synce ( bug #37874 , bug #37875 ). However there's a need to test the graphical part ( kontact and evolution support ), and also OpenSync. For people willing to have more information, and see how un-userfriendly the situation is, here are some links :

• Synchronisation PDA, Smartphones et PC sous Linux : La quête du Graal ?
• SyncML clients to install on the mobile devices
• OpenSync documentation wiki
• SynCE homepage
• Multisync Howto
• Synchroniser les contacts et l’agenda avec un téléphone portable : Utilisation de Multisync et Evolution
• OpenSync Howto
• Nokia evolution bluetooth syncing
• Sync and HAL integration proposal in Ubuntu
• Synce packages review in Fedora
• Synce package review in Ubuntu
• OpenSync presentation in OpenSuse
• SyncML-OBEX in openSuse : something interesting to note is the fact that htere may have issue for normal users to have access in read/write to USB raw devices. This may involved HAL/policykit/udev tweaking
• PDA support under Mandriva

For quite some time, I planned to shutdown my personal server at home but finding reliable services which provide exactly can be tricky. So, as always, I'm doing this in several phases.

For my blog, I migrated my own personal Wordpress to blogger, thanks to wptoblogger.py. You can now found it at http://blog.crozat.net/. For those using RSS feeds, please update your feed subscription (Planet GNOME is already updated).

For mail, I've been using a custom setup, with mail forwarding from my registrar (Gandi) to my ISP then using fetchmail + procmail + courier-imap and either Evolution or SquirrelMail to be able to access my email from anywhere. I've evaluated GMail (since it features IMAP) and it worked nicely (except for Evolution 2.20 which had issues with some strangely mime encoded titles but it has been fixed in 2.21.x release). And I must confess I've been using Gmail web interface for some months and they have almost converted me.. So, I decided to switch my domain mail directly to Google Apps, which is now effective for one week now.

For instant messaging, I was using my own jabber server. I've switched to Google Apps for that too. I still need to migration my transport for other IM services but this is not a big issue.

[EN] I've been at the "Salon Solutions Linux" at Paris and I was at the conference from Daniel Veillard about virtualization technologies under Linux. From the conference I could say that the situation was not so positive. Indeed KVM is still in early stage, Xen is not well integrated in linux kernel yet and XenSource as been bought by Citrix and so may be more interested by Windows platform, the others solutions like VMWare ( closed source ) or VirtualBox ( bought by Sun ) are slower. Today I've read an article about the new Microsoft Hyper-V hypervisor in Windows 2008 server. The solution, even if it's still a pre-release, is fast, easy to install and managed and there's even support for Linux guest ! So having a Windows having a hypervisor is as easy as adding a new Role to Windows and reboot. Then from Microsoft Management Console you can add and managed your virtuals machines : easy, complete, and fast. Unfortunately there's no open source solution as complete and easy to use, especially on the paravirtualization front. At least with VirtualBox or VMWare server, we can have easy Virtual Machine creation for free.

While I was updating the fastinit reimplementation with Metalshark’s patches, rallying enthusiast and Eeepc owner Ednilson Miura pointed me to a discussion in EeeUser about increasing screen resolution of the Eeepc display, basically by scaling down a higher resolution desktop to the native 800×480 Eeepc display. We’ve seen different approaches to solve the low resolution problem, from the traditional viewport to a larger virtual desktop to real screen rescaling (Intel has a driver-based rescaler for its Classmate PC, and there are similar resampling technologies used in other manufacturers with Eeepc-similar offerings usually with quality ranging from barely readable to unreadable). The aforementioned discussion presents a somewhat novel approach: a VNC connection to the local host. I think we could get a similar effect with a more elegant and less resource-intensive solution: X compositing. It would also be one of the first non-frivolous utilities for desktop compositing, previously used almost only for eye-candy. RandR and driver-based rescaling approaches are also discussed below.

(more…)

Permalink | 2 comments | Filed under eeepc, linux, en

Okay, I gave up on the point of getting the perl bindings for gtk2 going.
It was just too much work, and would not only require getting the gtk2 bindings going, but also writing bindings for hildon, the maemo-specific stuff.

So I went to plan B, which was to reimplement a maemo-specific GUI in python that just talks to a perl back-end which takes care of all of the actual data processing. This is now well under way. A working prototype of the GUI in python is now in SVN, it can read and display calendar data, but has no edit capabilities yet. The back-end portion is just about finished, it is a mixture of code from the dayplanner perl client and the dayplanner-daemon, what’s missing there is more configuration file handling (which can’t be done yet, because I’m not quite sure what config options the maemo UI actually needs) and synchronization code.

This has helped make Day Planner even more modular. I split out some code that is useful elsewhere into a DP::CoreModules module. That module now has code that for instance handles the configuration files, parses date strings, creates config dirs, runtime module loading, summary string wrappers and localtime() wrappers. All code that can be shared (and doesn’t merit having their own module) will be put there.

I expect the maemo port to have initial editing capabilities within 1-2 weeks, depending on my workload.

This came through as this week’s techmail, although I’m not sure why.. this was originally posted back in June, but since that was before I started linking to the tips I figured I’d note it here anyways. Tuning the Linux kernel for more aggressive network throughput talks about changing some Linux kernel options via sysctl to improve network performance via adjusting window scaling sizes and adjusting buffer sizes.

Found this link this morning, to a site with some nice cheatsheets that might be of interest to some people. There are cheetsheats for regexps, PHP, MySQL, CSS, HTML, etc. Single-page cheetsheats that can be used for easy reference. Found them on ilovejackdaniels.com. Might be worth checking out for some of you (I’ve already printed out a few of them).

I purchased an Arobie Aeropress last week. After spending some time with it, I thought I'd share my views, as it's a machine that takes some time to "get right".

I'm not a coffee snob, but I only drink one or two cups a day, so I like it to be pretty good. (I did get an espresso make for Christmas when I was, what, 12?) Over the years I've used several different devices to create my brew, with the French press being the standard I always fall back on.

The Aeropress certainly takes some time getting used to. There are so many variables to play with. The mechanics of it aren't so difficult and are well explained elsewhere on the net, including in video. At first I really liked:
- quick and easy
- less to clean than a French press
- easier to dispose of grounds
- coffee tastes "fresher"
- no grit in the coffee
<!--break-->
At first however, I didn't like:
- no bitterness... I like a bit of bitterness
- the instruction to use 80oC water troubled me
- introduction of a thermometer into my morning routine
- lots of parts and pieces to organize, store, and keep clean
- uses a lot more coffee per cup than I'm used to
- all the magical froth, the oily, light coloured foam on top of the brew, gets filtered out

But I've played with it a bit, and made a few personal tweaks.
1. To introduce bitterness, pass more water through the machine, and add less hot water later.
2. Don't use expensive coffee. It's so "smooth" that the early-morning jolt of flavour is missing.
3. Use a darker roast. Although medium roast is the most interesting in flavour, it's not what I'm expecting first thing in the AM. (It's also less prone to static electricity. Doesn't stick to all the plastic parts.)
4. Use slightly hotter water. I usually use 85-90oC.

I do follow some instructions to the tee though. I only stir for ten seconds, and then brew for 20-25. I do occasionally use the same filter twice, to save paper and money, but the second pressing requires much more pressure, which I'm not fond of. I don't want to splash a cupful of near-boiling water onto myself.

So the only lingering annoyance for me is the missing foam, and I guess that's just inherent to the machine's technique. Although I seems to remember someone on the net desigining an upside-down Aeropress. Lost the link though...

So far, so good :

• argyllcms 0.70 beta7 is now packaged on Mandriva contrib. I had to fight with Jam (because argyllcms insists on shipping a copy of libtiff and libusb and I didn't want those in our package) and with FORTIFY_SOURCE (causing buffer overflow in most tools, because of strange usage of printf, so I disabled FORTIFY_SOURCE).
• I've updated lprof package in Mandriva contrib to CVS snapshot and I got it to work nicely with Huey colorimeter. There are still some build issues to workaround (calreports.html is missing from CVS, preventing build, embedded copy of argyllcms has the same FORTIFY_SOURCE issue, build being not lib64 aware) and application bugs, such as not disabling screensaver when running calibration (unlike argyllcms), calibration windows badly interacting with Ia Ora QT theme, causing misrendering) but nothing not really serious.
• Until kernel is fixed to ignore Huey device for HID, you can unbind it from usbhid module, using echo -n "usb_id" > /sys/bus/drivers/usbhid/unbin. I'v created udev rule to handle this workaround until fix is merged in our kernel and put it in both argyllcms and lprof packages.

Christmas is coming, so I'm looking into buying a monitor calibration device. Requirements are simple :

• must be supported under Linux by Free Software ie must be supported by Argyllcms
• must be cheap (since it appears most of the features are implemented in software and not in hardware).

Version 0.70beta7 have added support for two cheap calibrators, Spyder2 Express and Huey. I know Ross has been successful with Spyder2 Express but I'm not a big fan of requiring firmware extraction from Windows driver and moreover ColorVision (maker of Spyder2) don't plan to support Free Software in future version of their product.

Huey doesn't seem to need firmware to work, but it is hacking around USB HID protocol, which requires some udev hackery to prevent kernel usbhid driver to handle the device, just like Wacom tablets (well, thanks to Pascal, this Wacom problem will be fixed in future kernel driver). So it would be better to "support" this device, over Spyder2, if possible.
I'm looking for reports of success use of Huey with Argyllcms on Linux (but if I don't get some, I'll probably buy a Spyder2 Express).

For almost 3 years, I've been enjoying my iAudio M3 player. But it seems its life is coming to a end slowly : power adapter died two months ago so I switched to USB recharge but an entire night is needed to refill battery. Moreover, it forces full internal harddrive rescan when booting the device (which scans for new tracks) and battery is also showing signs of age (It lasts for about 1 or 2 hours and the full rescan at startup doesn't help). It is still a great device, with Ogg/Vorbis support but I was hoping to change it with iAudio X7 (when/if it ever announced), because I want a portable USB OnTheGo drive as additional storage for my camera.

So, until there are news about X7, I decided to try to use my n800 as my portable audio player. And I must confess I kind of like it, even if it isn't perfect :

• I've tested the various alternative media players available and I've switched back to Nokia default media player. Why ? I've been hit by Canola battery eating background process with my 770 and I don't think installing a webserver to configure it is a good idea for a mobile device. Kagu is playlist based (I'm a "shuffle all my tracks" person) and way too long to startup. UKMP was nice until I discovered it was issuing poll on the device (thanks strace) when not playing and minimized, which is bad for autonomy.
• I'd like to have native Ogg/Vorbis playback but even with additional gstreamer tremor packages ; there are even two different versions available and none is working properly with default media player, so it might be a bug in Nokia media player. But it would be nice if both "ogg support gstreamer" packages could be merged (I've already sent some fixes to one of the packages author). So, for now, I'm back to encoding to MP3 when copying music to the device. Not perfect but it has the pro to increase battery life since decoding is handled by internal DSP.
• Audioscrobbler support : that is THE missing feature from M3. I enabled it in UKMP (thanks to maemoscrobbler), which was nice but since I reverted to Nokia player, I missed it. I guess somebody needs to write a small daemon listening to Media player D-Bus event (to notice when a file playback is finished) and kicked a maemoscrobbler D-Bus event.
• LastFM support : it isn't that important (since I can't use it in bus/metro) but it would be nice. For a long time, I was waiting for this and it is now over, thanks to Alberto Garcia and Vagalume. It is only missing lastfm: uri support in browser and love/ban buttons in the main UI. I guess I should fill bug reports :)
• Podcast support : I listen to a small list of podcasts but getting them automatically would be nice. Unfortunately, RSS internal client is horrible in that regard. But thankfully, Nokia VideoCenter can be used as a Podcast client and it isn't that bad (even if it does use a non standard UI). Now, the only problems remaining are missing bookmarking in a playback file (audiobook for instance) and podcasts being listed as available tracks in Media player main shuffle list :)
• Screen protection : I think every n800 user agrees the shipped case "protection" is awful, moreover if you compare with 770 screen casing. For some time, I've been using my DS case protection which is nice but too big. So, I ordered the official Nokia case for n800 (which is exactly what I want) but it is still in out of stock for one month now ; I even got a call from Nokia Store explaining they were expecting a shipment for October 15.. Unfortunately, I'm still waiting.

Overall, using n800 as a audio player is a nice experience which could be improved somehow (let's hope IT2008 will be better in that regard). It might even fill my need for next iAudio audio player...

I've finally finished to select, sort and "develop" my GUADEC photos (available on this flickr set). It took me too much time to complete it for various reasons :

• sort my photos and only publish relevant ones (until then, I was just pushing all photos on my flickr account to let people sort my mess ;) ),
• experiment with RAW photography (which is extremely time consuming when you aren't sure which settings you should tweak),
• tune results with GIMP (Cropping, Levels, Curve and Tone Mapping),
• make sure all photos are titled correctly and geopositionned too (I don't have a GPS received yet).

My next photos to take care of are those I took in Thaïland in June. Hopefully, they aren't in RAW format (I have 830 to sort) and I did a lot of try & errors for some monuments, so maybe it will be done for end of September ;)

This morning, while reading my daily RSS feed, I was delighted to read a great article on Wired about Hervé This (and I guess it is not by chance it hitted Slashdot too). As a lot of geeks (no need to hide, J5), I enjoy cooking and knowing and understanding how those things work it really interesting both intellectually and to improve your cooking technique. I've known about Hervé This for a long time (I have almost all his books at home and I was able to attend one of his sessions some years ago) and it is always a pleasure to read about his research. After all, everbody should know how is composed a mayonnaise and how you can recover it, when you think you screwed it :)

Anyway, I highly recommend his first french book Les Secrets de la Casserole or this english book Molecular Gastronomy: Exploring the Science of Flavor (I can't comment on this one, I only checked his french books).

(PS: I swear this post was written before I saw J5 announce of GNOME cookbook project opening :)

Federico, your remarks about patch management for distributions are quite similar to a mail I sent two years on Mandriva maintainers list, about my dream process for patch management. At that time, Git wasn't really on the radar but I thought it could be interesting to share it with everybody, now we might have tools to help :

Here are some ideas I've been having on how we could improve maintainer workflow concerning patches integration (which is quite critical for GNOME or KDE, for instance). I've been influenced by Mark Shuttleworth keynote about some stuff Ubuntu is working on (I was refering to Mark keynote at GUADEC 2005, about Launchpad).

Most of the time, maintainers are applying various patches on upstream source to generate its packages. For a good part, patches are extracted from CVS/SVN/whatever versioning system is used by upstream software maintainers, either in HEAD branch or other branches. Other potential patch sources are other distributions packages, upstream bugzilla or maintainers own brain.

Extracting patches from various CVS can be quite time consuming (this has improved with SVN since the original writing) and keeping history of patches, when upstream partially merged them is very time consuming.

When patches are written by maintainers, upstream integration is usually slow because it requires either submitting bugs upstream with patches or committing patches on upstream CVS once review process has approved it.

In order to improve this, maintainers could use a versioning system and/or magic scripts doing the following :

• upstream revisions and branches would be accessible in the repository just like using upstream repository

• Mandriva patched source would be using a separate branch containing source with all patches applied. Each patch could be done applied in a separate sub-branch, Mandriva top branch would merge all those sub-branches (this last point might not be that useful, since we are already using "Repository System" for building packages.

• When Mandriva patches are supposed to be merged upstream, branch relevant for each patch could be published for upstream integration or committed directly on upstream repository if approved by upstream maintainer.

• When fixes are needed for Mandriva package and are already available upstream, merging from upstream branch to a Mandriva sub-branch would ease package maintainer job, while keeping history and origin of the fix.

• When new upstream release is made available, it is merged into Mandriva branches and if some patches were merged upstream, they are removed automatically, since revision history is kept in each branch and the versioning system is supposed to be smart enough to deal with that.

In order to integrate easily when new Repository Build system, there might be some scripts magic to convert Mandriva patches sub-branches into subversion Build Repository (I'm refering here to Mandriva build system which is SVN based).

In an ideal world, each distribution could have their own branches and maintainers from each distribution would be able to access another distribution published branches, to easily find patches. And we would have a free (as speech) way to have a complete view of bug reports and available patches :) And I'm not even talking about migrations of bug between bugzilla (but at least, with Mandriva switch to Bugzilla 3, we will be ready for the future).

(end of mail, italic are comments I added today)

Comments welcome ;)

• 
  
• luggage : check
• 
  
• laptop borrowed from work : check
• 
  
• n800 : check
• 
  
• camera : check

Ok, I'm ready to go to GUADEC : I'll be arriving at BHX airport on Sunday morning.

As a sidenode, all GUADEC registered participants will receive a USB Flash key with a collector GNOME version of Mandriva Flash (it is our first GNOME Flash, with Metisse / Compiz and Beryl for anybody to test) with informations from GUADEC sponsors and GUADEC booklet too. There was a slight delay in the manufacturing so we are expecting them to be delivered on Tuesday (or maybe earlier if we are lucky) so don't blame GUADEC folks for this delay. Of course, if you have questions or issues with the distributions, feel free to ask me. And if you like it, you are free to let other people know too :)