Today I have released the next version of DebTorrent. This is the first release to be available in a binary package (.deb) form, and most of the changes are related to the packaging I still consider the program to be alpha quality, though all the functionality for a beta release is there, it just needs to be tested (so tell your friends). I run the program daily and use it for my apt-based updating, so I'm pretty sure it works, but there are definitely bugs. If you do find one please submit it to the DebTorrent mailing list. The installable binary can be found on the Alioth project, or in my personal repository which can be added to your sources.list like so:

deb http://debian.camrdale.org/ unstable main contrib non-free

Once installed, it will start running automatically, and will restart on bootup, so all that is needed is to modify your sources.list files to point them at DebTorrent by prepending localhost:9988 to the mirror name. For example, the entry above for my personal repository would become:

deb http://localhost:9988/debian.camrdale.org/ unstable main contrib non-free

Here's the changelog:

• First debian package release (Closes: #428005)
• Cleanup all the configuration options
• Add a global config file
• Moved all logging to log files
• Stopped displaying periodic updates
• Added init script and default options

After reading Mike Hommey's idea about buildd network for QA testing, I decided to try to implement the 10.1 policy recommendations check using rebuildd. Here is how I proceeded. Install and configure rebuildd This is done by apt-get install rebuildd. Then, init database (I use sqlite) with rebuildd init. Then I initialized build system with rebuildd-init-build-system. I had to add nostrip to DEB_BUILD_OPTIONS, so I decided to do quick and dirty and I edited /usr/bin/dpkg-build-package adding the good export info in the first lines. Configuration file and post build cmd My configuration file is simple and the one by default: I only changed email addresses and add a post_build_cmd script. Here's the code for the script:

#!/bin/sh
dist=$1
pkg=$2
version=$3
arch= dpkg --print-architecture 
RET=0
cd /var/cache/pbuilder/result   exit 1
for file in $(grep '.deb$' $ pkg _$ version _$ arch .changes  cut -d\  -f6)
do
	echo Checking $file for stripped binaries...
	echo ---------------------------------------
	mkdir /tmp/$file
	dpkg -x $file /tmp/$file
	find /tmp/$file -type f   (while read line
	do 
		L=$(file $line   egrep 'ELF.*, stripped')
		if test ! -z "$L"
		then
			echo $L
			RET=1
		fi
	done; exit $RET)
	RET=$?
	rm -rf /tmp/$file
done
echo
echo ...done
echo Removing result files...
for file in $(grep-dctrl -sFiles . $ pkg _$ version _$ arch .changes   sed '1d'   cut -d\  -f6)
do
	rm -f $file
	rm -f /var/cache/rebuildd/build/$file
done
rm -f $ pkg _$ version _$ arch .changes
echo ...done
exit $RET

Fille the db Then I fill the database with:

grep-dctrl -sPackage,Version .  /var/lib/apt/lists/ftp.fr.debian.org_debian_dists_sid_main_source_Sources   cut -d: -f2-   tr '\n' ' '   sed 's/   /\n/g'  sed 's/  / /'   xargs -L1 -ixxxxxx echo xxxxxx sid   rebuildd-job add

And finally I just have to start rebuildd and let it do the job. Argh, already 3 build logs received with stripped binaries Update: Bug list can be found here

As some of you may know, I’ve been working with Linbox for the past 3 years, on and off, part time and full time, depending on the time of the year. I won’t be working with Linbox anymore after Mandriva, which has bought Linbox back in June, decided Linbox wouldn’t go ahead in the Enterprise VoIP business. I have been, for the past 2 years, the architect of Linbox’ VoIP solution. This unfortunate and ill-advised decision of stopping the development of a successful product at its beginning will effectively leave the current customers out in the cold, as technical support will probably be erratic at best. Looking back in the mirror, I’ve done a lot of things, small and big, during these 3 years:

• [2004] Developed a web-managed multi-service turn-key solution for SMBs, of which the web interface served as a prototype for the Linbox Management Console (a web-based server management framework);
• [2004] Developed the product deployment system based on FAI; still in use today, obviously updated since then;
• [2004] Wrote an AD to LDAP account (including password) sync script (customer with a special need); that resulted in me hacking OpenLDAP to port the lanman password hash support to gcrypt (Debian #245341);
• [2004] Started the hosting business;
• [2005] Started the development of the Linbox IP Telephony Solution (LIPS), based on AMPortal (now called FreePBX); ended up forking AMPortal to fix the gazillion bugs and bring it to a more usable state;
• [2005] Hacked up OpenXchange to add a click’n'dial feature to the addressbook; eventually we decided to dump OpenXchange, mainly for being an underdocumented pile of crap full of security holes (nice SQL injections, eh) and, over all, a false free software (no upgrade path, no doc, some components not released, GPL patches added to the non-free version without agreement, among other things);
• [2006] Prototyped the cluster version of the VoIP solution; this cluster version meant the solution could scale up to support thousands of users on multiple sites with redundancy and failover;
• [2006] Wrote a migration tool to migrate mails away from a FirstClass groupware to anything IMAPv4-compliant, straight out of the on-disk FirstClass storage database;
• [2007] Integrated the VoIP solution into the Linbox Management Console; after 2 years of consolidating the AMPortal web interface, I’ve finally got rid of that horrible thing;
• [2007] Integrated the cluster support infrastructure into the solution;
• [2007] Added proper faxing (over PSTN) support, at last.

And, more importantly:

• [2007] Deployed client sites without any interruption in telephone service.

I’m especially proud of that; the solution was ready for that moment, and my deployment plan proved to be the right one and flexible enough to account for everything that wasn’t ready in time (missing network infrastructure, things that had been forgotten on the client side, things that didn’t go as planned and last minute changes to accommodate users’ needs). The customers were very happy and enthusiastic with regard to their new VoIP infrastructure - so much that there was more to come. And more to come means more business for a company that definitely needs it, and is now turning that business down. So it’s all over now, and overall I’ve had a good time working there with the technical team. They’re all very talented, and we were 3 DDs working there - that figure is now down to 1 (yes, one, as in 3 - 2 = 1). I’ve been able to produce a really great free (as in speech) Enterprise VoIP solution that I liked quite a lot. I had great plans for the LIPS, but couldn’t carry out much of that until it was integrated into the Linbox Management Console. In the last weeks, I’ve had confirmation that my plans were right and I was going the right way. That’s history now, and I’m looking at what I’ll be doing next. It’s good because I can look for a job that either involves VoIP or not; it’s good to change after a while. It sucks because looking for a job sucks.

I got bored recently, so I rebuilt the whole Debian archive on one of my machines. To make this not a completely useless excercise, I used the Open64 compiler instead of gcc and created build logs for your perusal. So what is Open64? From the Wikipedia page:

Open64 is an open source, state-of-art, optimizing compiler for the Intel IA-64 (Itanium), AMD Opteron and Intel IA-32e architecture. It derives from the SGI compilers for the MIPS R10000 processor. It was released under the GPL in 2000, and now mostly serves as a research platform for compiler and computer architecture research groups. Open64 is licensed under the GPL. Open64 supports Fortran 77/95 and C/C++, as well as the shared memory programming model OpenMP. It can conduct high-quality interprocedural analysis, data flow analysis, data dependence analysis and array region analysis.

Open64 installation The installation is pretty easy fortunately:

$ wget http://ovh.dl.sourceforge.net/sourceforge/open64/open64-4.0-src.tar.bz2
$ tar xfvj open64-4.0-src.tar.bz2
$ cd open64-4.0
$ export TOOLROOT=/opt/open64
$ make
$ make install (as root)

I think you need gcc-3.4 (gcc 4.x is not yet supported), and for some odd reason you also need csh as one of the install scripts seems to use it. It would be nice if someone could package Open64 for Debian, I definately don't have the time to maintain such a huge package (a whole maintainer team would probably be good here). Rebuilding the Debian archive There are several possible ways (and tools) to rebuild the Debian archive; I've used pbuilder/cowbuilder with the rebuild scripts from Bastian Venthur, which are now included in pbuilder. First we need to install the required packages, setup a cowbuilder base chroot, and get the list of packages:

$ apt-get install cowdancer grep-dctrl wget devscripts sudo
$ cowbuilder --create --distribution lenny --basepath /var/cache/pbuilder/testing-base.cow
$ cp -r /usr/share/doc/pbuilder/examples/rebuild .
$ cd rebuild
$ ./getlist lenny

Now we add Open64 into the cowbuilder chroot and fix up the chroot by pointing the gcc/g++ symlinks to Open64:

$ cp -a /opt/open64 /var/cache/pbuilder/testing-base.cow/opt
$ chroot /var/cache/pbuilder/testing-base.cow
$ cd /usr/bin
$ mv gcc gcc.orig
$ ln -s /opt/open64/bin/opencc gcc
$ mv g++ g++.orig
$ ln -s /opt/open64/bin/openCC g++
$ exit

In addition, we set the CC and CXX environment variables to Open64, which will make 90% of all (autoconf-using) packages automatically use Open64. We need a small script for that:

$ cat c.cfg:
export CC="/opt/open64/bin/opencc -m32"
export CXX="/opt/open64/bin/openCC -m32"

Now edit the buildall script. Change the Debian mirror used there (optional) and make it use our c.cfg script by adding the --configfile /path/to/rebuild/c.cfg option in the "pdebuild" line. We can now finally start building the archive:

./buildall list.lenny.i386 lenny

You can also run multiple buildall instances at once to speed up the archive rebuild on SMP/multicore machines, and you can even abort the command and simply restart it later. The script will continue where it left off. Results The whole rebuild (with 2 instances of buildall running at the same time) took ca. 9 days on an AMD64 Athlon64 X2 (dual core, 1.8 GHz each) machine with 1 GB of RAM. I really should have used something like apt-proxy to speed up the rebuild and save some bandwidth, but I read about apt-proxy too late... All log files from my rebuild are available for detailed analysis if anybody is interested (you can browse the logfiles online or download all of them as tarball). I didn't perform any detailed analysis, just some rough numbers here:

• Succeeded package builds: 8425
• Failed package builds: 2509
• Total number of packages rebuilt: 10934

If anybody does some more elaborate analysis, please let me know.

* Original announcement! If you have any idea/plan/suggestions what we can do there for Debian, let me know. Some thoughts, - Key Signing Party - Debian BoF, Debian-Indic/i18n BoF - Full day for Debian@Project Days, Talk.. - DDs from outside India, we will love to see you there!

A friend recently asked for advice on a “REALLY small laptop/word processor thingy that would pretty much fit into a (big) pocket, and that only needs to write/word process“. The first problem here is that most people associate “word processing” with desktop publishing and document management. Programs such as MS-Word are considered as having the features required of a word-processor (which includes spelling and grammer checking/correcting, annotations, colours, etc). Programs that have all those features take a lot of CPU power. A Pentium-4 system might be considered the minimum requirement for running a recent version of MS-Word. But a hand-held device can’t have such a powerful CPU (it’s too small to be able to dissipate the heat from such a CPU or contain batteries that can produce enough power to tun it). The next problem is the issue of screen space. A VGA resolution screen (640×480) is regarded as high resolution in the PDA market. Such a resolution does not work with a word-processor that has three toolbars at the top of it’s screen and a paperclip taking up space at the bottom right! I’m sure that everyone who was using computers in the early 1990’s can recall the minimal word-processing programs. One thing to consider is that 640×480 in a 15 inch CRT screen is much more useful than 640×480 in a hand-held device as the larger screen can have fewer pixels per character and therefore display more text on the screen. An added complication is that there are two methods of input for PDAs. One is to have a hardware keyboard (which may be a separate device or may be part of the PDA) and the other is to have a keyboard displayed on the screen. A hardware keyboard makes the device larger and a software keyboard takes up precious screen space (you just can’t win). My PDA is an iPaQ model h3900. It has 64M of RAM, 32M of flash, no hardware keyboard, and a screen resolution of 320×240. I have done some serious writing on my iPaQ (including writing an entire article for Linux Journal) and it works reasonably well. For serious writing you can produce plain text on a PDA and then easily paste it into your program of choice on a PC later (PDAs generally support connection to a PC via serial port and/or USB). The challenge is editing files that originate on a PC using a PDA. Generally I try and use HTML and TeX for my formatted documents so the text versions of those formats are easy to edit once you have learned them. Taking data from a MD-Word file, editing it on a PDA, and then taking it back to the PC would cause many problems and probably wouldn’t be worth attempting. Recently I have been using my iPaQ for writing notes about email and blog posts that I will write. If I get an idea then I immediately write some notes about it on my iPaQ and then usually type it again instead of downloading it. For example the notes for this post were “write about RAM, storage, and screen resolution”. Often getting the initial ideas to start writing is the hard part. Writing a 500 to 1000 word blog post or message is easy once I have the ideas. If I was going to buy a new PDA now I would prefer one with a hardware keyboard, the loss of screen space for a keyboard on the touch-screen is a serious impediment to writing. The maximum amount of text that can be displayed on the screen at any one time limits the complexity of what I work on (see my post about monitors for developers). Another factor is the fact that for small notes the amount of time taken to remove the stylus from it’s bay is greater than the amount of time saved by using it. So I end up writing small notes using my finger-nail on the touch-screen which is significantly slower than using a keyboard (even the crummy ones that PDAs have). Of course the keyboard would still have to be QWERTY and have raised keys so that I can touch-type. I haven’t investigated this seriously as my iPaQ is good enough to last me for another year or two at least and I’ve got an unused spare iPaQ to replace it when it fails. But if anyone has any recommendations of Linux based PDAs with keyboards then I would appreciate some comments.

Share This

Last thursday and friday, I spent around eleven hours in the InterCity Express (ICE) of Deutsche Bahn. I was online, using Simyo GPRS, during this entire time. Thanks to the cellular network repeaters in ICE’s coach 3 and 23, this has worked reasonably well and has cost me EUR 5,27 - in a tariff with no basic charge and no commitment. I really like that, because this usage of the mobile cellular network would have cost about fifty times more just a year ago. Thanks, Simyo, E Plus and the other E Plus resellers who have made the first step to reducing the cost of mobile Internet in Germany. A few technical notes:

• The repeaters in the ICE coaches do only repeat GSM and thus GPRS, but not UMTS. It is advised to lock the UMTS card to GPRS when using Internet from inside the ICE, since the card will otherwise move back and forth between UMTS and GPRS millions of times, which will always result in more than just a few seconds outage. It is much better to live with GPRS’ abysmally large latency.
• I took the opportunity to empty my still-active, old, GPRS only, Simyo SIM which still holds like fifteen Euros. I suspect that I’ll need two more trips of this magnitude to successfully get rid of the amount on that prepaid card.
• I need an external antenna for my UMTS card - it worked really really bad in my mom’s apartment right in the middle of Hamburg.
• There seem to be a number of independent issues in Debian sid (the reason why I am blogging this in English): The connection occasionally hangs (a couple of times an hour) and does not come back by itself. Often, poff/pon is enough, but sometimes it is necessary to pull the UMTS card (an Option 3G PC-Card Datacard) and to re-insert it since there was no answer any more on ttyUSB0. Very annoying.
• The Option 3G Datacard behaves differently depending on the SIM that is inserted. With my older, GPRS-only Simyo SIM, the response to AT+CPIN? is “SIM PUK2” after sending the PIN to the card, while it is “SIM PIN2” in the same situation with the newer UMTS-enabled Simyo SIM.
• chat(8) sucks badly, because it doesn’t seem to elegantly handle this case - no regexps, no if/then, every command sent needs to generate exactly one answer from the card, everything else is an error after timeout.
• When I do this more often, one of the now available flat rates (or, for starters, a 5 GB commitment tariff) for like 20 Euros becomes attractive.

* Congratulations Kapil, We have 3rd DD now!!

Debian Revolutions ... begin with small steps ... ... let's see if the one I'm seeing right now will be one of those. Since ages the collab-maint project on Alioth has been configured so that all DDs can commit to its SVN repository. I've always thought this is a good idea and I've always wanted that to be true for all Alioth's collaborative maintenance project, rationale being always the same: DDs are lazy, if I have a patch ready there is nothing more valuable than the ability to commit it right now (together with an appropriate changelog entry of course!). At Debconf I chatted a bit about that with Sam and Raphael, and we started thinking about how to make that wish a reality. As a first step the Alioth admins agree on giving DD-wide commit permissions to every alioth project asking so. Let me repeat: you can widen to the whole DD body the commit permissions of your collaborative maintenance project on Alioth just asking the alioth admins. It's quick and easy, and I'm confident Debian as a whole will benefit for mass adoption of this good practice. Raphael has proposed that for adoption to the Python and Perl modules maintenance groups, and it's now implemented for the OCaml maintenance group. Ask that for your beloved collaborative maintenance project! The next step is to patch the GForge running on Alioth so that project admins can enable such a setting by themselves: I volunteered to work on that, but I'm a bit swamped with other Debian-related stuff, help would be much appreciated!

The debian armel port reached one milestone yesterday: Being able to run debootstrap from DD-signed, upto-date unmodified debian/unstable packages.

Looking backward:

* When watching the buildd's, the worst of Debian is visible. You don't spend much time wondering on successful builds. The time goes into wondering about the crappy code that fails to compile, the maintainers who ignore RC bugs for months, code with dead upstream..
* bootstrapping a Debian port is still painful. Fortunately Lennert did that for us this time.
* Most maintainers are very responsive, and are happy enough apply patches that help even unofficial ports. The few who ignore patches or are else effectively MIA can cause long delays...
* C++ code is evil. or at least the g++ implementation of it. A random game written in C++ can take 5h to build, when even the most complex C apps compile in 2-3 hours (with a few exceptions like glibc and linux-2.6). Worse, g++-4.2 seems to be another 10-20% slower than g++-4.1... Remember God kills a kitten every time you upload a c++ package unnecessarily!.
* Esoteric language bindings suck too.

Looking forward:

There is some 500 (out of 7100) packages that in Dep-Wait state due some missing packages on armel port:
* ~290 packages that would need FORTRAN (!). specifically the old g77 version...
* ~80 packages waiting for objective C / gnustep
* ~70 packages waiting for ghc6 or related Haskell code
* ~40 packages waiting for Java (being worked on)
* ~15 packages waiting for mono (patch in BTS)
* Then there usual crop of esoteric languages, packages failing to build with current unstable on any port, and packages build-depending on stuff removed or to-be-removed packages.

Effectively this means getting armel over 90% built of Debian needs either g77 to armel or getting Debian to migrate from g77 to gfortran (which is available but not throughly tested on armel). I'm working on the second route..

* Start building d-i images. So that Eddyp can have blazingly fast softfloat rrdtool on his nslu-2 without bugs and trouble.

* Request inclusion into Debian ftp archives. I think with the latest milestones, armel should be ready for archive as a "second class citizen". Inclusion for lenny needs still some work.

* Finally: there's tablets and phones waiting to for Debian armel mobile ;)

This afternoon we had a Debian meeting in Melbourne (Australia) arranged through the Debian-Melb mailing list. We met under the clocks at Flinders St station, had lunch at a good Japanese restaurant, decided not to play LASER games (like paintball but with LASER guns instead of paint guns) due to the queue. The LASER games are at the Crown Casino, some people object to it on principle, but when you only use free tickets… One noteworthy thing about the casino is that they have a free cloak-room that stores bags (back-packs etc are not allowed on the gaming floor). I expect their cloak-room to be a little more secure than most places that you might stash your stuff (they have a reputation for security to uphold) so I felt safe leaving a back-pack containing a laptop in their care (it didn’t have any secret data and was a really old one). After leaving the casino we had Gelati/Gelato ice-cream (Gelati is the plural of Gelato and either word may be used to describe Italian style ice-cream). The general plan for the next meeting is to meet in the city at about 10AM on a weekend, play the LASER games, and then have lunch. Of course that would make it a greater requirement for people to arrive on time. ;) While at the meeting we discussed in concept the idea of a Bug Squashing Party (BSP). I can get a free venue for up to 12 people outside business hours which is not far from the center of Melbourne and which has good net access and a good supply of keyboards, monitors, and other misc computer bits (even possibly some PCs that can have their hard drives temporarily replaced to test Debian stuff). One guy who is rather keen on this idea asked if it would be possible to bring sleeping-bags and sleep on the floor. I hesitate to ask the guy who owns the office about that, it might make him reject the idea entirely. So probably starting at about 10AM and going to 10PM would be enough. We could do that both Saturday and Sunday on some weekend or maybe even start on Friday night. I’ve been planning to run a similar meeting to play Linux games which may end up as a games hacking party. I might get around to running that soon.

Share This

* Rain rain go away, Little Kavin wants to play..

Anyway, back to pure Linux stuff. A while ago, the Ubuntu Technical Board were asked to take a look at Automatix. I've finally got around to doing so, and here are my initial conclusions. I'd appreciate any factual corrections, and note that at this point this is my individual opinion rather than any sort of official statement.

Automatix is a combination system configuration/package installation
tool, aimed at making it easy for users to install features like
graphics drivers, media codecs and software not distributed as part of
the Ubuntu distribution. It is provided as a .deb file containing a
python GUI frontend that calls out to a shell backend. The frontend
parses an XML file which contains module descriptions and function
names for installing and uninstalling modules, with these functions
being part of the shell backend. An install module will typically
check whether another package manager is running, and if not either
install a set of debs or download and manually install a
tarball. Uninstall modules generally remove the same software or clean
up the manually installed files.

The following is a list of identified issues with the current version
of Automatix - it is the result of a few hours of investigation, so
may not be complete.

• Automatix is, in itself, a poor quality package which fails to
  conform to Debian or Ubuntu policy.
  
  
  • It is inappropriately flagged as belonging to base
    
  • Depends on essential packages
    
  • Has a short description of more than 80 characters and no long
    description
    
  • Provides no email address in the maintainer field
    
  • Contains no copyright information in the standard locations
    
  • Ships a TODO file as a control file
    
  • Provides no man pages
    
  • Ships files in /usr/etc
    
  • Contains many files inappropriately flagged as executable
    
  • Changelog is in /usr/etc/automatix2/ax_data ?
  
  These issues are primarily cosmetic and in themselves are unlikely to
  cause any harm to the system.
  
• In debug mode, automatix will write files to your home directory as
  root. Again, more of an irritation than anything dangerous.
  
• Provides platform-specific data in /usr/share. Potentially an issue
  if /usr/share is shared between multiple architectures, but since
  Automatix is x86/amd64 only probably not a real problem.
  

• #!/bin/bash
  #created by arnieboy 
  foo= gksudo -u root -k -m "enter your password for gedit root access" /bin/echo "Do you have root access?" 
  sudo gedit $NAUTILUS_SCRIPT_SELECTED_URIS

  appears to be an attempt to ensure that the user has sudo rights. This
  will break if timestamp_timeout is set to 0 in sudoers - gedit should
  be run directly from gksudo. This is repeated in more than one
  place. The assumption that sudo will not need to prompt appears
  prevalent throughout the code.
  
• catagory_data.xml - nitpick, but should be category
  
• "Please NOTE that downloading and installing w32codecs, libdvdcss2
  and other non-free codecs without paying a fee to the concerned
  authorities constitutes a CRIME in the United States of America"
  
  Somewhat dubious legal advice - the issue has nothing to do with fees,
  and isn't just limited to the USA.
  
• Automatix checks that other package managers aren't running at
  startup (by grepping for a static list of application names in the
  proces list), but doesn't enforce this by carrying out any locking of
  its own. This leaves Automatix open to race conditions.
  

• if ps -U root -u root u   grep "dpkg"   grep -v grep;
     then
       killall -9 dpkg

  May well leave the system in an inconsistent and unbootable state, and
  is carried out without warning. This is entirely unacceptable and will
  leave a stale lockfile in any case.
  

• function reloadnautilus  
         killall -9 nautilus
   

  Not actually used anywhere, but could potentially lose user
  information without warning.
  
• Most install functions contain a sleep statement for no obvious
  reason. They then call dpkg_check, which sleeps again. It's not at all
  clear what this is meant to be doing.
  
• Passes --assume-yes to apt-get, which will (as a result) happily
  remove packages without giving the user an opportunity to
  intervene. This is especially bad when removing Automatix modules -
  any package that depends on one of the packages being removed will
  also be uninstalled, even if the package was originally installed via
  something other than Automatix!
  
• Has no internal dependency management. Unable to keep track of why
  packages were installed, so prevents the removal of the multimedia
  module because that would remove sections of other modules without
  explicitly removing that module. Installing swiftfoxplugins will pull
  in several plugin packages, but removing swiftfoxplugins will not
  remove them even if nothing else depends on them. Also means that
  package installation and uninstallation have to be manually kept in
  sync - uninstall will not always remove all packages that were
  installed.
  
• Has no concept of file tracking, so will just remove entire
  directories. Makes no attempt to ensure that a user-installed version
  is not already installed in the same location, so effectively assumes
  that the /opt namespace belongs to it.
  
• Will remove Ubuntu repository packages in favour of tarballs with
  no warning.
  
• Setting ctrl-alt-del to open gnome system monitor will destroy any
  existing user configuration for run_command_9
  
• Installing streamtuner will create a world writable directory in
  /opt/ripped with no sticky bit, allowing users to interfere with other
  users' files.
  
• mplayerplugin moves totem plugin files to a backup, but does
  nothing to prevent package upgrades of totem replacing them.
  
• Only updates the java link after installing new java, not the rest
  of the java alternatives
  
• amsninstall installs tls libs that are never removed, copying over
  the ones in the tcltls package. This means that the md5sums in the
  tcltls package will no longer validate.
  

• sudo ln -s /usr/lib/libesd.so.0 /usr/lib/libesd.so.1

  is really not
  such a good idea.
  

• ln -s /tmp/.esd-1000 /tmp/.esd

  looks like it'll only ever work for
  the first user on the system, and there's nothing to recreate it on
  boot.
  

• sudo sed -i "s/^vboxusers\(.*\):$/vboxusers\1:$AXUSER/" /etc/group

  - assumes that the system isn't using some sort of user directory
  service.
  
• installs truecrypt suid root - not ideal, given its less than
  stellar security record
  
• Unmounts filesystems without checking to ensure that the unmount
  succeeded.
  
• Deletes lines from fstab and replaces them with device nodes
  rather than uuids.
  
• Includes acroread 7.0.9, despite the new Acrobat license appearing
  to grant no right to redistribute.

Conclusion:

Automatix exists to satisfy a genuine need, and further work should be
carried out to determine whether these user requirements can be
satisfied within the distribution as a whole. However, in its current
form Automatix is actively dangerous to systems - ranging from damage
to small items of user configuration, through removing user-installed
packages without adequate prompting or warning and up to the (small
but existing) potential to leave a system in an unbootable state.

The current design of Automatix precludes any reasonable way to fix
some of these problems. It is attempting to fulfil the role of a
high-level package manager without actually handling any sort of
dependency resolution itself.

A more reasonable method of integrating Automatix's functionality into
Ubuntu would be for the Automatix team to provide deb files to act as
installers for the software currently provided. These could then be
installed through the existing package manager interfaces. This would
solve many of the above problems while still providing the same level
of functionality.

In its current form Automatix is unsupportable, and a mechanism for
flagging bugs from machines with Automatix installed may provide a
valuable aid for determining whether issues are due to supported
distribution packages or third party software installers.

• Waiting for Omer
  Every day Iraq sinks a little bit deeper into horror...
• On the Other Hand: The Flip Side of Entrepreneurship
  "In the early days, start-ups focus on how great it s going to be when they succeed; but the moment they do, they start talking about how great it was before they did."
• elevator camera obscura
  Neat, check out the video.
• Mozilla Says Ten Fucking Days
• Your browser is a tcp/ip relay
• Packet Geeks Gone WWWild
  Lots of interesting stuff going on at Blackhat 2007, wish I had been there.

Matthew: Thanks for the followup and the summary of the MacBook status wrt power consumption. I’m running a 2.6.22 kernel with the hrt patchset and a set of patches including your patch to appletouch. Your patch works great and the trackpad’s behaviour is a bit better with it. I know pretty well what the problems are on my machine, but your summary will probably be useful to a lot of people. I know some of the issues can be fixed or worked around and others cannot. Also note that I can get something like 3h45 out of my battery under OS X with my standard workload, which is pretty good. If OS X can do that, there’s no reason Linux can’t, however bad Apple’s choices are wrt hardware. And to make it clear once again, my previous post didn’t criticize the C-states or anything else, but the fact that I see PowerTOP being used more as a blame shifting tool than as a debugging/profiling tool. Though I maintain that UHCI suffers from a bad design, OHCI is a much, much better spec.

The main reason for the lack of activity during this week was that I had some problems with my router, a NSLU2 running the debian arm port. This was the machine I wanted the softfloat rrdtool I was talking about in these 2 posts.

It turns out that for some weird reason the USB controller of the slug resets when there is too much traffic going on. I got lots and lots of messages like:


$ grep reset -A 1 /var/log/syslog grep -E '(reset repeated)'
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
...
Aug 3 11:50:29 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:51:03 ritter last message repeated 4 times
Aug 3 11:53:15 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:53:46 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:55:48 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:07 ritter last message repeated 2 times
Aug 3 11:56:52 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:56:57 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2


That wouldn't have been a problem as long as the damn thing worked, but in some cases after the reset the root filesystem was lost and all the services running on the machine died (except the networking itself since all of that is part of the kernel and is loaded in memory).

It took me about three evenings to get to this conclusion (imagine being locked out of a machine which advertised running ssh, http, and dns services, being able to telnet and getting a respons, but the full protocol failed).

It all became more clear when, while being connected via ssh I got his result:

eddy@ritter ~ $ ls
-bash: ls: command not found

"WHAT?" was the first reaction, then I figured that life without ls is unbearable and came up with this bit:

alias ls='for I in * ; do echo $I ; done'

Quite cool to understand a little bit about the system. Still, cat was unavailable so having /proc and /sys available did not help that much. At some point I was thinking about a busybox shell, tried that, it didn't work since it wanted to remove some important bits like the initramfs tools.


I googled again and found a good starting point for a discussion of the same problem someone else was having. I ended up trying all the proposed solutions: rmmod-ing ehci-hcd, blacklisting the module, regenerating a initrd image with the blacklisted module... None of these worked (individually) and I ended up having an even more unstable system when ehci was not present (I was loosing the root FS after aprox. 1 min after logging in remotely immediately after start). Restoring the image with ehci was a pain (not to mention the time spent trying to figure a way to revert the change safely, since bricking the machine was not out of the question - imagine loosing the FS while flashing the ram drive image).

I finally managed to revert the ehci enabled image and tried the workaround proposed in this gentoo BR. I tried 128 and now I am at 64 and I am still getting those resets; Still something good came out of this, I followed Michael Prokop's Use root=UUID on NSLU2 article and I think I have now a stable root file system just thanks to him.

Now I am stuck:


grep -E '(max_sect reset)' /var/log/syslog
Aug 3 07:02:27 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:27:38 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 08:38:43 ritter manual message: max_sectors was set to 128
Aug 3 08:55:25 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:31:47 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 09:54:11 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:09:32 ritter set_max_sectors: max_sectors was set to 128
Aug 3 10:15:27 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:24:24 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:38:12 ritter set_max_sectors: sda's max_sectors was set to 128
Aug 3 10:47:04 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 10:48:27 ritter set_max_sectors: sda's max_sectors was set to 64
Aug 3 11:04:36 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
Aug 3 11:06:16 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2
....
Aug 3 15:05:58 ritter kernel: usb 3-1: reset high speed USB device using ehci_hcd and address 2

Should I try setting to 32?

In case you're wondering, I am doing the setting with this script:

#!/bin/sh

MAX_SECTORS=64
DISK=$(ls -l grep 'uuid.* / ' /etc/fstab awk ' print $1; ' sed 's#.*/\(.*\)$#\1#' tr -d '[0-9]')

[ -z "$DISK" ] && logger -t 'set_max_sectors' "error: could not detect root disk" && exit

echo "$MAX_SECTORS" > /sys/block/$DISK/device/max_sectors
logger -t 'set_max_sectors' "$ DISK 's max_sectors was set to $ MAX_SECTORS "

exit 0


Dear (not at all) lazy web, what can I do to fix/workaround this issue? Any help would be gratly appreciated (personal mail or comments).

Note: I am reluctant to try the fix proposed in the last comment that claims to fix the issue since compiling an arm kernel natively is a pain and I would like to have an official kernel from Debian Etch, as I do now.

Say you have a virtual machine at one of the larger hosting companies. You're sharing a system with some unknown number of other users. Wouldn't it be nice to be able to chat with people from the other VMs on the machine? Assume that the hosting company doesn't particularly want you do to this; they prefer you don't know that the machine's CPU is split 30 ways and that you're migrated to a new, random machine every night at 3 am. I wonder how to accomplish this? The coolest hack would be to frob some kind of available on-machine data source that the other users could watch. This basically requires finding and exploiting a minor security hole, though. Maybe a centralised registry would be better, if there's some way to uniquely identify a given host machine from inside the VM. Focusing on xen, I think enough data is leaked to make this possible.

• /proc/cpuinfo
• uname -a
• /sys/hypervisor/compilation/*
• /sys/hypervisor/properties/*

This should at least narrow it down to a set of similar boxes at a given hosting company, and then you can start looking at the network..

---

On a not-unrelated note, this diversidial system is way cool. 300 baud via telnet! I especially like the use of an ipod as a tape drive for booting the Apple IIe.

Following many months of faff, today Katherine and I completed on a house in Castlerock. I say Katherine and I, but really I did very little. She started looking after she'd started at UU, before we knew Black Cat was going to be sold. My sole involvement was to be dragged round a few places (including this one) when I was back in April. The initial plan was that Norwich would remain our "home" and this would be somewhere that Katherine would be able to live during term time, that I could also work from now and then. Given recent events it'll no doubt become "home" and we'll leave Norwich. To that end I've been looking at the job market back in NI. I've found (and applied for) a few things in Belfast, all software development roles. I may even have an interview; had a phone call today that felt very much like a phone interview and ended with talk of getting a formal interview sorted for when I'm next over. All scary stuff. Belfast is a bit far for a commute, so I may end up living there during the week. Or I might not get anything in NI and have to look further afield. Anyone know anything going in Derry? That may be a more managable daily journey.