We need to get Jaldhar
a video-editing station and some free phase vocoder software.
Since a day or two, I've got myself a nice new
monitor. It's positively huge, which makes it useful even alone.
There is, however, one little problem. When I call xrandr
--output LVDS --right-of VGA, my laptop's display is situated at
the top right of the monitor. This is not what I'm after; I'd
much rather have it at the bottom right of the monitor, since
I'm off to Boston in under 16 hours, and I'll be getting into Portland around lunchtime on Monday. I'll be talking at Linuxcon about how we're broadening power management on Linux to be applicable from phones through netbooks up to supercomputers - that's 10:15 on Tuesday. At 10AM on Friday I'll be presenting at the Linux Plumbers conference on how userspace can express its requirements to the kernel more clearly, thereby allowing the kernel to be smarter about powering down hardware. And after a short hop down to SF for the weekend, I'll be back in Portland at the X developers conference talking about the role of X in providing relevant information to the kernel and using that to facilitate more aggressive power management. 
Now there is yet another package with a weird name in Debian - douf00 - a lightweight, slim and straight forward presentation tool. Written by some guys from a hacking and security team, which is mainly based in Vienna - guess that explains the l33t name (if you're scared now, yes, I've reviewed the code...). At the FrOSCon one of the authors asked me if I'd be willing to package it for Debian.I'm sure you'll love it if you're giving presentations and don't like to mess with Openoffice.org and friends. Below I've cited some parts of the README - make sure you read the linked file if you want to know more, or just install the package and give it a try.
Douf00 is a lightweight, slim and straight forward Presentation Tool.
It assists novice as well as experienced speakers when giving lectures
and business meetings. With its simple presenters Screen that includes
current slide - next slide (preview) as well as timers it is designed
to assist those of us, that are willing to step up their lectures
to the next level.
The main reason why we created douf00 is because
we (nice name crew) travel to conferences very often.
As a matter of fact i always carried my macbook pro to
every event. I always loved keynote and how the presenters
screen works. Not having to worry about your beamer configuration
and presenters screen is really comforting.
However since i love to pack small and play big (on it stuff)
i really felt we had to do something about it.
Given the current situation presenters using linux have to deal
with, we decided to simplify it.
Of corse as a geek i would love to travel just with my netback
saving valuable space in my backpack. In reality i was always
caring my heavy macbook pro 15" everywhere just to lecture.
Not only is it bad to give a presentation standing behind your
machine because your presenters remote doesn't work.
It is also highly annoying to always have to fumble around with
your graphics card.
Given the large verity of tools for creating your slides.
(i.e.: powerpoint, open office impress, apple's keynote,
latech-beamer,....)
We felt there was no room for yet another slide creation tool.
Nonetheless i noticed my desire to jump onstage, give a really
good presentation without the usual worries.
To be honest i use Keynote from apple on my home computer as i
find it the most comforting tool to create slides.
But now that we have created doufoo i save up on baggage space,
and i finally managed to get rid of all the worries beforehand.
But what is doufoo? - The perfect choice for every presenter that
has more important stuff todo than care about beamer configuration
more than once. Its fast, simple and lightweight.
We think that caring less about your gear and focusing on the
presentation itself is the best way to keep your audience
enthusiastic and entertained.
Subscribing to packages on the PTS is really useful to stay informed of everything happening with those packages. Unfortunately, managing your PTS subscriptions is really a challenge. Here is how I proceed to subscribe to packages I forgot to subscribe after uploading them:
/org/packages.qa.debian.org/bin/get-summary-subscribers.pl grep your@emailpsql -A -t service=udd -c "select source from sources
where distribution='debian' and release='sid'
and maintainer_email='your@email'
union select source from uploaders
where distribution='debian' and release='sid'
and email='your@email';"
- You can them use
combine to find the packages you should subscribe to, and mass-subscribe using the email interface.
- Then, you are done, or almost done: mass-confirming PTS subscriptions is a PITA because of #340863.
Some more info:
- The PTS lives on master, in
/org/packages.qa.debian.org.
- The script that handles emails send to pts@ is
bin/control.pl.
- The spool dir for pending requests is
spool/. The files are simple text files.
- You can send multiple commands per email. Sending them in the subject might be broken. (at least it failed for me)
- You don't need to take special care of the From for your emails. It's ignored (unless you subscribe without specifying an email address).
Hot from the oven: FusionForge 4.7 was just released. The release
notes follow. If you have local enhancements based on a previous
version of GForge, now is the time to port them to the 4.7 codebase
and submit them, so they can be merged in time for the next version!
Release notes for FusionForge 4.7
This is the first public release of FusionForge. FusionForge is based
on GForge, and started as an identical copy, with only a name change
to avoid confusion with the proprietary versions of GForge (known as
GForge Advanced Server or GForge AS). As such, it benefits from
mature code and known-good infrastructure, and builds on it for the
future.
This 4.7 release is focused on bringing the recent evolutions out to
the community in an official stable release. This should provide a
solid base as a starting point for community-based development, making
it easier for enhancements to be maintained. The FusionForge name was
chosen to reflect this: this is a community effort, and we hope to
hear about your improvements. Contributing these improvements would
make their future long-term maintenance easier for everyone.
Major changes since previous versions (of GForge) include:
Welcome to this month's FusionForge news batch.
I did a presentation of FusionForge at the Libre Software Meeting
(Rencontres Mondiales du Logiciel Libre, in
French) earlier this month, to explain where we come from and where we
hope to go. Many people attended despite the talk being early on the
morning following the formal dinner, and the questions showed
interest, which is encouraging for the project as a whole. I don't
think the talk has been recorded, but the summary and slides are
available on the RMLL
website.
The big news, though, is that I'm currently at the Debian Conference,
Debconf, and that I also attended
Debcamp before that. Debcamp is a very productive get-together of
developers from all across Debian, and I took the opportunity to get
help from them. I spent the first few days refactoring some of the
code that was duplicated between the CVS and Subversion plugins, and
the result is that version control plugins are now much easier to
implement. Case in point: I managed to get the attention of a few
users of other tools, and since they only had to implement small
specific parts, we now have almost complete plugins for Bazaar, Darcs
and Git, and Mercurial will probably follow. CPOLD was done too, but
mostly as a proof of concept. If you're around, come and see me,
we'll finish the support for your favourite tool together. Or even
start it (I haven't started on Arch and Monotone for lack of perceived
interest, but I'm quite open to these tools too). In both cases, I
promise it won't take long.
This code currently only lives on a temporary branch based off
FusionForge 4.8, but I'll port that to trunk and commit it in the
coming weeks.
I've been using Subversion and
Trac for some years now, and I have encouraged
its use at work since the last couple of years, with the undesired effect of
having to maintain four different Trac installations with different database
systems (SQLite3 and PostgreSQL), plugins (more than 15 on the big
servers), authentication systems (htpass files, LDAP and a database based
system) and tons of projects published (two internal servers have 64 and 16
projects, one of the client system has 33 projects and there is only one
single project installation, but it is living at a client's system).
Yesterday night, while reading Planet Debian I
found a post from
John Goerzen about tools to replace Trac,
including the option to use Git as the project
VCS.
In the post he talks about different options, mainly projects that I would
categorize as issue tracking systems (mantis, roundup, etc.), but it
also talks about Redmine, a project management
system implemented using the Ruby on Rails
framework that is similar to Trac.
As it looked interesting I downloaded, installed and executed an instance in
about 15 minutes (I love the systems that support
sqlite3 for this quick tests, not having to touch
real database servers speeds up simple tests a lot).
I played a little bit with the system and I believe that I will spend some
more time testing it at work next week, as it looks quite promising; the
standard version has almost all the features I'm interested in without the
need to install additional plugins and it can do most of the things I was
missing from Trac to do lightweight project management.
I evaluated ]project-open[ to use it together with
Trac for our internal project management tasks, mainly because we miss
important features from Trac, like having clean systems to view the tasks of
a user in all projects or a clean way to do the project planning using
tickets and gantt charts. Of course there are ways to do it, but the
plugins I've tried are not as good and simple as I would like.
The problem with the use of ]project-open[ is that I don't really like it
for us, as it has tons of features that I feel we don't need nor will use and,
on a first try, the system seemed difficult to deploy and maintain, probably
because my lack of knowledge about OpenACS and
TCL.
In fact we still don't have ]po[ running at work because I was unable to to
integrate the authentication system with our LDAP server on my first tries
and have had no time to investigate further since then.
The good thing about trying Redmine is that if we don't end up using it at
least I can take the most of this opportunity by looking at Ruby on Rails
and the Ruby Programming Language, at least
from the administration side, as I have never looked at it seriously.
I am, at best, a vim dilettante, preferring joe for most of my day-to-day
text-editing needs. However, I do like using vimoutliner for notes, plans,
todo lists, and calendaring (more on that some other time).
However, the Debian vimoutliner package (in combination with the awesomely
undocumented vim-addons mess) is an absolute pain to get going, requiring
far more swearing and prodding than seems necessary. Since I don't do it
often enough, too, I keep forgetting how, and today things came to an
absolute head when I very nearly flung my netbook across the room as it
singularly refused to do my outliner bidding.
Finally, however, after much swearing (and even installing vimoutliner's
upstream package to see if it worked -- it did -- and what it was doing
differently -- just a small, crucial addition to .vimrc), I got
the magical recipe. No doubt someone with an acheing need to make sure
that vim stays as user-hostile as possible will immediately spring into
action to
make sure this doesn't work for squeeze, but at least for the life of
lenny, here's how to get vimoutliner working:
# apt-get install vim-vimoutliner vim-addon-manager vim $ vim-addons install vimoutliner $ echo "filetype plugin indent on" >> ~/.vimrcMay it help someone avoid putting their laptop through a wall.
In the "blogging it so I don't forget about it" category, and also to try
and give Google some hints, here's one from the vault I recently came
across again...
Older e1000 chips (specifically the 82573(V/L/E)) have firmware which
enables the (buggy) power management functionality in the chips. Although
this shouldn't occur with hardware shipped in the last several years (the
updated firmware was released ages ago), I just came across it recently in
a supposedly-new server, so who knows what's going on there...
The problem manifests itself as flaky or unstable network performance,
combined with the kernel / log messages:
Detected Tx Unit Hang NETDEV WATCHDOG: ethX: transmit timed outThe fix is as described in the "82573(V/L/E) TX Unit Hang Messages" section of the Intel Linux driver documentation for the e1000 driver. The reason I'm blogging about it is that the top Google results point to either the now-dead e1000.sf.net wiki (which used to have all the necessary info, but now doesn't), or else forum posts which point to the now-dead e1000.sf.net wiki. Either way, it's not trivial to find a working location for the fix, so... linky love time!
I maintain several xen machines. Most servers that i maintain use serial consoles (i should probably write another post in more detail about why serial consoles are the One True Way to manage a server). Trouble is, the way that xen works with the serial console has changed between etch and lenny. So what's changed? From what i can tell: title Xen 3.0.3-1-i386-pae / Debian GNU/Linux, kernel 2.6.18-4-xen-686 root (hd0,0) kernel /xen-3.0.3-1-i386-pae.gz dom0_mem=131072 com1=115200,8n1 module /vmlinuz-2.6.18-4-xen-686 root=/dev/mapper/vg_monkey0-dom0 ro console=ttyS0,115200n8 module /initrd.img-2.6.18-4-xen-686 savedefaultbut in lenny, i find it necessary to do this:
title Xen 3.2-1-i386 / Debian GNU/Linux, kernel 2.6.26-2-xen-686 root (hd0,0) kernel /xen-3.2-1-i386.gz dom0_mem=131072 com1=115200,8n1 console=com1 module /vmlinuz-2.6.26-2-xen-686 root=/dev/mapper/vg_monkey0-dom0 ro console=hvc0 module /initrd.img-2.6.26-2-xen-686In particular, the hypervisor itself needs an additional console=com1 argument to make sure that it uses the serial console (i suppose the com1=... argument simply specifies how to use the serial console should you need it, instead of a requirement to use the console). And the Linux kernel itself for the dom0 needs to adopt hvc0 as its console, which i believe is an acronym for something like the "hypervisor virtual console" -- this way, the dom0 kernel will come out multiplexed over the hypervisor's console, no matter where that hypervisor's console is directed (you might not even need to specify this explicitly -- it might be set up by default). When i tried to use the etch settings for the console with the lenny hypervisor and kernel, i saw the hypervisor try to come out on the video card, and a dom0 crash!Tags: serial, serial console, xen
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
Next.