Search Results: "spa"

6 May 2010

Aigars Mahinovs: Going to Debconf10!

After a few months, today I finally got the approval and As I work for Accenture now, I got them to pay for the plane tickets and also spring for the Professional registration, so more people can attend. I am very happy, and very grateful to the company and to the managers here in Riga office for being so very supportive. It is refreshing to see that even a large corporation can be quite nimble. I hope I can get on a direct Riga New York flight (there actually is one, once a week, by Uzbekistan Airways) which would be a wicked cool way to save travel time and worries. This might even be faster end-to-end than last year going to Spain (via Frankfurt). Now I only need to replace my passport with the new biometric one, to qualify for USA Visa Waiver and I ll be good to go :)

Ian Wienand: How much slower is cross compiling to your own host?

The usual case for cross-compiling is that your target is so woefully slow and under-powered that you would be insane to do anything else. However, sometimes for one of the best reasons of all, "historical reasons", you might ship a 64-bit product but support building on 32-bit hosts, and thus cross-compile even on a very fast architecture like x86. How much does this cost, even though almost everyone is running the 32-bit cross-compiler on a modern 64-bit machine? To test, I got a a 32-bit cross and a 64-bit native x86_64 compiler and toolchain; in this case based on gcc-4.1.2 and binutils 2.17. I then did a allyesconfig build of Linux 2.6.33 x86_64 kernel 3 times using the cross compilier toolchain and then native one. The results (in seconds):
32-bit64-bit
60905684
60505616
60635652
average
60675650
So, all up, ~7% less by building your 64-bit code on a 64-bit machine with a 32-bit cross-compiler.

Andrew Pollock: [life] Crazy few days

Here's why: Zoe's birth Zoe Dianne Pollock was born at 12:30pm PDT, at Lucile Packard Children's Hospital, via Caesarean-section. Her birth weight was 2920 grams (6 lbs, 7 oz) and she's 49.5 centimetres (19.5 inches) long. As for why she was born 11 days early than her previously scheduled early arrival... Monday morning started off like any other normal Monday morning. I got up at 6am to go to the gym with Dan. I got home at around 8am. I asked Sarah if she'd felt any baby movement, and she said she hadn't. Even after some jiggling and a cold glass of orange juice, there was nothing. Not wanting a repeat performance of what happened last time, we wasted no time in heading to Labour and Delivery to get things checked out. When we were nearly at the hospital, Sarah felt some small movement, so that was a relief. When we got to the hospital, they performed a non-stress test as they have previously. They spent a good couple of hours with Sarah hooked up to the monitor, and then the on-call obstetrician asked us how we'd feel about just having the baby today. I asked if there was anything particularly concerning about the NST, and the OB said that she (the baby) was doing marvelously now, but was "less than marvelous" when we first came in. I haven't had a chance since to ask her if there was anything untoward observed during the delivery. Anyway, she (the on call OB) said that rather than have Sarah get stressed out for the following 11 days, she'd talked with our regular OB, and they felt that since she was at 37 weeks (and considered "full term") that it was okay to deliver at that point. At the end of the conversation, it was upgraded to a recommendation, rather than an option. So so much for an attempt at VBAC. We got to the hospital at around 9am, and I think they/we made the decision to deliver at about 10:30am. I had enough time to race home and grab the camera and race back again, and the next thing I knew we were all in the operating room, and Zoe was being delivered. It was amazing getting to see the "extraction". They dropped down the sheet that was blocking our view of the action right at the end, and I got to see (and photograph) Zoe's head and whole body being pulled out. She gave out a little cry, and Sarah and I totally lost it with relief. Things were a bit of a blur after that. I got to come over and meet Zoe while they were weighing her and measuring her, and then they bundled her up and let me take her back to Sarah's head-end on the operating table, so Sarah could get a look at her. Sarah handled this C-section better than last time. She didn't get any nausea, but she still got the itching and involuntary shivering, courtesy of the morphine. While they were still putting Sarah's insides back in, Zoe and I went to the nursery, where they put her under a heater for a little while to warm her up a bit. Then it was back to the recovery room to have a proper meeting with Sarah. Once Sarah was ready to move to the maternity ward, Zoe and I again returned to the nursery, where she got her first bath, had her umbilical cord trimmed some more, and her anti-theft device fitted to her umbilical cord clamp. Then it was off to the maternity ward. I think we were all in the maternity ward by 3pm. After a little while, we managed to get bumped to a private room, which was a lot better than the shared room (the other bed was vacant, but just having more space made a big difference), and that's where we've been ever since. I've stayed each night on the roll away bed, helping out with diaper (sorry Aussies, I've been here too long, and dealt with too many babies, I never think of them as "nappies" any more) changes, and burping and other miscellaneous tasks. Monday night was okay. Tuesday was a bit rough. Sarah didn't get any sleep on Monday night, and the anaesthesia totally wore off and she was in a fair bit of pain. She slept better on Tuesday night, and today, the breastfeeding has been going well, and the post-operative pain is well and truly under control. She's lost a bit of weight since delivery (as is to be expected). She was down to 5 lbs 14 oz (2664 grams) at last night's weigh-in, and at tonight's weigh-in she came in at 5 lbs 13 oz (2636 grams). So the weight loss is starting to plateau. We're already supplementing the breastfeeding with syringes of colostrum/milk that Sarah's pumped previously, so I hope the weight loss will have turned around by tomorrow night's weigh-in. The breastfeeding in general is going pretty well as of today. Mum and bub have both mastered the latch. I think it's just a matter of Sarah's milk coming in now. I've brought forward my 7 weeks paternity leave (an excellent benefit Google offers) to start as of Zoe's delivery. Sarah's Mum arrives on the 19th for 4 weeks, which will be great. We expect to be discharged from hospital on Friday. Luckily we were pretty much all ready for this happening a little bit earlier. We had our last baby classes on the weekend. The nursery is ready enough to bring a baby home to, so aside from Sarah's Mum being disappointed that Zoe's going to be a bit older when she first gets to see her, we're all good. The WiFi in the hospital is great. We've already Skyped with both grandmothers and they've had a chance to see Zoe. We've had a steady trickle of visitors, and the whole baby routine is making the time go pretty quickly.

5 May 2010

Alastair McKinstry: EGU 2010 - Monday afternoon

The EGU conference is packed, and this blog isn't anything remotely like real-time, but some interesting talks came up on Monday evening : Simon Katterhorn gave a neat presentarion on icy moon tectonics, specifically on Europa and Enceladus. He showed the cycloid tracks on Europa, and how these are probably generated by tidally-driven ice tectonics. The presence of these of different ages shows the existence of a global ocean underneath, and the decoupled ice shell on top. More on this can be seen in Greenbergs book on Europa; but he also showed further follow-on work on Enceladus. Enceladus is small enough that people thought it had cooled and could not support an ocean, explaining the geysers and plumes by "small reservoirs". He shows instead that the 'tiger stripes' at the south pole are also tidally-created stresses, and moreover older generations of stripes, at an angle to the current ones, are also present: the plumes occur at the intersections. This shows free rotation of the ice shell and almost certainly an ocean. As to how to heat it: tidal heating is the primary candidate. I'm looking forward to Tidal heating and orbital evolution of Enceladus on Thursday. Tags , , ,

4 May 2010

Chris Lamb: Rotating email into your inbox using imapfilter

I'm not a fan of "life hacks", but I have the adopted the following automated processing of my email inbox: if I don't want to deal with a message today, I move it to (eg.) Mail.DELAYED.4 and it will reappear in my inbox automatically in 4 days. It is inspired by the Inbox Zero, tickler files and the Debian DELAYED queue. My implementation uses imapfilter. You'll need to tweak the move_messages syntax for lenny's version; the following works fine in squeeze and sid: 
mbox = IMAP  
    server = 'mail.server.net',
    username = 'username',
    password = 'password',
    ssl = 'ssl3'
 
num = 14
dst = 'INBOX'
prefix = 'Mail.DELAYED.'
for x = num, 1, -1 do
    mbox[prefix .. x]:select_all():move_messages(
        mbox[x == 1 and dst or prefix .. (x - 1)]
    )
end
The messages are moved when I'm (hopefully) asleep: 
# m h dom mon dow command
  0 6 *   *   *   imapfilter -c /path/to/delayed.lua >/dev/null

Alastair McKinstry: EGU 2010 - Monday

I'm at the European Geosciences Union (EGU) General Assembly, 2010, the biggest gethering of European geoscientists, in Vienna, May 2-7. This is my first time here and its huge: over 9000 participants. Merely finding the talks and posters is a challenge (they supply a USB stick with the abstracts and agendas as they can't print them all! The first day I spent mostly at the exoplanet stream (and putting up my own poster). Some neat stuff on show: summaries by Borucki on Keplers findings (on the Hot Jupiters they found :" these things glow like a blast furnace; forget life"). He points out that when they look for Earth sized planets, radial velocity confirmation would take 1000s of hours on 10M telescopes - so it won't happen. hmm. Steve Unwin on SIM: neat astrometric mission for planet hunting and galaxy measurement. A targeted mission list, unlike the Gaia survey; to fly in 2016 if the Decadal survey says yes. 20% of time available under the general observer program, so get proposals ready ? Nestest poster idea: Anomalous night-time temps on Mars, Gonzales et al.. Finding hot spots on Arsia Mons, a volcano. Explained by air rising from 100km long lava tubes. We've seen pit entrances to caves on Mars with HiRISE, etc. here they model heat output from a pit entrace/exit and imply 100km caves. Oh to go exploring... Tinetti points out that we lack proper spectra, both experimental and theoretical, for high temperature and pressure gases such as methane, etc. Hmm, I know a group in Galway that might be able to help ... Helmut Lammer raised an interesting point at the poster session, that many groups ignore the stellar wind when looking at H2 atmospheres around exoplanets. Theis grossly inflates the apparent H2 atmosphere. Without taking this into acount it would be easy to mistake H2 detections with a Neptune-like atmosphere. He points to a 1.7M UV telescope that the Russians are planning to launch that would help do UV measurements when Hubble is gone. Lena Noack gave a talk on convection in tidally-locked planets (with related poster Low-lid formation on Super-Earths and implications for the habitability of Super-Earths and Sub-Earths). They argue that no covection can be expected in the mantle, and hence no geodynamo or magnetosphere. This could be a problem for holding an atmosphere. Time to check for planetary magnetic fields. Break out the polarimeter ? Oh, and it seems that That Damned Volcano is closing Irish airspace on Tuesday. Might be an idea to go to the meeting about it. Hope it clears by Friday ... Tags ,

Alastair McKinstry: EGU 2010 - Monday

I'm at the European Geosciences Union (EGU) General Assembly, 2010, the biggest gethering of European geoscientists, in Vienna, May 2-7. This is my first time here and its huge: over 9000 participants. Merely finding the talks and posters is a challenge (they supply a USB stick with the abstracts and agendas as they can't print them all! The first day I spent mostly at the exoplanet stream (and putting up my own poster). Some neat stuff on show: summaries by Borucki on Keplers findings (on the Hot Jupiters they found :" these things glow like a blast furnace; forget life"). He points out that when they look for Earth sized planets, radial velocity confirmation would take 1000s of hours on 10M telescopes - so it won't happen. hmm. Steve Unwin on SIM: neat astrometric mission for planet hunting and galaxy measurement. A targeted mission list, unlike the Gaia survey; to fly in 2016 if the Decadal survey says yes. 20% of time available under the general observer program, so get proposals ready ? Nestest poster idea: Anomalous night-time temps on Mars, Gonzales et al.. Finding hot spots on Arsia Mons, a volcano. Explained by air rising from 100km long lava tubes. We've seen pit entrances to caves on Mars with HiRISE, etc. here they model heat output from a pit entrace/exit and imply 100km caves. Oh to go exploring... Tinetti points out that we lack proper spectra, both experimental and theoretical, for high temperature and pressure gases such as methane, etc. Hmm, I know a group in Galway that might be able to help ... Helmut Lammer raised an interesting point at the poster session, that many groups ignore the stellar wind when looking at H2 atmospheres around exoplanets. Theis grossly inflates the apparent H2 atmosphere. Without taking this into acount it would be easy to mistake H2 detections with a Neptune-like atmosphere. He points to a 1.7M UV telescope that the Russians are planning to launch that would help do UV measurements when Hubble is gone. Lena Noack gave a talk on convection in tidally-locked planets (with related poster Low-lid formation on Super-Earths and implications for the habitability of Super-Earths and Sub-Earths). They argue that no covection can be expected in the mantle, and hence no geodynamo or magnetosphere. This could be a problem for holding an atmosphere. Time to check for planetary magnetic fields. Break out the polarimeter ? Oh, and it seems that That Damned Volcano is closing Irish airspace on Tuesday. Might be an idea to go to the meeting about it. Hope it clears by Friday ... Tags ,

3 May 2010

Matthew Garrett: PCI power management problems

I've previously written about some of the implementation details of runtime PCI power management. One of the key aspects for PCI devices is that the PME line on the device be able to generate a wakeup event. Unfortunately, it turns out that since Windows makes no use of this functionality at present, some vendors have started failing to wire this up. This is problematic because the device itself still announces PME support and will even raise a PME signal when it gets woken up - but it's pretty much screaming as hard as it can and nobody's listening because somebody's replaced the air with cheese.

Bother, etc.

The obvious question is what to do next. We could poll all the PCI devices every second or so to see if there's a PME status register that's been set. This would be reasonably cheap (we're going to wake up at least once a second on x86 anyway, so it makes no real difference to power consumption) but would introduce obvious latency in the wakeup path. This would be fine for certain types of situation (you're probably not going to be too sad if your SD reader takes a second longer to notice a card insertion) but not others (if an sdio wireless card generates a wakeup interrupt then we really ought to do something about it in a more sensible timeframe). A second is to force users to pass a boottime argument to enable this at all. That kind of sucks.

The third possibility is limited to a subset of hardware, but does allow the introduction of some kind of elegance into what would otherwise be one of those nightmarish scenarios that makes me consider taking up farming instead. If we can trigger a PME ourselves then we can test whether the line is connected. This doesn't appear to be possible on SDHCI but the spec for firewire makes it look like we can do it there - one of the interrupt sources is the port enable/disable register, and we can hit toggle that ourselves. I haven't actually tested this yet, but if it works that would let us make this determination.

It's depressing that doing anything interesting with power management is still heavily determined by what Microsoft have bothered to implement - to the extent that on some machines (hello, Thinkpads) there are no GPE methods at all for PME signals and you don't get runtime power management at all. The only thing that saves us is that (a) it's pretty hard to be able to screw up stuff that's already all glued into one chip package, so integrated stuff like USB should be fine anyway, and (b) PCIe does this as part of the normal traffic stream so there's no way to get that wrong. Unless you're still missing the GPE methods for the signals (hello, Thinkpads) in which case you get nothing unless the native PCIe signalling works. I suspect that we can always force that, so there's some hope yet.

In summary, then: dispassionate.

Christine Spang: Christine Spang: in case it wasn't already obvious

Mode of transportation has not yet been determined. Possibly bike, possibly train, possibly bus. It feels strange not needing to buy plane tickets. I should be there for all of the conference proper but not for DebCamp.

2 May 2010

Julien Blache: forked-daapd: now with AirTunes v2 streaming

I ve been working on this for a few months now; it s taken quite some time because I wanted to do it right and deliver something better than what already existed in the OpenSource world as far as that particular technology was (not) concerned. So here it is:

AirTunes v2 UDP streaming forked-daapd can now do streaming to multiple AirTunes devices (as well as the local soundcard) and can be controlled from Remote (and, ideally, from anything that speaks DACP). I m releasing this early while the paint is still wet and not everything works on the DACP-side of things. Case in point, while playing a song or an album is supported, playing a playlist isn t. There s some work needed on this particular feature, and it ll get there eventually. There have been a couple of other changes in the codebase in recent weeks too; details after the jump. Implementing AirTunes v2 has been quite fun and, in addition to releasing the forked-daapd code today, I ve also taken the time to write down my findings about the protocol so others can experiment with it. This documentation is by no means exhaustive nor complete as far as the protocol goes; if you find out anything I haven t, let me know so I can update this document. Let s review the recent changes in the forked-daapd codebase over the past few weeks. AirTunes v2 You can now use Remote from your iSomething together with your AirTunes devices and forked-daapd to listen to your library. As mentioned above, playing a playlist is not supported; I have a few things to sort out before this can work and I suspect this will bring changes not only to the DACP interface but also to other parts of the code. So, stay tuned. forked-daapd supports synchronized playback to multiple AirTunes devices together with the local soundcard if so desired. You can expect the AirTunes devices to be in sync with each other, but the soundcard will usually run in circles around them. It looks like AirTunes plays sound a bit slower than 44.1 kHz; not a big deal, though, as AirTunes will catch up periodically and the desync, while it can be noticeable, isn t big (ie we re not talking seconds, not even one full second). Make sure your network can handle the load, as streaming to a single AirTunes device requires in excess of 1.6 Mbps (1.8 Mbps is actually closer to the real thing). Local audio output is supported via ALSA and OSS4, although note that the OSS4 code hasn t been very well tested. I intend to test and debug it fully at a later date, but feel free to beat me to it and send patches. Also note that, while there is code for FreeBSD in the player/streaming part of forked-daapd, it doesn t work well at all. The streaming code needs a timer with a higher resolution than kqueue/kevent has to offer, and I haven t found anything as capable as timerfd. So it s there, but it s broken. Read on about FreeBSD support. Metadata scanning Several fixes and enhancements have been made to the filescanner so it picks more and better metadata. Format-specific tagnames have been added to work around ffmpeg s limitations. Using a recent enough ffmpeg version (anything after mid-december 2009) will work best, especially for MP3 files. SQLite concurrency fixes The database code has been reworked to handle concurrency on the database. Issues with locked tables (or the whole database) were noticed pretty easily with big libraries when accessing forked-daapd during the library update after startup. On uniprocessor machines, this was even easier to hit. This, however, comes with new requirements for SQLite3: you ll now need SQLite3 v3.5.0 at least and it must be built with the unlock notify API enabled. Not all distributions ship SQLite3 with the unlock notify API enabled, so you may need to do a rebuild. Debian, for instance, doesn t; this is #579266. A word about FreeBSD support I m giving up on FreeBSD support. The streaming code doesn t work on FreeBSD due to timer issues, and I don t intend to fix it. I also don t intend to invest much time in porting future features to FreeBSD; if I can make it work, then fine, otherwise, too bad. Someone needs to step up if there s interest in having forked-daapd work on FreeBSD.

1 May 2010

Filippo Giunchedi: how to ship spidermonkey in your autotools project

While working on freej we'd need to update spidermonkey/mozjs to the latest version and while doing that integrate it better with the rest of autoconf/automake. AFAICT spidermonkey/mozjs is distributed as part of XULRunner nowadays. The requirements are to make it easy to put a new version of spidermonkey into the tree and redistribute it with make dist and also to have a successful make distcheck. The first step is a trick explained in automake manual about third-party Makefiles so we're using a GNUMakefile.in (git) to "proxy" the targets down to the real Makefile or to ignore some targets called by autotools, e.g: 
# otherwise linking static libmozjs.a with dynamic libfreej.so won't work
CFLAGS += -fPIC
# the makefile to proxy targets to
js_makefile = $(builddir)/Makefile
# proxy these targets to the real makefile
all export js-config clean libs tools:
  $(MAKE) -f $(js_makefile) $(AM_MAKEFLAGS) $@
# targets required by autotools but which we don't need at all
.PHONY: dvi pdf ps info html installcheck check install uninstall
dvi pdf ps info html installcheck check install uninstall:
This more or less fixes the make part, now for the autoconf part there's a similar tecnique in the autoconf manual involving running arbitrary configuration commands. I first tried to treat spidermonkey as a separate project via AC_CONFIG_SUBDIRS as expained in Configuring Other Packages in Subdirectories but it didn't work and I forgot exactly why. The configure.ac (git) snippet is something like this: (sorry no highlighting, highlight doesn't support m4 yet) 
if test x$have_mozjs = xno   test x$static_mozjs = xyes; then
  dnl run lib/javascript/configure after freej's configure, building it static
  AC_CONFIG_COMMANDS([lib/javascript/.xulrunner-subdir],
    (cd lib/javascript &&
      CXXFLAGS="$GLOBAL_CFLAGS $CXXFLAGS -fPIC" \
      CFLAGS="$GLOBAL_CFLAGS $CFLAGS -fPIC" \
      $ac_srcdir/configure --enable-static \
        --enable-js-static-build --disable-jit)   exit $?
  ])
fi
This will run spidermonkey configure after the main configure, at this point config.status will also expand GNUmakefile.in into GNUmakefile with the correct variables. The final step after all this work is of course to add the spidermonkey directory to SUBDIRS (e.g. SUBDIRS += lib/javascript), after that make will hopefully recurse into lib/javascript and use our GNUmakefile. While this is nice it doesn't cater for the make dist family of autotools targets which build the real distribution tarball. To accomplish this I've used an explicit list of spidermonkey files that will end up in the tarball and made make distdir to copy only those files plus GNUmakefile.in and the list itself (.js-distfiles). Which is the second part of the GNUmakefile.in above, i.e. distdir/distfiles targets plus distclean to clean them up, see comments in the file as well. I hope this is somewhat useful to people who are trying to properly (autotools-wise) ship spidermonkey in their project, comments welcome as usual :)

Sean Finney: Nouveau, Gallium3D, and Compiz on Debian

update: 20100503: It's been brought to my attention that there might have been a regression in one of the libraries, mesa, maybe, so that master might not be as reliable a reference point for this guide. so, just in case, here are the commit hashes that were used from the different projects: for the non-git-savvy: git checkout -b mybranch <hash> we now return to your regular broadcasting... A week or two ago I figured it was about time that I took the plung and tried out the latest nouveau drivers from experimental on my laptop. Unfortunately, it meant bidding adieu to compiz (apart from the bling it does actually provide some pretty damned useful features). I thought I'd give it a shot at least for a while on principal, since I've always had to think of the nvidia drivers as a necessary evil, and their lack of proper xrandr support is really, really annoying. Since then I haven't noticed any problems, apart from the following message after every suspend/resume: 
[  931.213239] Uhhuh. NMI received for unknown reason 80 on CPU 0.
[  931.213240] You have some hardware problem, likely on the PCI bus.
[  931.213242] Dazed and confused, but trying to continue
No idea what's causing it, but otherwise the system is stable and functional. If anyone knows what can be done about this, I'd appreciate hearing from you. My graphics card, by the way: 
01:00.0 VGA compatible controller: nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300] (rev a1)
In the time since then, the nouveau driver has made its way into unstable, and a lot of distros (ubuntu, fedora, ...) are even using it as the default driver. So before going any further with the 3d/compiz stuff, I highly recommend that you get the packaged version working first. This will not only make sure that the basic driver works, but it will also make recovery/rollback a lot easier. Since it's all packaged in the standard repositories, it's not much harder than installing a few packages and editing a few files... so come on give it a try :) Getting the 2d driver working in Debian sid Really, this is so easy it's hardly worth writing up, but i'm running with the -v flag this morning... Make sure you don't have any reference to nvidia in /etc/modules or other places that might cause it to be automatically loaded. Then remove the proprietary glx bindings, which would otherwise interfere with the nouveau driver. 
sudo apt-get remove nvidia-glx
Next, you'll need to install a kernel that includes updated drm support. Normally this would require a kernel >= 2.6.33.1, but the debian kernel maintainers have graciously backported this code to the 2.6.32-4 kernel package. note this isn't the default kernel version in testing/unstable at the time of writing so you have to explicitly install it along with the nouveau driver. 
sudo apt-get install linux-image-2.6.32-4-amd64 xserver-xorg-video-nouveau
If you are already running this kernel and using the proprietary nvidia drivers, via module-assistant or otherwise, you /might/ need to uninstall them first. On my system I left them installed in the old kernel version but did not install them on the new kernel version. Required xorg configuration I don't believe that nouveau is picked by default if available at the time of writing, so you have to have the following in your xorg.conf: 
sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Device"
    Identifier     "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
    Driver         "nouveau"
EndSection
EOF
This was all I needed to do, apart from rebooting into the new kernel. For those who don't want to venture outside the packaging system, this is about as far as you can go for the time being. Though really, if you're bothering to read this far along, you're probably more interested in what comes next :) Getting 3d working (without voiding your distro warranty) So I thought I'd give the 3d-accelerated gallium a go. Their wiki page certainly makes one think twice, but at this point I was seriously fiending to get my bling back (well, the compiz scale plugin, anyway) and figured it wouldn't hurt too much to try. Via google and trawling around in various forums I found a number of how-to documents for getting Gallium3d on debian/ubuntu systems, but most of them recommended doing things in a way that wasn't easily reversible and that could totally hose your system in a not-so-hypothetical worst-case scenario. It's pretty hard to roll back a make install done into /usr, for example, and subsequent package upgrades can leave your system even worse off as they will probably clobber half of what you just did, leaving the other half totally broken. And if you have a laptop which requires the gui for networking (i.e. network-manager), then fixing/rolling-back the changes is not entirely trivial, since you'd likely have to re-download the various drm/mesa/xorg packages. So enter the tried and true unix utility stow (apt-get install stow, of course). stow is a utility that lets you install software into arbitrary folders, and then manage the system-wide installation of the software via a farm of symlinks pointing at the installed location. It's probably more well known among the sysadmin crowd than the desktop user crowd, but it's incredibly useful for the task at hand as it will let us easily install multiple copies of different software in a way that's very easy to update and/or roll-back. RTFM stow(1) for more information. So, on to the juicy stuff... Install needed software, remove problematic packages, setup, etc At least on my system, I had to remove libdrm-dev to keep things from accidentally linking against it instead of the updated version that we install later on below. There's probably a way to override this with CFLAGS but I figure this is simpler. 
sudo apt-get remove libdrm-dev
sudo apt-get install stow build-essential xorg-dev git-core libtool mesa-common-dev automake autoconf 
mkdir ~/nouveau
Compile a linux-2.6.34 RC kernel 
cd ~/nouveau
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f nouveau git://anongit.freedesktop.org/nouveau/linux-2.6
git checkout -b nouveau-master nouveau/master
make menuconfig
Enable device drivers -> staging drivers -> nouveau. Make any other changes you might want to make (I just took defaults for everything else). 
make deb-pkg
The linux-firmware-free debian package ships some of the same stuff from the generated linux-firmware-image package. I decided to opt for the upstream firmware, though I'm not sure that this is necessary: 
sudo apt-get remove linux-firmware-free
sudo dpkg -i ~/nouveau/linux-image*.deb ~/nouveau/linux-firmware-image*.deb
sudo update-grub
Install a copy of dri2proto 
cd ~/nouveau
git clone git://anongit.freedesktop.org/xorg/proto/dri2proto
cd dri2proto
./autogen.sh --prefix=/usr/local/stow/dri2proto-20100428
sudo mkdir -p /usr/local/stow/dri2proto-20100428
sudo make install
sudo stow -d /usr/local/stow dri2proto-20100428
Install a cutting-edge version of libdrm 
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/drm/
cd drm
./autogen.sh --prefix=/usr/local/stow/drm-20100428 --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-20100428
sudo make install
sudo stow  -d /usr/local/stow  drm-20100428
Likewise for mesa 
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/mesa/mesa
cd mesa
./autogen.sh --prefix=/usr/local/stow/mesa-20100428  --enable-debug --enable-glx-tls --disable-asm --with-dri-drivers= --enable-gallium-nouveau --disable-gallium-intel --disable-gallium-radeon --disable-gallium-svga --with-state-trackers=glx,dri --with-demos=xdemos,demos,trivial,tests
make
sudo mkdir -p /usr/local/stow/mesa-20100428 
sudo make install
sudo stow -d /usr/local/stow mesa-20100428
And now the xorg driver... 
cd ~/nouveau
git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/
cd xf86-video-nouveau
./autogen.sh --prefix=/usr/local/stow/xf86-video-nouveau-20100428
make
sudo mkdir -p /usr/local/stow/xf86-video-nouveau-20100428
sudo make install
sudo stow -d /usr/local/stow xf86-video-nouveau-20100428
Configuration Configure xorg to look in alternate location for xorg modules and set up DRI 
sudo sh -c "cat > /etc/X11/xorg.conf" << EOF
Section "Files"
    ModulePath "/usr/local/lib/xorg/modules,/usr/lib/xorg/modules"
EndSection
Section "ServerFlags"
    Option "GlxVisuals" "all"
Endsection
Section "Device"
    Identifier     "nVidia Corporation G72M [Quadro NVS 110M/GeForce Go 7300]"
    Driver         "nouveau"
EndSection
EOF
I've /heard/ that disabling TV out is a necessity on some cards, though I haven't seen this myself: 
sudo sh -c "cat > /etc/modprobe.d/nouveau.conf" << EOF
# not entirely sure this is necessary, but heard it helped with vsync
options nouveau tv_disable=1
EOF
Finally, the one thing that can not be done in /usr/local is making the nouveau DRI driver available. From what I could tell the path that mesa uses to find the DRI libraries is hard-coded (corrections welcome). Since you won't already have this file (otherwise, why would you be following along here?), just drop in a symlink to the file in /usr/local: 
sudo ln -s /usr/local/lib/dri/nouveau_dri.so /usr/lib/dri/
Finally, reboot, and hope for the best :) Riding the bleeding edge: how to upgrade later on Again, stow really shows its usefullness here. Using drm as an example case, upgrading an individual component would look something like: 
cd ~/nouveau/drm
git clean -dfx
git pull
today= date +%Y%m%d 
./autogen.sh --prefix=/usr/local/stow/drm-$today --disable-intel --disable-radeon --enable-nouveau-experimental-api
make
sudo mkdir -p /usr/local/stow/drm-$today
sudo make install
sudo stow -d /usr/local/stow -D drm-20100428
sudo stow -d /usr/local/stow  drm-$today
Note how the old version is still installed, so you can switch components around pretty freely. Abort! Abort!: How to roll back changes In case your system becomes totally unusable, or you've decided that you just want to go back to the safe and cozy world of what's provided by the debian packages, simply do the following: Assuming that you're using the nouveau driver from unstable, this should be all that is necessary. Conclusion Overall impression I am very, very happy with the resulting setup. I was led to believe that this whole thing was much more unstable and unusable than it actually is! While there are certainly some glitches and missing features, I feel comfortable enough using it that I don't have plans to switch back. But if I find myself in a situation where I can't use the new setup, rolling back shouldn't be a problem either. I figure I'm happy with what I have now and it will only get better. What works, at least to a "kinda works" level. What still doesn't work Further reading, references Thanks A couple shoutouts to those who helped me with this on the way: Feedback / Corrections Unforunately, I've had to disable comments for the time being due to overwhelming quantities of spam. So please drop me a line via email or on IRC (seanius on oftc/freenode).

Russell Coker: Marshmallow Challenge for Linux Programmers

Tom Wujec gave an interesting TED talk about training people in team-work and engineering through building the tallest possible structures from 20 pieces of spaghetti, 1 yard of string, and 1 yard of sticky-tape with a time limit of 18 minutes [1]. The project is completed by groups of four people which is probably about the maximum number of hands that you could have on such a small structure at one time. They have a web site MarshmallowChallenge.com/ which gives some suggestions for conducting a challenge. One interesting point made in the talk is that kindergarten students tend to do better than most adults. I think it would be good to have such challenges at events such as Linux conferences. The type of people who attend such conferences tend to enjoy such challenges, and it may lead to some lessons in team-work that can help the software development process. Also we can discover whether Linux programmers are better than the typical kindergarten students. ;)

30 April 2010

Biella Coleman: Baby Panda wants YOU to submit to DEBCONF



bad mood destroyer, originally uploaded by the biella.
People s the deadline is fast approaching. Don t worry though, the best ideas come under deadlines and your proposal need not be lengthy. So get those typing hands out and submit a proposal (a few sentences suffices) for a presentation! The annual Debian conference is being held in NYC this year. First time
setting foot in the imperial empire. Are you doing something related to
free software that might be interesting to share, show off or talk about
at Debconf? I bet you are! We are looking for art installations,
performances, movie screenings, maybe you are wanting to host a
roundtable/panel discussion, coordinate a workshop (you dont have to
know the subject deeply to do this!). I know the deadline is soon, but don t let that scare you. The
submission requirement bar is very low, and we are flexible! here is the submission information: [1] ********************* Calling all potential contributors to DebConf10! One more week until
the final submission deadline! The DebConf team is excited to announce that we are now accepting
proposals for contributions to this year s Debian conference! We
invite you to submit proposals for how you would contribute until the
deadline: soon There are many ways you can contribute, you could present a technical
paper, host a panel discussion, put on a tutorial, do a performance,
an art installation, a debate, host a meeting (BoFS, or Birds of a
Feather Session), or other possibilities that you devise. This year we
are also accepting proposals for tracks=E2=80=94a thematic grouping around a
particular subject, and people to coordinate those tracks. If you are
looking for ideas of things that you could contribute, or have ideas
for things that you would like to see happen at DebConf, have a look
at the Contribution Brainstorm[0] page. DebConf talks will be broadcast live on the Internet where possible,
unless otherwise requested. Videos of the talks will be published on
the web along with the presentation slides and papers. =3D=3D Step 1. Submit Proposal =3D=3D Proposals should provide an overview of your proposed contribution,
similar to an abstract, and be no more than 600 words. Since
contributions can cover a range of issues, please describe what your
proposal covers, be it political (Free Software, law, advocacy,
access, etc.), technical (d-i, OpenPGP, etc.), social (Debian
structures and groups). It s okay to hit all three of these. Your
proposal should also include some information on why you re qualified
to present, or coordinate this topic. For example, you can include
links to posts you have made to Debian mailing lists or other material
that indicates your qualifications. Proposals and their abstracts will
be accepted until May 1st, 2010, 23h59 UTC. To submit your proposal, go to Penta[1] and register as an
attendee. Once you are registered, there is a Submit a proposal
link. You will see your proposal on the site. You can choose between
different presentation types. If you are unsure what type you should
use, please read our glossary of definitions[2]. If it s not there for
some reason, or you have questions, please contact us immediately at
mailto:talks@debconf.org. =3D=3D Step 2. Committee Review =3D=3D The review committee for this year will make its decision by May 1st,
2010. All correspondence will be done by email. =3D=3D Step 3. Paper Submission =3D=3D Like last year, we are asking for papers to be submitted along with
the presentations. A full paper is optional, however we strongly
encourage you to submit one if possible as we intend to provide
written information along with transcripts of the sessions for later
viewing. Having written papers in advance will allow us to get
translations done to help non-native-English speakers feel more
comfortable with the topics presented. Papers are due by July 1st,
2010, and should cover the topic in reasonable depth (3 pages A4 text,
plus pictures and diagrams). We will use LaTeX to typeset the
proceedings. Please submit your paper formatted in LaTeX. Should you
be unfamiliar with LaTeX earlier submission in plain text is also
fine. =3D=3D Step 4. Live Presentation =3D=3D Longer presentations may have a break in the middle and should include
workshop items that directly involve the participants. If using slides
or any other presentation, please consider that your audience will
consist of people who use free software, and your choice of
application to prepare and display the slides should reflect this if
at all possible. =3D=3D Fine Print Publication Rights =3D=3D DebConf requires non-exclusive publication rights to papers,
presentations, and any additional handouts or audio/visual materials
used in conjunction with the presentation. The authors have the
freedom to pick a DFSG-free license for the papers themselves and
retain all copyrights. The presentations will be recorded, and may be
broadcast over the Internet. Any copies of the presentation will be
made available =3D=3D Failure to Submit =3D=3D In the event that a deadline is missed we reserve the right to revoke
any offer to present. =3D=3D About DebConf =3D=3D The annual DebConf conference is a technical and social forum for
Debian developers, sponsors, affiliates, and friends. It allows
various groups within Debian a chance to come together, network, and
share their work. Until we see you in the big city,
DebConf Talks Team [1] introduction written by Micah Anderson

Matt Brubeck: Fennec on Android: user feedback and next steps

Last month I joined Mozilla as a UI engineer on the Fennec (Mobile Firefox) project. Firefox is already available for Nokia's Maemo platform, and now a group of Mozilla programmers are porting it to Google's Android OS. This Tuesday they made an early preview build available for public feedback. Until now, the only people working on Firefox for Android were platform developers getting the back-end code to build and run. This week was the first time most other people including me got to try it out. We front-end developers and designers are now starting to adapt the user interface to Android. (The preview build used the look and feel of Firefox for Maemo, designed for rather different hardware and software.) Because we are an open source project, we like to share our work and hear your feedback even at this early stage of development. While I wasn't directly involved in the Android development effort, I spent some of my spare time this week talking to users via Twitter and our Android feedback group. Here's what I heard, in rough order of importance to users, plus some information on our future plans.1 We don't have a regular schedule yet for releasing new builds on Android. Once we get the code merged and automated build servers configured, we'll publish nightly builds of Firefox for Android alongside our Maemo and desktop nightlies. Later this year we will have alpha and beta versions, and hopefully a stable release. Until then, you can follow @MozMobile or Vlad (@vvuk) to hear about any new previews.
  1. Please remember I am still new to the project, and cannot speak for the whole team. This is a personal blog, not a Firefox roadmap!

28 April 2010

John Goerzen: Download A Piece of Internet History

Back in the early 1990s, before there was a World Wide Web, there was the Internet Gopher. It was a distributed information system in the same sense as the web, but didn t use hypertext and was text-based. Gopher was popular back then, as it made it easy to hop from one server to the next in a way that FTP didn t. Gopher has hung on over the years, and is still clinging to life in a way. Back in 2007, I was disturbed at the number of old famous Gopher servers that had disappeared off the Internet without a trace. Some of these used to be known by most users of the Internet in the early 90s. To my knowledge, no archive of this data existed. Nobody like archive.org had ever attempted to save Gopherspace. So I decided I would. I wrote Gopherbot, a spidering archiver for Gopherspace. I ran it in June 2007, and saved off all the documents and sites it could find. That saved 40GB of data, or about 780,000 documents. Since that time, more servers have died. To my knowledge, this is the only comprehensive archive there is of what Gopherspace was like. (Another person is working on a new 2010 archive run, which I m guessing will find some new documents but turn up fewer overall than 2007 did.) When this was done, I compressed the archive with tar and bzip2 and split it out to 4 DVDs and mailed copies to a few people in the Gopher community. Recently, we ve noted that hard disk failures have hobbled a few actually maintained Gopher sites, so I read this archive back in and posted it on BitTorrent. If you d like to own a piece of Internet history, download the torrent file and go to town (and please stick around to seed if you can). This is 15GB compressed, and also includes a rare video interview with two of the founders of Gopher. There are some plans to potentially host this archive publicly in the manner of archive.org; we ll have to wait and see if anything comes of it. Finally, I have tried to find a place willing to be a permanent host of this data, and to date have struck out. If anybody knows of such a place, please get in touch. I regret that so many Gopher sites disappeared before 2007, but life is what it is, and this is the best snapshot of the old Gopherspace that I m aware of and would like to make sure that this piece of history is preserved.

Brandon Holtsclaw: Kansas City Ubuntu 10.04 Lucid Release Party Update

Only one more day until release and a few more until the Kansas City Ubuntu Release Party.

I have updated this page with all the needed details ( even has a section to RSVP if you wish to be counted )

A Huge thanks got out to the great people over at Cowtown Computer Congress Hackerspace for offering to Host the event! Should be a great time.

Ingo Juergensmann: Comment Spam on Planet Debian

It always happen that I get lots and lots of comment spam via Planet Debian everytime I post something here. It's always the same sort of spam: trackbacks/pingbacks to some strange sites:



Is there anything that can be done? I'm quite sure I'm not the only one with that problem.

27 April 2010

Matthew Garrett: Radeon reclocking

Alex released another set of Radeon power management patches over the weekend, and I've been adding my own code on top of that (Alex's patches go on top of drm-next, mine go on top of there). I've left it stress-testing for a couple of hours without it falling over, which tells me that it's stable enough that I can feel smug. This is a pleasing counterpoint to the previous experiences I've been having, which have been rife with a heady mixture of chip lockups or kernel deadlocks. It turns out that gpus are hard.

There's a few things you need to know about gpus. The first is that if they're discrete devices they typically have their own memory controller and video memory. The second is that there's an impressive number of ways that you can end up touching that memory. The third is that they tend to get upset if something tries to touch that memory and the memory controller is in the middle of reclocking at the time.

The first and most obvious use of video memory is by the gpu itself. Accelerated operations on radeon are carried out by sending a command packet to the command processor. This is achieved by sharing a ring buffer between the cpu and the gpu, with the gpu reading packets out of that ring buffer and performing the operations contained within them. Many of these operations will touch video memory (that being the nature of most things you want a gpu to do), and if that happens bad things occur. Like the card locking up and potentially taking your PCI bus with it.

So, obviously, we don't want that to happen. The first thing we do is take a mutex that blocks any further accelerated operations from being submitted by userspace. Then we wait until we get an interrupt from the gpu telling us that the display engine has gone idle. The problem here is that we don't have a terribly good idea of how many more operations there are to complete and we don't know how long each of those operations is going to take, but this is less bad than some of the alternatives[1]. Jerome Glisse has some ideas on how to improve this to require less waiting, but the effects should still be pretty much invisible to the average user.

So we've stopped the command processor touching ram. Everything's good, right?

Well, not really. The obvious problem is that users typically want to display something, so there's a separate chunk of chip that's repeatedly copying video memory over to your monitor. That's got to go too. Thankfully, there's a convenient bit in the crtc registers that lets us turn that off, but the pretty unsurprising downside is that your screen goes blank while that's happening. So we don't want to do that. Instead, we try to perform the reclock while there's nothing being displayed on the screen - that is, while we're in the screen region where a crt's electron gun would be scanning back from the bottom of the screen to the top. It turns out that rather a lot of display assumptions depend on this happening even if there's no crt, no electron gun and no thick sheet of glass with a decent approximation of vacuum behind it, so we get to do this even if we're displaying to an LVDS. And we have about 400-500 microseconds to do it - an almost generous amount of time.

So we ask the hardware to generate an interrupt when we enter vblank and then we reclock. Except the hardware has an irritating habit of lying - sometimes we get the interrupt a line or two before vblank, sometimes we get it after we've already gone out the other side. Vexing, and not entirely solved yet - so sometimes you'll still get a single blank frame during reclock. But there are plans, and they'll probably even work.

At this point the acceleration hardware isn't touching the memory and the scanout hardware isn't touching the memory. Except it still crashes under some workloads. This one took me longer to track down, but the answer turned out to be pretty straightforward. Not all operations are accelerated. When they're not accelerated they have to be done in software. That means that the CPU has to write to the video memory itself. I'm sure you can see where this is going. This was fixed without too much trouble once I'd finished picking through the driver to work out every location where objects might be mapped into the CPU's address space, at which point it's a simple matter of unmapping them and blocking the fault handler from remapping them until the reclock is finished. Linux, thankfully, has lots of synchronisation primitives. And now everything works.

Except when it doesn't. This took a final period of head scratching, followed by the discovery that ttm (the memory allocator used by radeon) has a background thread that would occasionally fire to clean up objects. And by clean up objects, I mean change their mapping - which means updating their status in the gart, which means touching video memory. So, let's block that. And that tripped me off to the fact that even if it couldn't submit new commands, the CPU could still create or destroy objects - with the same consequences.

So, once all of these are blocked, video memory is quiescent and we can do what we want. And we do, at least once I'd sorted out the bits where I was taking locks in the wrong order and deadlocking. Depending on the powerplay tables available on your card we'll chose different rates and so your power savings will vary heavily depending on the values that your vendor provided, but the card I'm testing on sees a handy 30W drop at idle. Right now we're only changing clocks and not dropping voltage so there's potentially a little more to come.

While getting this stable was pretty miserable, the documented entry points for clock changing made a lot of this easier than it would otherwise have been. It's also probably worth noting that Intel's clock configuration registers are entirely missing from any public documentation and the dirver Intel submitted to make them work in their latest chips appeared to have been deliberately obfuscated, so thanks to AMD for making all of this possible.

[1] It's possible to insert various command packets that either indicate when they've passed or stall until a register value gets updated, but these either cause awkward problems with the cp locking or mean that the gui idle functionality never goes idle, so they're not ideal either.

Sylvain Le Gall: 32 year old

... or as some fellow DD said, one year ago: "j'ai 1000 ans". So what happened during last year, the DVCS way: 
$> cd "Sylvain Le Gall"
$> darcs whatsnew
hunk life.txt 0
+ Yvain, my son, talks and walks, this is quite amazing to see your
+ child growing up.  My wife is pregnant, release expected in July
+ ;-)
+ 
+ I traveled quite a lot this year: Spain, Tunisia, Belgium,
+ Roscoff and Huelgoat (Brittany) 
hunk debian.txt 0
+ I went to Debconf 9 and attended Debcamp before. I met a lot of
+ very interesting people there. I spent the Debcamp time to
+ implement Zack proposal to compute OCaml package dependencies
+ using dh-ocaml. It WORKS ;-) It was a pleasure to work with Mehdi
+ Dogguy and Stephane Glondu on this subject.
+ 
+ The dh-ocaml work allowed me to be the co-author, with Stephane
+ and Mehdi, of Zack's article on the subject. 
+ My first publication!
+ 
+ I went to FOSDEM 2010 and helped attend the Debian booth. Quite a
+ nice experience I was there with my good old Open Brick NG (need
+ to blog about it one day).
+ 
+ Found some time to enable the LLVM OCaml bindings in LLVM Debian
+ package.
+ 
+ Voted for the first  OCaml-aware DPL! (NB: this was not the
+ reason for my vote)
hunk work.txt 0
+ I worked on extending a tool that I delivered before. OCaml is
+ quite a good language when it comes to do maintenance. You can
+ extend something and have dozens of compiler errors where your
+ changes propagate. Once every error has been corrected, your
+ changes are OK. Of course, this requires to use OCaml types,
+ pattern matching and a bit of unit testing.
+ 
+ I was delighted when Jun Furuse ask me if he can organize 
+ OCaml Meeting 2010 in Japan. The first OCaml Meeting spin-off. 
+ 
+ OASIS has been growing quite a lot since the year before and got
+ enough importance. Thus I decided to give a talk about it at CAML
+ Consortium in December and then at OCaml Meeting 2010. 
+ 
+ I decided to have some English training. I was missing some oral
+ fluency.
+ 
+ I organized the OCaml Meeting 2010 in April. It was quite a lot
+ of work, especially to prepare my own presentation, but the
+ meeting was a success and probably my best birthday gift with the
+ OCaml Hacking Day organized just after.
$> darcs record -a
What is the patch name? "32 year old"
Unfortunately, this release is late. My birthday was on April 16th, but it was OCaml Meeting this day, which was my top level priority at this time. See you next year!

Next.

Previous.