The system which was hosting this blog had a tendency to go down every few days. I swapped it out for a spare yesterday. Let s see if it stays up. The hypervisor hosts this web server, a mysql server and an SKS pool member, all of which are built on top of Squeeze.
Part of our work to make it possible to use UEFI Secure Boot on Linux has been to improve our EFI variable support code. Right now this has a hardcoded assumption that variables are 1024 bytes or smaller, which was true in pre-1.0 versions of the EFI spec. Modern implementations allow the maximum variable size to be determined by the hardware, and with implementations using large key sizes and hashes 1024 bytes isn't really going to cut it. My first attempt at this was a little ugly but also fell foul of the fact that sysfs only allows writes of up to the size of a page - so 4KB on most of the platforms we're caring about. So I've now reimplemented it as a filesystem[1], which is trickier but avoids this problem nicely.BdsLibVariableToOption (
IN OUT LIST_ENTRY *BdsCommonOptionList,
IN CHAR16 *VariableName
)
UINT16 FilePathSize;
UINT8 *Variable;
UINT8 *TempPtr;
UINTN VariableSize;
VOID *LoadOptions;
UINT32 LoadOptionsSize;
CHAR16 *Description;
//
// Read the variable. We will never free this data.
//
Variable = BdsLibGetVariableAndSize (
VariableName,
&gEfiGlobalVariableGuid,
&VariableSize
);
if (Variable == NULL)
return NULL;
So so far so good - we read the variable from flash and put it in Variable, Variable is now 0xffffffff 0xffffffff 0x00000000. If it hadn't existed we'd have skipped over and continued. VariableSize is 12.// // Get the option attribute // TempPtr = Variable; Attribute = *(UINT32 *) Variable; TempPtr += sizeof (UINT32);Attribute is now 0xffffffff and TempPtr points to Variable + 4.
// // Get the option's device path size // FilePathSize = *(UINT16 *) TempPtr; TempPtr += sizeof (UINT16);FilePathSize is 0xffff, TempPtr points to Variable + 6.
// // Get the option's description string size // TempPtr += StrSize ((CHAR16 *) TempPtr);TempPtr points to 0xffff 0x0000, so StrSize (which is basically strlen) will be 4. TempPtr now points to Variable + 10.
// // Get the option's device path // DevicePath = (EFI_DEVICE_PATH_PROTOCOL *) TempPtr; TempPtr += FilePathSize;TempPtr now points to Variable + 65545 (FilePathSize is 0xffff).
LoadOptions = TempPtr; LoadOptionsSize = (UINT32) (VariableSize - (UINTN) (TempPtr - Variable));LoadOptionsSize is now 12 - (Variable + 65545 - Variable), or 12 - 65545, or -65533. But it's cast to an unsigned 32 bit integer, so it's actually 4294901763.
Option->LoadOptions = AllocateZeroPool (LoadOptionsSize); ASSERT(Option->LoadOptions != NULL);We attempt to allocate just under 4GB of RAM. This probably fails - if it does the boot manager exits. This probably means game over. But if it somehow succeeds:
CopyMem (Option->LoadOptions, LoadOptions, LoadOptionsSize);we then proceed to read almost 4GB of content from uninitialised addresses, and since Variable was probably allocated below 4GB that almost certainly includes all of your PCI space (which is typically still below 4GB) and bits of your hardware probably generate very unhappy signals on the bus and you lose anyway.
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
vncviewer (from the packages xvnc4viewer or xtightvncviewer), I get the following problems:~ vncviewer chrismac VNC Viewer Free Edition 4.1.1 for X - built Mar 10 2010 22:31:05 Copyright (C) 2002-2005 RealVNC Ltd. See http://www.realvnc.com for information on VNC. Wed Dec 7 10:40:41 2011 CConn: connected to host chrismac port 5900 CConnection: Server supports RFB protocol version 3.889 CConnection: Using RFB protocol version 3.8 CConnection: No matching security types main: No matching security types
remmina had some drawbacks when connecting to a Mac, such as, at least in my case, a weird problem with Shift: once I hit Shift, I'm never able again to type in lowercase characters, which is quite painful. I tried also Vinagre, who handled that better (but had some quite painful freezing moment), so I must say that I finally found a client I'm happy with: gtkvncviewer.
I thought it s going to be an easy task.
lintian told me it s not so easy I have to review all my packages, bump their stadards policy, comply with DEP-5, use new quilt format and so on
That s not an easy task with more than twenty packages.
Yeah I know it s not requirenment, but still want to do that.
The bug webinterface of the
Ultimate Debian Database
currently knows about the following release critical bugs:
| In Total: | 1614 |
|---|---|
| Affecting Wheezy: | 945 |
| Wheezy only: | 148 |
| Remaining to be fixed in Wheezy: | 797 |
| Pending in Wheezy: | 47 |
|---|---|
| Patched in Wheezy: | 135 |
| Duplicates in Wheezy: | 45 |
| Can be fixed in a security Update: | 28 |
| Contrib or non-free in Wheezy: | 10 |
| Claimed in Wheezy: | 0 |
| Delayed in Wheezy: | 6 |
| Otherwise fixed in Wheezy: | 50 |
Wheezyreleased. However, with the view of the Release Managers, 845 need to be dealt with for the release to happen. Please see
Interpreting the release critical bug statisticsfor an explanation of the different numbers.
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!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1,SHA512
Hello,
I'm transitioning from my 2003 GPG key to a new one.
The old key will continue to be valid for some time, but I eventually
plan to revoke it, so please use the new one from now on. I would also
like this new key to be re-integrated into the web of trust. This message
is signed by both keys to certify the transition.
The old key was:
pub 1024D/FC7F6D0F 2003-07-10
Key fingerprint = E6A8 8BA0 D28A 3629 30A9 899F 82D7 DF6D FC7F 6D0F
The new key is:
pub 4096R/90BDD207 2012-01-06
Key fingerprint = 6B85 4D46 E843 3CD7 CDC0 3630 E0F7 59F7 90BD D207
To fetch my new key from a public key server, you can simply do:
gpg --keyserver pgp.mit.edu --recv-key 90BDD207
If you already know my old key, you can now verify that the new key is
signed by the old one:
gpg --check-sigs 90BDD207
If you don't already know my old key, or you just want to be double
extra paranoid, you can check the fingerprint against the one above:
gpg --fingerprint 90BDD207
If you are satisfied that you've got the right key, and the UIDs match
what you expect, I'd appreciate it if you would sign my key:
gpg --sign-key 90BDD207
Lastly, if you could send me these signatures, i would appreciate it.
You can either send me an e-mail with the new signatures by attaching
the following file:
gpg --armor --export 90BDD207 > timojyrinki.asc
Or you can just upload the signatures to a public keyserver directly:
gpg --keyserver pgp.mit.edu --send-key 90BDD207
Please let me know if there is any trouble, and sorry for the inconvenience.
(this post has been modified from the example at
http://www.debian-administration.org/users/dkg/weblog/48)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk8GuZoACgkQgtffbfx/bQ9nqACglWyHnDTFQfdKmz8OCd3oL6iR
hcEAmgKJ7RZsgwxwkRGPhygy5y1Ztb+3iQIcBAEBCgAGBQJPBrmaAAoJEOD3WfeQ
vdIHdVQQAMT1yvIogzbtK6sUnWqwbrXI9pDEFk7AzJTb80R+wzxsw7gu9gcBDk8G
BL2O26GKUqKWA3ytuApSl42FJam/Lusi9npT3XNkmHs6FaBMNuLYrqEXmCwXwWr/
OrLyeeLiF4yxgbNWbv+600BqAWqFlo6NeTgQKsJWtCjR3RVMxX3R8nzjDnKJuF+z
c6+2JKBWyx/HVUKcJpJrFDDR36HRFvVJomTuma2JCQ/RAl9vzAguqNYOi1QkuuQv
EF1gXH7gLifukGuwquP1DHP6SWWkj77jtRWr5ewC0xymbrArzAwKbvMQl3VpKBHh
MmpJjYP3ECyL14AKi/TY2Lidi0Sf6yqFMcPcreoih01N0OU0NXmD4IrHMT24/ssb
okDUe1o3YImjGq1jTACvlzC8s54EfLsqDgSP98SGVpuoDqPJUwVk4nuHj8q0vDSs
qZox26gVwB2FAOUi1BFiZbIzM5rsyYfCGyWUGiAwBFf54lYRAeCDCt8iAOOL1Ov/
TumIGYdLoXnDuOJq1VjXLGx2OFDrpyU8SPGoa3zNEVz39tgxQ48ASJEqcqt7HvBy
IW+TTsMLdJ1Ait9aCM3mzzr1iwP8TrL0qUsdRLOE6AKdAqocIfqXY8OeDKhbUiOJ
CXWk5q3xheK3sDWUXX7J63bAAUH4jFnpQEOVMJKBUNMKsWa0iXDS
=mklN
-----END PGP SIGNATURE-----
])
<nthykier> damn, a britney run in 5 minutes
<adsb> they happen
<adsb> you've been spoilt by never seeing b1 at her "finest" *cough*
<aba> you mean, running for more than a day?
<Ganneff> adsb wants night-long runs?
<aba> I can remember runs where we had to block certain packages to
make sure the run could actually end *sometimes*
<adsb> I'm quite happy with just the memory of that sort of run,
thanks 
<nthykier> I don't mind being spoiled if it stays at 5 minutes
I took the liberty of collecting the resulting data for the Britney test suite. In its reduced state[1] in runs in 30 seconds on my machine. It is already my favourite live data sample in the test suite. 
[1] Only i386 and amd64 are considered, manual hints are ignored etc.
I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances.
No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle).
I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.
I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances.
No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle).
I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.
I am the happy owner of a new netbook with an AMD Fusion E-450 APU, which includes a Radeon graphics card. I am using the open-source driver on it, that is a 3.2-rc7 kernel for KMS, and xserver-xorg-video-radeon package from sid. I have to say I am not really happy about the performances.
No I don t speak about the graphical performances that are pretty good (especially compared to my Intel Atom N450 based previous netbook) but about the power consumption. With this setup and with the original battery I get 2h30 of autonomy. Switching to UMS and adding some power management options in xorg.conf improves it to 2h40, but breaks suspend to ram/disk (a pity for a netbook) and switch between VT. I then tried the non-free fglrx driver, it also suffers from the suspend to ram/disk issue, in addition to crashing xorg when playing videos On the other hand I get an impressive 3h30 of autonomy, and additionally a silent netbook (contrary to the open-source driver, the fan doesn t spin at idle).
I have tried plenty of options, ranging from adding some power management options to xorg.conf, to passing dynclks=1 to the radeon module, including setting /sys/class/drm/card0/device/power_method to dynpm. Right now I have worked around the issue by buying a bigger battery which brings me 5h30 of autonomy, but I would really appreciate any software way to improve it with the open-source driver.
bts show 123456'). How nice it would be to be able to fetch
a bug report from within mutt! And so, ladies and gentlemen, I present to you
mutt-fetchbug. It's extensively based on Zack's
mutt-notmuch script (a nice interface between mutt and
notmuch for searching mail, I highly recommend it).
By adding a line like the following to your ~/.muttrc, you can
simply press "F7" and enter a bug number from your mutt index in
order to fetch and display a bug report's mbox file:
macro index <f7> \
"<enter-command>unset wait_key<enter><shell-escape>~/bin/mutt-fetchbug --prompt search<enter><change-folder-readonly>~/.cache/mutt_btsresults<enter><enter-command>set wait_key<enter>" \
"fetch bug(s) (using bts show)"
The above presupposes you've downloaded mutt-fetchbug and placed it
with executable permissions in ~/bin.
Those interested in making improvements or extending
mutt-fetchbug are more than welcome to do so, it's licensed under
the GPLv3+. It can be fetched from my git
branch.
Update: Fixed the broken link to mutt-fetchbug, thanks
Christian for the heads up.
Please note that the stats page had some breakage for level 3 these
days. This is under repairbut newt translations are still missing as
of now.
It took me much more uploads than I expected, but ColorHug client is finally in unstable. I was fighting with various bugs, which I could not reproduce locally and of course with my own stupidity in configuring pbuilder.
Anyway the buildds overview now shows mostly green, so this is good. The remaining ones mostly wait for libgusb, which needs build on armhf and needs to be ported to non Linux (or rather libusb needs to exist there).
One of things I've learned on the way is that docbook-utils is not enough to convert docbook to man pages, you need docbook package as well. Still I don't understand why this did locally work for me...
The one outstanding issue is that client code assumes it runs on little endian host (or rather same endianity as the ColorHug device) and thus will break on PPC and other big endian machines. The upstream is aware of that an I even managed to produce patch which should fix it, though I have no means to test it (lack of big endian hardware and lack of the ColorHug device itself).
Filed under: Debian English 4 comments Flattr this!
In KDE e.V. (which is to KDE</kde> what SPI is to Debian, Jenkins and others) there is some times a need to vote. For example about accepting new members. Mostly about accepting new members. With the new vote system (ballot.kde.org), voters need to do a bit more to check their votes afterwards. basically
There it is. Nice. Simple. Effective.
Sources available. http://quickgit.kde.org/?p=scratch%2Fsune%2Fkrapyl.git&a=summary have fun, and remember to verify your votes.
In KDE e.V. (which is to KDE</kde> what SPI is to Debian, Jenkins and others) there is some times a need to vote. For example about accepting new members. Mostly about accepting new members. With the new vote system (ballot.kde.org), voters need to do a bit more to check their votes afterwards. basically
There it is. Nice. Simple. Effective.
Sources available. http://quickgit.kde.org/?p=scratch%2Fsune%2Fkrapyl.git&a=summary have fun, and remember to verify your votes.
Next.