Search Results: "pavel"

19 September 2022

Antoine Beaupr : Looking at Wayland terminal emulators

Back in 2018, I made a two part series about terminal emulators that was actually pretty painful to write. So I'm not going to retry this here, not at all. Especially since I'm not submitting this to the excellent LWN editors so I can get away with not being very good at writing. Phew. Still, it seems my future self will thank me for collecting my thoughts on the terminal emulators I have found out about since I wrote that article. Back then, Wayland was not quite at the level where it is now, being the default in Fedora (2016), Debian (2019), RedHat (2019), and Ubuntu (2021). Also, a bunch of folks thought they would solve everything by using OpenGL for rendering. Let's see how things stack up.

Recap In the previous article, I touched on those projects:
Terminal Changes since review
Alacritty releases! scrollback, better latency, URL launcher, clipboard support, still not in Debian, but close
GNOME Terminal not much? couldn't find a changelog
Konsole outdated changelog, color, image previews, clickable files, multi-input, SSH plugin, sixel images
mlterm long changelog but: supports console mode (like GNU screen?!), Wayland support through libvte, sixel graphics, zmodem, mosh (!)
pterm changes: Wayland support
st unparseable changelog, suggests scroll(1) or scrollback.patch for scrollback now
Terminator moved to GitHub, Python 3 support, not being dead
urxvt no significant changes, a single release, still in CVS!
Xfce Terminal hard to parse changelog, presumably some improvements to paste safety?
xterm notoriously hard to parse changelog, improvements to paste safety (disallowedPasteControls), fonts, clipboard improvements?
After writing those articles, bizarrely, I was still using rxvt even though it did not come up as shiny as I would have liked. The colors problems were especially irritating. I briefly played around with Konsole and xterm, and eventually switched to XTerm as my default x-terminal-emulator "alternative" in my Debian system, while writing this. I quickly noticed why I had stopped using it: clickable links are a huge limitation. I ended up adding keybindings to open URLs in a command. There's another keybinding to dump the history into a command. Neither are as satisfactory as just clicking a damn link.

Requirements Figuring out my requirements is actually a pretty hard thing to do. In my last reviews, I just tried a bunch of stuff and collected everything, but a lot of things (like tab support) I don't actually care about. So here's a set of things I actually do care about:
  • latency
  • resource usage
  • proper clipboard support, that is:
    • mouse selection and middle button uses PRIMARY
    • control-shift-c and control-shift-v for CLIPBOARD
  • true color support
  • no known security issues
  • active project
  • paste protection
  • clickable URLs
  • scrollback
  • font resize
  • non-destructive text-wrapping (ie. resizing a window doesn't drop scrollback history)
  • proper unicode support (at least latin-1, ideally "everything")
  • good emoji support (at least showing them, ideally "nicely"), which involves font fallback
Latency is particularly something I wonder about in Wayland. Kitty seem to have been pretty dilligent at doing latency tests, claiming 35ms with a hardware-based latency tester and 7ms with typometer, but it's unclear how those would come up in Wayland because, as far as I know, typometer does not support Wayland.

Candidates Those are the projects I am considering.
  • darktile - GPU rendering, Unicode support, themable, ligatures (optional), Sixel, window transparency, clickable URLs, true color support, not in Debian
  • foot - Wayland only, daemon-mode, sixel images, scrollback search, true color, font resize, URLs not clickable, but keyboard-driven selection, proper clipboard support, in Debian
  • havoc - minimal, scrollback, configurable keybindings, not in Debian
  • sakura - libvte, Wayland support, tabs, no menu bar, original libvte gangster, dynamic font size, probably supports Wayland, in Debian
  • termonad - Haskell? in Debian
  • wez - Rust, Wayland, multiplexer, ligatures, scrollback search, clipboard support, bracketed paste, panes, tabs, serial port support, Sixel, Kitty, iTerm graphics, built-in SSH client (!?), not in Debian
  • XTerm - status quo, no Wayland port obviously
  • zutty: OpenGL rendering, true color, clipboard support, small codebase, no Wayland support, crashes on bremner's, in Debian

Candidates not considered

Alacritty I would really, really like to use Alacritty, but it's still not packaged in Debian, and they haven't fully addressed the latency issues although, to be fair, maybe it's just an impossible task. Once it's packaged in Debian, maybe I'll reconsider.

Kitty Kitty is a "fast, feature-rich, GPU based", with ligatures, emojis, hyperlinks, pluggable, scriptable, tabs, layouts, history, file transfer over SSH, its own graphics system, and probably much more I'm forgetting. It's packaged in Debian. So I immediately got two people commenting (on IRC) that they use Kitty and are pretty happy with it. I've been hesitant in directly talking about Kitty publicly, but since it's likely there will be a pile-up of similar comments, I'll just say why it's not the first in my list, even if it might, considering it's packaged in Debian and otherwise checks all the boxes. I don't trust the Kitty code. Kitty was written by the same author as Calibre, which has a horrible security history and generally really messy source code. I have tried to do LTS work on Calibre, and have mostly given up on the idea of making that program secure in any way. See calibre for the details on that. Now it's possible Kitty is different: it's quite likely the author has gotten some experience writing (and maintaining for so long!) Calibre over the years. But I would be more optimistic if the author's reaction to the security issues were more open and proactive. I've also seen the same reaction play out on Kitty's side of things. As anyone who worked on writing or playing with non-XTerm terminal emulators, it's quite a struggle to make something (bug-for-bug) compatible with everything out there. And Kitty is in that uncomfortable place right now where it diverges from the canon and needs its own entry in the ncurses database. I don't remember the specifics, but the author also managed to get into fights with those people as well, which I don't feel is reassuring for the project going forward. If security and compatibility wasn't such big of a deal for me, I wouldn't mind so much, but I'll need a lot of convincing before I consider Kitty more seriously at this point.

Next steps It seems like Arch Linux defaults to foot in Sway, and I keep seeing it everywhere, so it is probably my next thing to try, if/when I switch to Wayland. One major problem with foot is that it's yet another terminfo entry. They did make it into ncurses (patch 2021-07-31) but only after Debian bullseye stable was released. So expect some weird compatibility issues when connecting to any other system that is older or the same as stable (!). One question mark with all Wayland terminals, and Foot in particular, is how much latency they introduce in the rendering pipeline. The foot performance and benchmarks look excellent, but do not include latency benchmarks.

No conclusion So I guess that's all I've got so far, I may try alacritty if it hits Debian, or foot if I switch to Wayland, but for now I'm hacking in xterm still. Happy to hear ideas in the comments. Stay tuned for more happy days.

31 August 2020

Chris Lamb: Free software activities in August 2020

Here is another monthly update covering what I have been doing in the free software world during August 2020 (previous month): I uploaded Lintian versions 2.86.0, 2.87.0, 2.88.0, 2.89.0, 2.90.0, 2.91.0 and 2.92.0, as well as made the following changes:

Reproducible Builds One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes. The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter. This month, I:

diffoscope I made the following changes to diffoscope, including preparing and uploading versions 155, 156, 157 and 158 to Debian:

Debian Debian LTS This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 hours on its sister Extended LTS project. You can find out more about the project via the following video:


Uploads to Debian

31 July 2020

Chris Lamb: Free software activities in July 2020

Here is my monthly update covering what I have been doing in the free and open source software world during July 2020 (previous month): For Lintian, the static analysis tool for Debian packages:

Reproducible Builds One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes. The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter. This month, I:

diffoscope Elsewhere in our tooling, I made the following changes to diffoscope, including preparing and uploading versions 150, 151, 152, 153 & 154 to Debian:

Debian In Debian, I made the following uploads this month:

Debian LTS This month I have worked 18 hours on Debian Long Term Support (LTS) and 12 for the Extended LTS project. This included: You can find out more about the project via the following video:

30 June 2020

Chris Lamb: Free software activities in June 2020

Here is my monthly update covering what I have been doing in the free software world during June 2020 (previous month): For Lintian, the static analysis tool for Debian packages:

Reproducible Builds One of the original promises of open source software is that distributed peer review and transparency of process results in enhanced end-user security. However, whilst anyone may inspect the source code of free and open source software for malicious flaws, almost all software today is distributed as pre-compiled binaries. This allows nefarious third-parties to compromise systems by injecting malicious code into ostensibly secure software during the various compilation and distribution processes. The motivation behind the Reproducible Builds effort is to ensure no flaws have been introduced during this compilation process by promising identical results are always generated from a given source, thus allowing multiple third-parties to come to a consensus on whether a build was compromised. The project is proud to be a member project of the Software Freedom Conservancy. Conservancy acts as a corporate umbrella allowing projects to operate as non-profit initiatives without managing their own corporate structure. If you like the work of the Conservancy or the Reproducible Builds project, please consider becoming an official supporter. This month, I:

Elsewhere in our tooling, I made the following changes to diffoscope including preparing and uploading versions 147, 148 and 149 to Debian: trydiffoscope is the web-based version of diffoscope. This month, I specified a location for the celerybeat scheduler to ensure that the clean/tidy tasks are actually called which had caused an accidental resource exhaustion. (#12)

Debian I filed three bugs against: Debian LTS This month I have worked 18 hours on Debian Long Term Support (LTS) and 5 hours on its sister Extended LTS project. You can find out more about the project via the following video:
Uploads

30 August 2017

Kees Cook: GRUB and LUKS

I got myself stuck yesterday with GRUB running from an ext4 /boot/grub, but with /boot inside my LUKS LVM root partition, which meant GRUB couldn t load the initramfs and kernel. Luckily, it turns out that GRUB does know how to mount LUKS volumes (and LVM volumes), but all the instructions I could find talk about setting this up ahead of time ( Add GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub ), rather than what the correct manual GRUB commands are to get things running on a failed boot. These are my notes on that, in case I ever need to do this again, since there was one specific gotcha with using GRUB s cryptomount command (noted below). Available devices were the raw disk (hd0), the /boot/grub partition (hd0,msdos1), and the LUKS volume (hd0,msdos5): 
grub> ls
(hd0) (hd0,msdos1) (hd0,msdos5)
Used cryptomount to open the LUKS volume (but without ()s! It says it works if you use parens, but then you can t use the resulting (crypto0)): 
grub> insmod luks
grub> cryptomount hd0,msdos5
Enter password...
Slot 0 opened.
Then you can load LVM and it ll see inside the LUKS volume: 
grub> insmod lvm
grub> ls
(crypto0) (hd0) (hd0,msdos1) (hd0,msdos5) (lvm/rootvg-rootlv)
And then I could boot normally: 
grub> configfile $prefix/grub.cfg
After booting, I added GRUB_ENABLE_CRYPTODISK=y to /etc/default/grub and ran update-grub. I could boot normally after that, though I d be prompted twice for the LUKS passphrase (once by GRUB, then again by the initramfs). To avoid this, it s possible to add a second LUKS passphrase, contained in a file in the initramfs, as described here and works for Ubuntu and Debian too. The quick summary is: Create the keyfile and add it to LUKS: 
# dd bs=512 count=4 if=/dev/urandom of=/crypto_keyfile.bin
# chmod 0400 /crypto_keyfile.bin
# cryptsetup luksAddKey /dev/sda5 /crypto_keyfile.bin
*enter original password*
Adjust the /etc/crypttab to include passing the file via /bin/cat: 
sda5_crypt UUID=4aa5da72-8da6-11e7-8ac9-001cc008534d /crypto_keyfile.bin luks,keyscript=/bin/cat
Add an initramfs hook to copy the key file into the initramfs, keep non-root users from being able to read your initramfs, and trigger a rebuild: 
# cat > /etc/initramfs-tools/hooks/crypto_keyfile <<EOF
#!/bin/bash
if [ "$1" = "prereqs" ] ; then
    cp /crypto_keyfile.bin "$ DESTDIR "
fi
EOF
# chmod a+x /etc/initramfs-tools/hooks/crypto_keyfile
# chmod 0700 /boot
# update-initramfs -u
This has the downside of leaving a LUKS passphrase in the clear while you re booted, but if someone has root, they can just get your dm-crypt encryption key directly anyway: 
# dmsetup table --showkeys sda5_crypt
0 155797496 crypt aes-cbc-essiv:sha256 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0 8:5 2056
And of course if you re worried about Evil Maid attacks, you ll need a real static root of trust instead of doing full disk encryption passphrase prompting from an unverified /boot partition. :)

2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

21 July 2015

Dmitry Shachnev: GNOME Flashback 3.16 available in archive, needs your help

Some time ago GNOME Flashback 3.16/3.17 packages landed in Debian testing and Ubuntu wily. GNOME Flashback is the project which continues the development of components of classic GNOME session, including the GNOME Panel, the Metacity window manager, and so on. Screenshot The full changelog can be found in official announcement mail by Alberts and in changelog.gz files in each package, but I want to list the most imporant improvements in this release (compared to 3.14): Sounds interesting? Contribute! If you are interested in helping us, please write to our mailing list: gnome-flashback-list@gnome.org. The current TODO list is:
  1. Notification Daemon needs GTK notification support.
  2. GNOME Flashback needs screenshot, screencast, keyboard layout switching and bluetooth status icon.
  3. Fix/replace deprecated function usage in all modules.
  4. libstatus-notifier get it in usable state, create a new applet for gnome-panel.

17 December 2012

Lars Wirzenius: Obnam 1.3 (backup software) and other releases

I've just pushed out the release files for Obnam version 1.3, my backup application, as well as Larch, my B-tree library, and cliapp, my Python framework for command line applications. They are available via my home page (http://liw.fi/). Since Debian is frozen, I am not uploading packages to Debian, but .deb files are available from my personal apt repository for the intrepid. (I will be uploading to Debian again after the freeze. I am afraid I'm too lazy to upload to experimental, or do backports. Help is welcome!) From the Obnam NEWS file: Bug fixes for Obnam: NEWS for Larch: NEWS for cliapp:

12 February 2011

Wouter Verhelst: Ten years of Debian

My first ever Linux installation was done in the late nineties 1998 or thereabouts but was a RedHat 4.5 installation rather than a Debian one. The reason for that was fairly simple: the Infomagick sixpack CD set that I'd bought contained RedHat, Debian, and Slackware, but the RedHat installation was the only one that could be installed directly from CD the other two required me to write floppies and boot from those to start the installation, and I wasn't very fond of that idea. It was only a few years and a few broken RedHat upgrades later that I saw the light and considered trying out this Debian thing that some of my classmates were talking about. The fact that I'd just bought my own computer (rather than having to compete for time with my siblings on my parents' computer) was a good reason to do a fresh Linux installation. I'd been planning to install Linux From Scratch, but as what was still known as the LFS HOWTO told me you'd need a working Linux installation to do that, I considered my options. Since I'd developed a strong dislike of RedHat, I wasn't interested in doing another RedHat anymore. So, I downloaded the most recent version of Debian at the time (Potato Test Cycle III), wrote it to a CD, and installed. I've probably still got the CD lying around somewhere. A few months later, I found these "Linux Gazette" packages in the archive, with the latest packaged issue being 47, but the latest upstream version being much higher. Trying to figure out what was going on, I mailed the maintainer, Adrian Bridgett, who encouraged me to take over maintenance. Thus began my life of actively contributing to Open Source software. In November 2000, I applied to become a Debian Developer. In January 2001, Martin Michlmayr was assigned to be my AM. And in early February 2001, now just over ten years ago, I'd become a Debian Developer. Yes, that was fast, and no, I probably wasn't really ready yet, at the time. Originally, I only cared much about these Linux Gazette packages. But, as time went on, I started looking around, too. A friend passed me an old Macintosh Centris 610. As I tried to install Debian on it, I found that it didn't actually run very well. This turned out to be due to it having a broken 68LC040 processor, so I bought me another m68k-based mac, one with a full 68040 processor (a Centris 650). Thus I became involved in the m68k port and buildd maintenance. As these old machines came with 80MB or 250MB SCSI hard disks of which I had none laying around, and a then-recent Debian installation had minimum requirements of about 200MB, I was in need of network storage to be able to do anything useful with the mac. NFS didn't work as expected; the RTC implementation on m68k mac hardware was reverse engineered and didn't work too well at the time, which meant that the clock would run slower if the machine was under load, and that in turn would mean that make would get confused about timestamps, since they would suddenly appear to originate from the future (in NFS, it's the server that assigns time stamps, not the client). There was a simple solution, however; Pavel Macheck had written this neat 'Network Block Device', which would let the client do its own filesystem on network storage. Only it wasn't packaged; but then, that was easy to fix. Thus I started maintaining the single piece of software that I've worked the most on, to date. A few years later, Pavel lost interest in maintaining NBD, and handed over upstream maintenance to me and maintenance of the kernel side to Paul Clements. Thus began my life in upstream work. And while I originally joined Debian with the intent of using it as a learning experience and stepping stone on my way to more "important" free software, I found that it wasn't as satisfying as was my work for Debian. Over the years, there's been this duality where I've felt like I was doing too much and not enough at the same time. Too much, because the things I was doing would eat up much of my spare time, leaving little time left for other hobbies. Not enough, because I witnessed other people doing much more for Debian than I did, and I wanted to make a difference. As the years passed by, many things have changed. Not only in Debian, but also besides it. I became an independent contractor, focusing mostly on supporting people in using Debian (although I support them with other distributions, too). The importance of a port went from 'something which these weird porter people are doing, and that we should probably help them with if it doesn't work, but is their problem really' to 'something that I really really really have to make sure works for my packages', and back for the port that I cared about most. After several years of trying, I finally managed to explain to my parents what this Debian thing is, why it matters, and what my role in the whole thing is. We did a few releases, some taking longer than I would've liked. People joined the project, and left again. Some of my friends died. My fame in the project rose, even though I wasn't aware of it initially; and thus I was rather surprised when someone asked me whether I was "the Wouter Verhelst" at a key signing party. Recently, I've started looking back, and considered the things which Debian has meant to me. Ten years ago, I was 22, still in college, and had way too much spare time on my hands. I'd recently gotten my first Internet installation, and all these online communities were very new to me. Yes, that was all probably rather late. Debian has changed my life in many ways; it has allowed me to meet various kinds of people, both online and in meatspace. I've been to Helsinki, Edinburgh, Mar del Plata, C ceres, and New York City, places that I might otherwise not have visited. Each of these trips was an incredible experience that I have fond memories of; and while the most fond ones originate from Helsinki, I cherish the memories of each of these trips as some of the best trips I've ever done. Working on Debian has forced me to learn about the inner workings of a Linux-based system, which is knowledge that has helped me tremendously professionally, too. And finally, working on Debian has given me a unique perspective on this whole FOSS community, which has helped shape my ethics and my view of the world. While I believe that I would've subscribed to most of that ideology at any rate, I'm not sure that the details of my beliefs and understanding would've been exactly the same. And while I don't agree on every position that the project subscribes to as a whole, I do believe that the philosophies that lie at the core of this project contain just the right mix of pragmatism and ideology that makes it possible for our project to thrive in a changing world of not only a growing group of people who subscribe unconditionally to the free software ideals, but also business people who care mostly about money. Over the years, somehow I moved from "one of the recent batch of new Debian Developers" to "someone who's been with the project longer than most". It still feels weird to see people shut up because you've built up a reputation in some area, and you give your gut opinion on some subject without researching it too much. I try not to let that happen too often. Today, ten years and just over a week ago, my life as a Debian Developer started, and it would change the way I looked at the world, the things I would do in my spare time, and the people I would meet. I wouldn't have it any other way. Thanks, Debian, for what's been a blast; may the next ten years be as inspiring to me and everyone as the past ten!

26 January 2011

Martin Pitt: Na zdrav PyGI!

(Update: Link to Tomeu s blog post, repost for planet.gnome.org) Last week I was in Prague to attend the GNOME/Python 2011 Hackfest for gobject-introspection, to which Tomeu Vizoso kindly invited me after I started working with PyGI some months ago. It happened at a place called brmlab which was quite the right environment for a bunch of 9 hackers: Some comfy couches and chairs, soldering irons, lots of old TV tubes, chips, and other electronics, a big Pirate flag, really good Wifi, plenty of Club Mate and Coke supplies, and not putting unnecessary effort into mundane things like wallpapers. It was really nice to get to know the upstream experts John (J5) Palmieri and Tomeu Vizoso (check out Tomeu s blog post for his summary and some really nice photos). When sitting together in a room, fully focussing on this area for a full week, it s so much easier to just ask them about something and getting things done and into upstream than on IRC or bugzilla, where you don t know each other personally. I certainly learned a lot this week (and not only how great Czech beer tastes :-) )! So what did I do? Application porting After already having ported four Ubuntu PyGTK applications to GI before (apport, jockey, aptdaemon, and language-selector),
my main goal and occupation during this week was to start porting a bigger PyGTK application. I picked system-config-printer, as it s two magnitudes bigger than the previous projects, exercises quite a lot more of the GTK GI bindings, and thus also exposes a lot more GTK annotation and pygobject bugs. This resulted in a new pygi s-c-p branch which has the first 100 rounds of test, break, fix iterations. It now at least starts, and you can do a number of things with it, but a lot of functionality is still broken. As a kind of finger exercise and also to check for how well pygi-convert works for small projects now, I also ported computer-janitor. This went really well (I had it working after about 30 minutes), and also led me to finally fixing the unicode vs. str mess for GtkTreeView that you got so far with Python 2.x. pygobject and GTK fixes Porting system-config-printer and computer-janitor uncovered a lot of opportunities to improve pygi-convert.sh, a big perl -e kind of script to do the mechanical grunt work of the porting process. It doesn t fix up changed signatures (such as adding missing arguments which were default arguments in PyGTK, or the ubiquitous user_data argument for signal handlers), but at least it gets a lot of namespaces, method, and constant names right. I also fixed three annotation fixes in GTK+. We also collaboratively reviewed and tested Pavel s annotation branch which helped to fix tons of problems, especially after Steve Fr cinaux s excellent reference leak fix, so if you play around with current pygobject git head, you really also have to use the current GTK+ git head. Speaking of which, if you want to port applications and always stay on top of the pygobject/GTK development without having to clutter your package system with make install s of those, it works very well to have this in your ~/.bashrc: 
export GI_TYPELIB_PATH=$HOME/projects/gtk/gtk:$HOME/projects/gtk/gdk
export PYTHONPATH=$HOME/projects/pygobject
Better GVariant/GDBus support The GNOME world is moving from the old dbus-glib python bindings to GDBus, which is integrated into GLib. However, dbus-python exposed a really nice and convenient way of doing D-Bus calls, while using GDBus from Python was hideously complicated, especially for nontrivial arguments with empty or nested arrays: 
from gi.repository import Gio, GLib
from gi._gi import variant_type_from_string
d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)
vb = GLib.VariantBuilder()
vb.init(variant_type_from_string('r'))
vb.add_value(GLib.Variant('s', 'test'))
vb.add_value(GLib.Variant('u', 1))
vb.add_value(GLib.Variant('s', 'gtk-ok'))
vb.add_value(GLib.Variant('s', 'Hello World!'))
vb.add_value(GLib.Variant('s', 'Subtext'))
# add an empty array
eavb = GLib.VariantBuilder()
eavb.init(variant_type_from_string('as'))
vb.add_value(eavb.end())
# add an empty dict
eavb = GLib.VariantBuilder()
eavb.init(variant_type_from_string('a sv '))
vb.add_value(eavb.end())
vb.add_value(GLib.Variant('i', 10000))
args = vb.end()
result = notify.call_sync('Notify', args, 0, -1, None)
id = result.get_child_value(0).get_uint32()
print id
So I went to making the GLib.Variant constructor work properly with nested types and boxed variants, adding Pythonic GVariant iterators and indexing (so that you can treat GVariant dictionaries/arrays/tuples just like their Python equivalents), and finally a Variant.unpack() method for converting the return value of a D-Bus call back into a native Python data type. This looks a lot friendlier now: 
from gi.repository import Gio, GLib
d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)
args = GLib.Variant('(susssasa sv i)', ('test', 1, 'gtk-ok', 'Hello World!',
    'Subtext', [],  , 10000))
result = notify.call_sync('Notify', args, 0, -1, None)
id = result.unpack()[0]
print id
I also prepared another patch in GNOME#640181 which will provide the icing on the cake, i. e. handle the variant building/unpacking transparently and make the explicit call_sync() unnecessary: 
from gi.repository import Gio, GLib
d = Gio.bus_get_sync(Gio.BusType.SESSION, None)
notify = Gio.DBusProxy.new_sync(d, 0, None, 'org.freedesktop.Notifications',
    '/org/freedesktop/Notifications', 'org.freedesktop.Notifications', None)
result = notify.Notify('(susssasa sv i)', 'test', 1, 'gtk-ok', 'Hello World!',
            'Subtext', [],  , 10000)
print result[0]
I hope that I can get this reviewed and land this soon. Thanks to our sponsors! Many thanks to the GNOME Foundation and Collabora for sponsoring this event!

14 December 2009

Ond&#345;ej &#268;ert&iacute;k: ESCO 2010 conference

An interesting conference 2nd European Seminar on Coupled Problems (ESCO) will be held on June 28 July 2, 2010 in Pilsen, Czech Republic.
Among the topics are solving PDEs and applications and using Python for scientific computing. In particular, Ga l Varoquaux is the keynote speaker.

Unfortunately, it was later announced that the SciPy 2010 conference is going to be at the same time, which is really unfortunate. But here are some reasons why you should consider going to ESCO 2010 instead:


If you have time, I can fully recommend to go to ESCO 2010.

6 May 2009

Wouter Verhelst: Star Trek

So, as a birthday present to me, I just returned from watching the new movie. Since the official release date is only in two days (but movies are traditionally released on wednesdays in Belgium, so they moved it ahead over here), and since this was in fact the first time it was shown, I guess there's not that many people who've seen it yet. So I won't disclose too many details. I can say that it's an interesting movie. Funny, exciting, and with an unexpected ending. Hrm. Well, no, that's not exactly true; the buildup to the ending starts pretty much halfway in the movie. However, you wouldn't expect it before seeing it, that's for sure. Best joke in the whole movie, in my opinion: Pavel Andrejevitch "wictor, wictor" Checkov trying to authenticate to the computer. "Access code unknown". grin.

28 March 2009

Jordi Mallach: An update on GRUB2

Some time ago I wrote about the the state of GRUB2 and a milestone on getting it boot my Apple PowerBook G4 without manual intervention. More than a year later, GRUB2 has changed and improved a lot, as the community keeps growing and patches and ideas are continously being posted. Some months and commits after my previous post, GRUB broke again on Apple OpenFirmware and I'd get dropped to OF console, the amount of commits since the last known working version and the current SVN was quite big, and although I was able to narrow it to a few suspicious changes, I had no time to bisect it properly, and sadly I had to go back to yaboot for a while. But procrastinating sometimes helps, and when I should have been writing and studying, on December I gave GRUB a new try on my laptop to see if a few important changes to memory allocation would have changed anything. And it did! So after fighting quite a few problems, I was able to report partial success to grub-devel. Again, getting GRUB installed correctly was a bit challenging and needed some hackery, due to incorrectly generated device.map, and the linux module mysteriously not getting loaded. Luckily, Michel D nzer found out that this was due to a bug in sort ordering in the HFS module, which broke the lookup of files with underscores like _linux.mod, and for which he posted a possible fix by taking Linux's table of character ordering, which is a blob of hex values. GRUB developers didn't seem too happy about applying the patch: they argument that a blob like that should be well documented or written in some other more readable way, and there's a possible problem with the mix of Linux GPLv2 and GRUB GPLv3+ codebases, if a table of data like what Michel posted is actually copyrightable. The discussion ended up dying and nothing was done... until Pavel Roskin picked it up weeks later and posted a new patch, based on hfsutils GPLv2+ code, which addressed these issues. The new patch seems to have a few issues, which makes it fail as before, but hopefully it'll be fixed soon. Additionally, I wasn't able to boot using UUIDs as the search commands fails to detect the correct boot device on my system (but not on Michel's), so I had to disable that in /etc/default/grub. To workaround the linux module loading bug while the patch is fixed, I just added this ugly hack to /etc/grub.d/09_local_prelinux: 
#! /bin/sh -e
# Work-around for bugs in the hfs module which makes the load of
# linux.mod fail.
cat << EOF
insmod (hd,3)/usr/lib/grub/powerpc-ieee1275/_linux.mod
insmod linux
EOF
This is enough to get the initrd and linux commands available. However, update-grub will still add search commands to your menu entries even if you disabled UUID support; I can't understand why, but I know it breaks on my PowerBook due to some OF rarety. Just removing the line from the menu entry will leave me with a working config that boots without any manual editing at GRUB prompt. The latest GRUB snapshot in Debian fixes the device.map issue, but adds one last issue: update-grub will fail due to some gfxterm detection code, a workaround is to replace an exit 1 with exit 0 when this happens in /etc/grub.d/00_header. On the weird architectures front, it's worth noting that this month Dave Miller popped up on the list and started posting patches to fix the rotten SPARC port, and I think it's safe to assume that it'll be on an usable state really soon. Impressive!

17 March 2009

Ond&#345;ej &#268;ert&iacute;k: Newtonian Mechanics with SymPy

Luke Peterson from UC Davis came to visit me in Reno and we spent the last weekend hacking on the Python Dynamics package that uses SymPy to calculate equations of motion for basically any rigid body system.

On Friday we did some preliminary work, mostly on the paper, Luke showed me his rolling torus demo that he did with the proprietary autolev package. We set ourselves a goal to get this implemented in SymPy by the time Luke leaves and then we went to the Atlantis casino together with my boss Pavel and other guys from the Desert Research Institute and I had my favourite meal here, a big burger, fries and a beer.

On Saturday we started to code and had couple lines of the autolev torus script working. Then we went on the bike ride from Reno to California. I took some pictures with Luke's iphone:


Those mountains are in California and we went roughly to the snow line level and back:

This is Nevada side:


That was fun. Then we worked hard and by the evening we had a dot product and a cross product working, so we went to an Irish pub to have couple beers and I had my burger as usual.

On Sunday we spent the whole day and evening coding and we got the equations of motion working. On Monday we worked very hard again:



and fixed some remaining nasty bugs. I taught Luke to use git, so our code is at: http://github.com/hazelnusse/pydy, for the time being we call it pydy and after we polish everything, we'll probably put it into sympy/physics/pydy.py. If you run rollingtorus.py, you get this plot of the trajectory of the torus in a plane:

It's basically if you throw a coin on the table, e.g. this model takes into account moments of inertia, yaw (heading), lean, spin and the x-y motion in the plane. Depending on the initial conditions, you can get many different trajectories, e.g for example:

or:


This is very exciting, as the code is very short, and most of the things that Luke needs are needed for all the other applications of sympy, e.g. a good printing of equations and vectors (both in the terminal and in latex), C code generation, fast handling of expressions, nice ipython terminal for experimentation, plotting, etc.

Together with the atomic physics package that we started to develop with Brian sympy will soon be able to cover some basic areas of physics. Other areas are general relativity (there is some preliminary code in examples/advanced/relativity.py) and quantum field theory and Feynman diagrams - for that we need someone enthusiastic that needs this for his/her research --- if you are interested, drop me an email, you can come to Reno (or work remotely) and we can get it done.

My vision is that sympy should be able to handle all areas of physics, e.g. it needs good assumptions (if you want to help out, please help us test Fabian's patches here), then faster core, we have a pretty good optional Cython core here, so we'll be merging it after the new assumptions are in place. Then sympy should have basic modules for most areas in physics so that one can get started really quickly. From our experience so far in sympy/physics, those modules will not be big, as most of the functionality is not module specific.

5 February 2009

Frans Pop: Debian on HP 2510p

In August I got a very nice HP 2510p notebook which is now my main system for development. This took a while for two reasons. First of all the system did not resume 100% reliably. This has now been solved, although the final patches needed for that will only be in 2.6.29, but that's no problem as I run upstream kernels anyway (I do quite a bit of kernel testing). Kudos have to go to Rafael J. Wysocki who has been doing a huge amount of work to improve the suspend/resume code in the kernel. Second of all I wanted a docking station so I could continue to use my 19" monitor, with the laptop's LCD as second display. I bought the docking station in December. The challenge then was to automatically (de)activate the external display when the notebook is (un)docked. Unfortunately there are no ACPI events, but the hp-wmi module (written by Mattew Garrett) sends docking events to the input subsystem. I wrote a small program to catch these events and a script that uses xrandr to switch displays. There were two issues with that setup. The first docking event was getting lost, but I managed to fix that. And the X server would crash when starting some applications (einstein and virtualbox) after undocking, but there's a patch for that too now. The notebook is now really well supported and stable. The system is currently running Debian/lenny with a KDE desktop and a 2.6.29-rc3 kernel. Working with upstream developers to get this far has really been worthwhile, and fun.

16 January 2009

Petr Rockai: darcs 2.2.0

I am happy to announce general availability of darcs 2.2.0. Getting the release For this release, we have decided to provide two flavours, depending on the build system used:
  1. The source tarball, http://www.darcs.net/darcs-2.2.0.tar.gz, which can be built using the traditional autoconf-based system. This is the fully supported version. After downloading and unpacking, you can issue: 
    $ ./configure
$ make
    and possibly 
    # make install
    More detailed instructions inside the tarball (file README). Please note that we had at least one report of build failure, with quickcheck-related message. The currently best workaround, if this happens to you, is to use the cabal version of the package instead, see below.
  2. Cabalised source. You can either download a tarball from http://hackage.haskell.org/packages/archive/darcs/2.2.0/darcs-2.2.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy: 
    $ cabal update
$ cabal install darcs
    This will give you a darcs binary in ~/.cabal/bin you should probably add that to your PATH.
In addition to source tarballs, we expect binary packages for various UNIX platforms will be available in due time. For Windows users, Salvatore Insalaco has prepared a binary build, available from http://homepage.mac.com/kirby81_it/darcs/darcs-2.2.0-win1.zip. You just need to unpack the directory somewhere and add it to your path (if you like). Moreover, an experimental TortoiseDarcs release for darcs 2 has been made available by Kari Hoijarvi and is looking for home. It can be found at http://datafed.net/darcs (unfortunately, at the time of this writing, the site seemed unreachable If you can help with hosting, please mail Kari.) What s New The summary of changes since version 2.1.2 (released last November) follows: And a summary of issues that have been fixed in darcs since version 2.1.2 (compiled by Thorkil Naur): 525 amend-record => darcs patches show duplicate additions
971 darcs check fails (case sensitivity on filenames)
1006 darcs check and repair do not look for adds
1043 pull => mergeAfterConflicting failed in geteff (2.0.2+)
1101 darcs send cc recipient not included in success message
1117 Whatsnew should warn on non-recorded files
1144 Add darcs send in-reply-to or header In-Reply-To: x@y.z
1165 get should print last gotten tag
1196 Asking for changes in /. of directory that doesn t exist gives changes in entire repo
1198 Reproducible mergeConflictingNons failed in geteff with ix
1199 Backup files darcs added after external merge
1223 sporadic init.sh test failure (2.1.1rc2+472)
1238 wish: darcs help setpref should list all prefs
1247 make TAGS is broken
1249 2.1.2 (+ 342 patches) local drive detection on Windows error
1272 amend-record not the same as unrecord + record
1273 renameFile: does not exist (No such file or directory)
1223 sporadic init.sh test failure (2.1.1rc2+472) I would like to thank all contributors for making this release possible. Future The next release will be 2.2.1, fixing low-risk issues found in 2.2.0, or those that have been excluded for 2.2.0 due to freeze. This release will appear in two or three weeks time, depending on circumstances. The next major release will be 2.3, due in June or July this year. The focus of this release will be new features and further work on performance. Moreover, we expect that it will use Cabal as its default build system and will make first steps towards sustainable libdarcs API.

13 January 2009

Petr Rockai: darcs 2.2.0rc1

(This post is somewhat late, the final release is in two days. However, we still need testing and reports of possible issues.) I am pleased to announce that darcs 2.2 is coming along nicely. I would like to ask everyone to give a ride to darcs 2.2, release candidate 1. This release again comes in two flavours:
  1. The source tarball, http://repos.mornfall.net/darcs/darcs-2.2.0rc1.tar.gz, which can be built using the traditional autoconf-based buildsystem. This is the fully supported version. After downloading and unpacking, you can issue: 
    $ ./configure
$ make
$ ./darcs --version
    or 
    # make install
    More detailed instructions inside the tarball (file README).
  2. Cabalised source. You can either download a tarball from http://repos.mornfall.net/darcs/darcs-2.1.99.0.tar.gz and build manually (see the build instructions in README inside the tarball), or, alternatively, you can use cabal-install to obtain a copy (the release candidate is now available on hackage): 
    $ cabal update  
$ cabal install darcs
    This should give you a darcs binary in ~/.cabal/bin you should probably add that to your PATH.
This is a preliminary changelog since version 2.1.2 (released last November): Preliminary list of issues that have been fixed in darcs since version 2.1.2: 1223 sporadic init.sh test failure (2.1.1rc2+472)
525 amend-record => darcs patches show duplicate additions
1247 make TAGS is broken
1273 renameFile: does not exist (No such file or directory)
1165 get should print last gotten tag
1249 2.1.2 (+ 342 patches) local drive detection on Windows error
1238 wish: darcs help setpref should list all prefs
1199 Backup files darcs added after external merge
1043 pull => mergeAfterConflicting failed in geteff (2.0.2+)
1117 Whatsnew should warn on non-recorded files
1101 darcs send cc recipient not included in success message Thanks to Thorkil Naur for compiling this list. I would like to thank all contributors developers, testers, bystanders for helping darcs get along further. It s been hard times recently for darcs, as many of you probably know. Nevertheless, we are regaining confidence in future darcs development. No way are we going to leave darcs fall by the road. I am sure that this one time, I speak for everyone in our developer and user community.

2 April 2008

Wouter Verhelst: nbd 2.9.10

I Just released NBD 2.9.10. It had been upcoming for a while already, with a few interesting patches being applied. In addition, some bugfixes were applied to subversion, and some more interesting things had happened. Really, a release was getting overdue. Sometimes life just intervenes. Anyway, apart from the upstream release, I of course also did a Debian update of these packages, which also contains some changes that had been pending for a while. Combined, the changelog mentions five different bugs of which none are l10n bugs, which is a record (there had been 5-bug uploads before, but those did include l10n bugs). On top of that, I closed some other outstanding bugs which really had been closed a while back, but either I forgot to close the bug, or I forgot that there even was a bug in the first place. I should stop slacking so much. While preparing this upload, it occurred to me that nbd has come a long way since I got involved with it back in 2001. The original nbd-server that Pavel Macheck had written did work well, but it was a bit of a hack; it did not fork() upon startup or anything similar, so starting it was a pain. It could only serve one device at a time. It was not documented. It had no concept of a configuration file. The code, frankly, was also bit of a mess; it was written on a hack night, and not much design had gone into it. I guess it was no surprise, then, that no single distribution had a package for nbd at the time. I only packaged it because I actually had some use for nbd; at the time, I'd just bought quickstep, my first functional m68k machine, and had installed Debian on its 250MB hard disk. However, running a buildd on that machine proved problematic, to say the least; with so little disk space, you could hardly boot Debian, and due to speed and clock skew issues, NFS was not an option. So I went with NBD, which worked great. After a while, quickstep got a bigger hard disk (it has an 18G disk today), so diskspace was less of an issue at that point; but, well, I'd been maintaining it already, and that was fun, so I didn't think of giving up. When Pavel lost interest in nbd back in 2003, he gave maintenance of the kernel bits to Paul Clements, and maintenance of the userspace bits to me. I promptly went ahead with what I thought should have been done already, but felt reluctant to do at the time to suggest that: refactoring the code, adding features, etc. Today, nbd-server does support all of the above things of which I mentioned it was lacking; and, probably as a result of that, apart from Debian, there are now packages of nbd in, at least, SuSE, Fedora, Gentoo, uClibc, and FreeBSD (the latter obviously only containing the server). Well—the fact that LTSP uses it might have something to do with it, too ;-) That's not to say there's nothing left to be done, but I'm quite happy about how far we've come. Really.

9 February 2008

Jordi Mallach: Time for GRUB2?

My Apple Powerbook 5,4 just booted for the first time using GRUB, with no manual intervention, from Apple chime to GDM prompt. This is a great milestone for GRUB2 on powerpc-ieee1275 and OpenFirmware, as until now, multiple problems in the loader would drop you to OF console straight away, although other PowerPC hardware with other firmware implementations did manage to work. Recent fixes by Pavel in the core and some other minor fixes for the userland utils have taken grub2 to the point where it is usable on most PowerPC hardware. On Apple, the only minor issue remaining is grub-probe insisting on (hd) not being a valid device name, so for now I have to trick it into believing it's really (hd1). In parallel, many other GRUB2 improvements haven't stopped hitting CVS in the last months, which have seen how new contributors joined grub-devel and helped GRUB2 get the great momentum it's enjoying right now. Vesa, Robert and Bean have been really active lately, and have fixed long standing issues or written a lot of new code. One of the features GRUB2 acquired recently was image loading for background images. Much more powerful than the implementation in GRUB Legacy, GRUB2 can now read images in multiple formats, can handle up to 24bit colour and render a menu in arbitrary resolutions. The menu can now show UTF-8, and the Debian package will configure a pretty theme that matches the rest of the system if desktop-base is installed:


GRUB2 speaking UTF-8 Catalan Although I'm not sure if GRUB2 is completely up-to-par with GRUB Legacy on i386/amd64, it seems the tricky bits, like video, LVM, RAID and the standard filesystems are supported and working. What GRUB2 needs now, in order to finally replace the aging and upstream-lacking GRUB Legacy you probably have installed, is massive testing. Debian has traditionally been a testbed for GRUB Legacy patches, and is also the platform where GRUB2 is being more widely tested. Having GRUB2 included in lenny's debian-installer would be a great step forward, and by the looks, I think we're well on time to manage this. Replacing GRUB Legacy with GRUB2 is trivial. On PCs, just install the grub-pc package. You'll be offered to keep GRUB Legacy, but with an added menu entry to chainload GRUB2. If you're worried that GRUB2 might fail on your hardware, accept this, and try to load GRUB2 from GRUB. If it works, you then know you can get rid of GRUB Legacy completely and keep GRUB2 in the MBR. On PowerPC-based Macs, you'll have to work around the small issue I mentioned above. Install the grub-ieee1275 package. You also need a very recent powerpc-ibm-utils package, which was just uploaded to unstable. Mount your bootstrap partition, probably /dev/hda2 in /boot/grub, and generate a device.map file with grub-mkdevicemap. Check the contents. If your first device name lacks a drive number such as (hd), it's probably correct, although this will make things fail later. Change it to (hd0) for now. As grub-install relies on grub-probe, you'll have to generate your grub image by hand. Copy all .mod files in /usr/lib/grub/powerpc-ieee1275 to your bootstrap partition, and generate a core.img: 

root@powerpc:/boot/grub# grub-mkimage -d . -o /boot/grub/core.img *.mod
root@powerpc:/boot/grub# update-grub
root@powerpc:/boot/grub# nvsetenv boot-device hd:2,core.img
The generated grub.cfg will have references to (hd0,X), which you'll have to correct back to (hd,X) if necessary for your OpenFirmware. After this, you are probably ready to reboot, cross two fingers and get a warm "Welcome to GNU GRUB!" message at boot, which will then be followed by a standard GRUB menu, but on your nice PowerPC box. Unfortunately, the eye candy in the screenshot above isn't available yet in this platform, as it lacks VESA. Does someone in the audience want to contribute a video driver for powerpc? :)

6 August 2007

Michal &#268;iha&#345;: Gammu test version 1.12.93

I just released new version of Gammu. This release brings lots of bug fixes and should allow to compile Gammu using MSVC and CMake. Full list of changes:

5 June 2007

Martin-&#201;ric Racine: Award to the Debian community of Finland

Open Source 2006 is a one-day seminar that provides Free Software actors of Finland with a forum to present their work and the current trends in Free Software development to a greater audience comprised mainly of decision-makers from the business and governmental sectors. Finnish Open Office localization team This year, a noticeable trend were governmental cases of transition to Open Office and other Free Software solutions on the municipal desktop. Thus, it was only fitting that Finnish localization took greater importance than before and, in concordance, that this year's Linux-tekij award went to the Finnish Open Office localization team. The jury invited 3 people from the localization team to receive the award on their team's behalf: Pastor Koskinen also gave a very stimulating lecture on the collaborative effort behind the localization, mentioning in passing that Czech Pavel Jani k also plays an important role in building the Open Office binaries for a number of Baltic and Scandinavian languages. Debian community of Finland The jury also granted an honorary mention to the Debian community of Finland to acknowledge years of achievements, reaching an important milestone in 2005 when Finland hosted the yearly Debian Conference. Another motivation was a number of nominations for Ubuntu, both as a distribution and for its extremely active local user community. Given how a majority of Ubuntu developers actually are Debian Developers, the jury unanimously decided to honor them collectively from the perspective of Debian and its derivatives. The jury invited 3 people to receive the honorary mention on the community's behalf: Lars gave the audience a very interesting perspective of his long involvement with Debian, while Tapio emphasized particular pride in seeing non-programmers that maintain documentation or localize software be acknowledged. Fabian gave a very emotional speech in which he praised the commendable efforts of dozens of volunteer DebConf5 organizers that discretely handled unpleasant tasks that were nonetheless essential to the success of the event. The Jury Yours truly was invited to join the jury on behalf of Linux Aktivaattori, alongside representatives from the academic, business and Free Software communities. During the prize ceremony, FLUG chairman Arto Ter s and myself took turns at describing the award's selection process and at introducing the winners.

Next.