Search Results: "reg"

2 May 2010

Dominique Dumont: Config-Model related project for GSoC 2010

Hello It s official: I m going to mentor a project related to config-model (without forgetting Augeas which might also be involved) this year:

Content-aware Config Files Upgrading
by Krzysztof Tyszecki, mentored by Dominique Dumont When a package deliver configuration files, the problem of merging user data with new configuration instructions will arise during package upgrades on users systems. Sometimes merging can be done with 3 way merge, but this process does not insure that the resulting file is correct or even legal. This project intends to create standards,
tools and heuristics to make the scary config file conflict resolution debconf prompt a thing of the past.
This project is hosted by Debian organization. Since this project might interest a lot of people, I will (try to) blog regularly on progress, issues, ideas.

From you people, I d like feedback and more importantly, I d like to get real life use cases.

What are the configuration upgrade scenario that bothered you ? What was your configuration file ? What was the setup done by package maintainer ? What result did you get ? What result did you expected to get ?

All the best


1 May 2010

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).

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

Michael Banck: 30 Apr 2010

Science Track at Debconf10 This year's Debconf will probably have for the first time tracks pertaining to certain subjects. One of the proposed tracks will be "Math and Science and Debian" and I was asked to organize it. We have some talk proposals already, and we will have a panel discussion about Debian science packaging between the major contributors of the various packaging teams, but more talks are welome! Talks could be about science with/on Debian, or Debian development in scientific fields. Additionally, I would like to encourage contributions on three types of topics: Full length talks are not required, we could split up each topic among a number of people depending on interest and submissions. Talks can be officially submitted until the end of tomorrow (Saturday May 1st, 23h59 UTC), but even afterwards, if you plan to go to Debconf and would like to give a talk about Math, Science and Debian, please contact me and we will see what can be done. Especially contributions to the three topics above can be made later as the events will be registered already.

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.

Andrew Pollock: [life] 17 days

Getting close now. Sarah had another ultrasound yesterday, just to check things. Unfortunately I couldn't be there due to a self-inflicted scheduling screw up. Apparently you could see hair on the ultrasound, so I'm a bit bummed to have missed it. The baby has "dropped", so that's good. Her head's still down, and she's swallowing, so that's all good too. Weight-wise she's now in the 38th percentile. We're booked in for a C-section on the 14th, unless she comes of her own free will between now and then (which is what we'd prefer), in which case our OB will allow an attempt at a VBAC. Our OB is reluctant to allow the pregnancy to go past 39 weeks, given prior history and Sarah's heart, and they don't induce for VBACs, so it's going to require some planetary alignment to avoid a C-section. The whole heart thing still being an issue was only a fairly recent discovery for us. Sarah's cardiac surgeon had told us we could go forth and have as many kids as we wanted, but it turns out the fine print in that statement is that while the previous aneurysm has been repaired, she has an undiagnosed connective tissue disorder, so there's no telling what might happen with the rest of her aorta in the future. So her OB is just doing what a good high-risk OB should do, and being extra paranoid, on two fronts. So we've got a couple of weeks to try and convince our daughter to come more than a week and 2 days early. I don't think we have statistics on our side, unfortunately (although I had a surprisingly hard time finding concrete statistics on delivery dates relative to due dates for first-time deliveries versus subsequent deliveries).

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!

Phil Hands: The rise of the Clan MacDebian

I've asked the weavers to start doing their job today, so with luck the tailors will still have time to make kilts ready to wear for DebConf10.If you've been wondering if you'd like some Debian Tartan, now's your chance. We've ordered a little over 16 yards more than we need, which will be enough to make about 2 extra kilts and a few ties (depending on exact details), so order early to avoid disappointment.Of course, kilts are not the only thing one can make out of tartan. The tailors make other things, but there's nothing stopping you from buying some cloth by the yard and being inventive (it costs about 25.00 GBP per yard). We'll also be making ties, so if you're interested in one of those, please add yourself to the relevant table on the wiki, and I'll get in touch with prices etc.Full details of this silliness are available on the wiki page -- send any questions to phil at hands dot comUpdate 16:00 UTC 27th: one 8-yard kilt snapped up already (numbers above updated)

Diego Escalante Urrelo: Summer lessons

Over the last few months I ve been working for Igalia, as an intern, fixing regressions in Epiphany, which extends to WebKitGTK+ sometimes. Surely a dream job: working on my favourite projects, on a great company, surrounded by great teammates and friends. Igalia: Free Software Engineering I m happy about it, really really happy. I love this job, totally, completely!. I ve had the chance to learn a lot. Here I d like to share some things I have learned so far, I look forward to post again with more ideas, but meanwhile here you have two. Different timezones are hard The time when I find most of the Igalia crew online is between 2am and 12pm. Of course this doesn t mean you can t find them past 12pm, but it s already 7pm or 8pm in Europe then. I m on UTC-5 and Spain is on UTC+1 or (now) UTC+2. You probably agree that asking anyone to wake up at 7am in summer is unrealistic. Luckily, Igalia doesn t make me pass a turing test everyday at a fixed time. This rocks.

valpo
Valpara so, Chile I love it when people understand that a happy hacker working at midnight is better than an unhappy hacker working on a set in stone schedule. Kudos to Igalia for that. Your code should explain and defend itself My written expression teacher says Your text should be good enough to explain and defend itself . This applies to code too. I confirmed this at the expense of Xan s patience. It s a common situation: when the maintainer reviews your patch you are not around to explain it, or present the rationale you put into the change. The solution? well, simple, your patch and commit log should explain by themselves.

Felix, chillin
Don t just post a patch and do this.
Review it yourself. I saw, after realising how much ping-pong Xan and I had to play to get a patch in, that my patches lacked a harder review by myself before being posted. You have to be your first reviewer. Be a severe judge of your patch, ask yourself if you would accept such a patch, if you would like a commit message like that, if that variable name is really good, if someone could quickly grasp what s it all about, etc. Get into the flippy flops of the maintainer, don t assume everything is obvious to everyone.

Dirk Eddelbuettel: R Project and Google Summer of Code: Welcome to our students!

A few hours ago, I sent the following to both the R development list and the informal R / GSoC list: 
Date: Mon, 26 Apr 2010 15:27:29 -0500
To: R Development List <r-devel>
CC: gsoc-r <gsoc-r>
Subject: R and the Google Summer of Code 2010 -- Please welcome our new students!
From: Dirk Eddelbuettel <edd>
Earlier today Google finalised student / mentor pairings and allocations for
the Google Summer of Code 2010 (GSoC 2010).  The R Project is happy to
announce that the following students have been accepted:
   Colin Rundel, "rgeos - an R wrapper for GEOS", mentored by Roger Bivand of
      the Norges Handelshoyskole, Norway
   Ian Fellows, "A GUI for Graphics using ggplot2 and Deducer", mentored by
      Hadley Wickham of Rice University, USA
   Chidambaram Annamalai, "rdx - Automatic Differentiation in R", mentored by
      John Nash of University of Ottawa, Canada
   Yasuhisa Yoshida, "NoSQL interface for R", mentored by Dirk Eddelbuettel,
      Chicago, USA
   Felix Schoenbrodt, "Social Relations Analyses in R", mentored by Stefan
      Schmukle, Universitaet Muenster, Germany
   Details about all proposals are on the R Wiki page for the GSoC 2010 at
   http://rwiki.sciviews.org/doku.php?id=developers:projects:gsoc2010
The R Project is honoured to have received its highest number of student
allocations yet, and looks forward to an exciting Summer of Code.  Please
join me in welcoming our new students.
At this time, I would also like to thank all the other students who have
applied for working with R in this Summer of Code. With a limited number of
available slots, not all proposals can be accepted -- but I hope that those
not lucky enough to have been granted a slot will continue to work with R and
towards making contributions within the R world. 
I would also like to express my thanks to all other mentors who provided for
a record number of proposals.  Without mentors and their project ideas we
would not have a Summer of Code -- so hopefully we will see you again next
year. 
Regards,  
Dirk (acting as R/GSoC 2010 admin)

C.J. Adams-Collier: GSoC 2010

Earlier this month, I applied to the Mono Project (and the University of Washington, and Ubuntu, and Debian, and The Perl Foundation) requesting a mentor to get Perl6 hosted on the DLR. Last Tuesday, Miguel contacted me and asked that I chat with Michael Hutchinson about possibly taking up a different project. It seems that the group did not have any mentors who felt comfortable mentoring the Perl6 project. After a bit of consideration, I agreed to modify my application and take up a project to revive the regular expression compiler from 2.2. Today, the project was officially accepted, and I met with my mentor for the first time (hi Rodrigo!). I will also be working with Matthew Wilson (aka @diakopter), since he has purportedly implemented a number of regex-to-IL compilers ;) He also offered to mentor me if The Perl Foundation had accepted my application, and since he has already implemented a perl6 compiler in javascript, I have been looking forward to poking some code with him. Although the GSoC doesn t officially get started until 5/24, I m making a git-svn checkout now. I ve always committed the code directly to svn, but I ve enjoyed working with git, and it seems about time to start contributing via git-svn. It will be easier to have local branches this way, too. Anyway, I m looking forward to it ;)

26 April 2010

Debian News: Brief Updates: d-i l10n status, DebConf, snapshot service, GSOC

Obey Arthur Liu: Welcome to our 2010 Debian Google Summer of Code students!

I d like to extend a warm welcome to our selected students for the 2010 Debian Google Summer of Code! They should pop up on Debian Planet soon and you re welcome to come talk to them on #debian-soc on irc.debian.org Aptitude Qt by Piotr Galiszewski, mentored by Sune Vuorela Qt GUI for aptitude. Currently, KDE users need to use Aptitude via the console interface, or install the newly developed GTK frontend, which does not fit well into KDE desktop. Making Qt frontend to Aptitude would solve this problem and bring an advanced and fully Debian-compliant graphical package manager to KDE. Content-aware Config Files Upgrading by Krzysztof Tyszecki, mentored by Dominique Dumont When a package deliver configuration files, the problem of merging user data with new configuration instructions will arise during package upgrades on users systems. Sometimes merging can be done with 3 way merge, but this process does not insure that the resulting file is correct or even legal. This project intends to create standards, tools an heuristics to make the scary config file conflict resolution debconf prompt a thing of the past. Debbugs Bug Reporting and Manipulation API by David Wendt Jr., mentored by Bastian Venthur Currently debbugs supports a SOAP interface for querying Debian s Bug Tracking System. Unfortunately this operation is read-only. This project would create an API for debbugs which supports sending and manipulating bug reports, without having to resort to email. This project does not intend to replace email as mean to manipulate the BTS but rather to enhance the BTS to allow other means of bug creation and manipulation. Debian High Performance Computing on Clouds by Dominique Belhachemi, mentored by Steffen Moeller The project paves a way to combine the demands in high performance computing with the dynamics of compute clouds with Debian. Combining the Eucalyptus cloud computing infrastructure with the TORQUE resource manager and preparing the components for dynamically added and removed instances provides the user with a attractive high performance computing environment. Such a system allows users to share resources with large compute centers with minimal changes in their workflow and scripts. Debian-Installer on Neo FreeRunner and Handheld Devices by Thibaut Girka, mentored by Gaudenz Steinlin This project aims to improve the installation experience of Debian on handheld devices by replacing ad-hoc install scripts by a full-blown and adapted Debian-Installer. The Neo FreeRunner is used as it is the most convenient and open device from a development standpoint, but other devices will also be explored. Hurd port and de-Linux-ization of Debian-Installer by J r mie Koenig, mentored by Samuel Thibault The primary means of distributing the Hurd is through Debian GNU/Hurd. However, the installation CDs presently use an ancient, non-native installer. The goal of this project is to port the missing parts of Debian-Installer to Hurd. To achieve this, all problematic Linux-specific code in Debian-Installer will be replaced by less or non-kernel dependent code, paving the way for better support of other non-Linux ports of Debian. Multi-Arch support in APT by David Kalnischkies, mentored by Michael Vogt Hardware like 64bit processors are perfectly able to execute 32bit opcode but until now this potentiality is disregard as the infrastructure tools like dpkg and APT are not able to install and/or solve dependencies across multiple architectures. The project therefore focuses on enabling APT to work out good solutions in a MultiArch aware environments without the need of hacky and partly working biarch packages currently in use. Package Repository Analysis and Migration Automation by Ricardo O Donell, mentored by Neil Williams Emdebian uses a filter to select packages from the main Debian repositories that are considered useful to embedded devices, excluding the majority of packages. The results of processing the filter are automated but maintaining the filter list is manual. This project seeks to automate certain elements of the filtering process to cope with specific conditions. This project will also generalize to more elaborate and intelligent algorithms to improve the transitions of the main Debian archives. Smart Upload Server for FTP Master by Petr Jasek, mentored by Joerg Jaspert Making packages upload smarter, more interactive and painless for uploaders by switching from anonymous FTP and Cron jobs to a robust protocol and modern package checking and processing daemon. This daemon would test early and report early, saving developers time. More details coming soon on http://wiki.debian.org/gsoc Congratulations everyone and have a fruitful summer!

Stefano Zacchiroli: the DebConf Newbies initiative

DebConf newbies: we want you! You've probably already read a nice blog post by Joey about the DebConf Newbies initiative. Let me recap in case you didn't: Debian will invest some money to explicit sponsor DebConf10 attendance for "non-regulars", i.e. for those that have not attended DebConf ever, or quite in a while. If you are interested you should check the wiki page and mail Joey as requested. (Including a big thank you to him would be more than appropriate, given that he'll be taking care of most gory details.) Why are we doing this and why is it separate from the regular DebConf sponsorship process? Answering the latter is rather easy. The initiative has sponsoring criteria different than regular DebConf sponsoring (which is well oiled and taken care of by the DebConf orga team) and it didn't seem fair to mix the two, possibly keeping out from regular sponsoring requests some people, just because of this new initiative. Also, as we're well past the deadline for requesting regular DebConf sponsoring, it wouldn't have been nice to induce extra work to the DebConf sponsoring team (and Joey has been kind enough to volunteer anyhow, so ... :-) ). Answers to the former question (why are we doing this in the first place?) are possibly subjectives. My personal belief is that attending DebConf increases the enthusiasm of attendees and ultimately will make them better Debian citizens. It surely happened to me years ago: in the beginning of my Debian membership (as DD, since DMs did not exist back then) I just cared about my pet packages. It was only after meeting the Debian crowd in person at a FOSS event (LinuxTag 2004, IIRC) that I got really enthusiastic about Debian, gradually increasing my involvement in the project. I've never regretted it. I hope it can happen to some of you too, possibly starting with DebConf10.
See you in New York!

25 April 2010

Gregor Herrmann: RC bugs 2010/15, 2010/16

my current list of worked on RC bugs; not many for two weeks but I was on vacation for almost a week ...

Clint Adams: Keep braid secrets under the Hat

Even though I do not understand the whole European campaign-period concept, I kept my mouth shut even though it was at odds with trying to answer every question, no matter how stupid. I give props to Jeroen for his efforts in question-answering that year, even though the electorate obviously never cares about that. I wanted to answer all questions directed to all candidates (excluding replies for the same reason that I only responded on-list to questions directed explicitly at me), but did not. Quite a bit of the encouragement I have received after the fact has been from people who are not DDs. I find this strange since most of what I have said has been about the enfranchisement of DDs, and nothing about non-DDs. I could speculate about why this might be the case, but I will refrain. We now return you to your regular program.

Vincent Sanders: XCB programming is hard

I have been looking at writing a program with XCB today. I seem to pick projects that are an exercise in undocumented frustration.

All I wanted to do was have an x window open and be able to plot an arbitrary changeable image to it (no I am not writing yet another image viewer!). The XCB documentation seems to be a cross between "good luck with that" and some rather erratic doxygen output.

The utility libraries are rather skimpy on examples and its tiresome worrying that when you feed any of the xcb function names into Google (web or codesearch) there are very, very few hits beyond the freedesktop API docs.

My favourite has to be the xcb_image_create documentation, go on I challenge anyone to follow that logic without going and reading the sources! The answer (afaict) is that if you pass a pointer in base that pointer will be freed by xcb_image_destroy otherwise the data pointer will be used, unless the bytes value is too small in which case memory will be allocated with malloc and the passed pointer ignored.
Anyhow, I have succeeded and the result is below, mainly so I do not loose it :-)

/* XCB application drawing an updating bitmap in a window
*
* Inspired by the xcb black rectangle in a window example
*
* Copyright 2010 V. R. Sanders, released under the MIT licence
*/

/* compile with:
*   gcc -Wall -lxcb-icccm -lxcb -lxcb-image -o disp disp.c
*/

#include <string.h>

#include <xcb/xcb.h>
#include <xcb/xcb_image.h>
#include <xcb/xcb_atom.h>
#include <xcb/xcb_icccm.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>

static xcb_format_t *
find_format (xcb_connection_t * c, uint8_t depth, uint8_t bpp)
 
 const xcb_setup_t *setup = xcb_get_setup(c);
 xcb_format_t *fmt = xcb_setup_pixmap_formats(setup);
 xcb_format_t *fmtend = fmt + xcb_setup_pixmap_formats_length(setup);
 for(; fmt != fmtend; ++fmt)
  if((fmt->depth == depth) && (fmt->bits_per_pixel == bpp))  
   /* printf("fmt %p has pad %d depth %d, bpp %d\n",
      fmt,fmt->scanline_pad, depth,bpp); */
   return fmt;
   
 return 0;
 

void
fillimage(unsigned char *p, int width, int height)
 
 int i, j;
 for(i=0; i < width; i++)
  
  for(j=0; j < height; j++)
   
   if((i < 256)&&(j < 256))
    
    *p++=rand()%256; // blue
    *p++=rand()%256; // green
    *p++=rand()%256; // red
     else  
    *p++=i%256; // blue
    *p++=j%256; // green
    if(i < 256)
     *p++=i%256; // red
    else if(j < 256)
     *p++=j%256; // red
    else
     *p++=(256-j)%256; // red
    
   p++; /* unused byte */
   
  
 

xcb_image_t *
CreateTrueColorImage(xcb_connection_t *c,
       int width,
       int height)
 
 const xcb_setup_t *setup = xcb_get_setup(c);
 unsigned char *image32=(unsigned char *)malloc(width*height*4);
 xcb_format_t *fmt = find_format(c, 24, 32);
 if (fmt == NULL)
  return NULL;

 fillimage(image32, width, height);

 return xcb_image_create(width,
    height,
    XCB_IMAGE_FORMAT_Z_PIXMAP,
    fmt->scanline_pad,
    fmt->depth,
    fmt->bits_per_pixel,
    0,
    setup->image_byte_order,
    XCB_IMAGE_ORDER_LSB_FIRST,
    image32,
    width*height*4,
    image32);
 

int
main (int argc, char **argv)
 
 xcb_connection_t *c;
 xcb_screen_t *s;
 xcb_window_t w;
 xcb_pixmap_t pmap;
 xcb_gcontext_t gc;
 xcb_generic_event_t *e;
 uint32_t mask;
 uint32_t values[2];
 int done=0;
 xcb_image_t *image;
 uint8_t *image32;
 xcb_expose_event_t *ee;
 char *title="Hello World!";
 xcb_size_hints_t *hints;

 /* open connection with the server */
 c = xcb_connect (NULL, NULL);

 if (!c)  
  printf ("Cannot open display\n");
  exit (1);
  

 s = xcb_setup_roots_iterator (xcb_get_setup (c)).data;

 /* printf("root depth %d\n",s->root_depth); */

 /* create image */
 image = CreateTrueColorImage(c, 640, 480);
 if (image == NULL)  
  printf ("Cannot create iamge\n");
  xcb_disconnect(c);
  return 1;
  
 image32 = image->data;

 /* create window */
 mask = XCB_CW_BACK_PIXEL   XCB_CW_EVENT_MASK;
 values[0] = s->white_pixel;
 values[1] = XCB_EVENT_MASK_EXPOSURE  
  XCB_EVENT_MASK_KEY_PRESS  
  XCB_EVENT_MASK_BUTTON_PRESS;

 w = xcb_generate_id (c);
 xcb_create_window (c, XCB_COPY_FROM_PARENT, w, s->root,
      10, 10, image->width, image->height, 1,
      XCB_WINDOW_CLASS_INPUT_OUTPUT,
      s->root_visual,
      mask, values);

 /* set title on window */
 xcb_set_wm_name(c, w, STRING, strlen(title), title);

 /* set size hits on window */
 hints = xcb_alloc_size_hints();
 xcb_size_hints_set_max_size(hints, image->width,image->height);
 xcb_size_hints_set_min_size(hints, image->width,image->height);
 xcb_set_wm_size_hints(c, w, WM_NORMAL_HINTS, hints);

 /* create backing pixmap */
 pmap = xcb_generate_id(c);
 xcb_create_pixmap(c, 24, pmap, w, image->width, image->height);

 /* create pixmap plot gc */
 mask = XCB_GC_FOREGROUND   XCB_GC_BACKGROUND;
 values[0] = s->black_pixel;
 values[1] = 0xffffff;

 gc = xcb_generate_id (c);
 xcb_create_gc (c, gc, pmap, mask, values);

 /* put the image into the pixmap */
 xcb_image_put(c, pmap, gc, image, 0, 0, 0);

 /* show the window */
 xcb_map_window (c, w);
 xcb_flush (c);

 /* event loop */
 while (!done && (e = xcb_wait_for_event (c)))  
  switch (e->response_type)  
  case XCB_EXPOSE:
   ee=(xcb_expose_event_t *)e;
   /* printf ("expose %d,%d - %d,%d\n",
      ee->x,ee->y,ee->width,ee->height); */
   xcb_copy_area(c, pmap, w, gc,
          ee->x,
          ee->y,
          ee->x,
          ee->y,
          ee->width,
          ee->height);
   xcb_flush (c);
   image32+=16;
   break;

  case XCB_KEY_PRESS:
   /* exit on keypress */
   done = 1;
   break;

  case XCB_BUTTON_PRESS:
   fillimage(image->data, image->width, image->height);
   memset(image->data, 0, image32 - image->data);
   xcb_image_put(c, pmap, gc, image, 0, 0, 0);
   xcb_copy_area(c, pmap, w, gc, 0,0,0,0,image->width,image->height);
   xcb_flush (c);
   break;
   
  free (e);
  

 /* free pixmap */
 xcb_free_pixmap(c, pmap);

 /* close connection to server */
 xcb_disconnect (c);

 return 0;




Tiago Bortoletto Vaz: Government Resquest tool fails

So it s no surprise that Google, like other technology and telecommunications companies, regularly receives demands from government agencies to remove content from our services. Of course many of these requests are entirely legitimate, such as requests for the removal of child pornography (1). We also regularly receive requests from law enforcement agencies to hand over private user data. Again, the vast majority of these requests are valid and the information needed is for legitimate criminal investigations. However, data about these activities historically has not been broadly available. We believe that greater transparency will lead to less censorship (2).

source (1)
Do your statistics cover all categories of content removals? No. Our policies and systems are set up to identify and remove child pornography whenever we become aware of it, regardless of whether that request comes from the government. As a result, it s difficult to accurately track which of those removals were requested by governments, and we haven t included those statistics here.
(So, why did you mention this as these requests ?)

(2)
* Chinese officials consider censorship demands as state secrets, so we cannot disclose that information at this time.
(where s the real transparency?) Furthermore, I tell you the incorrectness regarding requests/removals data from Brazil in your tool is a big truth.

Next.

Previous.