Tag: debian

Building a custom debian CD

The French version was originally written for linuxembedded.fr : Crée un CD d’installation d’une debian spécialisée.

The goal is to build a debian install CD suitable for the distribution of a complete system including the operating system and applications.

Debian already has a tool for that purpose: simple-cdd. Simple-cdd is a set of scripts wrapping debian-cd which is the tool used to build official CDs.

In our case, we will include some “non-free” packages (firmwares for instance) and application specific packages in the system.

Continue reading →

Kernel develpoment on e60

Now that I have access to the serial console on Samsung e60 reader let’s build a new linux kernel for it.

The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don’t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung’s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don’t seam to embed homemade patches. As for ggc I didn’t take time to check.
I choose to use the emdebian cross-development toolchain lenny version. (As the article in the french open silicium magazine #1 about FriendlyARM proposes to do).

Installing the cross-development toolchain on debian

First the archive keys:


sudo apt-get install emdebian-archive-keyring

Then we add a /etc/apt/sources.list.d/emdebian.list file with the following content:


deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main

The we update the package list to install the needed packages:


sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi

That’s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove.

The kernel sources

Samsung released it’s modified 2.6.29.4 version. By cloning the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the 2.6.29.6 version (the last in the branch).

In order to better sort the changes michel.s had splat them into several patches
(patchs on e60-open project). After a few trials I build a series file allowing to apply those patches with quilt or better to import them to a git branch with git quiltimport. The order I choose allows to drop easily some patches (the last ones).

One particular point on those patches is that some include binary files:

  • fs/rfs/*.o a proprietary journaling layer over FAT. If you want my point ov vue, we don’t need that. After all we have free journaling file systems available and linux is able to mount something else than FAT over USB…
  • drivers/usb/gadget/file_storage.o also the corresponding .c file was removed, the BSD/GPL license from the original code allows a binary distribution (however I didn’t check if Alan Stern’s name appears in the doc) but I’d have liked that Samsung give that source code.

U-Boot

Before compiling the kernel, we need the mkimage utility from U-Boot. Here, Let’s build the U-Boot released by Samsung, and let’s just copy the tools/mkimage to a location in our PATH (that’s the only install method I could find).


make smdkc100_config 
make CROSS_COMPILE=arm-linux-gnueabi-

cp tools/mkimage ~/bin/

Building linux

For the config, one of the patches includes a .config. That file is a copy of config_rfs so even without the previous patch, we can get Samsung’s config.

Finally we can compile!


make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage

We can then load our kernel by following The kernel testing howto from e60-open project. To load the kernel we will need the following command:


sudo dnw arch/arm/boot/uImage

That’it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the /lib/modules/max14540.ko and lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel.

Missing source code

The Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let’s wait …

Conclusion

We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for 2.6.29.4 and our kernel does not want to load them. (I’ve already done a few tests but that will be a next posts’ topic.)
But without the missing sources it will be hard for us to best use our e60 reader.

Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.

Triage X Bugs of the Week (TXBW18)

Better later than never, I restarted to triage last week, here is the report for it.

  • #526095 ping & close – KVM switch change makes mouse stop working.
  • #495139 upstream – cleanlinks: warning in “find” usage.
  • #550308 ping – x11-apps: xedit search dialog shows garbage.
  • #555647 ping – x11-xserver-utils: xrandr -o left leaves xdm, after I logout, unresponsive, with no login prompt.

In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage.

Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of the Week (TXBW12)

This report is 2 week late… It was delayed by an important event, not the release of squeeze, but the birth of my first child: Célestine is born Monday the 31th of January.

My wife and Célestine are both fine now but the firsts days were not that easy. I’m starting to recover from the lack of sleep, but I’m still very late on my debian tasks 😉 So I guess I just drop Triaging for week 13, 14 and maybe 15…

Now the bugs I triaged just before :

  • #509489 ping & merge with #492783 – Switching from tty to X by pressing Alt+cursorkey pass cursorkey keypress to X. OK for this user, waiting for more responses on other merged bugs…
  • #515546 ping & closed – keys stick when switching consoles.
  • #369202 ping – randomly activated ‘access keys’.
  • #547143 ping, it’s udev now, not hal – xorg/evdev/HAL versus serial mouse – submitter said serial devices should be handled using inputattach. I think It’s been added to some docs but didn’t take time to look at it.
  • #547888 ping & closed by submitter thanks! – high CPU usage in X.org server after some time.
  • #489996 mail error, closed – problem auto-detecting / selecting some modes.
  • #550124 ping & closed – some modes aren’t recognized.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of 2011 first Weeks (TXBW9-10-11)

I’ve been lasy about the reporting lately, so this is a 3 weeks update at once !

The bug count according to udd is down to 818. I guess this is due to Kibi‘s triaging on input related bugs, but I helped to close a few one too !

I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! 😉

  • #451708 ping & close – xserver-xorg-input-synaptics: Option “GuestMouseOff” “true” not working.
  • #424743 ping & forwarded – X11 pen driver doesn’t work on tabletPC Fujitsu Stylistic 2300 (fix included).
  • #499664 ping, try nouveau – X fails to start with xserver-xorg-video-nv 1:2.1.12-1.
  • #512614 confirmed & upstream – xset dpms rejects reasonable values as illegal.
  • #512711 ping and later closed – All keypresses repeated roughly three times each, makes login impossible.
  • #513128 ping – X server crashes every time when gnome-screensaver starts.
  • #486356 merge with #482592 – numlock led is inversed (using numlockx) .
  • #515737 ping & closed – After upgrading from Etch to Lenny, mouse pointer is very slow and keys don’t repeat.
  • #515840 ping – Desktop is not using full screen after upgrade from etch to lenny.
  • #516860 closed after looking at the git history – Xorg with ‘-sharevts’ use almost 100% of the CPU.
  • #362434 ping & closed, suggested to try nouveau – nv has problems with xcursor-themes.
  • #502131 ping & closed – System gets into a `state’ and fails to process modifier keys.
  • #453296 closed (old ping unanswered) – MacBook: cannot assign right mouse click to lower Enter key.
  • #504537 ping – X server eats CPU on sparc.
  • #502313 ping – Applications are getting “ghost” Alt keypress events, but I press no keys.
  • #527118 ping – autoadded input devices kill X server.
  • #270887 forwarded – startx and xinit do not preserve client arguments.
  • #542542 closed after looking at the git history – non-VGA compatible graphics devices won’t run X.
  • #492888 ping – xorg ignores keystrokes.
  • #543210 merge with #492783 – Alt-F7 to return to X, passes F7 key to top focus’d window.
  • #524413 closed – xauth fails with xorg 7.4, this was actually an xinit bug and the git log lead to #549377 being closed…

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triaging bugs is not that hard !

There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer’s job. While it’s true in general, some understaffed teams are so flooded by bugs that they just can’t do it.
I’ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks!

Then the thread evolved in lots of directions, I’m not following all of it, but there was the question of the bug triaging and as I’m doing it for the X packages, I want to share about my experience here.

The available triaging docs

The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project’s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don’t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o !

Now if all those docs don’t help you, then try to improve the docs as a first step ! 😉

Talk with the maintainer(s)

Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway.

My current process

This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!

  1. List bug from UDD: XSF unstable bugs sorted by date.
  2. Pick an old bug (once you answer and UDD runs, the bug moves down the list, so there are always old bugs on the top).
  3. Read the report, don’t be afraid by the subject, it might be unrelated, the bug might be merged with other bugs, then reading the other bugs can help.
  4. If relevant try to reproduce it. (most bugs in X are hardware related or specific to one setup, so it’s not that often that I have something to test).
  5. Decide what to do, most of the time, I will ‘ping’ the submitter.
  6. I’m a mutt user, and to my help the bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.
    So I launch bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.
    The triaging procedure suggest to ping -submitter, but using mutt it’s easier to just reply and add a -quiet to the bug number (this avoid spamming the debian-x with all my pings).
  7. In the message, always try to be kind and helpful, most of the time ask to test newer versions.
  8. Keep track of the pinged bugs, well I do it for my blog but it will be useful anyway, see below.
  9. When the submitter answers, just react accordingly, if the bug can be closed, then close it ! 😉
  10. If after some time, the bug are still not answered, consider closing them (I haven’t started that yet, but this will probably get the bug number down faster:) ).

Note: Sometime I don’t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. 😉

To submitters, please keep the bug CCed when you answer, thanks.

For the skeptics

Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don’t close bugs if I’m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! 😉

Also this work might look boring, but it’s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I’ve learned on Xorg.

Conclusion

As long as I have time for it, I’ll continue to triage bugs and I’d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! 😉

Get involved !

Triage X Bugs of the last 2010 Week (TXBW8)

Happy new year !

  • #440495, #437255 ping – Keyboard steal after stopping touchpad.
  • #476143 Closed: submitter never answered Brice’s request – xserver-xorg-video-nv: Driver reports wrong display size.
  • #468331 ping – xserver-xorg-input-kbd: xorg.conf okay, no AltGr though but “setxkbmap -variant nodeadkeys de” works.
  • #498210 ping – xserver-xorg-input-kbd: ctrl:nocaps keycode 66 is on both the control and shiftlock modifier list.
  • #488685 ping & close: hardware not available anymore – xserver-xorg-input-kbd: Acer TravelMate 2303M : the ‘Fn’ key is inverted.
  • #511910 ping – xserver-xorg-input-evtouch 0.8.7-3 does not work with HAL.
  • #513297 close – x11-xkb-utils: When I use the setxkbmap command i get the following error: Error loading new keyboard description.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

Triage X Bugs of the Christmas Week (TXBW7)

For some reason1 bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn’t write to me, this bug will have waited for what… about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort 😉

  • #607242 reassign & give+ask moreinfo.
  • #403350 ping & try nouveau – xserver-xorg-video-nv: xset dpms force off does not turn off the backlight.
  • #469104 config suggestions & close – xserver-xorg-video-tdfx: screen resolution too low.
  • #476198 closed – xserver-xorg-video-radeonhd: Cannot turn on a secondary screen without restarting X (xrandr-related problem).
  • #492783 ping, unreproducible – vt switch key combination leaks to clients.
  • #496150 ping – xserver-xorg-core: shutting off monitor messes up display.
  • #504104 ping & closed – xserver-xorg-input-mouse: Emulate3Buttons stops working from time to time.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.

  1. Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail. ↩︎

Triage X Bugs of the Week 6 (TXBW6)

An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875…

  • #471423 ping – ati driver ignore Option “Enable” “false” in monitor section, but accept the undocumented Option “Disable” “true”.
  • #468561 ping & closed – vesa: switching resolution with xrandr after suspend-to-ram.
  • #447526 ping – memory leaks.
  • #475534 closed – as reported said, oclock seams to work correctly…
  • #466044 ping – xserver-xorg-core: internal screen of laptop with external screen attached not blanked when laptop closed but still in use.
  • #482317 ping – libxt6: scroll list overflow in gv.
  • #425814 ping – xserver-xorg-video-ati: Xv broken on Mach64 3D Rage LT Pro AGP-133.

The X Strike Force (still) needs you !

You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.