Image by Cayusa via Flickr
#!/bin/sh # # Rygel daemon handling RYGEL='/usr/bin/rygel' RYGEL_ARGS='' su -s /bin/sh -c "nohup $RYGEL $RYGEL_ARGS > /var/local/rygel/rygel.log 2>&1 &" rygel EXIT_CODE=$? if [ $EXIT_CODE != 0 ] ; then return $EXIT_CODE fi PGROUP= ps --no-headers -o pgrp $$ PID= pgrep -g $PGROUP -f $RYGEL echo $PID > /var/run/rygel.pid exit 0
I have a laptop used for playing music (and occasionally also videos) which is currently running Windows XP with XBMC. Reinstalling this beast to Linux is on my todo list for ages and now I've finally found time to try that.
Starting Debian installer worked like charm and in few minutes I got Debian system running. I've chosen to run sid, well for reason I run it usually on place where I want latest software. Installing XBMC from Debian multimedia worked also fine and you can easily find some howtos for directly starting XBMC.
And that's where I ran into trouble - XBMC is damn slow. Notebook has oldish nVidia GeForce FX Go5200 card, which seems to be poorly supported by nouveau (and "Do not file bug reports about this driver." suggest that this is what authors do expect). Okay, I can survive having some binary crap so let's try nVidia proprietary drivers. I've quickly realized that the legacy drivers won't work with recent xserver and probably also not with the kernel.
Maybe I should try installing something older, what would run binary drivers, but for now I gave up and system is back on Windows (with all problems I have there...).
Filed under: Debian English Linux 7 comments Flattr this!
I had a bit of an adventure yesterday, which would have taken some
explaining if the police had gotten involved. It went a little something
like this...
My friend and former co-worker Sara was in the US Virgin Islands for the
holidays. Her boyfriend, Karl, flew there separately for the tail end of her
time there.
Yesterday, I received a phone call from Sara, saying that Karl had managed
to fly out to the Virgin Islands without his passport. Apparently you can
get there without one, but to get back into the mainland US, you need one.
She wanted to know if I could get one of my lock-picking co-workers to break
into their apartment and retrieve Karl's passport and mail it them. Karl was
supposed to fly out the next day. Attempts by Sara to contact her landlord
had failed, so they didn't have many other options (apart from mailing me a
key, which would have cost them another day).
I asked one of my co-workers, Jason, who I knew was into lock picking, if he
was up for it, and he offered to put me in touch with another guy who had
dominated the recent lock picking night that he'd run.
So now I'm talking to David, who's on board with the mission, but doesn't
have his lock picking gear on him. No problem, Jason says he'll lend me his,
which was at work with him. So we have a plan.
Our friends Ian and Melinda are currently in Australia. They've lent us
their car because it's leased, and they have some minimum mileage they're
supposed to do and they're under it, so I've been driving to work in their
car some days. As it happens, I drove to work in it yesterday.
So now David and I set out in a car that neither of us own, with a lock
picking set that belongs to another person, to break into an apartment of
someone who's in the Virgin Islands. What could possibly go wrong?
I'm told that it's not illegal to own a lock picking set, but if you're
caught with one on your person and you're not a locksmith, you can get into
all sorts of trouble. On top of that I'd have a hard time explaining the car
I'm driving.
We get to Sara and Karl's condo complex. It has a common gate that visitors
would normal get buzzed through. Turns out it's not that hard to climb over.
It's got some benign-looking spiky things on top, but I could get a leg
over from the left hand side of the gate and jump over without impaling
myself. Then I let David in and we proceeded upstairs to Sara and Karl's
apartment door, where David set to work.
Sara said that just the dead bolt was locked. David started at it with
Jason's tools, trying to be as discreet as possible. It was about 3:30pm and
there was no one around, but we could hear some noises from the neighbouring
apartment (the two front doors were right next to each other).
After what felt like about half an hour without success (the last pin of the
lock was particularly tricky apparently) David was having to resort to more
noisy techniques with the lock, so I decided to take the up-front approach
and just inform the next door neighbour what we were doing in case he/she (I
think it was a she) decided to call the cops on us. I told her through the
door why we were there and what we were doing. She didn't seem to care too
much.
David then proceeded to start "raking" the lock, essentially brute forcing
the pins with a lot of jiggling, and finally managed to pick it and we were
in. I quickly found Karl's passport where it was suspected to be, and then
we pondered how we were going to lock the door again.
We could have just locked the door knob instead of the deadbolt and closed
the door behind us, but we weren't sure if Sara and Karl had a key to the
doorknob (Sara said they always just locked the deadbolt). Sara was fine
with leaving the door unlocked until they got home, but weren't so keen on
leaving our fingerprints all over the place and then leaving the door
unlocked.
David tried to re-pick the deadbolt so that he could lock it via the same
means as opened it, and I scouted around for a key. I managed to find a key
that locked both the deadbolt and the doorknob, so I took that with us and
locked up their apartment. In David's defense, the deadbolt was a bit stiff
to lock even with the key.
I dropped David back at work, collected my stuff (it was now about 4:30pm)
and headed to the UPS Store to ship Karl's passport to him as fast as
humanly possible. I just made the 5pm pick up.
Today I received an SMS from Sara informing me that they had received the
passport. I was very impressed with how fast it got to them.
So that was all a bit of an adventure. I'm not sure how much longer Karl is
going to have to stay in the Virgin Islands as a result. I'm going to
suggest that Sara and Karl leave a spare key with someone in future.
From what I can see on both my personal Flattr account (where was never really much going on) and on (more attractive) phpMyAdmin's profile, the amount of people using Flattr there goes down there every month. There was definitely big momentum when it has been introduced, many geeks saw it as great opportunity for making micro payments work. Maybe people who started to use it at beginning are slowly abandoning it (what is true for me as well) and new ones simply don't come that much or whatever else. Anyway I definitely don't have the big picture to see whether is global trend or just my project is more unlucky...
Filed under: English Phpmyadmin 9 comments Flattr this!
After dist-upgrading my main Hetzner server from Lenny to Squeeze,
Apache failed to come up, barfing the following error message in the
alphabetically last defined and enabled virtual host s error log:
[error] Illegal attempt to re-initialise SSL for server (theoretically shouldn't happen!)Well this is not theory but the real world and it did happen and it took me a while to find out what was wrong with the configuration despite it worked with Lenny s Apache version. To avoid that others have to search as long as I had to, here s the solution: Look at all enabled sites, pick out those which have a VirtualHost on port 443 defined and verify that all these VirtualHost containers do have their own SSLEngine On statement. If at least one is missing, you ll run into the above mentioned error message. And it won t necessarily show up in the error log of those VirtualHosts which are missing the statement but only in the last VirtualHost (or the last VirtualHost on port 443). To find the relevant site files, I used the following one-liner:
grep -lE 'VirtualHost.*443' sites-enabled/*[^~] \ xargs grep -ci "SSLEngine On" \ grep :0Should work for all sites which have defined just one VirtualHost on port 443 per file. I suspect that the raise of SNI made Apache s SSL implementation more picky with regards to VirtualHosts. Oh, and kudos to this comment to an article on Debian-Administration.org because it finally pointed me in the right direction. :-)
Current status
Back in September,
I wrote
about the machines that I set up to help bootstrap the new armhf
port in Debian. Basing on Konstantinos' huge efforts in bringing up
the new "architecture" in debian-ports, we started importing armhf
into the main Debian archive on the 24th of November. Since then,
those builders have been churning away night and day to build the
huge collection of software that makes up the Debian archive. The
current state can be seen on
the armhf
buildd status page, and there's a nice graph showing how quickly
we've managed to run from 0 to over 90% of the archive here. (Click
on the image for a larger version, or visit
https://buildd.debian.org/stats/
for other versions. We overtook hurd-i386 quickly and are now ahead
of the kfreebsd-* architectures.
We've recently brought 3 more similar build machines online
(hildegard, howells
and hummel), again sponsored by the nice folks
at Linaro but now hosted at
the York NeuroImaging Centre
at the University of York. This gives us both more build
horsepower to keep up with building more different bits of Debian
(experimental, updates etc.) and more redundancy in case of
problems.
We now have the vast majority of the archive built, and now a
number of us are concentrating on fixing the remaining issues:
language bootstraps and bugs. Also, on the 7th of January we were
just added into testing, the next step on our path for inclusion as
a Debian release architecture.
Setting up the machines
A lot of people have been asking me about the physical setup I
showed in my last blog about these machines, so here's more details
for those who are interested.
Use vim? Check out some sweet vim exrc stuff for editing one-line JSON files:
exec(), you fork() a process in the background that will wait for the current process id to disappear from the process list, and then does whatever you want to do.
A simple proof-of-concept I wrote is composed of two bash programs: wrapper and real.
real is really simple: it just waits a few seconds and then prints its process id to the console:
#!/bin/bash
sleep 5
echo $BASHPID
wrapper is the program that handles the situation we want to exercise: it replaces itself with real, but still has the chance to do something after real finishes. In this case, wrapper notifies the user that real finished.
#!/bin/bash
echo $BASHPID
real_program_pid=$BASHPID
(
while ps -p "$real_program_pid" >/dev/null; do
sleep 0.1s
done
notify-send 'real program finished'
) &
exec ./real
wrapper explores is that when exec() starts real, it really replaces wrapper, and therefore has the same process id (in this case accessible by bash in the $BASHPID variable). Because of this, the background process that wrapper starts just before the exec() call already knows which process it has to watch for.
The actual code for waiting is not optimal, though. I cannot use waitpid() (the wait builtin in bash), since real is not a child process of wrapper. I went with a brute force approach here, and I am pretty sure there is a cheaper way to wait for a random PID without a busy loop (but that wasn t the point here).
1
update: I am aware of the classic fork()/exec() pattern. My Very Good Reasons include the fact that I can t control the flow: I am writing a plugin for a program that calls its plugins in sequence, and after that, calls exec(), but my plugin is interested in doing some work after exec() finishes.
Recently I've been wanting to replace my old point and shoot camera, a Canon PowerShot A620. I've got a pair of DLSR cameras and I do frequently carry one of them out with me, but there are undoubtedly occasions where I'd rather not bother, or where I find myself wanting to take a picture without having one to hand.
Unfortunately the PowerShot is pretty large itself, although significantly less so than the DSLRS I possess. (I cannot remember the last time I used the PowerShot outside my flat, that is how rarely it goes outdoors).
The PowerShot has been a good camera to me for many years and the three features I liked the most:
That time of the year comes where I summarize my running
activities. It's now 4.5 years that I resumed running, after nearly 10
years without active sports. Apparently, things continue to improve,
though I'm logically reaching my limits in some way.
I finally missed the 2500km mark by 14 kilometers, mostly because of a
cold I had during the last 2 days of the year.
The grand total is thus 2486 kilometers run, in 237 hours (9 days
21hours), at about 10.5km/h. The climbed height difference is 27700
meters, so about three times the altitude of Mount Sagarmatha..:-)
This was achieved in 294 "activities". That seems to be a lot (nearly
1 activity per day): indeed, there are days where I have up to 4
activities, when I run to/back work, which means two runs in the
morning (3+4km) and two in the evening. If I count the number of days
where I had at least one running activity, this lowers to 181.
In short, I ran about every 2 days. Indeed, along the year, the
biggest timeframe between two runs has been 7 days. In short, I ran
at least once every week during this year. The most active month was
July with 272km and the less active was September with 163.5.
When counted by distance, this summarizes to:
This article could become one of my recurring "let's make noise about
translators work" articles. You've been warned.
In Squeeze, a few languages reached full completion of debconf
strings, those "questions" that are asked during packages installation
or upgrades. This can be followed here
(for unstable: we don't have an online status page for testing).. Many
of you, particularly those who aren't bored at reading me, know that I
like pushing this friendly "competition" as a good way to encourage
progress in localization of that part of Debian.
As of now, we have really good and active teams that are able to
maintain a great completion in this. Several of them are likely to
reach full 100% completion for wheezy. Let's look at the current
status:
Image via Wikipedia
cc -Iproc -g -O2 -o \$progdir/\$file pmap.o ./proc/.libs/libprocps.so \ -Wl,-rpath -Wl,/home/csmall/debian/procps/procps/proc/.libs \ -Wl,-rpath -Wl,//usr/lib/x86_64-linux-gnu
./configure \
--build=$(DEB_BUILD_GNU_TYPE) \
--enable-watch8bit --enable-w-from \
--prefix=/ \
--mandir=\$$ prefix /usr/share/man \
--libdir=\$$ prefix /usr/lib/$(DEB_HOST_MULTIARCH)xfonts- packages shipping their fonts in the directories known by the X server. According to Keith Packard it isn't easy to add fontconfig support to Xorg, there are some ways to paper over this though. We could use the Xorg server's font catalogue system to link to a fontconfig provided symlink farm (similar to what is done with defoma & Xorg). We could adjust the Xorg fonts utils to recurse into subdirectories. As far as I can tell, other distributions have completely ignored this issue and not all fonts are available to the Xorg server there.
So there should be no nerd left behind...
Mac OS X support
With the help of Steven McGrath (Steve[cug]) who created the initial Mac OS X
installer for Smuxi we now have official support for Mac OS X. The
download page contains the instructions how to obtain and install Smuxi on
Mac OS X. This makes the 4th platform where Smuxi can be used on besides
Windows, Linux and *BSD.
For now Smuxi 0.8.9 doesn't feel as native as it could as it relies on the GTK+
port. We are looking into enhancing the experience though, just
stay tuned.
Chat History on Disk (Beta)
The most exciting feature in this release I think are the
"persistent message buffers". With this feature I could solve one of the
biggest drawbacks IRC ever had: IRC does not retain any messages you have sent
or received. All messages are only relayed to all users. The issue is that if
you close your IRC client or even just leave a channel, all your received
messages are gone.
One workaround in most clients was to create text log files which then contains
the chat history, but it is annoying and not user-friendly to open some text
file somewhere from your disk to read the history outside of your IRC client.
Now with Smuxi 0.8.9 you no longer have this issue, all chat history gets
automatically written and read to a message database when you start Smuxi,
join channels or open queries! As this feature is not fully stable yet it is
not enabled by default. If you want to try it go to: File -> Preferences ->
Interface and change "Persistency Type" from "Volatile" to "Persistent", hit OK
and restart Smuxi. Now all messages are saved into the database and will
automatically be shown.
Click here for a screencast of this feature
Jabber / XMPP Support (Beta)
You probably have friends not on IRC and Twitter, say on Jabber, gTalk or
Facebook? This is where the new XMPP engine of Smuxi comes into play. You can
send and receive messages to/from them now! The implementation is far from
complete, though. It has no buddy list for example and needs only to be treated
as a technical preview of what will be coming in future Smuxi releases.
Click here for a screencast of this feature
Text Interface (Alpha)
This is the first release that contains a text frontend based on the
STFL library. STFL is a library that uses ncurses to draw text based
user interface using a markup language (like Glade for GTK+). This frontend
is in early alpha state and lacks a lot of interface features and likes to
crash. It is still included to attract potential developers who want to enhance
this frontend. The frontend can be enabled by passing --enable-frontend-stfl
to the configure script and then by executing smuxi-frontend-stfl.
NetworkManager Support
Everyone with a laptop knows how annoying it can be to suspend and resume when
network based applications suddenly go crazy because they have lost the
connection and either spew errors or take forever to get back in shape. Smuxi
will now detect the network state right away with the help of the new
Network Manager support. It automatically reconnects when needed right
away for you.
Next Generation Internet Support
You can now connect to IRC servers using the IPv6 protocol
Enhanced Find Group Chat Support
Users had real issues to find out how to search for channels, thus Bianca Mix
added a neat feature. The /list command will now simply open the
Find Group Chat dialog for you. This way everyone used to IRC will find it in
no time. Searching for channels on freenode wasn't working correctly, this is
now fixed. Smuxi also supports the SAFELIST feature of the IRC
protocol now which allows to retrieve a full channel list and do client side
search which makes consecutive searches much faster.
Enhanced Windows Experience
For a long time you could not use Smuxi with the latest GTK# version of 2.12.10
on Windows. The issue was that Smuxi relied on SVG support which 2.12.10 no
longer had. Smuxi is no longer using SVG instead it uses pre-scaled PNG images
thus it works just fine with GTK# 2.12.10 on Windows now. At the same
time the issue that the maximized state of the main window was left when
restoring from task bar is fixed with GTK# 2.12.10.
Smuxi used by default the FixedSys font on Windows to give it the typical IRC
look most people are used to. Since Windows Vista there is a better
console-like font available called Consolas. Smuxi will now
use the Consolas font instead on Windows Vista or later.
Another important enhancement is that Smuxi no longer has issues with
multiple GTK+ installs on the same computer, which was getting more
common with more popular ported GTK+ applications such as GIMP or Pidgin.
SSL for IRC fixed
IRC with SSL was only working with the default port of 6697. Thanks to Jo
Shields now any port can be used with SSL.
Crash Related Issues
Desktop notifications could crash Smuxi in case
of errors related to the notification system or an
absent notification daemon. There was a chance that the
crash dialog simply disappeared which made reporting bugs more
difficult no longer happens. Rapid use of ctrl+w,
/window close (Jimmie Elvenmark) and
opening the Find Group Chat dialog on the Smuxi tab do no longer crash.
Also number-only network names, /network switch freenode and
GTK+ install without SVG support no longer lead into a crash.
Enhanced Notice Handling
Notices will no longer open query tabs for you instead it will
show them on tabs you share with the person who sent it with the server
tab as fallback. This also avoids ChanServ, NickServ and spammy IRCop
tabs.
Twitter fixes
Twitter made some changes to their API which broke the Twitter support of
Smuxi 0.8. This was taken care of and also a few other
issues were solved allowing Smuxi 0.8.9 to work smoothly with Twitter
again.
Extended Keybindings
Smuxi allows now to use the ctrl+tab / ctrl+shift+tab and
ctrl+n / ctrl+p keys to switch tabs. The keybindings still work even
with a hidden menu bar now.
Smuxi Server specific highlights
More interactive and much faster synchronization
When connecting to a smuxi-server you had to wait till Smuxi finished the
synchronization before you could use the interface. Also you could not tell how
far the synchronization was and just had to wait till it was completed.
With Smuxi 0.8.9 the connect just takes a few seconds and all chats are
synchronized in the background with a progress bar so you can use the
interface from the first moment on and know how far it is. The speed how much
it takes to synchronize all chats also reduced drastictly by 400%!
Click here for a screencast of this feature
More background communication
When using a smuxi-server the interface sometimes had load times like when
opening the preferences or when using the nickname completion
(Andrew Kannan). These operations are done in the background and no longer
blocks the interface. Also when the communication is lost to the smuxi-server
the frontend will now automatically reconnect to it in the background.
Low Bandwidth Mode
When it comes to mobile internet connectivity such as UMTS/HSDPA, Edge and GRPS
it can be a real pain to connect to the smuxi-server as it has to transfer all
the messages over that. If you just want to ask someone you know then you don't
need any old messages to do that. With the "Low Bandwidth Mode" you can
now connect to the smuxi-server without loading old messages which makes the
connect very quick. You find this option in the engine connect dialog.
Stable Protocol
Initially I didn't plan to make the protocol of Smuxi stable before the 0.9
release, but as it turned out the 0.8 protocol was good enough to still use
it and for that reason Smuxi 0.8.9 is still compatible with 0.8. The 0.8
protocol will see no breakages, instead the next protocol will be on-top or
opt-in of the current one. This means future Smuxi versions
stay compatible with it.
Shutdown Command
You can now shutdown the smuxi-server if you like using the
/shutdown command. It it safe to use the command, it will do a clean
shutdown sequence for you. For example it makes sure all messages are written
to disk in the case of enabled persistent message buffers. If you have your
smuxi-server daemon monitored (e.g. with runit) it can also automatically be
restarted and upgraded this way.
Built-in SSH Keyfile Support
It is no longer needed to fiddle with the .ssh/config file or pagent to get
SSH key authorization working. You can now simply tell Smuxi which
SSH keyfile you want to use to connect to your smuxi-server.
Updated Translations
One of Django applications I maintain is our internal tool used at SUSE used for managing incoming L3 requests. Recently request to add some API arose (read only for now). Looking at available solutions, I came to conclusion that django-piston should be the best choice for me.
Adding simple model based API with it is indeed quite simple, all basic information you need is written in getting started part of their documentation.
On the other side, things can never go without problems, so I was hit by well known bug. Fortunately fix exists, though it is not yet merged upstream. While digging so deep into problem anyway, I've submitted a request to include this patch in devel:languages:python OBS repo.
Filed under: Django English Suse 4 comments Flattr this!
])
Next.