Search Results: "olek"

19 January 2023

Antoine Beaupr : Mastodon comments in ikiwiki

Today I noticed bounces in my mail box. They were from ikiwiki trying to send registration confirmation email to users who probably never asked for it. I'm getting truly fed up with spam in my wiki. At this point, all comments are manually approved and I still get trouble: now it's scammers spamming the registration form with dummy accounts, which bounce back to me when I make new posts, or just generate backscatter spam for the confirmation email. It's really bad. I have hundreds of users registered on my blog, and I don't know which are spammy, which aren't. So. I'm considering ditching ikiwiki comments altogether. I am testing Mastodon as a commenting platforms. Others (e.g. JAK) have implemented this as a server but a simpler approach is toload them dynamically from Mastodon, which is what Carl Shwan has done. They are using Hugo, however, so they can easily embed page metadata in the template to load the right server with the right comment ID. I wasn't sure how to do this in ikiwiki: it's typically hard to access page-specific metadata in templates. Even the page name is not there, for example. I have tried using templates, and that (obviously?) fails because the <script> stuff gets sanitized away. It seems I would need to split the JavaScript out of the template into a base template and then make the page template refer to a function in there. It's kind of horrible and messy. I wish there was a way to just access page metadata from the page template itself... I found out the meta plugin passes along its metadata, but that's not (easily) extensible. So i'd need to either patch that module, and my history of merged patches is not great so far. So: another plugin. I have something that kind of works that's a combination of a page.tmpl patch and a plugin. The plugin adds a mastodon directive that feeds the page.tmpl with the right stuff. On clicking a button, it injects comments from the Mastodon API, with a JavaScript callback. It's not pretty (it's not themed at all!), but it works. If you want to do this at home, you need this page.tmpl (or at least this patch and that one) and the mastodon.pm plugin from my mastodon-plugin branch. I'm not sure this is a good idea. The first test I did was a "test comment" which led to half a dozen "test reply". I then realized I couldn't redact individual posts from there. I don't even know if, when I mute a user, it actually gets hidden from everyone else too... So I'll test this for a while, I guess. I have also turned off all CGI on this site. It will keep users from registering while I cleanup this mess and think about next steps. I have other options as well if push comes to shove, but I'm unlikely to go back to ikiwiki comments. Mastodon comments are nice because they don't require me to run any extra software: either I have my own federated service I reuse, or I use someone else's, but I don't need to run something extra. And, of course, comments are published in a standard way that's interoperable with everything... On the other hand, now I won't have comments enabled until the blog is posted on Mastodon... Right now this happens only when feed2exec runs and the HTTP cache expires, which can take up to a day. I should probably do this some other way, like flush the cache when a new post arrives, or run post-commit hooks, but for now, this will have to do. Update: I figured out a way to make this work in a timely manner:
  1. there's a post-merge hook in my ikiwiki git repository which calls feed2exec in /home/w-anarcat/source/.git/hooks/ took me a while to find it! I tried post-update and post-receive first, but ikiwiki actually pulls from the bare directory in the source directory, so only post-merge fires (even though it's not a merge)
  2. feed2exec then finds new blog posts (if any!) and fires up the new ikiwikitoot plugin which then...
  3. posts the toot using the toot command (it just works, why reinvent the wheel), keeping the toot URL
  4. finds the Markdown source file associated with the post, and adds the magic mastodon directive
  5. commits and pushes the result
This will make the interaction with Mastodon much smoother: as soon as a blog post is out of "draft" (i.e. when it hits the RSS feeds), this will immediately trigger and post the blog entry to Mastodon, enabling comments. It's kind of a tangled mess of stuff, but it works! I have briefly considered not using feed2exec for this, but it turns out it does an important job of parsing the result of ikiwiki's rendering. Otherwise I would have to guess which post is really a blog post, is this just an update or is it new, is it a draft, and so on... all sorts of questions where the business logic already resides in ikiwiki, and that I would need to reimplement myself. Plus it goes alongside moving more stuff (like my feed reader) to dedicated UNIX accounts (in this case, the blog sandbox) for security reasons. Whee!

16 November 2022

Antoine Beaupr : Wayland: i3 to Sway migration

I started migrating my graphical workstations to Wayland, specifically migrating from i3 to Sway. This is mostly to address serious graphics bugs in the latest Framwork laptop, but also something I felt was inevitable. The current status is that I've been able to convert my i3 configuration to Sway, and adapt my systemd startup sequence to the new environment. Screen sharing only works with Pipewire, so I also did that migration, which basically requires an upgrade to Debian bookworm to get a nice enough Pipewire release. I'm testing Wayland on my laptop, but I'm not using it as a daily driver because I first need to upgrade to Debian bookworm on my main workstation. Most irritants have been solved one way or the other. My main problem with Wayland right now is that I spent a frigging week doing the conversion: it's exciting and new, but it basically sucked the life out of all my other projects and it's distracting, and I want it to stop. The rest of this page documents why I made the switch, how it happened, and what's left to do. Hopefully it will keep you from spending as much time as I did in fixing this. TL;DR: Wayland is mostly ready. Main blockers you might find are that you need to do manual configurations, DisplayLink (multiple monitors on a single cable) doesn't work in Sway, HDR and color management are still in development. I had to install the following packages:
apt install \
    brightnessctl \
    foot \
    gammastep \
    gdm3 \
    grim slurp \
    pipewire-pulse \
    sway \
    swayidle \
    swaylock \
    wdisplays \
    wev \
    wireplumber \
    wlr-randr \
    xdg-desktop-portal-wlr
And did some of tweaks in my $HOME, mostly dealing with my esoteric systemd startup sequence, which you won't have to deal with if you are not a fan.

Why switch? I originally held back from migrating to Wayland: it seemed like a complicated endeavor hardly worth the cost. It also didn't seem actually ready. But after reading this blurb on LWN, I decided to at least document the situation here. The actual quote that convinced me it might be worth it was:
It s amazing. I have never experienced gaming on Linux that looked this smooth in my life.
... I'm not a gamer, but I do care about latency. The longer version is worth a read as well. The point here is not to bash one side or the other, or even do a thorough comparison. I start with the premise that Xorg is likely going away in the future and that I will need to adapt some day. In fact, the last major Xorg release (21.1, October 2021) is rumored to be the last ("just like the previous release...", that said, minor releases are still coming out, e.g. 21.1.4). Indeed, it seems even core Xorg people have moved on to developing Wayland, or at least Xwayland, which was spun off it its own source tree. X, or at least Xorg, in in maintenance mode and has been for years. Granted, the X Window System is getting close to forty years old at this point: it got us amazingly far for something that was designed around the time the first graphical interface. Since Mac and (especially?) Windows released theirs, they have rebuilt their graphical backends numerous times, but UNIX derivatives have stuck on Xorg this entire time, which is a testament to the design and reliability of X. (Or our incapacity at developing meaningful architectural change across the entire ecosystem, take your pick I guess.) What pushed me over the edge is that I had some pretty bad driver crashes with Xorg while screen sharing under Firefox, in Debian bookworm (around November 2022). The symptom would be that the UI would completely crash, reverting to a text-only console, while Firefox would keep running, audio and everything still working. People could still see my screen, but I couldn't, of course, let alone interact with it. All processes still running, including Xorg. (And no, sorry, I haven't reported that bug, maybe I should have, and it's actually possible it comes up again in Wayland, of course. But at first, screen sharing didn't work of course, so it's coming a much further way. After making screen sharing work, though, the bug didn't occur again, so I consider this a Xorg-specific problem until further notice.) There were also frustrating glitches in the UI, in general. I actually had to setup a compositor alongside i3 to make things bearable at all. Video playback in a window was laggy, sluggish, and out of sync. Wayland fixed all of this.

Wayland equivalents This section documents each tool I have picked as an alternative to the current Xorg tool I am using for the task at hand. It also touches on other alternatives and how the tool was configured. Note that this list is based on the series of tools I use in desktop. TODO: update desktop with the following when done, possibly moving old configs to a ?xorg archive.

Window manager: i3 sway This seems like kind of a no-brainer. Sway is around, it's feature-complete, and it's in Debian. I'm a bit worried about the "Drew DeVault community", to be honest. There's a certain aggressiveness in the community I don't like so much; at least an open hostility towards more modern UNIX tools like containers and systemd that make it hard to do my work while interacting with that community. I'm also concern about the lack of unit tests and user manual for Sway. The i3 window manager has been designed by a fellow (ex-)Debian developer I have a lot of respect for (Michael Stapelberg), partly because of i3 itself, but also working with him on other projects. Beyond the characters, i3 has a user guide, a code of conduct, and lots more documentation. It has a test suite. Sway has... manual pages, with the homepage just telling users to use man -k sway to find what they need. I don't think we need that kind of elitism in our communities, to put this bluntly. But let's put that aside: Sway is still a no-brainer. It's the easiest thing to migrate to, because it's mostly compatible with i3. I had to immediately fix those resources to get a minimal session going:
i3 Sway note
set_from_resources set no support for X resources, naturally
new_window pixel 1 default_border pixel 1 actually supported in i3 as well
That's it. All of the other changes I had to do (and there were actually a lot) were all Wayland-specific changes, not Sway-specific changes. For example, use brightnessctl instead of xbacklight to change the backlight levels. See a copy of my full sway/config for details. Other options include:
  • dwl: tiling, minimalist, dwm for Wayland, not in Debian
  • Hyprland: tiling, fancy animations, not in Debian
  • Qtile: tiling, extensible, in Python, not in Debian (1015267)
  • river: Zig, stackable, tagging, not in Debian (1006593)
  • velox: inspired by xmonad and dwm, not in Debian
  • vivarium: inspired by xmonad, not in Debian

Status bar: py3status waybar I have invested quite a bit of effort in setting up my status bar with py3status. It supports Sway directly, and did not actually require any change when migrating to Wayland. Unfortunately, I had trouble making nm-applet work. Based on this nm-applet.service, I found that you need to pass --indicator for it to show up at all. In theory, tray icon support was merged in 1.5, but in practice there are still several limitations, like icons not clickable. Also, on startup, nm-applet --indicator triggers this error in the Sway logs:
nov 11 22:34:12 angela sway[298938]: 00:49:42.325 [INFO] [swaybar/tray/host.c:24] Registering Status Notifier Item ':1.47/org/ayatana/NotificationItem/nm_applet'
nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet IconPixmap: No such property  IconPixmap 
nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet AttentionIconPixmap: No such property  AttentionIconPixmap 
nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet ItemIsMenu: No such property  ItemIsMenu 
nov 11 22:36:10 angela sway[313419]: info: fcft.c:838: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: size=24.00pt/32px, dpi=96.00
... but that seems innocuous. The tray icon displays but is not clickable. Note that there is currently (November 2022) a pull request to hook up a "Tray D-Bus Menu" which, according to Reddit might fix this, or at least be somewhat relevant. If you don't see the icon, check the bar.tray_output property in the Sway config, try: tray_output *. The non-working tray was the biggest irritant in my migration. I have used nmtui to connect to new Wifi hotspots or change connection settings, but that doesn't support actions like "turn off WiFi". I eventually fixed this by switching from py3status to waybar, which was another yak horde shaving session, but ultimately, it worked.

Web browser: Firefox Firefox has had support for Wayland for a while now, with the team enabling it by default in nightlies around January 2022. It's actually not easy to figure out the state of the port, the meta bug report is still open and it's huge: it currently (Sept 2022) depends on 76 open bugs, it was opened twelve (2010) years ago, and it's still getting daily updates (mostly linking to other tickets). Firefox 106 presumably shipped with "Better screen sharing for Windows and Linux Wayland users", but I couldn't quite figure out what those were. TL;DR: echo MOZ_ENABLE_WAYLAND=1 >> ~/.config/environment.d/firefox.conf && apt install xdg-desktop-portal-wlr

How to enable it Firefox depends on this silly variable to start correctly under Wayland (otherwise it starts inside Xwayland and looks fuzzy and fails to screen share):
MOZ_ENABLE_WAYLAND=1 firefox
To make the change permanent, many recipes recommend adding this to an environment startup script:
if [ "$XDG_SESSION_TYPE" == "wayland" ]; then
    export MOZ_ENABLE_WAYLAND=1
fi
At least that's the theory. In practice, Sway doesn't actually run any startup shell script, so that can't possibly work. Furthermore, XDG_SESSION_TYPE is not actually set when starting Sway from gdm3 which I find really confusing, and I'm not the only one. So the above trick doesn't actually work, even if the environment (XDG_SESSION_TYPE) is set correctly, because we don't have conditionals in environment.d(5). (Note that systemd.environment-generator(7) do support running arbitrary commands to generate environment, but for some some do not support user-specific configuration files... Even then it may be a solution to have a conditional MOZ_ENABLE_WAYLAND environment, but I'm not sure it would work because ordering between those two isn't clear: maybe the XDG_SESSION_TYPE wouldn't be set just yet...) At first, I made this ridiculous script to workaround those issues. Really, it seems to me Firefox should just parse the XDG_SESSION_TYPE variable here... but then I realized that Firefox works fine in Xorg when the MOZ_ENABLE_WAYLAND is set. So now I just set that variable in environment.d and It Just Works :
MOZ_ENABLE_WAYLAND=1

Screen sharing Out of the box, screen sharing doesn't work until you install xdg-desktop-portal-wlr or similar (e.g. xdg-desktop-portal-gnome on GNOME). I had to reboot for the change to take effect. Without those tools, it shows the usual permission prompt with "Use operating system settings" as the only choice, but when we accept... nothing happens. After installing the portals, it actualyl works, and works well! This was tested in Debian bookworm/testing with Firefox ESR 102 and Firefox 106. Major caveat: we can only share a full screen, we can't currently share just a window. The major upside to that is that, by default, it streams only one output which is actually what I want most of the time! See the screencast compatibility for more information on what is supposed to work. This is actually a huge improvement over the situation in Xorg, where Firefox can only share a window or all monitors, which led me to use Chromium a lot for video-conferencing. With this change, in other words, I will not need Chromium for anything anymore, whoohoo! If slurp, wofi, or bemenu are installed, one of them will be used to pick the monitor to share, which effectively acts as some minimal security measure. See xdg-desktop-portal-wlr(1) for how to configure that.

Side note: Chrome fails to share a full screen I was still using Google Chrome (or, more accurately, Debian's Chromium package) for some videoconferencing. It's mainly because Chromium was the only browser which will allow me to share only one of my two monitors, which is extremely useful. To start chrome with the Wayland backend, you need to use:
chromium  -enable-features=UseOzonePlatform -ozone-platform=wayland
If it shows an ugly gray border, check the Use system title bar and borders setting. It can do some screensharing. Sharing a window and a tab seems to work, but sharing a full screen doesn't: it's all black. Maybe not ready for prime time. And since Firefox can do what I need under Wayland now, I will not need to fight with Chromium to work under Wayland:
apt purge chromium
Note that a similar fix was necessary for Signal Desktop, see this commit. Basically you need to figure out a way to pass those same flags to signal:
--enable-features=WaylandWindowDecorations --ozone-platform-hint=auto

Email: notmuch See Emacs, below.

File manager: thunar Unchanged.

News: feed2exec, gnus See Email, above, or Emacs in Editor, below.

Editor: Emacs okay-ish Emacs is being actively ported to Wayland. According to this LWN article, the first (partial, to Cairo) port was done in 2014 and a working port (to GTK3) was completed in 2021, but wasn't merged until late 2021. That is: after Emacs 28 was released (April 2022). So we'll probably need to wait for Emacs 29 to have native Wayland support in Emacs, which, in turn, is unlikely to arrive in time for the Debian bookworm freeze. There are, however, unofficial builds for both Emacs 28 and 29 provided by spwhitton which may provide native Wayland support. I tested the snapshot packages and they do not quite work well enough. First off, they completely take over the builtin Emacs they hijack the $PATH in /etc! and certain things are simply not working in my setup. For example, this hook never gets ran on startup:
(add-hook 'after-init-hook 'server-start t) 
Still, like many X11 applications, Emacs mostly works fine under Xwayland. The clipboard works as expected, for example. Scaling is a bit of an issue: fonts look fuzzy. I have heard anecdotal evidence of hard lockups with Emacs running under Xwayland as well, but haven't experienced any problem so far. I did experience a Wayland crash with the snapshot version however. TODO: look again at Wayland in Emacs 29.

Backups: borg Mostly irrelevant, as I do not use a GUI.

Color theme: srcery, redshift gammastep I am keeping Srcery as a color theme, in general. Redshift is another story: it has no support for Wayland out of the box, but it's apparently possible to apply a hack on the TTY before starting Wayland, with:
redshift -m drm -PO 3000
This tip is from the arch wiki which also has other suggestions for Wayland-based alternatives. Both KDE and GNOME have their own "red shifters", and for wlroots-based compositors, they (currently, Sept. 2022) list the following alternatives: I configured gammastep with a simple gammastep.service file associated with the sway-session.target.

Display manager: lightdm gdm3 Switched because lightdm failed to start sway:
nov 16 16:41:43 angela sway[843121]: 00:00:00.002 [ERROR] [wlr] [libseat] [common/terminal.c:162] Could not open target tty: Permission denied
Possible alternatives:

Terminal: xterm foot One of the biggest question mark in this transition was what to do about Xterm. After writing two articles about terminal emulators as a professional journalist, decades of working on the terminal, and probably using dozens of different terminal emulators, I'm still not happy with any of them. This is such a big topic that I actually have an entire blog post specifically about this. For starters, using xterm under Xwayland works well enough, although the font scaling makes things look a bit too fuzzy. I have also tried foot: it ... just works! Fonts are much crisper than Xterm and Emacs. URLs are not clickable but the URL selector (control-shift-u) is just plain awesome (think "vimperator" for the terminal). There's cool hack to jump between prompts. Copy-paste works. True colors work. The word-wrapping is excellent: it doesn't lose one byte. Emojis are nicely sized and colored. Font resize works. There's even scroll back search (control-shift-r). Foot went from a question mark to being a reason to switch to Wayland, just for this little goodie, which says a lot about the quality of that software. The selection clicks are a not quite what I would expect though. In rxvt and others, you have the following patterns:
  • single click: reset selection, or drag to select
  • double: select word
  • triple: select quotes or line
  • quadruple: select line
I particularly find the "select quotes" bit useful. It seems like foot just supports double and triple clicks, with word and line selected. You can select a rectangle with control,. It correctly extends the selection word-wise with right click if double-click was first used. One major problem with Foot is that it's a new terminal, with its own termcap entry. Support for foot was added to ncurses in the 20210731 release, which was shipped after the current Debian stable release (Debian bullseye, which ships 6.2+20201114-2). A workaround for this problem is to install the foot-terminfo package on the remote host, which is available in Debian stable. This should eventually resolve itself, as Debian bookworm has a newer version. Note that some corrections were also shipped in the 20211113 release, but that is also shipped in Debian bookworm. That said, I am almost certain I will have to revert back to xterm under Xwayland at some point in the future. Back when I was using GNOME Terminal, it would mostly work for everything until I had to use the serial console on a (HP ProCurve) network switch, which have a fancy TUI that was basically unusable there. I fully expect such problems with foot, or any other terminal than xterm, for that matter. The foot wiki has good troubleshooting instructions as well. Update: I did find one tiny thing to improve with foot, and it's the default logging level which I found pretty verbose. After discussing it with the maintainer on IRC, I submitted this patch to tweak it, which I described like this on Mastodon:
today's reason why i will go to hell when i die (TRWIWGTHWID?): a 600-word, 63 lines commit log for a one line change: https://codeberg.org/dnkl/foot/pulls/1215
It's Friday.

Launcher: rofi rofi?? rofi does not support Wayland. There was a rather disgraceful battle in the pull request that led to the creation of a fork (lbonn/rofi), so it's unclear how that will turn out. Given how relatively trivial problem space is, there is of course a profusion of options:
Tool In Debian Notes
alfred yes general launcher/assistant tool
bemenu yes, bookworm+ inspired by dmenu
cerebro no Javascript ... uh... thing
dmenu-wl no fork of dmenu, straight port to Wayland
Fuzzel ITP 982140 dmenu/drun replacement, app icon overlay
gmenu no drun replacement, with app icons
kickoff no dmenu/run replacement, fuzzy search, "snappy", history, copy-paste, Rust
krunner yes KDE's runner
mauncher no dmenu/drun replacement, math
nwg-launchers no dmenu/drun replacement, JSON config, app icons, nwg-shell project
Onagre no rofi/alfred inspired, multiple plugins, Rust
menu no dmenu/drun rewrite
Rofi (lbonn's fork) no see above
sirula no .desktop based app launcher
Ulauncher ITP 949358 generic launcher like Onagre/rofi/alfred, might be overkill
tofi yes, bookworm+ dmenu/drun replacement, C
wmenu no fork of dmenu-wl, but mostly a rewrite
Wofi yes dmenu/drun replacement, not actively maintained
yofi no dmenu/drun replacement, Rust
The above list comes partly from https://arewewaylandyet.com/ and awesome-wayland. It is likely incomplete. I have read some good things about bemenu, fuzzel, and wofi. A particularly tricky option is that my rofi password management depends on xdotool for some operations. At first, I thought this was just going to be (thankfully?) impossible, because we actually like the idea that one app cannot send keystrokes to another. But it seems there are actually alternatives to this, like wtype or ydotool, the latter which requires root access. wl-ime-type does that through the input-method-unstable-v2 protocol (sample emoji picker, but is not packaged in Debian. As it turns out, wtype just works as expected, and fixing this was basically a two-line patch. Another alternative, not in Debian, is wofi-pass. The other problem is that I actually heavily modified rofi. I use "modis" which are not actually implemented in wofi or tofi, so I'm left with reinventing those wheels from scratch or using the rofi + wayland fork... It's really too bad that fork isn't being reintegrated... For now, I'm actually still using rofi under Xwayland. The main downside is that fonts are fuzzy, but it otherwise just works. Note that wlogout could be a partial replacement (just for the "power menu").

Image viewers: geeqie ? I'm not very happy with geeqie in the first place, and I suspect the Wayland switch will just make add impossible things on top of the things I already find irritating (Geeqie doesn't support copy-pasting images). In practice, Geeqie doesn't seem to work so well under Wayland. The fonts are fuzzy and the thumbnail preview just doesn't work anymore (filed as Debian bug 1024092). It seems it also has problems with scaling. Alternatives: See also this list and that list for other list of image viewers, not necessarily ported to Wayland. TODO: pick an alternative to geeqie, nomacs would be gorgeous if it wouldn't be basically abandoned upstream (no release since 2020), has an unpatched CVE-2020-23884 since July 2020, does bad vendoring, and is in bad shape in Debian (4 minor releases behind). So for now I'm still grumpily using Geeqie.

Media player: mpv, gmpc / sublime This is basically unchanged. mpv seems to work fine under Wayland, better than Xorg on my new laptop (as mentioned in the introduction), and that before the version which improves Wayland support significantly, by bringing native Pipewire support and DMA-BUF support. gmpc is more of a problem, mainly because it is abandoned. See 2022-08-22-gmpc-alternatives for the full discussion, one of the alternatives there will likely support Wayland. Finally, I might just switch to sublime-music instead... In any case, not many changes here, thankfully.

Screensaver: xsecurelock swaylock I was previously using xss-lock and xsecurelock as a screensaver, with xscreensaver "hacks" as a backend for xsecurelock. The basic screensaver in Sway seems to be built with swayidle and swaylock. It's interesting because it's the same "split" design as xss-lock and xsecurelock. That, unfortunately, does not include the fancy "hacks" provided by xscreensaver, and that is unlikely to be implemented upstream. Other alternatives include gtklock and waylock (zig), which do not solve that problem either. It looks like swaylock-plugin, a swaylock fork, which at least attempts to solve this problem, although not directly using the real xscreensaver hacks. swaylock-effects is another attempt at this, but it only adds more effects, it doesn't delegate the image display. Other than that, maybe it's time to just let go of those funky animations and just let swaylock do it's thing, which is display a static image or just a black screen, which is fine by me. In the end, I am just using swayidle with a configuration based on the systemd integration wiki page but with additional tweaks from this service, see the resulting swayidle.service file. Interestingly, damjan also has a service for swaylock itself, although it's not clear to me what its purpose is...

Screenshot: maim grim, pubpaste I'm a heavy user of maim (and a package uploader in Debian). It looks like the direct replacement to maim (and slop) is grim (and slurp). There's also swappy which goes on top of grim and allows preview/edit of the resulting image, nice touch (not in Debian though). See also awesome-wayland screenshots for other alternatives: there are many, including X11 tools like Flameshot that also support Wayland. One key problem here was that I have my own screenshot / pastebin software which will needed an update for Wayland as well. That, thankfully, meant actually cleaning up a lot of horrible code that involved calling xterm and xmessage for user interaction. Now, pubpaste uses GTK for prompts and looks much better. (And before anyone freaks out, I already had to use GTK for proper clipboard support, so this isn't much of a stretch...)

Screen recorder: simplescreenrecorder wf-recorder In Xorg, I have used both peek or simplescreenrecorder for screen recordings. The former will work in Wayland, but has no sound support. The latter has a fork with Wayland support but it is limited and buggy ("doesn't support recording area selection and has issues with multiple screens"). It looks like wf-recorder will just do everything correctly out of the box, including audio support (with --audio, duh). It's also packaged in Debian. One has to wonder how this works while keeping the "between app security" that Wayland promises, however... Would installing such a program make my system less secure? Many other options are available, see the awesome Wayland screencasting list.

RSI: workrave nothing? Workrave has no support for Wayland. activity watch is a time tracker alternative, but is not a RSI watcher. KDE has rsiwatcher, but that's a bit too much on the heavy side for my taste. SafeEyes looks like an alternative at first, but it has many issues under Wayland (escape doesn't work, idle doesn't work, it just doesn't work really). timekpr-next could be an alternative as well, and has support for Wayland. I am also considering just abandoning workrave, even if I stick with Xorg, because it apparently introduces significant latency in the input pipeline. And besides, I've developed a pretty unhealthy alert fatigue with Workrave. I have used the program for so long that my fingers know exactly where to click to dismiss those warnings very effectively. It makes my work just more irritating, and doesn't fix the fundamental problem I have with computers.

Other apps This is a constantly changing list, of course. There's a bit of a "death by a thousand cuts" in migrating to Wayland because you realize how many things you were using are tightly bound to X.
  • .Xresources - just say goodbye to that old resource system, it was used, in my case, only for rofi, xterm, and ... Xboard!?
  • keyboard layout switcher: built-in to Sway since 2017 (PR 1505, 1.5rc2+), requires a small configuration change, see this answer as well, looks something like this command:
     swaymsg input 0:0:X11_keyboard xkb_layout de
    
    or using this config:
     input *  
         xkb_layout "ca,us"
         xkb_options "grp:sclk_toggle"
      
    
    That works refreshingly well, even better than in Xorg, I must say. swaykbdd is an alternative that supports per-window layouts (in Debian).
  • wallpaper: currently using feh, will need a replacement, TODO: figure out something that does, like feh, a random shuffle. swaybg just loads a single image, duh. oguri might be a solution, but unmaintained, used here, not in Debian. wallutils is another option, also not in Debian. For now I just don't have a wallpaper, the background is a solid gray, which is better than Xorg's default (which is whatever crap was left around a buffer by the previous collection of programs, basically)
  • notifications: currently using dunst in some places, which works well in both Xorg and Wayland, not a blocker, salut a possible alternative (not in Debian), damjan uses mako. TODO: install dunst everywhere
  • notification area: I had trouble making nm-applet work. based on this nm-applet.service, I found that you need to pass --indicator. In theory, tray icon support was merged in 1.5, but in practice there are still several limitations, like icons not clickable. On startup, nm-applet --indicator triggers this error in the Sway logs:
     nov 11 22:34:12 angela sway[298938]: 00:49:42.325 [INFO] [swaybar/tray/host.c:24] Registering Status Notifier Item ':1.47/org/ayatana/NotificationItem/nm_applet'
     nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet IconPixmap: No such property  IconPixmap 
     nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet AttentionIconPixmap: No such property  AttentionIconPixmap 
     nov 11 22:34:12 angela sway[298938]: 00:49:42.327 [ERROR] [swaybar/tray/item.c:127] :1.47/org/ayatana/NotificationItem/nm_applet ItemIsMenu: No such property  ItemIsMenu 
     nov 11 22:36:10 angela sway[313419]: info: fcft.c:838: /usr/share/fonts/truetype/dejavu/DejaVuSans.ttf: size=24.00pt/32px, dpi=96.00
    
    ... but it seems innocuous. The tray icon displays but, as stated above, is not clickable. If you don't see the icon, check the bar.tray_output property in the Sway config, try: tray_output *. Note that there is currently (November 2022) a pull request to hook up a "Tray D-Bus Menu" which, according to Reddit might fix this, or at least be somewhat relevant. This was the biggest irritant in my migration. I have used nmtui to connect to new Wifi hotspots or change connection settings, but that doesn't support actions like "turn off WiFi". I eventually fixed this by switching from py3status to waybar.
  • window switcher: in i3 I was using this bespoke i3-focus script, which doesn't work under Sway, swayr an option, not in Debian. So I put together this other bespoke hack from multiple sources, which works.
  • PDF viewer: currently using atril (which supports Wayland), could also just switch to zatura/mupdf permanently, see also calibre for a discussion on document viewers
See also this list of useful addons and this other list for other app alternatives.

More X11 / Wayland equivalents For all the tools above, it's not exactly clear what options exist in Wayland, or when they do, which one should be used. But for some basic tools, it seems the options are actually quite clear. If that's the case, they should be listed here:
X11 Wayland In Debian
arandr wdisplays yes
autorandr kanshi yes
xdotool wtype yes
xev wev yes
xlsclients swaymsg -t get_tree yes
xrandr wlr-randr yes
lswt is a more direct replacement for xlsclients but is not packaged in Debian. See also: Note that arandr and autorandr are not directly part of X. arewewaylandyet.com refers to a few alternatives. We suggest wdisplays and kanshi above (see also this service file) but wallutils can also do the autorandr stuff, apparently, and nwg-displays can do the arandr part. Neither are packaged in Debian yet. So I have tried wdisplays and it Just Works, and well. The UI even looks better and more usable than arandr, so another clean win from Wayland here. TODO: test kanshi as a autorandr replacement

Other issues

systemd integration I've had trouble getting session startup to work. This is partly because I had a kind of funky system to start my session in the first place. I used to have my whole session started from .xsession like this:
#!/bin/sh
. ~/.shenv
systemctl --user import-environment
exec systemctl --user start --wait xsession.target
But obviously, the xsession.target is not started by the Sway session. It seems to just start a default.target, which is really not what we want because we want to associate the services directly with the graphical-session.target, so that they don't start when logging in over (say) SSH. damjan on #debian-systemd showed me his sway-setup which features systemd integration. It involves starting a different session in a completely new .desktop file. That work was submitted upstream but refused on the grounds that "I'd rather not give a preference to any particular init system." Another PR was abandoned because "restarting sway does not makes sense: that kills everything". The work was therefore moved to the wiki. So. Not a great situation. The upstream wiki systemd integration suggests starting the systemd target from within Sway, which has all sorts of problems:
  • you don't get Sway logs anywhere
  • control groups are all messed up
I have done a lot of work trying to figure this out, but I remember that starting systemd from Sway didn't actually work for me: my previously configured systemd units didn't correctly start, and especially not with the right $PATH and environment. So I went down that rabbit hole and managed to correctly configure Sway to be started from the systemd --user session. I have partly followed the wiki but also picked ideas from damjan's sway-setup and xdbob's sway-services. Another option is uwsm (not in Debian). This is the config I have in .config/systemd/user/: I have also configured those services, but that's somewhat optional: You will also need at least part of my sway/config, which sends the systemd notification (because, no, Sway doesn't support any sort of readiness notification, that would be too easy). And you might like to see my swayidle-config while you're there. Finally, you need to hook this up somehow to the login manager. This is typically done with a desktop file, so drop sway-session.desktop in /usr/share/wayland-sessions and sway-user-service somewhere in your $PATH (typically /usr/bin/sway-user-service). The session then looks something like this:
$ systemd-cgls   head -101
Control group /:
-.slice
 user.slice (#472)
    user.invocation_id: bc405c6341de4e93a545bde6d7abbeec
    trusted.invocation_id: bc405c6341de4e93a545bde6d7abbeec
   user-1000.slice (#10072)
      user.invocation_id: 08f40f5c4bcd4fd6adfd27bec24e4827
      trusted.invocation_id: 08f40f5c4bcd4fd6adfd27bec24e4827
     user@1000.service   (#10156)
        user.delegate: 1
        trusted.delegate: 1
        user.invocation_id: 76bed72a1ffb41dca9bfda7bb174ef6b
        trusted.invocation_id: 76bed72a1ffb41dca9bfda7bb174ef6b
       session.slice (#10282)
         xdg-document-portal.service (#12248)
           9533 /usr/libexec/xdg-document-portal
           9542 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subt 
         xdg-desktop-portal.service (#12211)
           9529 /usr/libexec/xdg-desktop-portal
         pipewire-pulse.service (#10778)
           6002 /usr/bin/pipewire-pulse
         wireplumber.service (#10519)
           5944 /usr/bin/wireplumber
         gvfs-daemon.service (#10667)
           5960 /usr/libexec/gvfsd
         gvfs-udisks2-volume-monitor.service (#10852)
           6021 /usr/libexec/gvfs-udisks2-volume-monitor
         at-spi-dbus-bus.service (#11481)
           6210 /usr/libexec/at-spi-bus-launcher
           6216 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2 
           6450 /usr/libexec/at-spi2-registryd --use-gnome-session
         pipewire.service (#10403)
           5940 /usr/bin/pipewire
         dbus.service (#10593)
           5946 /usr/bin/dbus-daemon --session --address=systemd: --nofork --n 
       background.slice (#10324)
         tracker-miner-fs-3.service (#10741)
           6001 /usr/libexec/tracker-miner-fs-3
       app.slice (#10240)
         xdg-permission-store.service (#12285)
           9536 /usr/libexec/xdg-permission-store
         gammastep.service (#11370)
           6197 gammastep
         dunst.service (#11958)
           7460 /usr/bin/dunst
         wterminal.service (#13980)
           69100 foot --title pop-up
           69101 /bin/bash
           77660 sudo systemd-cgls
           77661 head -101
           77662 wl-copy
           77663 sudo systemd-cgls
           77664 systemd-cgls
         syncthing.service (#11995)
           7529 /usr/bin/syncthing -no-browser -no-restart -logflags=0 --verbo 
           7537 /usr/bin/syncthing -no-browser -no-restart -logflags=0 --verbo 
         dconf.service (#10704)
           5967 /usr/libexec/dconf-service
         gnome-keyring-daemon.service (#10630)
           5951 /usr/bin/gnome-keyring-daemon --foreground --components=pkcs11 
         gcr-ssh-agent.service (#10963)
           6035 /usr/libexec/gcr-ssh-agent /run/user/1000/gcr
         swayidle.service (#11444)
           6199 /usr/bin/swayidle -w
         nm-applet.service (#11407)
           6198 /usr/bin/nm-applet --indicator
         wcolortaillog.service (#11518)
           6226 foot colortaillog
           6228 /bin/sh /home/anarcat/bin/colortaillog
           6230 sudo journalctl -f
           6233 ccze -m ansi
           6235 sudo journalctl -f
           6236 journalctl -f
         afuse.service (#10889)
           6051 /usr/bin/afuse -o mount_template=sshfs -o transform_symlinks - 
         gpg-agent.service (#13547)
           51662 /usr/bin/gpg-agent --supervised
           51719 scdaemon --multi-server
         emacs.service (#10926)
            6034 /usr/bin/emacs --fg-daemon
           33203 /usr/bin/aspell -a -m -d en --encoding=utf-8
         xdg-desktop-portal-gtk.service (#12322)
           9546 /usr/libexec/xdg-desktop-portal-gtk
         xdg-desktop-portal-wlr.service (#12359)
           9555 /usr/libexec/xdg-desktop-portal-wlr
         sway.service (#11037)
           6037 /usr/bin/sway
           6181 swaybar -b bar-0
           6209 py3status
           6309 /usr/bin/i3status -c /tmp/py3status_oy4ntfnq
           6969 Xwayland :0 -rootless -terminate -core -listen 29 -listen 30 - 
       init.scope (#10198)
         5909 /lib/systemd/systemd --user
         5911 (sd-pam)
     session-7.scope (#10440)
       5895 gdm-session-worker [pam/gdm-password]
       6028 /usr/libexec/gdm-wayland-session --register-session sway-user-serv 
[...]
I think that's pretty neat.

Environment propagation At first, my terminals and rofi didn't have the right $PATH, which broke a lot of my workflow. It's hard to tell exactly how Wayland gets started or where to inject environment. This discussion suggests a few alternatives and this Debian bug report discusses this issue as well. I eventually picked environment.d(5) since I already manage my user session with systemd, and it fixes a bunch of other problems. I used to have a .shenv that I had to manually source everywhere. The only problem with that approach is that it doesn't support conditionals, but that's something that's rarely needed.

Pipewire This is a whole topic onto itself, but migrating to Wayland also involves using Pipewire if you want screen sharing to work. You can actually keep using Pulseaudio for audio, that said, but that migration is actually something I've wanted to do anyways: Pipewire's design seems much better than Pulseaudio, as it folds in JACK features which allows for pretty neat tricks. (Which I should probably show in a separate post, because this one is getting rather long.) I first tried this migration in Debian bullseye, and it didn't work very well. Ardour would fail to export tracks and I would get into weird situations where streams would just drop mid-way. A particularly funny incident is when I was in a meeting and I couldn't hear my colleagues speak anymore (but they could) and I went on blabbering on my own for a solid 5 minutes until I realized what was going on. By then, people had tried numerous ways of letting me know that something was off, including (apparently) coughing, saying "hello?", chat messages, IRC, and so on, until they just gave up and left. I suspect that was also a Pipewire bug, but it could also have been that I muted the tab by error, as I recently learned that clicking on the little tiny speaker icon on a tab mutes that tab. Since the tab itself can get pretty small when you have lots of them, it's actually quite frequently that I mistakenly mute tabs. Anyways. Point is: I already knew how to make the migration, and I had already documented how to make the change in Puppet. It's basically:
apt install pipewire pipewire-audio-client-libraries pipewire-pulse wireplumber 
Then, as a regular user:
systemctl --user daemon-reload
systemctl --user --now disable pulseaudio.service pulseaudio.socket
systemctl --user --now enable pipewire pipewire-pulse
systemctl --user mask pulseaudio
An optional (but key, IMHO) configuration you should also make is to "switch on connect", which will make your Bluetooth or USB headset automatically be the default route for audio, when connected. In ~/.config/pipewire/pipewire-pulse.conf.d/autoconnect.conf:
context.exec = [
      path = "pactl"        args = "load-module module-always-sink"  
      path = "pactl"        args = "load-module module-switch-on-connect"  
    #  path = "/usr/bin/sh"  args = "~/.config/pipewire/default.pw"  
]
See the excellent as usual Arch wiki page about Pipewire for that trick and more information about Pipewire. Note that you must not put the file in ~/.config/pipewire/pipewire.conf (or pipewire-pulse.conf, maybe) directly, as that will break your setup. If you want to add to that file, first copy the template from /usr/share/pipewire/pipewire-pulse.conf first. So far I'm happy with Pipewire in bookworm, but I've heard mixed reports from it. I have high hopes it will become the standard media server for Linux in the coming months or years, which is great because I've been (rather boldly, I admit) on the record saying I don't like PulseAudio. Rereading this now, I feel it might have been a little unfair, as "over-engineered and tries to do too many things at once" applies probably even more to Pipewire than PulseAudio (since it also handles video dispatching). That said, I think Pipewire took the right approach by implementing existing interfaces like Pulseaudio and JACK. That way we're not adding a third (or fourth?) way of doing audio in Linux; we're just making the server better.

Keypress drops Sometimes I lose keyboard presses. This correlates with the following warning from Sway:
d c 06 10:36:31 curie sway[343384]: 23:32:14.034 [ERROR] [wlr] [libinput] event5  - SONiX USB Keyboard: client bug: event processing lagging behind by 37ms, your system is too slow 
... and corresponds to an open bug report in Sway. It seems the "system is too slow" should really be "your compositor is too slow" which seems to be the case here on this older system (curie). It doesn't happen often, but it does happen, particularly when a bunch of busy processes start in parallel (in my case: a linter running inside a container and notmuch new). The proposed fix for this in Sway is to gain real time privileges and add the CAP_SYS_NICE capability to the binary. We'll see how that goes in Debian once 1.8 gets released and shipped.

Improvements over i3

Tiling improvements There's a lot of improvements Sway could bring over using plain i3. There are pretty neat auto-tilers that could replicate the configurations I used to have in Xmonad or Awesome, see:

Display latency tweaks TODO: You can tweak the display latency in wlroots compositors with the max_render_time parameter, possibly getting lower latency than X11 in the end.

Sound/brightness changes notifications TODO: Avizo can display a pop-up to give feedback on volume and brightness changes. Not in Debian. Other alternatives include SwayOSD and sway-nc, also not in Debian.

Debugging tricks The xeyes (in the x11-apps package) will run in Wayland, and can actually be used to easily see if a given window is also in Wayland. If the "eyes" follow the cursor, the app is actually running in xwayland, so not natively in Wayland. Another way to see what is using Wayland in Sway is with the command:
swaymsg -t get_tree

Other documentation

Conclusion In general, this took me a long time, but it mostly works. The tray icon situation is pretty frustrating, but there's a workaround and I have high hopes it will eventually fix itself. I'm also actually worried about the DisplayLink support because I eventually want to be using this, but hopefully that's another thing that will hopefully fix itself before I need it.

A word on the security model I'm kind of worried about all the hacks that have been added to Wayland just to make things work. Pretty much everywhere we need to, we punched a hole in the security model: Wikipedia describes the security properties of Wayland as it "isolates the input and output of every window, achieving confidentiality, integrity and availability for both." I'm not sure those are actually realized in the actual implementation, because of all those holes punched in the design, at least in Sway. For example, apparently the GNOME compositor doesn't have the virtual-keyboard protocol, but they do have (another?!) text input protocol. Wayland does offer a better basis to implement such a system, however. It feels like the Linux applications security model lacks critical decision points in the UI, like the user approving "yes, this application can share my screen now". Applications themselves might have some of those prompts, but it's not mandatory, and that is worrisome.

18 September 2021

Mike Gabriel: X2Go, Remmina and X2GoKdrive

In this blog post, I will cover a few related but also different topics around X2Go - the GNU/Linux based remote computing framework. Introduction and Catch Up For those, who haven't come across X2Go, so far... With X2Go [0] you can log into remote GNU/Linux machines graphically and launch headless desktop environments, seamless/published applications or access an already running desktop session (on a local Xserver or running as a headless X2Go desktop session) via X2Go's session shadowing / mirroring feature. Graphical backend: NXv3 For several years, there was only one graphical backend available in X2Go, the NXv3 software. In NXv3, you have a headless or nested (it can do both) Xserver that has some remote magic built-in and is able to transfer the Xserver's graphical data to a remote client (NX proxy). Over the wire, the NX protocol allows for data compression (JPEG, PNG, etc.) and combines it with bitmap caching, so that the overall result is a fast and responsive desktop experience even on low latency and low bandwidth connections. This especially applies to X desktop environments that use many native X protocol operations for drawing windows and widget onto the screen. The more bitmaps involved (e.g. in applications with client-side rendering of window controls and such), the worse the quality of a session experience. The current main maintainer of NVv3 (aka nx-libs [1]) is Ulrich Sibiller. Uli has my and the X2Go community's full appreciation, admiration and gratitude for all the work he does on nx-libs, constantly improving NXv3 without breaking compatibility with legacy use cases (yes, FreeNX is still alive, by the way). NEW: Alternative Graphical Backend: X2Go Kdrive Over the past 1.5 years, Oleksandr Shneyder (Alex), co-founder of X2Go, has been working on a re-implementation of an alternative, less X11-dependent graphical backend. The underlying Xserver technology is the kdrive part of the X.org server project. People on GNU/Linux might have used kdrive technology already: The Xephyr nested Xserver uses the kdrive implementation. The idea of the X2Go Kdrive [2] implementation in X2Go is providing a headless Xserver on the X2Go Server side for running X11 based desktop sessions inside while using an X11-agnostic data protocol for sending the graphical desktop data to the client-side for rendering. Whereas, with NXv3 technology, you need a local Xserver on the client side, with X2Go Kdrive you only need a client app(lication) that can draw bitmaps into some sort of framebuffer, such as a client-side X11 Xserver, a client-side Wayland compositor or (hold your breath) an HTMLv5 canvas in a web browser. X2Go Kdrive Client Implementations During first half of this year, I tested and DEB-packaged Alex's X2Go HTMLv5 client code [3] and it has been available for testing in the X2Go nightly builds archive for a while now. Of course, the native X2Go Client application has X2Go Kdrive support for a while, too, but it requires a Qt5 application in the background, the x2gokdriveclient (which is still only available in X2Go nightly builds or from X2Go Git [4]). X2Go and Remmina As currently posted by the Remmina community [5], one of my employees has been working on finalizing an already existing draft of mine for the last couple of months: Remmina Plugin X2Go. This project has been contracted by BAUR-ITCS UG (haftungsbeschr nkt) already a while back and has been financed via X2Go funding from one of their customers. Unfortunately, I never got around really to finalizing the project. Apologies for this. Daniel Teichmann, who has been in the company for a while now, but just recently switched to an employment model with considerably more work hours per week, now picked up this project two months ago and achieved awesome things on the way. Daniel Teichmann and Antenore Gatta (Remmina core developer, aka tmow) have been cooperating intensely on this, recently, with the objective of getting the X2Go plugin code merged into Remmina asap. We are pretty close to the first touchdown (i.e. code merge) of this endeavour. Thanks to Antenore for his support on this. This is much appreciated. Remmina Plugin X2Go - Current Challenges The X2Go Plugin for Remmina implementation uses Python X2Go (PyHoca-CLI) under the bonnet and basically does a system call to pyhoca-cli according to the session settings configured in the Remmina session profile UI. When using NXv3 based sessions, the session window appears on the client-side Xserver and immediately gets caught by Remmina and embedded into the Remmina frame (via Xembed protocol) where its remote sessions are supposed to appear. (Thanks that GtkSocket is still around in GTK-3). The knowing GTK-3 experts among you may have noticed: GtkSocket is obsolete and has been removed from GTK-4. Also, GtkSocket support is only available in GTK-3 when using its X11 rendering backend. For the X2Go Kdrive implementation, we tested a similar approach (embedding the x2gokdriveclient Qt5 window via Xembed/GtkSocket), but it seems that GtkSocket and Qt5 applications don't work well together and we did not succeed in embedding the Qt5 window of the x2gokdriveclient application into Remmina, so far. Also, this would be a work-around for the bigger problem: We want, long-term, provide X2Go Kdrive support in Remmina, not only for Remmina running with GTK-3/X11, but also when Remmina is used natively on top of Wayland. So, the more sustainable approach for showing an X2Go Kdrive based X2Go session in Remmina would be a GTK-3/4 or a Glib-2.0 + Cairo based rendering client provided as a shared library. This then could be used by Remmina for drawing the session bitmaps into the Remmina session frame. This would require a port of the x2gokdriveclient Qt code into a non-Qt implementation. However, we are running out of funding to make this happen at the moment. More Funding Needed for this Journey As you might guess, such a project as proposed is a project that some people do in their spare time, others do it for a living. I'd love to continue this project and have Daniel Teichmann continue his work on this, so that Remmina might soon be able to provide native X2Go Kdrive Client support. If people read this and are interested in supporting such a project, please get in touch [6]. Thanks so much! light+love
Mike (aka sunweaver) [0] https://wiki.x2go.org/
[1] https://github.com/ArcticaProject/nx-libs
[2] https://code.x2go.org/gitweb?p=x2gokdrive.git;a=tree
[3] https://code.x2go.org/gitweb?p=x2gohtmlclient.git;a=tree
[4] https://code.x2go.org/gitweb?p=x2gokdriveclient.git;a=tree
[5] https://remmina.org/x2go/
[6] https://das-netzwerkteam.de/

12 April 2020

Enrico Zini: Some inventors links

Cleopatra the Alchemist - Wikipedia
history people archive.org
Cleopatra the Alchemist who likely lived during the 3rd century AD, was a Greek alchemist, author, and philosopher. She experimented with practical alchemy but is also credited as one of the four female alchemists that could produce the Philosopher's stone. Some writers consider her to be the inventor of the alembic, a distillation apparatus.
Hedy Lamarr (/ he di/), born Hedwig Eva Maria Kiesler (November 9, 1914[a] January 19, 2000), was an Austrian-born American film actress and inventor who was posthumously inducted into the National Inventors Hall of Fame.[1]
Radia Joy Perlman (born December 18, 1951) is an American computer programmer and network engineer. She is most famous for her invention of the spanning-tree protocol (STP), which is fundamental to the operation of network bridges, while working for Digital Equipment Corporation. She also made large contributions to many other areas of network design and standardization, such as link-state routing protocols.
Stephanie Louise Kwolek (July 31, 1923 June 18, 2014) was an American chemist who is known for inventing Kevlar. She was of Polish heritage and her career at the DuPont company spanned more than 40 years.[1] She discovered the first of a family of synthetic fibres of exceptional strength and stiffness: poly-paraphenylene terephthalamide.
This page aims to list inventions and discoveries in which women played a major role.

7 October 2016

Petter Reinholdtsen: Isenkram, Appstream and udev make life as a LEGO builder easier

The Isenkram system provide a practical and easy way to figure out which packages support the hardware in a given machine. The command line tool isenkram-lookup and the tasksel options provide a convenient way to list and install packages relevant for the current hardware during system installation, both user space packages and firmware packages. The GUI background daemon on the other hand provide a pop-up proposing to install packages when a new dongle is inserted while using the computer. For example, if you plug in a smart card reader, the system will ask if you want to install pcscd if that package isn't already installed, and if you plug in a USB video camera the system will ask if you want to install cheese if cheese is currently missing. This already work just fine. But Isenkram depend on a database mapping from hardware IDs to package names. When I started no such database existed in Debian, so I made my own data set and included it with the isenkram package and made isenkram fetch the latest version of this database from git using http. This way the isenkram users would get updated package proposals as soon as I learned more about hardware related packages. The hardware is identified using modalias strings. The modalias design is from the Linux kernel where most hardware descriptors are made available as a strings that can be matched using filename style globbing. It handle USB, PCI, DMI and a lot of other hardware related identifiers. The downside to the Isenkram specific database is that there is no information about relevant distribution / Debian version, making isenkram propose obsolete packages too. But along came AppStream, a cross distribution mechanism to store and collect metadata about software packages. When I heard about the proposal, I contacted the people involved and suggested to add a hardware matching rule using modalias strings in the specification, to be able to use AppStream for mapping hardware to packages. This idea was accepted and AppStream is now a great way for a package to announce the hardware it support in a distribution neutral way. I wrote a recipe on how to add such meta-information in a blog post last December. If you have a hardware related package in Debian, please announce the relevant hardware IDs using AppStream. In Debian, almost all packages that can talk to a LEGO Mindestorms RCX or NXT unit, announce this support using AppStream. The effect is that when you insert such LEGO robot controller into your Debian machine, Isenkram will propose to install the packages needed to get it working. The intention is that this should allow the local user to start programming his robot controller right away without having to guess what packages to use or which permissions to fix. But when I sat down with my son the other day to program our NXT unit using his Debian Stretch computer, I discovered something annoying. The local console user (ie my son) did not get access to the USB device for programming the unit. This used to work, but no longer in Jessie and Stretch. After some investigation and asking around on #debian-devel, I discovered that this was because udev had changed the mechanism used to grant access to local devices. The ConsoleKit mechanism from /lib/udev/rules.d/70-udev-acl.rules no longer applied, because LDAP users no longer was added to the plugdev group during login. Michael Biebl told me that this method was obsolete and the new method used ACLs instead. This was good news, as the plugdev mechanism is a mess when using a remote user directory like LDAP. Using ACLs would make sure a user lost device access when she logged out, even if the user left behind a background process which would retain the plugdev membership with the ConsoleKit setup. Armed with this knowledge I moved on to fix the access problem for the LEGO Mindstorms related packages. The new system uses a udev tag, 'uaccess'. It can either be applied directly for a device, or is applied in /lib/udev/rules.d/70-uaccess.rules for classes of devices. As the LEGO Mindstorms udev rules did not have a class, I decided to add the tag directly in the udev rules files included in the packages. Here is one example. For the nqc C compiler for the RCX, the /lib/udev/rules.d/60-nqc.rules file now look like this:
SUBSYSTEM=="usb", ACTION=="add", ATTR idVendor =="0694", ATTR idProduct =="0001", \
    SYMLINK+="rcx-%k", TAG+="uaccess"
The key part is the 'TAG+="uaccess"' at the end. I suspect all packages using plugdev in their /lib/udev/rules.d/ files should be changed to use this tag (either directly or indirectly via 70-uaccess.rules). Perhaps a lintian check should be created to detect this? I've been unable to find good documentation on the uaccess feature. It is unclear to me if the uaccess tag is an internal implementation detail like the udev-acl tag used by /lib/udev/rules.d/70-udev-acl.rules. If it is, I guess the indirect method is the preferred way. Michael asked for more documentation from the systemd project and I hope it will make this clearer. For now I use the generic classes when they exist and is already handled by 70-uaccess.rules, and add the tag directly if no such class exist. To learn more about the isenkram system, please check out my blog posts tagged isenkram. To help out making life for LEGO constructors in Debian easier, please join us on our IRC channel #debian-lego and join the Debian LEGO team in the Alioth project we created yesterday. A mailing list is not yet created, but we are working on it. :) As usual, if you use Bitcoin and want to show your support of my activities, please send Bitcoin donations to my address 15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b.

3 September 2016

Bits from Debian: New Debian Developers and Maintainers (July and August 2016)

The following contributors got their Debian Developer accounts in the last two months: The following contributors were added as Debian Maintainers in the last two months: Congratulations!

10 February 2015

Enrico Zini: systemd-default-rescue

seat-inspect Four months ago I wrote this somewhere:
Seeing a DD saying "this new dbus stuff scares me" would make most debian users scared. Seeing a DD who has an idea of what is going on, and who can explain it, would be an interesting and exciting experience. So, let's be exemplary, competent and patient. Or at least, competent. Some may like or not like the changes, but do we all understand what is going on? Will we all be able to support our friends and customers running jessie? I confess that although I understand the need for it, I don't feel competent enough to support systemd-based machines right now. So, are we maybe in need of help, cheat sheets, arsenals of one-liners, diagnostic tools? Maybe a round of posts on -planet like "one debian package a day" but with new features that jessie will have, and how to understand them and take advantage of them?
That was four months ago. In the meantime, I did some work, and it got better for me. Yesterday, however, I've seen an experienced Linux person frustrated because the shutdown function of the desktop was doing nothing whatsoever. Today I found John Goerzen's post on planet. I felt like some more diagnostic tools were needed, so I spent the day making seat-inspect. seat-inspect tries to make the status of the login/seat system visible, to help with understanding and troubleshooting. The intent of running the code is to have an overview of the system status, both to see what the new facilities are about, and to figure out if there is something out of place. The intent of reading the code is to have an idea of how to use these facilities: the code has been written to be straightforward and is annotated with relevant bits from the logind API documentation. seat-inspect is not a finished tool, but a starting point. I put it on github hoping that people will fork it and add their own extra sanity checks and warnings, so that it can grow into a standard thing to run if a system acts weird. As it is now, it should be able to issue warnings if some bits are missing for network-manager or shutdown functions to work correctly. I haven't really tested that, though, because I don't have a system at hand where they are currently not working fine. Another nice thing of it is that when running seat-inspect -v you get a dump of what logind/consolekit think about your system. I found it an interesting way to explore the new functionalities that we recently grew. The same can be done, and in more details, with loginctl calls, but I lacked a summary. After writing this I feel a bit more competent, probably enough to sit at somebody's computer and poke into loginctl bits. I highly recommend the experience.

12 January 2015

Russell Coker: Systemd Notes

A few months ago I gave a lecture about systemd for the Linux Users of Victoria. Here are some of my notes reformatted as a blog post: Scripts in /etc/init.d can still be used, they work the same way as they do under sysvinit for the user. You type the same commands to start and stop daemons. To get a result similar to changing runlevel use the systemctl isolate command. Runlevels were never really supported in Debian (unlike Red Hat where they were used for starting and stopping the X server) so for Debian users there s no change here. The command systemctl with no params shows a list of loaded services and highlights failed units. The command journalctl -u UNIT-PATTERN shows journal entries for the unit(s) in question. The pattern uses wildcards not regexs. The systemd journal includes the stdout and stderr of all daemons. This solves the problem of daemons that don t log all errors to syslog and leave the sysadmin wondering why they don t work. The command systemctl status UNIT gives the status and last log entries for the unit in question. A program can use ioctl(fd, TIOCSTI, ) to push characters into a tty buffer. If the sysadmin runs an untrusted program with the same controlling tty then it can cause the sysadmin shell to run hostile commands. The system call setsid() to create a new terminal session is one solution but managing which daemons can be started with it is difficult. The way that systemd manages start/stop of all daemons solves this. I am glad to be rid of the run_init program we used to use on SE Linux systems to deal with this. Systemd has a mechanism to ask for passwords for SSL keys and encrypted filesystems etc. There have been problems with that in the past but I think they are all fixed now. While there is some difficulty during development the end result of having one consistent way of managing this will be better than having multiple daemons doing it in different ways. The commands systemctl enable and systemctl disable enable/disable daemon start at boot which is easier than the SysVinit alternative of update-rc.d in Debian. Systemd has built in seat management, which is not more complex than consolekit which it replaces. Consolekit was installed automatically without controversy so I don t think there should be controversy about systemd replacing consolekit. Systemd improves performance by parallel start and autofs style fsck. The command systemd-cgtop shows resource use for cgroups it creates. The command systemd-analyze blame shows what delayed the boot process and
systemd-analyze critical-chain shows the critical path in boot delays. Sysremd also has security features such as service private /tmp and restricting service access to directory trees. Conclusion For basic use things just work, you don t need to learn anything new to use systemd. It provides significant benefits for boot speed and potentially security. It doesn t seem more complex than other alternative solutions to the same problems. https://wiki.debian.org/systemd http://freedesktop.org/wiki/Software/systemd/Optimizations/ http://0pointer.de/blog/projects/security.html

10 January 2015

Mike Gabriel: Shifting my Focus in X2Go

Dear X2Go Community, dear friends, as many of you may know, I have been contributing a considerable amount
of time to upstream-maintaining X2Go over the past 4 years. I provided
new X2Go components (Python X2Go, PyHoca X2Go Client, a publicly
available X2Go Session Broker, X2Go MATE Bindings, etc.) and focused on
making X2Go a wide-spread community project. For the last 2-3 years I
have been in the role of the X2Go project coordinator and various other
roles. With the beginning of 2015, I will pass on several of those roles to
other people in the project, see the below list for already assigned and
unassigned roles: The reasons for tremendously reducing my workload on X2Go are these: In several internal exchanges we (Heinz, Stefan, Mihai, Mike#2, read more

7 August 2014

Jordi Mallach: A pile of reasons why GNOME should be Debian jessie s default desktop environment

GNOME has, for some reason or another, always been the default desktop environment in Debian since the installer is able to install a full desktop environment by default. Release after release, Debian has been shipping different versions of GNOME, first based on the venerable 1.2/1.4 series, then moving to the time-based GNOME 2.x series, and finally to the newly designed 3.4 series for the last stable release, Debian 7 wheezy . During the final stages of wheezy s development, it was pointed out that the first install CD image would not longer hold all of the required packages to install a full GNOME desktop environment. There was lots of discussion surrounding this bug or fact, and there were two major reactions to it. The Debian GNOME team rebuilt some key packages so they would be compressed using xz instead of gzip, saving the few megabytes that were needed to squeeze everything in the first CD. In parallel, the tasksel maintainer decided switching to Xfce as default desktop was another obvious fix. This change, unannounced and two days before the freeze, was very contested and spurred the usual massive debian-devel threads. In the end, and after a few default desktop flip flops, it was agreed that GNOME would remain as the default for the already frozen wheezy release, and this issue would be revisited later on during jessie s development. And indeed, some months ago, Xfce was again reinstated as Debian s default desktop for jessie as announced:
Change default desktop to xfce.
This will be re-evaluated before jessie is frozen. The evaluation will
start around the point of DebConf (August 2014). If at that point gnome
looks like a better choice, it ll go back as the default.
Some criteria for that choice will include:
* Popcon numbers for gnome on jessie. If gnome installations continue to
  rise fast enough despite xfce being the default (compared with, say
  kde installations), then we ll know that users prefer gnome.
  Currently we have no data about how many users would choose gnome when
  it s not the default. Part of the reason for switching to xfce now
  is to get such data.
* The state of accessability support, particularly for the blind.
* How well the UI works for both new and existing users. Gnome 3
  seems to be adding back many gnome 2 features that existing users
  expect, as well as making some available via addons. If it feels
  comfortable to gnome 2 (and xfce) users, that would go a long way
  toward switching back to it as the default. Meanwhile, Gnome 3 is also
  breaking new ground in its interface; if the interface seems more
  welcoming to new users, or works better on mobile devices, etc, that
  would again point toward switching back.
* Whatever size constraints exist for CD or other images at the time.
--
Hello to all the tech journalists out there. This is pretty boring.
Why don t you write a story about monads instead?
Joey Hess in dfca406eb694e0ac00ea04b12fc912237e01c9b5.
Suffice to say that the Debian GNOME team participants have never been thrilled about how the whole issue is being handled, and we ve been wondering if we should be doing anything about it, or just move along and enjoy the smaller amount of bug reports against GNOME packages that this change would bring us, if it finally made it through to the final release. During our real life meet-ups in FOSDEM and the systemd+GNOME sprint in Antwerp, most members of the team did feel Debian would not be delivering a graphical environment with the polish we think our users deserve, and decided we at least should try to convince the rest of the Debian project and our users that Debian will be best suited by shipping GNOME 3.12 by default. Power users, of course, can and know how to get around this default and install KDE, Xfce, Cinnamon, MATE or whatever other choice they have. For the average user, though, we think we should be shipping GNOME by default, and tasksel should revert the above commit again. Some of our reasons are: In short, we think defaulting to GNOME is the best option for the Debian release, and in contrast, shipping Xfce as the default desktop could mean delivering a desktop experience that has some incomplete or rough edges, and not on par with Debian quality standards for a stable release. We believe tasksel should again revert the change and be uploaded as soon as possible, in order to get people testing images with GNOME the sooner the better, with the freeze only two months away. We would also like that in the future, changes of this nature will not be announced in a git commit log, but widely discussed in debian-project and the other usual development/decision channels, like the change of init system happened recently. We will, whichever the final decision is, continue to package GNOME with great care to ensure our users get the best possible desktop experience Debian can offer.

11 June 2014

Yves-Alexis Perez: Debian, Xfce, policykit and permissions

So, it seems that for a lot of people using unstable, hardware-related permissions (shutdown/reboot, suspend/hibernate, devices mount/umount etc.) have been broken since some times. That's usually the case for people using GNOME with lightdm display manager, Xfce with either gdm or lightdm. It seems that recently, policykit (which is used by GNOME and Xfce) switched from consolekit backend to logind backend (yeah, systemd-logind). So applications using policykit needs to handle that correctly, and that means beeing sure a logind session is correctly setup, which is done by installing the package libpam-systemd. For now, it's still possible to not switch to systemd as init system, by installing the systemd-shim package before libpam-systemd. Be aware that (at least with the current state of affairs), this is only true with logind before 204. When systemd maintainers start transitionning to a later version, only systemd-sysv (so, systemd as init system) will work. For people reluctant to switch to systemd, they can use systemd-shim for now. Then when systemd 205+ enters the archive, either lose those hardware permissions, or try to improve systemd-shim to handle that situation. There's not much we (Xfce/LightDM maintainers) can do about that.

28 May 2014

Tanguy Ortolo: GNU/Linux graphic sessions: allowing computer suspend and disabling a monitor

Allowing computer suspend Major desktop environments such as Xfce or KDE have a built-in computer suspend feature, but when you use a lighter alternative, things are a bit more complicated, because basically: only root can suspend the computer. Possible solutions include: With recent updates of the related Debian packages no idea of which one exactly the latter solution may not work any more, in which case it will only return the following error:
Error org.freedesktop.UPower.GeneralError: not authorized
It appears that this error is linked to ConsoleKit, a part of all this modern *Kit gizmo pile. If you are in this case, try prefixing your session launcher with the undocumented dark magic call ck-launch-session. For instance, this is what I have in my .xsession to launch my window manager i3:
exec ck-launch-session i3
Note: I do not know what ck-launch-session does exactly, why it is needed, and I do not want to know. To me, all that WhatsitKit pile is just some opaque, under-documented as in: no man page crap, that no one but their author really understand, designed to solve theoretical problems no one really cares about like: how to allow locally connected users to use the sound card while forbidding it to remote users while creating new issues such as this one. This stuff is too complex and under-documented for me to dive into it, so if it does not work out of the box, it is just some crap that gets in my way to using my computer as I wish. Disabling a monitor In some configurations, you have two monitors and want to disable one. For instance, in addition to my LCD monitor, I have a projector which I only use for movies. According to xorg.conf's man page, it can be disabled this way:
Section "Device"
    Identifier  "Internal graphic card"
    Option      "Monitor-DVI"   "LCD Monitor"
    Option      "Monitor-VGA"   "Projector"
EndSection
Section "Monitor"
    Identifier  "LCD Monitor"
EndSection
Section "Monitor"
    Identifier  "Projector"
    Option      "Enable"    "false"
EndSection
Except that does not work, because contrary to what the man page says the real option to use is not Enable but Disable! So here is the correct configuration to disable that monitor at start-up:
Section "Device"
    Identifier  "Internal graphic card"
    Option      "Monitor-DVI"   "LCD Monitor"
    Option      "Monitor-VGA"   "Projector"
EndSection
Section "Monitor"
    Identifier  "LCD Monitor"
EndSection
Section "Monitor"
    Identifier  "Projector"
    Option      "Disable"   "true"
EndSection
Note: yes, I will send a bug report with a patch against xorg.conf's man page.

13 April 2014

C.J. Adams-Collier: When was the last time you upgraded from squeeze to wheezy?

Wow. 3G delta. I haven t booted this laptop for a while I think I m finally ready to make the move from gnome2 to gnome3. There are bits that still annoy me, but I think it s off to a good start. Upgrading perl from 5.10 to 5.14.
cjac@calcifer:~$ sudo apt-get dist-upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Calculating upgrade... Done
The following packages will be REMOVED:
  at-spi capplets-data compiz compiz-gnome compiz-gtk defoma deskbar-applet g++-4.3 gcc-4.3 gcj-4.4-base gcj-4.4-jre gcj-4.4-jre-headless gcj-4.4-jre-lib
  gdm3 gir1.0-clutter-1.0 gir1.0-freedesktop gir1.0-glib-2.0 gir1.0-gstreamer-0.10 gir1.0-gtk-2.0 gir1.0-json-glib-1.0 glade-gnome gnome-about
  gnome-accessibility gnome-applets gnome-core gnome-panel gnome-utils-common lib32readline5-dev libbrasero-media0 libclass-mop-perl libdb4.7-java
  libdb4.8-dev libdevhelp-1-1 libdigest-sha1-perl libdirectfb-dev libebook1.2-9 libecal1.2-7 libedata-book1.2-2 libedata-cal1.2-7 libedataserverui1.2-8
  libepc-1.0-2 libepc-ui-1.0-2 libept1 libgcj10 libgcj10-awt libgd2-noxpm libgstfarsight0.10-0 libgtkhtml-editor0 libjpeg62-dev libmetacity-private0
  libmono-accessibility1.0-cil libmono-bytefx0.7.6.1-cil libmono-cairo1.0-cil libmono-cil-dev libmono-corlib1.0-cil libmono-cscompmgd7.0-cil
  libmono-data-tds1.0-cil libmono-data1.0-cil libmono-debugger-soft0.0-cil libmono-getoptions1.0-cil libmono-i18n-west1.0-cil libmono-i18n1.0-cil
  libmono-ldap1.0-cil libmono-microsoft7.0-cil libmono-npgsql1.0-cil libmono-oracle1.0-cil libmono-peapi1.0-cil libmono-posix1.0-cil
  libmono-relaxng1.0-cil libmono-security1.0-cil libmono-sharpzip0.6-cil libmono-sharpzip0.84-cil libmono-sqlite1.0-cil libmono-system-data1.0-cil
  libmono-system-ldap1.0-cil libmono-system-messaging1.0-cil libmono-system-runtime1.0-cil libmono-system-web1.0-cil libmono-system1.0-cil
  libmono-webbrowser0.5-cil libmono-winforms1.0-cil libmono1.0-cil libmtp8 libnautilus-extension1 libpango1.0-common libperl5.10 libpolkit-gtk-1-0
  libpulse-browse0 librpm1 librpmbuild1 libsdl1.2-dev libsdl1.2debian-pulseaudio libseed0 libstdc++6-4.3-dev libtelepathy-farsight0 libupnp3 libvlccore4
  libxmlrpc-c3 linphone-nox linux-headers-2.6.32-5-amd64 linux-sound-base metacity mono-2.0-devel mono-devel mysql-client-5.1 mysql-query-browser
  mysql-server-5.1 mysql-server-core-5.1 openoffice.org-base-core openoffice.org-core openoffice.org-gcj openoffice.org-report-builder-bin
  openoffice.org-style-andromeda php5-suhosin portmap python-beagle python-brasero python-docky python-encutils python-evince python-gnomeapplet
  python-gtop python-mediaprofiles python-metacity python-totem-plparser seahorse-plugins smbfs speedbar totem-coherence tqsllib1c2a unixcw vlc
  xserver-xorg-video-nv
The following NEW packages will be installed:
  accountsservice acl aisleriot apg aptdaemon-data aptitude-common asterisk-core-sounds-en asterisk-modules asterisk-moh-opsound-gsm at-spi2-core
  ax25-node bluez btrfs-tools caribou caribou-antler chromium chromium-inspector colord console-setup console-setup-linux cpp-4.6 cpp-4.7 crda
  cryptsetup-bin cups-filters db-util db5.1-util dconf-gsettings-backend dconf-service dconf-tools distro-info-data docutils-common docutils-doc enchant
  extlinux finger folks-common fonts-cantarell fonts-droid fonts-freefont-ttf fonts-horai-umefont fonts-lg-aboriginal fonts-liberation fonts-lyx
  fonts-opensymbol fonts-sil-gentium fonts-sil-gentium-basic fonts-sipa-arundina fonts-stix fonts-takao fonts-takao-gothic fonts-takao-mincho
  fonts-thai-tlwg fonts-tlwg-garuda fonts-tlwg-kinnari fonts-tlwg-loma fonts-tlwg-mono fonts-tlwg-norasi fonts-tlwg-purisa fonts-tlwg-sawasdee
  fonts-tlwg-typewriter fonts-tlwg-typist fonts-tlwg-typo fonts-tlwg-umpush fonts-tlwg-waree fonts-umeplus fuse g++-4.7 g++-4.7-multilib gcc-4.6
  gcc-4.6-base gcc-4.7 gcc-4.7-base gcc-4.7-multilib gcj-4.7-base gcj-4.7-jre gcj-4.7-jre-headless gcj-4.7-jre-lib gconf-service gcr
  gir1.2-accountsservice-1.0 gir1.2-atk-1.0 gir1.2-atspi-2.0 gir1.2-caribou-1.0 gir1.2-clutter-1.0 gir1.2-clutter-gst-1.0 gir1.2-cogl-1.0
  gir1.2-coglpango-1.0 gir1.2-evince-3.0 gir1.2-folks-0.6 gir1.2-freedesktop gir1.2-gck-1 gir1.2-gconf-2.0 gir1.2-gcr-3 gir1.2-gdesktopenums-3.0
  gir1.2-gdkpixbuf-2.0 gir1.2-gee-1.0 gir1.2-gkbd-3.0 gir1.2-glib-2.0 gir1.2-gmenu-3.0 gir1.2-gnomebluetooth-1.0 gir1.2-gnomekeyring-1.0
  gir1.2-gst-plugins-base-0.10 gir1.2-gstreamer-0.10 gir1.2-gtk-3.0 gir1.2-gtkclutter-1.0 gir1.2-gtksource-3.0 gir1.2-gtop-2.0 gir1.2-gucharmap-2.90
  gir1.2-javascriptcoregtk-3.0 gir1.2-json-1.0 gir1.2-mutter-3.0 gir1.2-networkmanager-1.0 gir1.2-notify-0.7 gir1.2-panelapplet-4.0 gir1.2-pango-1.0
  gir1.2-peas-1.0 gir1.2-polkit-1.0 gir1.2-rb-3.0 gir1.2-soup-2.4 gir1.2-telepathyglib-0.12 gir1.2-telepathylogger-0.2 gir1.2-totem-1.0
  gir1.2-totem-plparser-1.0 gir1.2-upowerglib-1.0 gir1.2-vte-2.90 gir1.2-webkit-3.0 gir1.2-wnck-3.0 gir1.2-xkl-1.0 git-man gjs gkbd-capplet glchess
  glib-networking glib-networking-common glib-networking-services glines gnect gnibbles gnobots2 gnome-bluetooth gnome-contacts gnome-control-center-data
  gnome-desktop3-data gnome-font-viewer gnome-icon-theme-extras gnome-icon-theme-symbolic gnome-online-accounts gnome-packagekit gnome-packagekit-data
  gnome-shell gnome-shell-common gnome-sudoku gnome-sushi gnome-themes-standard gnome-themes-standard-data gnome-user-share gnome-video-effects gnomine
  gnotravex gnotski gnuplot gnuplot-nox grilo-plugins-0.1 groff growisofs gsettings-desktop-schemas gstreamer0.10-gconf gtali guile-2.0-libs gvfs-common
  gvfs-daemons gvfs-libs hardening-includes hwdata iagno ienglish-common imagemagick-common ioquake3 ioquake3-server iputils-tracepath ipxe-qemu iw
  keyutils kmod krb5-locales lib32itm1 lib32quadmath0 lib32tinfo-dev lib32tinfo5 libaacplus2 libaacs0 libabiword-2.9 libaccountsservice0 libamd2.2.0
  libapache-pom-java libapol4 libapt-inst1.5 libapt-pkg4.12 libaqbanking-plugins-libgwenhywfar60 libaqbanking34 libaqbanking34-plugins libaqhbci20
  libaqofxconnect7 libarchive12 libasprintf0c2 libassuan0 libatk-adaptor libatk-adaptor-data libatk-bridge2.0-0 libatkmm-1.6-1 libatkmm-1.6-dev
  libatspi2.0-0 libaudiofile1 libavahi-ui-gtk3-0 libavcodec53 libavcodec54 libavformat53 libavformat54 libavutil51 libbabl-0.1-0 libbind9-80 libbison-dev
  libblas3 libbluray1 libboost-iostreams1.49.0 libboost-program-options1.49.0 libboost-python1.49.0 libboost-serialization1.49.0 libboost-thread1.49.0
  libbrasero-media3-1 libcairo-gobject2 libcairo-script-interpreter2 libcamel-1.2-33 libcanberra-dev libcanberra-gtk3-0 libcanberra-gtk3-module
  libcanberra-pulse libcapi20-3 libcaribou-common libcaribou-gtk-module libcaribou-gtk3-module libcaribou0 libccrtp0 libcdio-cdda1 libcdio-paranoia1
  libcdio13 libcfg4 libchamplain-0.12-0 libchamplain-gtk-0.12-0 libcheese-gtk21 libcheese3 libclass-factory-util-perl libclass-isa-perl libclass-load-perl
  libclass-load-xs-perl libclutter-1.0-common libclutter-gst-1.0-0 libclutter-gtk-1.0-0 libclutter-imcontext-0.1-0 libclutter-imcontext-0.1-bin
  libcluttergesture-0.0.2-0 libcmis-0.2-0 libcogl-common libcogl-pango0 libcogl9 libcolord1 libcommons-parent-java libconfdb4 libcoroipcc4 libcoroipcs4
  libcpg4 libcryptsetup4 libcrystalhd3 libcupsfilters1 libcw3 libdata-alias-perl libdatetime-format-builder-perl libdatetime-format-iso8601-perl
  libdb-java libdb5.1 libdb5.1-dev libdb5.1-java libdb5.1-java-jni libdbus-c++-1-0 libdbus-glib1.0-cil libdbus1.0-cil libdconf0 libdee-1.0-4
  libdevel-partialdump-perl libdevhelp-3-0 libdevmapper-event1.02.1 libdistro-info-perl libdmapsharing-3.0-2 libdns88 libdotconf1.0 libdvbpsi7
  libebackend-1.2-2 libebml3 libebook-1.2-13 libecal-1.2-11 libecore1 libedata-book-1.2-13 libedata-cal-1.2-15 libedataserver-1.2-16
  libedataserverui-3.0-1 libeina1 libemail-valid-perl libencode-locale-perl libepc-1.0-3 libepc-ui-1.0-3 libept1.4.12 libescpr1 libev4
  libeval-closure-perl libevdocument3-4 libevent-2.0-5 libevent-perl libevs4 libevview3-3 libexiv2-12 libexosip2-7 libexporter-lite-perl
  libexttextcat-data libexttextcat0 libfakechroot libfarstream-0.1-0 libfdk-aac0 libfdt1 libfile-basedir-perl libfile-desktopentry-perl
  libfile-fcntllock-perl libfile-listing-perl libfile-mimeinfo-perl libfltk-images1.3 libfltk1.3 libfolks-eds25 libfolks-telepathy25 libfolks25
  libfont-afm-perl libgail-3-0 libgcj13 libgcj13-awt libgck-1-0 libgconf-2-4 libgconf2-doc libgcr-3-1 libgcr-3-common libgd2-xpm libgdata13
  libgdata2.1-cil libgdict-common libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-common libgdk-pixbuf2.0-dev libgegl-0.2-0 libgeocode-glib0 libgettextpo0 libgexiv2-1
  libgirepository-1.0-1 libgjs0b libgkeyfile1.0-cil libgladeui-2-0 libgladeui-common libglapi-mesa libglew1.7 libglib2.0-bin libgmime-2.6-0
  libgmime2.6-cil libgmp10 libgnome-bluetooth10 libgnome-desktop-3-2 libgnome-keyring-common libgnome-media-profiles-3.0-0 libgnome-menu-3-0 libgnomekbd7
  libgnutls-openssl27 libgnutlsxx27 libgoa-1.0-0 libgoa-1.0-common libgphoto2-l10n libgraphite2-2.0.0 libgrilo-0.1-0 libgs9 libgs9-common libgssdp-1.0-3
  libgstreamer-plugins-bad0.10-0 libgtk-3-0 libgtk-3-bin libgtk-3-common libgtk-3-dev libgtk-3-doc libgtk-sharp-beans-cil libgtk-vnc-2.0-0
  libgtkhtml-4.0-0 libgtkhtml-4.0-common libgtkhtml-editor-4.0-0 libgtkmm-3.0-1 libgtksourceview-3.0-0 libgtksourceview-3.0-common libgucharmap-2-90-7
  libgudev1.0-cil libgupnp-1.0-4 libgupnp-av-1.0-2 libgupnp-igd-1.0-4 libgusb2 libgvnc-1.0-0 libgweather-3-0 libgwenhywfar-data libgwenhywfar60 libgxps2
  libhcrypto4-heimdal libheimbase1-heimdal libhtml-form-perl libhtml-format-perl libhttp-cookies-perl libhttp-daemon-perl libhttp-date-perl
  libhttp-message-perl libhttp-negotiate-perl libhunspell-1.3-0 libicu48 libimobiledevice2 libio-aio-perl libisc84 libisccc80 libisccfg82 libiscsi1
  libiso9660-8 libisoburn1 libitm1 libjavascriptcoregtk-1.0-0 libjavascriptcoregtk-3.0-0 libjbig0 libjs-sphinxdoc libjs-underscore libjson0 libjte1
  libkadm5clnt-mit8 libkadm5srv-mit8 libkarma0 libkdb5-6 libkmod2 libkpathsea6 liblapack3 liblavfile-2.0-0 liblavjpeg-2.0-0 liblavplay-2.0-0 liblcms2-2
  liblensfun-data liblensfun0 liblinear-tools liblinear1 liblinphone4 liblockfile-bin liblogsys4 liblvm2app2.2 liblwp-mediatypes-perl
  liblwp-protocol-https-perl liblwres80 liblzma5 libmaa3 libmagick++5 libmagickcore5 libmagickcore5-extra libmagickwand5 libmath-bigint-perl
  libmath-round-perl libmatroska5 libmediastreamer1 libmhash2 libminiupnpc5 libmission-control-plugins0 libmjpegutils-2.0-0 libmodule-implementation-perl
  libmodule-runtime-perl libmono-2.0-1 libmono-2.0-dev libmono-accessibility4.0-cil libmono-cairo4.0-cil libmono-codecontracts4.0-cil
  libmono-compilerservices-symbolwriter4.0-cil libmono-corlib4.0-cil libmono-csharp4.0-cil libmono-custommarshalers4.0-cil libmono-data-tds4.0-cil
  libmono-debugger-soft2.0-cil libmono-debugger-soft4.0-cil libmono-http4.0-cil libmono-i18n-cjk4.0-cil libmono-i18n-mideast4.0-cil
  libmono-i18n-other4.0-cil libmono-i18n-rare4.0-cil libmono-i18n-west4.0-cil libmono-i18n4.0-all libmono-i18n4.0-cil libmono-ldap4.0-cil
  libmono-management4.0-cil libmono-messaging-rabbitmq4.0-cil libmono-messaging4.0-cil libmono-microsoft-build-engine4.0-cil
  libmono-microsoft-build-framework4.0-cil libmono-microsoft-build-tasks-v4.0-4.0-cil libmono-microsoft-build-utilities-v4.0-4.0-cil
  libmono-microsoft-csharp4.0-cil libmono-microsoft-visualc10.0-cil libmono-microsoft-web-infrastructure1.0-cil libmono-npgsql4.0-cil
  libmono-opensystem-c4.0-cil libmono-oracle4.0-cil libmono-peapi4.0-cil libmono-posix4.0-cil libmono-rabbitmq4.0-cil libmono-relaxng4.0-cil
  libmono-security4.0-cil libmono-sharpzip4.84-cil libmono-simd4.0-cil libmono-sqlite4.0-cil libmono-system-componentmodel-composition4.0-cil
  libmono-system-componentmodel-dataannotations4.0-cil libmono-system-configuration-install4.0-cil libmono-system-configuration4.0-cil
  libmono-system-core4.0-cil libmono-system-data-datasetextensions4.0-cil libmono-system-data-linq4.0-cil libmono-system-data-services-client4.0-cil
  libmono-system-data-services4.0-cil libmono-system-data4.0-cil libmono-system-design4.0-cil libmono-system-drawing-design4.0-cil
  libmono-system-drawing4.0-cil libmono-system-dynamic4.0-cil libmono-system-enterpriseservices4.0-cil libmono-system-identitymodel-selectors4.0-cil
  libmono-system-identitymodel4.0-cil libmono-system-ldap4.0-cil libmono-system-management4.0-cil libmono-system-messaging4.0-cil
  libmono-system-net4.0-cil libmono-system-numerics4.0-cil libmono-system-runtime-caching4.0-cil libmono-system-runtime-durableinstancing4.0-cil
  libmono-system-runtime-serialization-formatters-soap4.0-cil libmono-system-runtime-serialization4.0-cil libmono-system-runtime4.0-cil
  libmono-system-security4.0-cil libmono-system-servicemodel-discovery4.0-cil libmono-system-servicemodel-routing4.0-cil
  libmono-system-servicemodel-web4.0-cil libmono-system-servicemodel4.0-cil libmono-system-serviceprocess4.0-cil libmono-system-transactions4.0-cil
  libmono-system-web-abstractions4.0-cil libmono-system-web-applicationservices4.0-cil libmono-system-web-dynamicdata4.0-cil
  libmono-system-web-extensions-design4.0-cil libmono-system-web-extensions4.0-cil libmono-system-web-routing4.0-cil libmono-system-web-services4.0-cil
  libmono-system-web4.0-cil libmono-system-windows-forms-datavisualization4.0-cil libmono-system-windows-forms4.0-cil libmono-system-xaml4.0-cil
  libmono-system-xml-linq4.0-cil libmono-system-xml4.0-cil libmono-system4.0-cil libmono-tasklets4.0-cil libmono-web4.0-cil libmono-webbrowser2.0-cil
  libmono-webbrowser4.0-cil libmono-webmatrix-data4.0-cil libmono-windowsbase4.0-cil libmount1 libmozjs10d libmozjs17d libmozjs185-1.0 libmpeg2encpp-2.0-0
  libmplex2-2.0-0 libmtdev1 libmtp-common libmtp-runtime libmtp9 libmupen64plus2 libmusicbrainz-discid-perl libmusicbrainz5-0 libmutter0 libmx-1.0-2
  libmx-bin libmx-common libmysqlclient18 libnatpmp1 libnautilus-extension1a libnet-domain-tld-perl libnet-http-perl libnet-ip-minimal-perl libnetcf1
  libnetfilter-conntrack3 libnettle4 libnewtonsoft-json4.5-cil libnice10 libnl-3-200 libnl-genl-3-200 libnl-route-3-200 libnm-glib4 libnm-gtk-common
  libnm-gtk0 libnm-util2 libnotify4 libnspr4 libnss-winbind libnss3 libnuma1 libnunit2.6-cil liboauth0 libodbc1 liboobs-1-5 libopal3.10.4 libopenal-data
  libopus0 libosip2-7 libp11-2 libp11-kit-dev libp11-kit0 libpackage-stash-xs-perl libpackagekit-glib2-14 libpam-cap libpam-modules-bin libpam-winbind
  libpanel-applet-4-0 libparams-classify-perl libpcre3-dev libpcrecpp0 libpeas-1.0-0 libpeas-common libperl5.14 libpipeline1 libpload4 libpodofo0.9.0
  libpoe-component-resolver-perl libpoppler-glib8 libpoppler19 libportsmf0 libpostproc52 libprocps0 libpst4 libpt2.10.4 libptexenc1 libpython2.7
  libqt4-declarative libqtassistantclient4 libqtdbus4 libqtwebkit4 libquadmath0 libquicktime2 libquorum4 libquvi-scripts libquvi7 libraptor2-0 librasqal3
  libraw5 libregexp-reggrp-perl libreoffice libreoffice-base libreoffice-base-core libreoffice-calc libreoffice-common libreoffice-core libreoffice-draw
  libreoffice-emailmerge libreoffice-evolution libreoffice-filter-binfilter libreoffice-filter-mobiledev libreoffice-gnome libreoffice-gtk
  libreoffice-help-en-us libreoffice-impress libreoffice-java-common libreoffice-math libreoffice-officebean libreoffice-report-builder-bin
  libreoffice-style-galaxy libreoffice-style-tango libreoffice-writer libresid-builder0c2a librest-0.7-0 librest-extras-0.7-0 librhythmbox-core6 librpm3
  librpmbuild3 librpmio3 librpmsign1 libruby1.9.1 libsaamf3 libsackpt3 libsaclm3 libsaevt3 libsalck3 libsam4 libsamsg4 libsane-common
  libsane-extras-common libsatmr3 libsbsms10 libseed-gtk3-0 libsidplay2 libsigsegv2 libsocialweb-client2 libsocialweb-common libsocialweb-service
  libsocialweb0 libsocket-getaddrinfo-perl libsocket-perl libsonic0 libsoundtouch0 libsox2 libspeechd2 libspice-client-glib-2.0-1
  libspice-client-gtk-2.0-1 libspice-server1 libssl-doc libssl1.0.0 libstdc++6-4.7-dev libsvm-tools libswitch-perl libswscale2 libsystemd-daemon0
  libsystemd-login0 libtagc0 libtelepathy-farstream2 libtelepathy-logger2 libtest-warn-perl libtinfo-dev libtinfo5 libtirpc1 libtokyocabinet9 libtotem-pg4
  libtotem0 libtqsllib1 libtracker-sparql-0.14-0 libtree-dagnode-perl libts-dev libucommon5 libumfpack5.4.0 libunique-3.0-0 libupnp6 libusbredirhost1
  libusbredirparser0 libv4lconvert0 libverto-libev1 libverto1 libvisio-0.0-0 libvlccore5 libvo-aacenc0 libvo-amrwbenc0 libvorbisidec1 libvotequorum4
  libvpx1 libvte-2.90-9 libvte-2.90-common libwacom-common libwacom2 libwebkitgtk-1.0-0 libwebkitgtk-1.0-common libwebkitgtk-3.0-0 libwebkitgtk-3.0-common
  libwebp2 libwebrtc-audio-processing-0 libwildmidi-config libwireshark-data libwireshark2 libwiretap2 libwnck-3-0 libwnck-3-common libwpd-0.9-9
  libwpg-0.2-2 libwps-0.2-2 libwsutil2 libwv-1.2-4 libwww-robotrules-perl libx11-doc libx11-protocol-perl libx264-123 libx264-124 libx264-130 libx264-132
  libxalan2-java libxcb-composite0 libxcb-glx0 libxcb-shape0 libxcb-shm0-dev libxcb-util0 libxen-4.1 libxml-commons-external-java
  libxml-commons-resolver1.1-java libxml-sax-base-perl libxmlrpc-c++4 libxmlrpc-core-c3 libxz-java libyajl2 libyaml-0-2 libyaml-perl libyelp0 libzrtpcpp2
  libzvbi-common libzvbi0 lightsoff linphone-nogtk linux-headers-3.2.0-4-amd64 linux-headers-3.2.0-4-common linux-headers-amd64 linux-image-3.2.0-4-amd64
  linux-image-amd64 linux-kbuild-3.2 live-boot-doc live-config-doc live-manual-html mahjongg memtest86+ minissdpd mono-4.0-gac mono-dmcs mscompress
  multiarch-support mupen64plus-audio-all mupen64plus-audio-sdl mupen64plus-data mupen64plus-input-all mupen64plus-input-sdl mupen64plus-rsp-all
  mupen64plus-rsp-hle mupen64plus-rsp-z64 mupen64plus-ui-console mupen64plus-video-all mupen64plus-video-arachnoid mupen64plus-video-glide64
  mupen64plus-video-rice mupen64plus-video-z64 mutter-common mysql-client-5.5 mysql-server-5.5 mysql-server-core-5.5 mythes-en-us openarena-081-maps
  openarena-081-misc openarena-081-players openarena-081-players-mature openarena-081-textures openarena-085-data openarena-088-data packagekit
  packagekit-backend-aptcc packagekit-tools planner-data planner-doc poppler-data printer-driver-all printer-driver-c2050 printer-driver-c2esp
  printer-driver-cjet printer-driver-escpr printer-driver-foo2zjs printer-driver-gutenprint printer-driver-hpcups printer-driver-hpijs
  printer-driver-m2300w printer-driver-min12xxw printer-driver-pnm2ppa printer-driver-postscript-hp printer-driver-ptouch printer-driver-pxljr
  printer-driver-sag-gdi printer-driver-splix psutils python-aptdaemon.gtk3widgets python-aptdaemon.gtkwidgets python-bzrlib python-dbus-dev
  python-debianbts python-defer python-dnspython python-fpconst python-gi python-gi-cairo python-gi-dev python-gobject-2 python-gobject-2-dev
  python-keyring python-launchpadlib python-lazr.restfulclient python-lazr.uri python-liblarch python-liblarch-gtk python-magic python-oauth
  python-packagekit python-pyatspi2 python-pyparsing python-repoze.lru python-routes python-setools python-simplejson python-soappy python-speechd
  python-spice-client-gtk python-wadllib python-webob python-zeitgeist python2.7 python2.7-dev python2.7-minimal qdbus quadrapassel remmina-common
  rhythmbox-data rpcbind rtkit ruby ruby1.9.1 shotwell-common smartdimmer software-properties-common sound-theme-freedesktop speech-dispatcher
  sphinx-common sphinx-doc swell-foop syslinux-themes-debian syslinux-themes-debian-wheezy tdb-tools telepathy-haze telepathy-logger telepathy-rakia
  tex-gyre ttf-marvosym wireless-regdb xbrlapi xorg-sgml-doctools xorriso xserver-xorg-input-mouse xserver-xorg-input-vmmouse xulrunner-17.0 yelp-xsl
  zeitgeist-core zenity-common
The following packages have been kept back:
  acroread-debian-files db4.8-util hibernate ia32-libs ia32-libs-gtk libboost-dev libboost-serialization-dev opensc wine
The following packages will be upgraded:
  abcde abiword abiword-common abiword-plugin-grammar abiword-plugin-mathview acpi acpi-fakekey acpi-support acpi-support-base acpid acroread-data
  acroread-dictionary-en acroread-l10n-en adduser alacarte alsa-base alsa-utils amb-plugins anacron analog ant ant-optional apache2 apache2-doc
  apache2-mpm-prefork apache2-utils apache2.2-bin apache2.2-common app-install-data apt apt-file apt-utils apt-xapian-index aptdaemon aptitude
  aqbanking-tools aspell aspell-en asterisk asterisk-config asterisk-core-sounds-en-gsm asterisk-doc asterisk-voicemail astyle at audacity audacity-data
  augeas-lenses augeas-tools autoconf autoconf-doc automake automake1.9 autopoint autotools-dev avahi-autoipd avahi-daemon avidemux avidemux-common
  avidemux-plugins aview ax25-tools banshee baobab base-files base-passwd bash bash-completion bc bind9-doc bind9-host bind9utils binfmt-support binutils
  bison bluez-cups bogofilter bogofilter-bdb bogofilter-common brasero brasero-common bridge-utils browser-plugin-gnash bsd-mailx bsdmainutils bsdutils
  busybox buzztard buzztard-data bwidget bzip2 bzr bzrtools ca-certificates calibre calibre-bin ccache cd-discid cdebootstrap cdparanoia cdrdao
  checkpolicy cheese cheese-common chromium-browser chromium-browser-inspector cifs-utils cl-asdf cli-common clisp comerr-dev common-lisp-controller
  console-common console-data console-tools consolekit coreutils cowbuilder cowdancer cpio cpp cpp-4.4 cpufrequtils cracklib-runtime crawl-common
  crawl-tiles cron cryptsetup cups cups-bsd cups-client cups-common cups-driver-gutenprint cups-pk-helper cups-ppdc cupsddk curl curlftpfs cvs cw dash
  dasher dasher-data dbus dbus-x11 dc dcraw dctrl-tools debconf debconf-i18n debhelper debian-archive-keyring debian-faq debian-keyring debianutils debirf
  debootstrap desktop-base desktop-file-utils devhelp devhelp-common devscripts dialog dict dictionaries-common diffstat diffutils djtools dkms dmidecode
  dmsetup dnsmasq-base dnsutils doc-debian docbook docbook-dsssl docbook-to-man docbook-utils docbook-xml docbook-xsl docbook-xsl-doc-html docky dosemu
  dosfstools dpatch dpkg dpkg-dev dput dvd+rw-tools dvi2ps dynagen dynamips e2fslibs e2fsprogs ebtables ed eject ekiga emacs23-bin-common emacs23-common
  emacs23-nox emacsen-common emdebian-archive-keyring empathy empathy-common eog epiphany-browser epiphany-browser-data epiphany-extensions esound-common
  espeak espeak-data ethtool evince evince-common evolution evolution-common evolution-data-server evolution-data-server-common evolution-exchange
  evolution-plugins evolution-webcal exif exiftags exim4 exim4-base exim4-config exim4-daemon-light exiv2 f-spot fakechroot fakeroot fancontrol fceu
  fcrackzip fdupes feynmf file file-roller finch findutils firmware-iwlwifi firmware-linux-free firmware-linux-nonfree flac flashrom fldigi flex
  fontconfig fontconfig-config foo2zjs foomatic-db foomatic-db-engine foomatic-db-gutenprint foomatic-filters fping freedesktop-sound-theme freeglut3
  freetds-common ftp fuse-utils g++ g++-4.4 g++-4.4-multilib g++-multilib gawk gcalctool gcc gcc-4.4 gcc-4.4-base gcc-4.4-doc gcc-4.4-multilib
  gcc-doc-base gcc-multilib gcj-jre gcj-jre-headless gconf-defaults-service gconf-editor gconf2 gconf2-common gddrescue gdebi gdebi-core gedit
  gedit-common gedit-plugins genisoimage geoclue geoclue-hostip geoclue-localnet geoclue-manual geoclue-yahoo geoip-database gettext gettext-base
  ghostscript ghostscript-cups gimp gimp-data git git-buildpackage git-core git-svn gitk gksu glade gnash gnash-common gnash-opengl
  gnome-accessibility-themes gnome-applets-data gnome-backgrounds gnome-cards-data gnome-common gnome-control-center gnome-control-center-dev
  gnome-desktop-data gnome-dictionary gnome-disk-utility gnome-do gnome-do-plugins gnome-doc-utils gnome-games gnome-games-data gnome-games-extra-data
  gnome-icon-theme gnome-js-common gnome-keyring gnome-mag gnome-media gnome-menus gnome-nettool gnome-orca gnome-panel-data gnome-pkg-tools
  gnome-power-manager gnome-rdp gnome-screensaver gnome-screenshot gnome-search-tool gnome-session gnome-session-bin gnome-session-canberra
  gnome-session-common gnome-settings-daemon gnome-settings-daemon-dev gnome-system-log gnome-system-monitor gnome-system-tools gnome-terminal
  gnome-terminal-data gnome-user-guide gnomint gnu-fdisk gnucash-docs gnuchess gnumeric gnumeric-common gnupg gnupg-agent gocr google-talkplugin gparted
  gpgv gpredict gpscorrelate grep groff-base grub-common grub-legacy gsfonts-x11 gsmartcontrol gstreamer0.10-alsa gstreamer0.10-buzztard
  gstreamer0.10-buzztard-doc gstreamer0.10-doc gstreamer0.10-ffmpeg gstreamer0.10-ffmpeg-dbg gstreamer0.10-fluendo-mp3 gstreamer0.10-gnonlin
  gstreamer0.10-gnonlin-dbg gstreamer0.10-gnonlin-doc gstreamer0.10-nice gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-dbg
  gstreamer0.10-plugins-bad-doc gstreamer0.10-plugins-base gstreamer0.10-plugins-base-apps gstreamer0.10-plugins-base-dbg gstreamer0.10-plugins-base-doc
  gstreamer0.10-plugins-good gstreamer0.10-plugins-good-dbg gstreamer0.10-plugins-good-doc gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-dbg
  gstreamer0.10-plugins-ugly-doc gstreamer0.10-pulseaudio gstreamer0.10-tools gstreamer0.10-x gtg gthumb gthumb-data gtk2-engines gtk2-engines-pixbuf
  gucharmap guile-1.6 guile-1.6-libs guile-1.8-libs gvfs gvfs-backends gvfs-bin gzip hal hamster-applet hardinfo hddtemp hdparm hfsprogs hostname hp-ppd
  hpijs hplip hplip-cups hplip-data htmldoc htmldoc-common iamerican ibritish iceweasel ifupdown ijsgutenprint imagemagick imagemagick-doc info
  initramfs-tools initscripts inkscape insserv install-info installation-report intltool iotop iproute ipsec-tools iptables iptraf iputils-ping
  ircd-hybrid irssi isc-dhcp-client isc-dhcp-common isc-dhcp-server iscsitarget-dkms iso-codes ispell jack jadetex java-common jigdo-file keyanalyze
  keyboard-configuration keychain klibc-utils kpartx krb5-admin-server krb5-auth-dialog krb5-config krb5-doc krb5-kdc krb5-kdc-ldap krb5-multidev
  krb5-pkinit krb5-user lacheck lame latex-beamer latex-xcolor less lesstif2 lesstif2-dev lib32asound2 lib32bz2-1.0 lib32gcc1 lib32gomp1 lib32ncurses5
  lib32ncurses5-dev lib32nss-mdns lib32readline5 lib32stdc++6 lib32v4l-0 lib32z1 lib32z1-dev liba52-0.7.4 libaa1 libaa1-dev libacl1 libaften0
  libaiksaurus-1.2-0c2a libaiksaurus-1.2-data libaiksaurusgtk-1.2-0c2a libaio1 libalgorithm-diff-xs-perl libany-moose-perl libanyevent-perl libao-common
  libao4 libapache-dbi-perl libapache2-mod-apreq2 libapache2-mod-dnssd libapache2-mod-perl2 libapache2-mod-php5 libapache2-mod-python
  libapache2-request-perl libappconfig-perl libapr1 libapreq2 libaprutil1 libaprutil1-dbd-sqlite3 libaprutil1-ldap libapt-pkg-perl libaqbanking-data
  libarchive-zip-perl libart-2.0-2 libart-2.0-dev libart2.0-cil libasn1-8-heimdal libasound2 libasound2-dev libasound2-plugins libaspell15 libass4
  libasync-interrupt-perl libasyncns0 libatasmart4 libatk1.0-0 libatk1.0-data libatk1.0-dev libatk1.0-doc libatspi1.0-0 libattr1 libaudio-dev libaudio2
  libaudiofile-dev libaudit0 libaugeas0 libavahi-client-dev libavahi-client3 libavahi-common-data libavahi-common-dev libavahi-common3 libavahi-core7
  libavahi-glib-dev libavahi-glib1 libavahi-gobject0 libavahi-ui0 libavc1394-0 libax25 libb-hooks-endofscope-perl libb-keywords-perl libbind9-60
  libblas3gf libblkid1 libbluetooth3 libbml0 libboo2.0.9-cil libbrlapi0.5 libbs2b0 libbsd0 libburn4 libbusiness-paypal-api-perl
  libbusiness-tax-vat-validation-perl libbuzztard0 libbz2-1.0 libc-ares2 libc-bin libc-dev-bin libc6 libc6-dev libc6-dev-i386 libc6-i386 libcaca-dev
  libcaca0 libcache-fastmmap-perl libcairo-perl libcairo2 libcairo2-dev libcairomm-1.0-1 libcairomm-1.0-dev libcanberra-gtk0 libcanberra0 libcap-ng0
  libcap2 libcap2-bin libcapture-tiny-perl libccid libcdaudio1 libcddb-get-perl libcddb2 libcdparanoia0 libcdt4 libchm-bin libchm1 libck-connector0
  libclass-c3-perl libclass-c3-xs-perl libclass-insideout-perl libclass-inspector-perl libclass-method-modifiers-perl libclass-methodmaker-perl
  libclone-perl libclutter-1.0-0 libcolamd2.7.1 libcolor-calc-perl libcomedi0 libcomerr2 libcommon-sense-perl libcommons-beanutils-java
  libcommons-collections3-java libcommons-compress-java libcommons-digester-java libcommons-logging-java libconfig-inifiles-perl libconfig-json-perl
  libconfig-tiny-perl libconsole libcontextual-return-perl libconvert-asn1-perl libcoro-perl libcorosync4 libcpufreq-dev libcpufreq0 libcrack2 libcroco3
  libcrypt-openssl-bignum-perl libcrypt-openssl-random-perl libcrypt-openssl-rsa-perl libcrypt-passwdmd5-perl libcrypt-ssleay-perl libcss-minifier-xs-perl
  libcss-packer-perl libcups2 libcupscgi1 libcupsdriver1 libcupsimage2 libcupsmime1 libcupsppdc1 libcurl3 libcurl3-gnutls libcurses-perl libcwidget3
  libdata-optlist-perl libdata-structure-util-perl libdata-visitor-perl libdatetime-format-http-perl libdatetime-perl libdatetime-set-perl
  libdatetime-timezone-perl libdatrie1 libdb-dev libdb-je-java libdbd-mysql-perl libdbi-perl libdbus-1-3 libdbus-1-dev libdbus-glib-1-2 libdbus-glib-1-dev
  libdc1394-22 libdca0 libdebian-installer-extra4 libdebian-installer4 libdevel-globaldestruction-perl libdevel-size-perl libdevel-stacktrace-perl
  libdevel-symdump-perl libdevmapper1.02.1 libdigest-hmac-perl libdirac-decoder0 libdirac-encoder0 libdirectfb-1.2-9 libdirectfb-extra libdiscid0
  libdjvulibre-text libdjvulibre21 libdns69 libdpkg-perl libdrm-dev libdrm-intel1 libdrm-nouveau1a libdrm-radeon1 libdrm2 libdv4 libdvdcss2 libdvdnav4
  libdvdread4 libedit2 libelf1 libelfg0 libemail-address-perl libenca0 libenchant1c2a libengine-pkcs11-openssl libepc-common libesd0 libesd0-dev
  libespeak1 libevolution libexception-class-perl libexempi3 libexif12 libexpat1 libexpat1-dev libexpect-perl libfaac0 libfaad2 libfcgi-perl libfcgi0ldbl
  libffi-dev libffi5 libfftw3-3 libfile-homedir-perl libfile-libmagic-perl libfile-mmagic-perl libfile-slurp-perl libfile-which-perl libfilter-perl
  libfinance-quote-perl libflac++6 libflac8 libflickrnet2.2-cil libflite1 libfltk1.1 libfluidsynth1 libfontconfig1 libfontconfig1-dev libfontenc1
  libfreetype6 libfreetype6-dev libfribidi0 libfs6 libftdi-dev libftdi1 libfuse2 libgail-common libgail-dev libgail18 libgc1c2 libgcc1 libgcj-bc
  libgcj-common libgconf2-4 libgconf2-dev libgconf2.0-cil libgcrypt11 libgcrypt11-dev libgd-gd2-noxpm-perl libgdata-common libgdbm3 libgdict-1.0-6
  libgdiplus libgdome2-0 libgdome2-cpp-smart0c2a libgdu-gtk0 libgdu0 libgee2 libgeoclue0 libgeoip1 libgfortran3 libgif4 libgimp2.0 libgio-cil libgksu2-0
  libgl1-mesa-dev libgl1-mesa-dri libgl1-mesa-glx libglade2.0-cil libgladeui-1-9 libglib-perl libglib2.0-0 libglib2.0-cil libglib2.0-data libglib2.0-dev
  libglib2.0-doc libglibmm-2.4-1c2a libglibmm-2.4-dev libglu1-mesa libglu1-mesa-dev libgnome-desktop-2-17 libgnome-desktop-dev libgnome-keyring-dev
  libgnome-keyring0 libgnome-keyring1.0-cil libgnome-mag2 libgnome-menu2 libgnome-speech7 libgnome-vfs2.0-cil libgnome2-0 libgnome2-canvas-perl
  libgnome2-common libgnome2-dev libgnome2-perl libgnome2-vfs-perl libgnome2.24-cil libgnomecanvas2-0 libgnomecanvas2-common libgnomecanvas2-dev
  libgnomedesktop2.20-cil libgnomekbd-common libgnomeui-0 libgnomeui-common libgnomeui-dev libgnomevfs2-0 libgnomevfs2-common libgnomevfs2-dev
  libgnomevfs2-extra libgnupg-interface-perl libgnutls-dev libgnutls26 libgoffice-0.8-8 libgoffice-0.8-8-common libgomp1 libgpg-error-dev libgpg-error0
  libgpgme11 libgphoto2-2 libgphoto2-port0 libgpm2 libgpod-common libgpod4 libgraph4 libgsf-1-114 libgsf-1-common libgsl0ldbl libgsm0710-0 libgsm1
  libgssapi-krb5-2 libgssglue1 libgssrpc4 libgstbuzztard0 libgstreamer-plugins-base0.10-0 libgstreamer-plugins-base0.10-dev libgstreamer0.10-0
  libgstreamer0.10-0-dbg libgstreamer0.10-dev libgtk-vnc-1.0-0 libgtk2-perl libgtk2.0-0 libgtk2.0-bin libgtk2.0-cil libgtk2.0-common libgtk2.0-dev
  libgtk2.0-doc libgtkglext1 libgtkhtml3.14-19 libgtkimageview0 libgtkmathview0c2a libgtkmm-2.4-1c2a libgtkmm-2.4-dev libgtop2-7 libgtop2-common
  libgtop2-dev libguard-perl libgudev-1.0-0 libguile-ltdl-1 libgutenprint2 libgvc5 libgweather-common libhal-dev libhal-storage1 libhal1 libhamlib2
  libhpmud0 libhsqldb-java libhtml-packer-perl libhtml-parser-perl libhtml-tableextract-perl libhtml-tagcloud-perl libhtml-template-expr-perl
  libhtml-template-perl libhtml-tree-perl libhtml-treebuilder-xpath-perl libhttp-server-simple-perl libhx509-5-heimdal libhyphen0 libical0 libice-dev
  libice6 libicu44 libicu4j-java libidl-dev libidl0 libidn11 libidn11-dev libieee1284-3 libijs-0.35 libilmbase6 libimage-exif-perl libimage-exiftool-perl
  libio-pty-perl libio-socket-inet6-perl libio-socket-ssl-perl libio-stringy-perl libio-stty-perl libipc-run-perl libiptcdata0 libisc62 libisccc60
  libisccfg62 libisofs6 libiw30 libjack0 libjasper1 libjavascript-minifier-xs-perl libjavascript-packer-perl libjaxp1.3-java libjaxp1.3-java-gcj
  libjbig2dec0 libjline-java libjpeg-progs libjpeg62 libjpeg8 libjs-jquery libjs-yui libjson-any-perl libjson-glib-1.0-0 libjson-perl libjson-xs-perl
  libjtidy-java libk5crypto3 libkadm5clnt-mit7 libkadm5srv-mit7 libkate1 libkdb5-4 libkeyutils1 libklibc libkms1 libkrb5-26-heimdal libkrb5-3
  libkrb5support0 libktoblzcheck1c2a liblapack3gf liblcms1 libldap-2.4-2 liblink-grammar4 liblircclient0 liblist-moreutils-perl liblocale-gettext-perl
  liblocales-perl liblockfile1 liblog-dispatch-perl liblog4c3 liblog4cxx10 libloudmouth1-0 liblouis-data liblouis2 liblqr-1-0 libltdl-dev libltdl7
  liblua5.1-0 liblua5.1-0-dev liblucene2-java liblwres60 liblzo2-2 libmad0 libmagic1 libmagick++3 libmagickcore3 libmagickcore3-extra libmagickwand3
  libmailtools-perl libmeanwhile1 libmime-tools-perl libmime-types-perl libmimic0 libmms0 libmng1 libmodplug1 libmodule-find-perl libmodule-starter-perl
  libmono-accessibility2.0-cil libmono-addins-gui0.2-cil libmono-addins0.2-cil libmono-c5-1.1-cil libmono-cairo2.0-cil libmono-cecil-private-cil
  libmono-corlib2.0-cil libmono-cscompmgd8.0-cil libmono-data-tds2.0-cil libmono-db2-1.0-cil libmono-i18n-west2.0-cil libmono-i18n2.0-cil
  libmono-ldap2.0-cil libmono-management2.0-cil libmono-messaging-rabbitmq2.0-cil libmono-messaging2.0-cil libmono-microsoft-build2.0-cil
  libmono-microsoft8.0-cil libmono-npgsql2.0-cil libmono-oracle2.0-cil libmono-peapi2.0-cil libmono-posix2.0-cil libmono-rabbitmq2.0-cil
  libmono-relaxng2.0-cil libmono-security2.0-cil libmono-sharpzip2.6-cil libmono-sharpzip2.84-cil libmono-simd2.0-cil libmono-sqlite2.0-cil
  libmono-system-data-linq2.0-cil libmono-system-data2.0-cil libmono-system-ldap2.0-cil libmono-system-messaging2.0-cil libmono-system-runtime2.0-cil
  libmono-system-web-mvc1.0-cil libmono-system-web-mvc2.0-cil libmono-system-web2.0-cil libmono-system2.0-cil libmono-tasklets2.0-cil libmono-wcf3.0-cil
  libmono-windowsbase3.0-cil libmono-winforms2.0-cil libmono-zeroconf1.0-cil libmono2.0-cil libmoose-perl libmouse-perl libmp3lame0 libmpc2 libmpcdec6
  libmpfr4 libmpg123-0 libmusicbrainz3-6 libmysqlclient-dev libmysqlclient16 libmythes-1.2-0 libnamespace-autoclean-perl libnamespace-clean-perl
  libncurses5 libncurses5-dev libncursesw5 libncursesw5-dev libndesk-dbus-glib1.0-cil libndesk-dbus1.0-cil libneon27 libneon27-gnutls libnet-daemon-perl
  libnet-dbus-perl libnet-dns-perl libnet-ip-perl libnet-ldap-perl libnet-libidn-perl libnet-netmask-perl libnet-oauth-perl libnet-snmp-perl
  libnet-ssleay-perl libnet1 libnet1-dev libnet6-1.3-0 libnetaddr-ip-perl libnetpbm10 libnewt0.52 libnfnetlink0 libnfsidmap2 libnl1 libnm-glib-dev
  libnm-glib-vpn-dev libnm-glib-vpn1 libnm-util-dev libnotify-dev libnotify0.4-cil libnspr4-0d libnss-mdns libnss3-1d libnunit-cil-dev libofa0 libogg0
  liboobs-1-dev libopenais3 libopenal1 libopencore-amrnb0 libopencore-amrwb0 libopenct1 libopenexr6 libopenjpeg2 libopenraw1 libopenrawgnome1 libopts25
  liborbit2 liborbit2-dev liborc-0.4-0 libortp8 libosp5 libossp-uuid-perl libossp-uuid16 libostyle1c2 libotr2 libots0 libpackage-deprecationmanager-perl
  libpackage-stash-perl libpam-cracklib libpam-gnome-keyring libpam-ldap libpam-modules libpam-p11 libpam-runtime libpam0g libpam0g-dev libpango-perl
  libpango1.0-0 libpango1.0-dev libpango1.0-doc libpangomm-1.4-1 libpangomm-1.4-dev libpaper-utils libpaper1 libparams-util-perl libparams-validate-perl
  libparse-debcontrol-perl libparse-debianchangelog-perl libparse-recdescent-perl libparted0debian1 libpath-class-perl libpathplan4 libpcap0.8
  libpcap0.8-dev libpci3 libpciaccess-dev libpciaccess0 libpcre3 libpcsc-perl libpcsclite-dev libpcsclite1 libperl-critic-perl libperlio-eol-perl
  libphonon4 libpixman-1-0 libpixman-1-dev libpkcs11-helper1 libplist1 libplot2c2 libpng12-0 libpng12-dev libpod-coverage-perl libpoe-api-peek-perl
  libpoe-component-client-http-perl libpoe-component-client-keepalive-perl libpoe-component-ikc-perl libpoe-perl libpolkit-agent-1-0 libpolkit-backend-1-0
  libpolkit-gobject-1-0 libpolkit-gobject-1-dev libpoppler-glib4 libpoppler5 libpopt-dev libpopt0 libportaudio2 libppi-perl libppix-regexp-perl
  libppix-utilities-perl libpq5 libproxy0 libpstoedit0c2a libpthread-stubs0 libpthread-stubs0-dev libpulse-dev libpulse-mainloop-glib0 libpulse0
  libpurple0 libpython2.6 libqdbm14 libqpol1 libqt4-assistant libqt4-core libqt4-dbus libqt4-designer libqt4-gui libqt4-help libqt4-network libqt4-opengl
  libqt4-qt3support libqt4-script libqt4-scripttools libqt4-sql libqt4-sql-mysql libqt4-svg libqt4-test libqt4-webkit libqt4-xml libqt4-xmlpatterns
  libqtcore4 libqtgui4 libraptor1 libraw1394-11 librdf0 libreadline-dev libreadline5 libreadline6 libreadline6-dev libreadonly-perl libreadonly-xs-perl
  librecode0 libregexp-assemble-perl libregexp-common-perl libregexp-java libresample1 libroken18-heimdal librpc-xml-perl librpcsecgss3 librsvg2-2
  librsvg2-2.18-cil librsvg2-common librtmp0 libruby1.8 libsamplerate0 libsane libsane-extras libsane-hpaio libsasl2-2 libsasl2-modules
  libschroedinger-1.0-0 libsctp1 libsdl-image1.2 libsdl-ttf2.0-0 libsdl1.2debian libselinux1 libselinux1-dev libsemanage-common libsemanage1
  libsensors-applet-plugin0 libsensors4 libsepol1 libsepol1-dev libservlet2.5-java libsetools-tcl libsgutils2-2 libshout3 libsigc++-2.0-0c2a
  libsigc++-2.0-dev libslang2 libslang2-dev libslp1 libslv2-9 libsm-dev libsm6 libsmbclient libsmi2ldbl libsndfile1 libsnmp-base libsnmp15
  libsoap-lite-perl libsocket6-perl libsofia-sip-ua-glib3 libsofia-sip-ua0 libsoup-gnome2.4-1 libsoup-gnome2.4-dev libsoup2.4-1 libsoup2.4-dev
  libsox-fmt-all libsox-fmt-alsa libsox-fmt-ao libsox-fmt-base libsox-fmt-ffmpeg libsox-fmt-mp3 libsox-fmt-oss libsox-fmt-pulse libsp1c2 libspandsp2
  libspectre1 libspeex1 libspeexdsp1 libsqlite0 libsqlite3-0 libsqlite3-dev libsrtp0 libss2 libssh-4 libssh2-1 libssl-dev libstartup-notification0
  libstartup-notification0-dev libstdc++6 libstdc++6-4.4-dev libstrongswan libsub-exporter-perl libsub-identify-perl libsub-install-perl libsub-name-perl
  libsub-uplevel-perl libsvga1 libsvga1-dev libsvn-perl libsvn1 libsybdb5 libsysfs-dev libsysfs2 libt1-5 libtag1-vanilla libtag1c2a libtaglib2.0-cil
  libtalloc2 libtar libtasn1-3 libtasn1-3-dev libtdb1 libtelepathy-glib0 libtemplate-perl libterm-readkey-perl libterm-size-perl
  libtest-checkmanifest-perl libtest-class-perl libtest-deep-perl libtest-exception-perl libtest-mockobject-perl libtest-pod-perl libtext-aspell-perl
  libtext-charwidth-perl libtext-csv-perl libtext-csv-xs-perl libtext-iconv-perl libtext-template-perl libthai-data libthai0 libtheora0 libtidy-0.99-0
  libtie-cphash-perl libtie-toobject-perl libtiff4 libtime-format-perl libtool libtotem-plparser17 libtry-tiny-perl libts-0.0-0 libtwolame0 libudev-dev
  libudev0 libuniconf4.6 libunique-1.0-0 libunistring0 libuniversal-can-perl libuniversal-isa-perl libupower-glib-dev libupower-glib1 liburi-perl
  libusb-0.1-4 libusb-1.0-0 libusb-1.0-0-dev libusb-dev libusbmuxd1 libustr-1.0-1 libutempter0 libuuid-perl libuuid1 libv4l-0 libva-x11-1 libva1
  libvamp-hostsdk3 libvariable-magic-perl libvcdinfo0 libvde0 libvdeplug2 libvirt-bin libvirt0 libvisual-0.4-0 libvlc5 libvorbis0a libvorbisenc2
  libvorbisfile3 libvpb0 libvte-common libvte0.16-cil libvte9 libwant-perl libwavpack1 libwbclient0 libwebkit1.1-cil libwildmidi1 libwind0-heimdal
  libwmf0.2-7 libwnck-common libwnck-dev libwnck2.20-cil libwnck22 libwrap0 libwvstreams4.6-base libwvstreams4.6-extras libwww-mechanize-perl libwww-perl
  libwxbase2.8-0 libwxgtk2.8-0 libx11-6 libx11-data libx11-dev libx11-xcb1 libx86-1 libxapian22 libxau-dev libxau6 libxaw7 libxcb-dri2-0 libxcb-keysyms1
  libxcb-randr0 libxcb-render-util0 libxcb-render-util0-dev libxcb-render0 libxcb-render0-dev libxcb-shm0 libxcb-xv0 libxcb1 libxcb1-dev libxcomposite-dev
  libxcomposite1 libxcursor-dev libxcursor1 libxdamage-dev libxdamage1 libxdg-basedir1 libxdmcp-dev libxdmcp6 libxdot4 libxenstore3.0 libxerces2-java
  libxerces2-java-gcj libxext-dev libxext6 libxfixes-dev libxfixes3 libxfont1 libxft-dev libxft2 libxi-dev libxi6 libxinerama-dev libxinerama1
  libxkbfile-dev libxkbfile1 libxklavier-dev libxklavier16 libxml-feedpp-perl libxml-libxml-perl libxml-parser-perl libxml-regexp-perl
  libxml-sax-expat-perl libxml-sax-perl libxml-simple-perl libxml-twig-perl libxml-xpathengine-perl libxml2 libxml2-dev libxml2-doc libxml2-utils libxmu6
  libxmuu1 libxp-dev libxp6 libxpm4 libxrandr-dev libxrandr2 libxrender-dev libxrender1 libxres-dev libxres1 libxslt1-dev libxslt1.1 libxss1 libxt-dev
  libxt6 libxtst6 libxv1 libxvidcore4 libxvmc1 libxxf86dga1 libxxf86vm-dev libxxf86vm1 libyaml-syck-perl libzbar0 libzephyr4 liferea liferea-data
  link-grammar-dictionaries-en links linphone linphone-common lintian linux-base linux-headers-2.6-amd64 linux-headers-2.6.32-5-common
  linux-image-2.6-amd64 linux-image-2.6.32-5-amd64 linux-libc-dev linux-source-2.6.32 live-build lm-sensors lmodern locales lockfile-progs login logjam
  logrotate lsb-base lsb-release lsof luatex lvm2 lwresd lzma m4 make make-doc makedev makepasswd man-db manpages manpages-dev mawk mdadm
  media-player-info mencoder menu mercurial mercurial-common mesa-common-dev mesa-utils metacity-common mic2 mime-support mingw32-binutils mjpegtools
  mktemp mlocate mobile-broadband-provider-info modemmanager module-init-tools mono-2.0-gac mono-csharp-shell mono-gac mono-gmcs mono-mcs mono-runtime
  mono-xbuild mount mousetweaks mozilla-plugin-gnash mpg123 mtd-utils mtools mupen64plus mutt myspell-en-us mysql-client mysql-common mysql-server nano
  nautilus nautilus-data nautilus-sendto nautilus-sendto-empathy nbd-client ncftp ncurses-base ncurses-bin ncurses-term ndisc6 net-tools netatalk netbase
  netcat-openbsd netcat-traditional netenv netpbm network-manager network-manager-dev network-manager-gnome network-manager-openvpn
  network-manager-openvpn-gnome network-manager-vpnc network-manager-vpnc-gnome nfs-common nfs-kernel-server nmap node normalize-audio notification-daemon
  ntp ntpdate nvclock obex-data-server obexd-client odbcinst odbcinst1debian2 open-iscsi openarena openarena-data openarena-server openbios-ppc
  openbios-sparc openbsd-inetd openhackware openjade openocd openoffice.org openoffice.org-base openoffice.org-calc openoffice.org-common
  openoffice.org-draw openoffice.org-emailmerge openoffice.org-evolution openoffice.org-filter-binfilter openoffice.org-filter-mobiledev
  openoffice.org-gnome openoffice.org-gtk openoffice.org-help-en-us openoffice.org-impress openoffice.org-java-common openoffice.org-math
  openoffice.org-officebean openoffice.org-style-tango openoffice.org-thesaurus-en-us openoffice.org-writer openprinting-ppds openssh-blacklist
  openssh-blacklist-extra openssh-client openssh-server openssl openssl-blacklist openvpn openvpn-blacklist orbit2 org-mode os-prober oss-compat p7zip
  p7zip-full parted passwd patch patchutils pavucontrol pavumeter pbuilder pbzip2 pciutils pcmciautils pcsc-tools perl perl-base perl-doc perl-modules
  perlmagick perltidy pgf php-pear php-services-json php5-cli php5-common php5-dev pidgin pidgin-data pidgin-otr pidgin-sipe pinentry-gtk2 pkg-config
  planner pm-utils po-debconf po4a policycoreutils policykit-1 policykit-1-gnome poppler-utils popularity-contest powertop ppp ppp-dev pristine-tar
  procmail procps ps2eps psmisc pstoedit pulseaudio pulseaudio-esound-compat pulseaudio-module-x11 pulseaudio-utils purifyeps pwgen python python-apt
  python-apt-common python-aptdaemon python-aptdaemon-gtk python-axiom python-beautifulsoup python-brlapi python-cairo python-cddb python-central
  python-chardet python-cherrypy3 python-chm python-clientform python-coherence python-configobj python-crypto python-cssutils python-cups
  python-cupshelpers python-dateutil python-dbus python-debian python-demjson python-dev python-django python-django-tagging python-docutils
  python-evolution python-eyed3 python-feedparser python-gconf python-gdata python-gdbm python-glade2 python-gmenu python-gnome2 python-gnome2-desktop-dev
  python-gnome2-dev python-gnome2-doc python-gnomedesktop python-gnomekeyring python-gobject python-gobject-dev python-gpgme python-gst0.10 python-gtk-vnc
  python-gtk2 python-gtk2-dev python-gtk2-doc python-gtkglext1 python-gtksourceview2 python-html5lib python-httplib2 python-imaging python-iniparse
  python-ipy python-jinja2 python-libvirt python-libxml2 python-louis python-lxml python-mako python-markdown python-markupsafe python-mechanize
  python-minimal python-nevow python-notify python-numpy python-ogg python-old-doctools python-opengl python-openssl python-pam python-paramiko
  python-pexpect python-pkg-resources python-pyasn1 python-pyatspi python-pycurl python-pygments python-pykickstart python-pyorbit python-pypdf
  python-pysqlite2 python-pyvorbis python-qt4 python-rdflib python-renderpm python-reportbug python-reportlab python-reportlab-accel python-roman
  python-rpm python-rsvg python-selinux python-semanage python-sepolgen python-serial python-sip python-software-properties python-sphinx python-sqlite
  python-sqlitecachec python-support python-tagpy python-twisted-bin python-twisted-conch python-twisted-core python-twisted-web python-uno
  python-utidylib python-vte python-webkit python-wnck python-xapian python-xdg python-zope.interface python2.6 python2.6-dev python2.6-minimal
  qemu-keymaps qemu-kvm qemu-system qemu-user-static qemu-utils qt4-qtconfig quagga quagga-doc quilt radeontool rdesktop readline-common realpath recode
  remmina reportbug resolvconf rhythmbox rhythmbox-plugins rinse ripit rpm rpm-common rpm2cpio rsync rsyslog samba samba-common samba-common-bin samba-doc
  sane-utils scons screen seabios seahorse sed selinux-policy-default sensible-utils sensors-applet setools sflphone-daemon sflphone-data sflphone-gnome
  sgml-base sgml-data shared-mime-info sharutils shorewall-core shorewall6 shotwell siege signing-party simple-scan slapd smartmontools smbclient smistrip
  snd snd-gtk-pulse snmp software-center software-properties-gtk sound-juicer soundmodem sox sp spidermonkey-bin squashfs-tools ssh-krb5 sshfs ssl-cert
  strace strongswan strongswan-ikev1 strongswan-ikev2 strongswan-starter subversion sudo svn-buildpackage swat synaptic synergy syslinux syslinux-common
  system-config-printer system-config-printer-udev system-tools-backends system-tools-backends-dev sysv-rc sysvinit sysvinit-utils tar tasksel
  tasksel-data tcl tcl8.4 tcl8.5 tcpd tcpdump telepathy-gabble telepathy-mission-control-5 telepathy-salut telepathy-sofiasip tex-common texinfo
  texlive-base texlive-binaries texlive-common texlive-doc-base texlive-extra-utils texlive-font-utils texlive-fonts-recommended
  texlive-fonts-recommended-doc texlive-generic-recommended texlive-latex-base texlive-latex-base-doc texlive-latex-recommended
  texlive-latex-recommended-doc texlive-luatex texlive-metapost texlive-metapost-doc texlive-pstricks texlive-pstricks-doc texlive-xetex tidy time tinymce
  tipa tk tk8.4 tk8.5 tofrodos tomboy toshset totem totem-common totem-mozilla totem-plugins traceroute transfig transmission-cli transmission-common
  transmission-gtk trustedqsl tsconf ttf-ancient-fonts ttf-dejavu ttf-dejavu-core ttf-dejavu-extra ttf-freefont ttf-lg-aboriginal ttf-liberation ttf-lyx
  ttf-opensymbol ttf-sil-gentium ttf-sil-gentium-basic ttf-takao ttf-takao-gothic ttf-takao-mincho ttf-thai-arundina ttf-thai-tlwg ttf-umefont ttf-umeplus
  ttf-unifont twm twolame tzdata ucf udev udisks ufraw-batch unattended-upgrades unetbootin unetbootin-translations unifont unixodbc uno-libs3 unp unrar
  unzip update-inetd update-manager-core update-manager-gnome update-notifier update-notifier-common upower ure usbmuxd usbutils util-linux vde2 vflib3
  vgabios vim-common vim-tiny vino virt-manager virt-viewer virtinst vlc-data vlc-nox vlc-plugin-notify vlc-plugin-pulse vpnc vzctl w3m wamerican wdiff
  wget whiptail whois winbind wireless-tools wireshark wireshark-common wordnet wordnet-base wordnet-gui wpasupplicant wvdial wwwconfig-common x11-apps
  x11-common x11-session-utils x11-utils x11-xfs-utils x11-xkb-utils x11-xserver-utils x11proto-composite-dev x11proto-core-dev x11proto-damage-dev
  x11proto-dri2-dev x11proto-fixes-dev x11proto-fonts-dev x11proto-gl-dev x11proto-input-dev x11proto-kb-dev x11proto-print-dev x11proto-randr-dev
  x11proto-render-dev x11proto-resource-dev x11proto-video-dev x11proto-xext-dev x11proto-xf86dri-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev xauth
  xbase-clients xbitmaps xca xclip xdemorse xdg-user-dirs xdg-user-dirs-gtk xdg-utils xen-tools xen-utils-common xenstore-utils xfonts-100dpi
  xfonts-100dpi-transcoded xfonts-75dpi xfonts-75dpi-transcoded xfonts-a12k12 xfonts-ayu xfonts-baekmuk xfonts-base xfonts-bitmap-mule
  xfonts-biznet-100dpi xfonts-biznet-75dpi xfonts-biznet-base xfonts-cyrillic xfonts-efont-unicode xfonts-efont-unicode-ib xfonts-encodings
  xfonts-jisx0213 xfonts-kaname xfonts-kapl xfonts-mathml xfonts-mona xfonts-naga10 xfonts-scalable xfonts-terminus xfonts-terminus-dos
  xfonts-terminus-oblique xfonts-thai xfonts-thai-etl xfonts-thai-manop xfonts-thai-nectec xfonts-thai-poonlap xfonts-thai-vor xfonts-tipa xfonts-unifont
  xfonts-utils xfonts-wqy xindy xindy-rules xinit xkb-data xml-core xorg xorg-docs-core xoscope xsane xsane-common xserver-common xserver-xephyr
  xserver-xorg xserver-xorg-core xserver-xorg-dev xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-input-wacom
  xserver-xorg-video-apm xserver-xorg-video-ark xserver-xorg-video-ati xserver-xorg-video-chips xserver-xorg-video-cirrus xserver-xorg-video-fbdev
  xserver-xorg-video-i128 xserver-xorg-video-intel xserver-xorg-video-mach64 xserver-xorg-video-mga xserver-xorg-video-neomagic
  xserver-xorg-video-openchrome xserver-xorg-video-r128 xserver-xorg-video-radeon xserver-xorg-video-rendition xserver-xorg-video-s3
  xserver-xorg-video-s3virge xserver-xorg-video-savage xserver-xorg-video-siliconmotion xserver-xorg-video-sis xserver-xorg-video-sisusb
  xserver-xorg-video-tdfx xserver-xorg-video-trident xserver-xorg-video-tseng xserver-xorg-video-vesa xserver-xorg-video-vmware xserver-xorg-video-voodoo
  xsltproc xterm xtightvncviewer xtrans-dev xutils-dev xz-utils yelp yum zenity zip zlib1g zlib1g-dev
2160 upgraded, 944 newly installed, 133 to remove and 9 not upgraded.
Need to get 90.5 MB/2,928 MB of archives.
After this operation, 1,287 MB of additional disk space will be used.
Do you want to continue [Y/n]? 

22 January 2014

Erich Schubert: The init wars

The init wars have recently caught a lot of media attention (e.g. heise, prolinux, phoronix). However, one detail that is often overlooked: Debian is debating over the default, while all of them are already supported to a large extend, actually. Most likely, at least two of them will be made mandatory to support IMHO.
The discussion seems to be quite heated, with lots of people trying to evangelize for their preferred system. This actually only highlights that we need to support more than one, as Debian has always been about choice. This may mean some extra work for the debian-installer developers, because choosing the init system at install time (instead of switching later) will be much easier. More often than not, when switching from one init system to another you will have to perform a hard reset.
If you want to learn about the options, please go to the formal discussion page, which does a good job at presenting the positions in a neutral way.
Here is my subjective view of the init systems:
  • SysV init is the current default, and thus deserves to be mentioned first. It is slow, because it is based on a huge series of shell scripts. It can often be fragile, but at the same time it is very transparent. For a UNIX system administrator, SysV init is probably the preferred choice. You only reboot your servers every year anyway.
  • upstart seems to be a typical Canonical project. It solves a great deal of problems, but apparently isn't good enough at it for everybody, and they fail at including anyone in their efforts. Other examples of these fails include Unity and Mir, where they also announced the project as-is, instead of trying to get other supporters on board early (AFAICT). The key problem to widespread upstart acceptance seems to be the Canonical Contributor License Agreement that many would-be contributors are unwilling to accept. The only alternative would be to fork upstart completely, to make it independent of Canonical. (Note that upstart nevertheless is GPL, which is why it can be used by Debian just fine. The CLA only makes getting patches and enhancements included in the official version hard.)
  • systemd is the rising star in the init world. It probably has the best set of features, and it has started to incorporate/replace a number of existing projects such as ConsoleKit. I.e. it not only manages services, but also user sessions. It can be loosely tied to the GNOME project which has started to rely on it more and more (much to the unhappyness of Canonical, who used to be a key player for GNOME; note that officially, GNOME chose to not depend on systemd, yet I see this as the only reliable combination to get a complete GNOME system running, and since "systemd can eventually replace gnome-session" I foresee this tie to become closer). As the main drawback, systemd as is will (apparently) only work with the Linux kernel, whereas Debian has to also support kFreeBSD, NetBSD, Hurd and the OpenSolaris kernels (some aren't officially supported by Debian, but by separate projects).
So my take: I believe the only reasonable default is systemd. It has the most active development community and widest set of features. But as it cannot support all architectures, we need mandatory support for an alternative init system, probably SysV. Getting both working reliably will be a pain, in particular since more and more projects (e.g. GNOME) tie themselves closely to systemd, and would then become Linux-only or require major patches.
I have tried only systemd on a number of machines, and unfortunately I cannot report it as "prime time ready" yet. You do have the occasional upgrade problems and incompatibilities, as it is quite invasive. From screensavers activating during movies to double suspends, to being unable to shutdown my system when logged in (systemd would treat the login manager as separate session, and not being the sole user it would not allow me to shut down), I have seen quite a lot of annoyances happen. This is an obvious consequence of the active development on systemd. This means that we should make the decision early, because we will need a lot of time to resolve all these bugs for the release.
There are more disruptions coming on the way. Nobody seems to have talked about kDBUS yet, the integration of an IPC mechanism like DBUS into the Linux kernel. It IMHO has a good chance of making it into the Linux kernel rather soon, and I wouldn't be surprised if it became mandatory for systemd soon after. Which then implies that only a recent kernel (say, mid-2014) version might be fully supported by systemd soon.
I would also like to see less GNOME influence in systemd. I have pretty much given up on the GNOME community, which is moving into a UI direction that I hate: they seem to only care about tablet and mobile phones for dumb users, and slowly turn GNOME into an android UI; selling black background as major UI improvements. I feel that the key GNOME development community does not care about developers and desktop users like me anymore (but dream of being the next Android), and therefore I have abandoned GNOME and switched to XFCE.
I don't give upstart much of a chance. Of course there are some Debian developers already involved in its development (employed by Canonical), so this will cause some frustration. But so far, upstart is largely an Ubuntu-only solution. And just like Mir, I don't see much future in it; instead I foresee Ubuntu going systemd within a few years, because it will want to get all the latest GNOME features. Ubuntu relies on GNOME, and apparently GNOME already has chosen systemd over upstart (even though this is "officially" denied).
Sticking with SysV is obviously the easiest choice, but it does not make a lot of sense to me technically. It's okay for servers, but more and more desktop applications will start to rely on systemd. For legacy reasons, I would however like to retain good SysV support for at least 5-10 more years.

But what is the real problem? After all, this is a long overdue decision.
  • There is too much advocacy and evangelism, from either side. The CTTE isn't really left alone to do a technical decision, but instead the main factors have become of political nature, unfortunately. You have all kinds of companies (such as Spotify) weigh in on the debate, too.
  • The tone has become quite aggressive and emotional, unfortunately. I can already foresee some comments on this blog post "you are a liar, because GNOME is now spelled Gnome!!1!".
  • Media attention. This upcoming decision has been picked up by various Linux media already, increasing the pressure on everybody.
  • Last but not least, the impact will be major. Debian is one of the largest distributions, last but not least used by Ubuntu and Steam, amongst others. Debian preferring one over the other will be a slap in somebodys face, unfortunately.
So how to solve it? Let the CTTE do their discussions, and stop flooding them with mails trying to influence them. There has been so much influencing going on, it may even backfire. I'm confident they will find a reasonable decision, or they'll decide to poll all the DDs. If you want to influence the outcome provide patches to anything that doesn't yet fully support your init system of choice! I'm sure there are hundreds of packages which do neither have upstart nor systemd support yet (as is, I currently have 27 init.d scripts launched by systemd, for example). IMHO, nothing is more convincing than have things just work, and of course, contributing code. We are in open source development, and the one thing that gets you sympathy in the community is to contribute code to someone elses project. For example, contribute full integrated power-management support into XFCE, if you include power management functionality.
As is, I have apparently 7 packages installed with upstart support, and 25 with systemd support. So either, everybody is crazy about systemd, or they have the better record of getting their scripts accepted upstream. (Note that this straw poll is biased - with systemd, the benefits of not using "legacy" init.d script may just be larger).

28 October 2013

Matthias Klumpp: Tanglu update & release plans

Long time with no article about Tanglu! This was mainly because we were busy with the project itself, improving various aspects of the distribution. So, here is a new summary on what has been done and what you can expect from the first release ;-) Tanglu QA We further improved the automatic archive QA. There is now qa.tanglu.org, which constantly monitors the number of uninstallable or unbuildable packages in the Tanglu suites. It also provides tanglu-platform-smallstatus information on the metapackage generator, which helps us in finding out which packages are available on the live-cds. Furthermore, information about the staging->devel migration process is provided, to answer the question why a package does not migrate (this still needs some improvements, but it is being worked on). We also use some code from Ubuntu to monitor package versions in Debian and upstream, which helps to see if others have released newer versions of software shipped with Tanglu. This already resulted in many improvements: The Tanglu Aequorea suite does not contain unbuildable packages (at least not due to build-dependency changed), and all live-cds are working well. We will soon migrate the archive to a new server, which frees some server capacities we can use for automated QA and things like automatic live-CD building. Live-CDs, Installer, Alpha-Releases We currently don t do Alpha-Releases of Tanglu, but we create Live-CD snapshots of Tanglu, which are available at releases.tanglu.org (or mirror1, mirror2). These snapshots still have issues and are just early previews. They also ship without and installer, we are still working on that part. Please note that CD more or less means DVD or USB-Stick right now (and this won t change the expected image size will be around 800MB). Release Planning I am happy to announce that we will do a release this year, most likely in December. But what can you expect from the release? KDE 4.11kde-konqui We will ship with KDE 4.11, which will be the only desktop we officially support so far. The reason is simply lack of manpower we could promise to support more, but that would just be not realistic for the small team. So we focus on KDE (Plasma Shells) right now, and try to make it awesome. Also, the team consists mostly of KDE people right now, which contributed to that decision ;-) . If you want to try Tanglu, right now the KDE live-images are the best to try it out. GNOME 3.8 gnome-logoWe will also provide images with GNOME. The problem with GNOME is, that the GNOME team does not have enough manpower to maintain the whole desktop or to upgrade it to the latest version (it is essentially just me looking at it from time to time). So GNOME will be available in a preview state. We invite everyone with GNOME knowledge to join the project and help improving Tanglu-GNOME GNOMErs, we want you! systemd >= 204 We ship with systemd by default, which works nicely so far, although more testing needs to be done. The logind service will be used to replace ConsoleKit, if we manage to get everything in place and working in time (if there are issues, we might switch back to CK for one release). There are some plans to use a higher systemd version, due to some improvements made there, but if this will be done is still unclear (Debian will most likely stick to 204 for some time, because with systemd > 205, running it as pid 1 will be mandatory to use logind (and Debian is just in the process to decide which init-system we will use there)). Systemd will run in SysVInit compatibility mode for most of the available services. This will improve in later Tanglu releases. Of course, systemd is usable, even if not every init-script has been converted to a service file. It just has an impact on startup times, so Tanglu will not be the distributions with the fastest startup times (yet ;-) ). Debian Package Mixdebian_logo1 Tanglu consists mostly of packages from Debian Testing (Jessie), but we take full advantage of the Debian archive, so you will also find package versions from Unstable or even Experimental (where it made sense). A very small portion of packages has also been merged with Ubuntu. Although stuff has been changed, the incompatibilities with Debian are almost zero, so if you are installing Tanglu, it will currently feel like an more up-to-date Debian Testing with some extras. Still, the differences are large enough that upgrading a Debian system to Tanglu might result in some issues. Installer Right now, the installer is a major field of work. Tanglu will most likely ship with the Debian-Installer, because it is the easiest thing to do right now. For later releases, it is planned to also offer the Ubiquity installer (the thing Ubuntu uses), or a new installer with a similar UI and concept. Other Cool Things266px-Wayland_Logo Tanglu will ship with a fully working Qt5 (which is currently being tested and updated) and the latest version of Wayland/Weston as a preview for developers to play around with. We also ship with Perl 5.18 and Haskell GHC 7.6, as well as with GCC 4.8 as default compiler (although the whole distribution does not yet compile with GCC 4.8). We might ship with Linux 3.12, but this also depends on other things. The Linux kernel build will be the same as in Debian. There might be more things to come :-) Please do always keep in mind that Tanglu is a new project, so the first release might still have some teething problems but we re working on it. The Aequorea release will be supported one to two more months after the next release is out. Tanglu Policy I started to draft a Tanglu policy, which defines stuff like the procedures to become a Tanglu project member and/or developer, some basic values of the distribution, decision making processes etc. This work is at a very early stage right now, and will need lots of feedback later. But as soon as it is done, joining the project will be easier and what Tanglu is will be well-defined. The policy will also include a Code-of-Conduct as an additional document from the start. We need help! ;-) First of all, thanks to everyone working on Tanglu! You are amazing! Also, many thanks to every Debian developer or contributor who helped a lot in setting the project up and contributed knowledge. And of course, thanks to everyone else who contributed by creating awesome artwork, helped with code, TangluTanglu Logo (big) archive mirrors, buildd-servers or by testing the distribution and providing feedback! (given the state the aequorea suite was in at the beginning, testing was a really frustrating activity but people still did it!) So, if you would like to help, just find us on #tanglu-devel on Freenode or join the tg-devel mailinglist. We also really need some people taking care of the Tanglu website and updating it with some recent information from time to time, so people can see what is going on. Before we have the Tanglu policy finished and the Tanglu members and developers directory in place (a software which allows us to track all registered developers and gives them an @tanglu.org mailalias), the start might be a bit confusing, but we do our best to make it easy for new people to join. The best way is asking people. Tanglu is still created by an incredibly small team, which has a large task to accomplish. Help is welcome :-)

3 September 2013

Miriam Ruiz: pySioGame: Educational activities and games for kids

I discovered pySioGame for the first time in the first half of 2012, and even though it was still in a beta state, I liked it a lot. pySioGame is essentially a set of educational activities and games for kids. pySioGame was initially developed by its author -Ireneusz Imiolek- for his son, but he soon decided to make it Free Software. And I m glad that he did, because it s a very cute application. Even though -in it s author s own words- it s hard to put age range on this kind of games, it is primarily targeted to children from as young as 3 years old, up to about 10 years old. The activities included, many of which are grid based, cover topics like maths, reading, writing, painting, and memory activities, among others. I was finally able to upload pySioGame to Debian during the DebConf, and it has very recently hit the archive. I m convinced that pySioGame is soon going to be one of the references among the free programs for small kids, among titles such as GCompris, ChildsPlay, PySyCache, or Bouncy. Or, even though it s not in the archives, Omnitux. Finally, to whet your appetite, here is the link to a video, and there go some screenshots:

5 March 2013

Tanguy Ortolo: Suspend your computer from a non-mainstream desktop environment

Battery icon UPower for regular users Major desktop environments usually provide a user-friendly menu to suspend your computer. Internally, if seems to use something called UPower, which uses something called PolicyKit, which in turn may or may not use another piece called ConsoleKit (do not ask me what all these pieces are and how they relate to each other, I do not know and I do not want to know). For the regular user, the result is the following: when they click on that button, it suspends their computer.UPower for command line users However, if you are using a more unusual desktop environment, for instance a simple, light window manager, you will not have such a button. And no, UPower does not provide a simple command line tool to suspend your computer (they probably consider that command line is out of fashion ). Well, in case you need it, here is a way to suspend your computer from a command line or whatever: just alias it or bind it to a key shortcut. It uses some dark DBus magic:
$ dbus-send --system --print-reply --dest='org.freedesktop.UPower' \
    /org/freedesktop/UPower org.freedesktop.UPower.Suspend
If you prefer to hibernate your computer, that is, to suspend it, not to RAM but to disk:
$ dbus-send --system --print-reply --dest='org.freedesktop.UPower' \
    /org/freedesktop/UPower org.freedesktop.UPower.Hibernate
As you can see, for some reason it requires some duplication of information: the name org.freedesktop.UPower appears three times in that command line: in the destination , object path and interface member , whatever that could mean. Again, do not ask me why, I know nothing about that and I do not want to. Notes
  1. Actually, UPower does provide a command line tool called upower, but the only thing it does (monitoring power sources) is not really useful for that matter.

25 January 2013

Johannes Schauer: Bootstrappable Debian - New Milestone

This post is about the port bootstrap build ordering tool (naming suggestions welcome) which was started as a Debian Google Summer of Code project in 2012 and continued to be developed afterwards. Sources are available through gitorious. In the end of November 2012, I managed to put down an approximation algorithm to the feedback arc set problem which allowed to break the dependency graph into a directed acyclic graph with only few removed build dependencies. I wrote about this effort on our mailinglist but didnt mention it here because it was still too much of a proof-of-concept. Later, in January 2013, I mentioned the result of this algorithm in an email wookey and me wrote to debian-devel mailinglist. Many things happened since November 2012:

Processing pipeline instead of monolithic tools The tools I developed so far tried to accomplish everything by themselves, reusing functionality implemented in a central library. Therefor, if one wanted to try out even trivial new things, it mostly meant to hack some OCaml code. Pietro Abate suggested to instead develop smaller tools which could work independently of each other, would only execute one algorithm each and could easily be connected together in different ways to achieve different effects. This switch is now done and all functionality from the old tools is moved into a new toolset. The exchange format between the tools is either plain text files in deb822 control format (Packages/Sources files) or a dependency graph. The dependency graph is currently marshalled by OCaml but future versions should work with just passing a GraphML (an XML graph format) representation around. This new way of doing things seems close to the UNIX philosophy (each program does one thing well, data is stored as text, every program is a filter). For example the deb822 control output can easily be manipulated using grep-dctrl(1) and there exist many tools which can read, analyze and manipulate GraphML. It is a big improvement over the old, monolithic tools which did not allow to manipulate any intermediate result by external, existing tools. Currently, a shell script (native.sh) will execute all tools in a meaningful order, connecting them together correctly. The same tools will be used for a future cross.sh but they will be connected differently. I wrote about a first proposal of what the individual tools should do and how they should be connected in this email from which I also linked a confusing overview of the pipeline. This overview has recently been improved to be even more confusing and the current version of the lower half (the native part) now looks like this: native reduced Solid arrows represent a flow of binary packages, dottend arrows represent a flow of source packages, ovals represent a set of packages, boxes with rounded corners represent set operations, rectangular boxes represent filters. There is only one input to a filter, which is the arrow connected to the top of the box. Outgoing arrows from the bottom represent the filtered input. Ingoing arrows to either side are arguments to the filter and control how the filter behaves depending on the algorithm. I will explain this better once the pipeline proved to be less in flux. The pipeline is currently executed like this by native.sh.

Two new ways to break dependency cycles have been discovered So far, we knew of three ways to formally break dependency cycles:
  • remove build dependencies through build profiles
  • find out that the build dependency is only used to build arch:all packages and therefor put it into Build-Depends-Indep
  • cross compile some source packages
Two new methods can be added to the above:

Dependency graph definition changed Back in September when I was visiting irill, Pietro found a flaw in how the dependency graph used to be generated. He supplied a new definition of the dependency graph which does away with the problem he found. After fixing some small issues with his code, I changed all the existing algorithms to use the new graph definition. The old graph is as of today removed from the repository. Thanks to Pietro for supplying the new graph definition - I must still admit that my OCaml foo is not strong enough to have come up with his code.

Added complexity for profile built source packages As mentioned in the introduction, wookey and me addressed the debian-devel list with a proposal on necessary changes for an automated bootstrapping of Debian. During the discussiong, two important things came up which are to be considered by the dependency graph algorithms:
  • profile built source packages may not create all binary packages
  • profile built source packages may need additional build dependencies
Both things make it necessary to alter the dependency graph during the generation of a feedback arc set and feedback vertex set beyond the simple removal of edges. Luckily, the developed approximation algorithms can be extended to support such changes in the graph.

Different feedback arc set algorithms The initially developed feedback arc set algorithm is well suited to discover build dependency edges which should be dropped. It performs far worse when creating the final build order because it only considers edges by itself and not how many edges of a source package can be dropped by profile building it. The adjusted algorithm for generating a build order is more of a feedback vertex set algorithm because instead of greedily finding the edge with most cycles through it, it greedily finds the source package which would break most cycles if it was profile built.

Generating a build order with less profile built source packages After implementing all the features above I now feel more confident to publish the current status of the tools to a wider audience. The following test shows a run of the aforementioned ./native.sh shell script. Its final output is a list of source packages which have to be profile built and a build order. Using the resulting build order, starting from a minimal build system (essential:yes, build-essential and debhelper), all source packages will be compiled which are needed to compile all binary packages in the system. The result will therefor be a list of source and binary packages which fulfill the following property:
  • all binary packages can be built from the available source packages
  • all source packages can be built with the available binary packages
I called this a "reduceded distribution" in earlier posts. The interesting property of this specific selection is, that it contains the biggest problem set of Debian when bootstrapping it: a 900 to 1000 nodes big strongly connected component. Here is a visualization of the problem: hideous mess Source packages do not yet come with build profiles and the cross build situation can not yet be analyzed, so the following assumptions were made: The last point is about 14 build dependencies which were decided to be broken by the feedback arc set algorithm but for which other data sources did not indicate that they are actually breakable. Those 14 are dynamically generated by native.sh. If above assumptions should not be too far from the actual situation, then not more than 73 source packages have to be modified to bootstrap a reduced distribution. This reduced distribution even includes dependency-wise "big" packages like webkit, metacity, iceweasel, network-manager, tracker, gnome-panel, evolution-data-server, kde-runtime, libav and nautilus. By changing one line in native.sh one could easily develop a build order which generates gnome-desktop or really any given (meta-)package selection. All of native.sh takes only 80 seconds to execute on my system (Core i5, 2.5 GHz, singlethreaded). Here is the final build order which creates 2044 binary packages from 613 source packages.
  1. nspr, libio-pty-perl, libmcrypt, unzip, libdbi-perl, cdparanoia, libelf, c-ares, liblocale-gettext-perl, libibverbs, numactl, ilmbase, tbb, check, libogg, libatomic-ops, libnl($), orc($), libaio, tcl8.4, kmod, libgsm, lame, opencore-amr, tcl8.5, exuberant-ctags, mhash, libtext-iconv-perl, libutempter, pciutils, gperf, hspell, recode, tcp-wrappers, fdupes, chrpath, libbsd, zip, procps, wireless-tools, cpufrequtils, ed, libjpeg8, hesiod, pax, less, dietlibc, netkit-telnet, psmisc, docbook-to-man, libhtml-parser-perl, libonig, opensp($), libterm-size-perl, linux86, libxmltok, db-defaults, java-common, sharutils, libgpg-error, hardening-wrapper, cvsps, p11-kit, libyaml, diffstat, m4
  2. openexr, enca, help2man, speex, libvorbis, libid3tag, patch, openjade1.3, openjade, expat, fakeroot, libgcrypt11($), ustr, sysvinit, netcat, libirman, html2text, libmad, pth, clucene-core, libdaemon($), texinfo, popt, net-tools, tar, libsigsegv, gmp, patchutils($), dirac, cunit, bridge-utils, expect, libgc, nettle, elfutils, jade, bison
  3. sed, indent, findutils, fastjar, cpio, chicken, bzip2, aspell, realpath, dctrl-tools, rsync, ctdb, pkg-config($), libarchive, gpgme1.0, exempi, pump, re2c, klibc, gzip, gawk, flex-old, original-awk, mawk, libtasn1-3($), flex($), libtool
  4. libcap2, mksh, readline6, libcdio, libpipeline, libcroco, schroedinger, desktop-file-utils, eina, fribidi, libusb, binfmt-support, silgraphite2.0, atk1.0($), perl, gnutls26($), netcat-openbsd, ossp-uuid, gsl, libnfnetlink, sg3-utils, jbigkit, lua5.1, unixodbc, sqlite, wayland, radvd, open-iscsi, libpcap, linux-atm, gdbm, id3lib3.8.3, vo-aacenc, vo-amrwbenc, fam, faad2, hunspell, dpkg, tslib, libart-lgpl, libidl, dh-exec, giflib, openslp-dfsg, ppl($), xutils-dev, blcr, bc, time, libdatrie, libpthread-stubs, guile-1.8, libev, attr, libsigc++-2.0, pixman, libpng, libssh2, sqlite3, acpica-unix, acl, a52dec
  5. json-c, cloog-ppl, libverto, glibmm2.4, rtmpdump, libdbd-sqlite3-perl, nss, freetds, slang2, libpciaccess, iptables, e2fsprogs, libnetfilter-conntrack, bash, libthai, python2.6($), libice($), libpaper, libfontenc($), libxau, libxdmcp($), openldap($), cyrus-sasl2($), openssl, python2.7($)
  6. psutils, libevent, stunnel4, libnet-ssleay-perl, libffi, readline5, file, libvoikko, gamin, libieee1284, build-essential, libcap-ng($), lcms($), keyutils, libxml2, libxml++2.6, gcc-4.6($), binutils, dbus($), libsm($), libxslt, doxygen($)
  7. liblqr, rarian, xmlto, policykit-1($), libxml-parser-perl, tdb, devscripts, eet, libasyncns, libusbx, icu, linux, libmng, shadow, xmlstarlet, tidy, gavl, flac, dbus-glib($), libxcb, apr, krb5, alsa-lib
  8. usbutils, enchant, neon27, uw-imap, libsndfile, yasm, xcb-util, gconf($), shared-mime-info($), audiofile, ijs($), jbig2dec, libx11($)
  9. esound, freetype, libxkbfile, xvidcore, xcb-util-image, udev($), libxfixes, libxext($), libxt, libxrender
  10. tk8.4, startup-notification, libatasmart, fontconfig, libxp, libdmx, libvdpau, libdrm, libxres, directfb, libxv, libxxf86dga, libxxf86vm, pcsc-lite, libxss, libxcomposite, libxcursor, libxdamage, libxi($), libxinerama, libxrandr, libxmu($), libxpm, libxfont($)
  11. xfonts-utils, libxvmc, xauth, libxtst($), libxaw($)
  12. pmake, corosync, x11-xserver-utils, x11-xkb-utils, coreutils, xft, nas, cairo
  13. libedit, cairomm, tk8.5, openais, pango1.0($)
  14. ocaml, blt, ruby1.8, firebird2.5, heimdal, lvm2($)
  15. cvs($), python-stdlib-extensions, parted, llvm-2.9, ruby1.9.1, findlib, qt4-x11($)
  16. xen, mesa, audit($), avahi($)
  17. x11-utils, xorg-server, freeglut, libva
  18. jasper, tiff3, python3.2($)
  19. openjpeg, qt-assistant-compat, v4l-utils, qca2, jinja2, markupsafe, lcms2, sip4, imlib2, netpbm-free, cracklib2, cups($), postgresql-9.1
  20. py3cairo, pycairo, pam, libgnomecups, gobject-introspection($)
  21. gdk-pixbuf, libgnomeprint, gnome-menus, gsettings-desktop-schemas, pangomm, consolekit, vala-0.16($), colord($), atkmm1.6
  22. libgee, gtk+3.0($), gtk+2.0($)
  23. gtkmm2.4, poppler($), openssh, libglade2, libiodbc2, gcr($), libwmf, systemd($), gcj-4.7, java-atk-wrapper($)
  24. torque, ecj($), vala-0.14, gnome-keyring($), gcc-defaults, gnome-vfs($)
  25. libidn, libgnome-keyring($), openmpi
  26. mpi-defaults, dnsmasq, wget, lynx-cur, ghostscript, curl
  27. fftw3, gnupg, libquvi, xmlrpc-c, raptor, liboauth, groff, fftw, boost1.49, apt
  28. boost-defaults, libsamplerate, cmake, python-apt
  29. qjson, qtzeitgeist, libssh, qimageblitz, pkg-kde-tools, libical, dwarves-dfsg, automoc, attica, yajl, source-highlight, pygobject, pygobject-2, mysql-5.5($)
  30. libdbd-mysql-perl, polkit-qt-1, libdbusmenu-qt, raptor2, dbus-python, apr-util
  31. rasqal, serf, subversion($), apache2
  32. git, redland
  33. xz-utils, util-linux, rpm, man-db, make-dfsg, libvisual, cryptsetup, libgd2, gstreamer0.10
  34. mscgen, texlive-bin
  35. dvipng, luatex
  36. libconfig, transfig, augeas, blas, libcaca, autogen, libdbi, linuxdoc-tools, gdb, gpm
  37. ncurses, python-numpy($), rrdtool, w3m, iproute, gcc-4.7, libtheora($), gcc-4.4
  38. libraw1394, base-passwd, lm-sensors, netcf, eglibc, gst-plugins-base0.10
  39. libiec61883, qtwebkit, libvirt, libdc1394-22, net-snmp, jack-audio-connection-kit($), bluez
  40. redhat-cluster, gvfs($), pulseaudio($)
  41. phonon, libsdl1.2, openjdk-6($)
  42. phonon-backend-gstreamer($), gettext, libbluray, db, swi-prolog, qdbm, swig2.0($)
  43. highlight, libselinux, talloc, libhdate, libftdi, libplist, python-qt4, libprelude, libsemanage, php5
  44. samba, usbmuxd, libvpx, lirc, bsdmainutils, libiptcdata, libgtop2, libgsf, telepathy-glib, libwnck3, libnotify, libunique3, gnome-desktop3, gmime, glib2.0, json-glib, libgnomecanvas, libcanberra, orbit2, udisks, d-conf, libgusb
  45. libgnomeprintui, libimobiledevice, nautilus($), libbonobo, librsvg
  46. evas, wxwidgets2.8, upower, gnome-disk-utility, libgnome
  47. ecore, libbonoboui
  48. libgnomeui
  49. graphviz
  50. exiv2, libexif, lapack, soprano, libnl3, dbus-c++
  51. atlas, libffado, graphicsmagick, libgphoto2, network-manager
  52. pygtk, jackd2, sane-backends, djvulibre
  53. libav($), gpac($), ntrack, python-imaging, imagemagick, dia
  54. x264($), matplotlib, iceweasel
  55. strigi, opencv, libproxy($), ffms2
  56. kde4libs, frei0r, glib-networking
  57. kde-baseapps, kate, libsoup2.4
  58. geoclue, kde-runtime, totem-pl-parser, libgweather, librest, libgdata
  59. webkit
  60. zenity, gnome-online-accounts
  61. metacity, evolution-data-server
  62. gnome-panel
  63. tracker
The final recompilation of profile built source packages is omitted. Source packages marked with a ($) are selected to be profile built. All source packages listed in the same line can be built in parallel as they do not depend upon each other. This order looks convincing as it first compiles a multitude of source packages which have no or only few build dependencies lacking. Later steps allow fewer source packages to be compiled in parallel. The amount of needed build dependencies is highest in the source packages that are built last.

1 October 2012

Martin Pitt: Announcing D-Bus mocker library

I was working on writing tests for gnome-settings-daemon a week or so ago, and finally got blocked on being unable to set up upower/ConsoleKit/etc. the way I need them. Also, doing so needs root privileges, I don t want my test suite to actually suspend my machine, and using the real service is generally not suitable for test suites that are supposed to run during make check , in jhbuild, and the like these do not have the polkit privileges to do all that, and may not even have a system D-Bus running in the first place. So I wrote a little test_upower.py helper, then realized that I need another one for systemd/ConsoleKit (for the system idle property), also looked at the mock polkit in udisks and finally sat down for two days to generalize this and do this properly. The result is python-dbusmock, I just released the first tarball. With this you can easily create mock objects on D-Bus from any programming language with a D-Bus binding, or even from the shell. The mock objects look like the real API (or at least the parts that you actually need), but they do not actually do anything (or only some action that you specify yourself). You can configure their state, behaviour and responses as you like in your test, without making any assumptions about the real system status. When using a local system/session bus, you can do unit or integration testing without needing root privileges or disturbing a running system. The Python API offers some convenience functions like start_session_bus() and start_system_bus() for this, in a DBusTestCase class (subclass of the standard unittest.TestCase ). Surprisingly I found very little precedence here. There is a Perl module, but that s not particuarly helpful for test suites in C/Vala/Python. And there is Phil s excellent Bendy Bus, but this has a different goal: If you want to thoroughly test a particular D-BUS service, such as ensuring that it does the right thing, doesn t crash on bad input, etc., then Bendy Bus is for you (and python-dbusmock isn t). However, it is too much overhead and rather inconvenient if you want to test a client-side program and just need a few system services around it which you want to set up in different states for each test. You can use python-dbusmock with any programming language, as you can run the mocker as a normal program. The actual setup of the mock (adding objects, methods, properties, etc.) all happen via D-Bus methods on the org.freedesktop.DBus.Mock interface. You just don t have the convenience D-Bus launch API. The simplest possible example is to create a mock upower with a single Suspend() method, which you can set up like this from Python:
import dbus
import dbusmock
class TestMyProgram(dbusmock.DBusTestCase):
[...]
    def setUp(self):
        self.p_mock = self.spawn_server('org.freedesktop.UPower',
                                        '/org/freedesktop/UPower',
                                        'org.freedesktop.UPower',
                                        system_bus=True,
                                        stdout=subprocess.PIPE)
        # Get a proxy for the UPower object's Mock interface
        self.dbus_upower_mock = dbus.Interface(self.dbus_con.get_object(
            'org.freedesktop.UPower', '/org/freedesktop/UPower'),
            'org.freedesktop.DBus.Mock')
        self.dbus_upower_mock.AddMethod('', 'Suspend', '', '', '')
[...]
    def test_suspend_on_idle(self):
        # run your program in a way that should trigger one suspend call
        # now check the log that we got one Suspend() call
        self.assertRegex(self.p_mock.stdout.readline(), b'^[0-9.]+ Suspend$')
This doesn t depend on Python, you can just as well run the mocker like this:
python3 -m dbusmock org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower
and then set up the mocks through D-Bus like
gdbus call --system -d org.freedesktop.UPower -o /org/freedesktop/UPower \
      -m org.freedesktop.DBus.Mock.AddMethod '' Suspend '' '' ''
If you use it with Python, you get access to the dbusmock.DBusTestCase class which provides some convenience functions to set up and tear down local private session and system buses. If you use it from another language, you have to call dbus-launch yourself. Please see the README for some more details, pointers to documentation and examples. Update: You can now install this via pip from PyPI or from the daily builds PPA. Update 2: Adjusted blog entry for version 0.0.3 API, to avoid spreading now false information too far.

28 July 2012

Vincent Bernat: Switching to the awesome window manager

I have happily used FVWM as my window manager for more than 10 years. However, I recently got tired of manually arranging windows and using the mouse so much. A window manager is one of the handful pieces of software getting in your way at every moment which explains why there are so many of them and why we might put so much time in it. I decided to try a tiling window manager. While i3 seemed pretty hot and powerful (watch the screencast!), I really wanted something configurable and extensible with some language. So far, the common choices are: I chose awesome, despite the fact that StumpWM vote for Lisp seemed a better fit (but it is more minimalist). I hope there is some parallel universe where I enjoy StumpWM. Visually, here is what I got so far: awesome dual screen setup

Awesome configuration Without a configuration file, awesome does nothing. It does not come with any hard-coded behavior: everything needs to be configured through its Lua configuration file. Of course, a default one is provided but you can also start from scratch. If you like to control your window manager, this is somewhat wonderful. awesome is well documented. The wiki provides a FAQ, a good introduction and the API reference is concise enough to be read from the top to the bottom. Knowing Lua is not mandatory since it is quite easy to dive into such a language. I have posted my configuration on GitHub. It should not be used as is but some snippets may be worth to be stolen and adapted into your own configuration. The following sections put light on some notable points.

Keybindings Ten years ago was the epoch of scavanger hunts to recover IBM Model M keyboards from waste containers. They were great to type on and they did not feature the infamous Windows keys. Nowadays, this is harder to get such a keyboard. All my keyboards now have Windows keys. This is a major change with respect to configure a window manager: the left Windows key is mapped to Mod4 and is usually unused by most applications and can therefore be dedicated to the window manager. The main problem with the ability to define many keybindings is to remember the less frequently used one. I have monkey-patched awful.key module to be able to attach a documentation string to a keybinding. I have documented the whole process on the awesome wiki. awesome online help

Quake console A Quake console is a drop-down terminal which can be toggled with some key. I was heavily relying on it in FVWM. I think this is still a useful addition to any awesome configuration. There are several possible solutions documented in the awesome wiki. I have added my own1 which works great for me. Quake console

XRandR XRandR is an extension which allows to dynamically reconfigure outputs: you plug an external screen to your laptop and you issue some command to enable it:
$ xrandr --output VGA-1 --auto --left-of LVDS-1
awesome detects the change and will restart automatically. Laptops usually come with a special key to enable/disable an external screen. Nowadays, this key does nothing unless configured appropriately. Out of the box, it is mapped to XF86Display symbol. I have associated this key to a function that will cycle through possible configurations depending on the plugged screens. For example, if I plug an external screen to my laptop, I can cycle through the following configurations:
  • only the internal screen,
  • only the external screen,
  • internal screen on the left, external screen on the right,
  • external screen on the left, internal screen on the right,
  • no change.
The proposed configuration is displayed using naughty, the notification system integrated in awesome. Notification of screen reconfiguration

Widgets I was previously using Conky to display various system-related information, like free space, CPU usage and network usage. awesome comes with widgets that can fit the same use. I am relying on vicious, a contributed widget manager, to manage most of them. It allows one to attach a function whose task is to fetch values to be displayed. This is quite powerful. Here is an example with a volume widget:
local volwidget = widget(  type = "textbox"  )
vicious.register(volwidget, vicious.widgets.volume,
         '<span font="Terminus 8">$2 $1%</span>',
        2, "Master")
volwidget:buttons(awful.util.table.join(
             awful.button(   , 1, volume.mixer),
             awful.button(   , 3, volume.toggle),
             awful.button(   , 4, volume.increase),
             awful.button(   , 5, volume.decrease)))
You can also use a function to format the text as you wish. For example, you can display a value in red if it is too low. Have a look at my battery widget for an example. Various widgets

Miscellaneous While I was working on my awesome configuration, I also changed some other desktop-related bits.

Keyboard configuration I happen to setup all my keyboards to use the QWERTY layout. I use a compose key to input special characters like . I have also recently use Caps Lock as a Control key. All this is perfectly supported since ages by X11 I am also mapping the Pause key to XF86ScreenSaver key symbol which will in turn be bound to a function that will trigger xautolock to lock the screen. Thanks to a great article about extending the X keyboard map with xkb, I discovered that X was able to switch from one layout to another using groups2. I finally opted for this simple configuration:
$ setxkbmap us,fr '' compose:rwin ctrl:nocaps grp:rctrl_rshift_toggle
$ xmodmap -e 'keysym Pause = XF86ScreenSaver'
I switch from us to fr by pressing both left Control and left Shift keys.

Getting rid of most GNOME stuff Less than one year ago, to take a step forward to the future, I started to heavily rely on some GNOME components like GNOME Display Manager, GNOME Power Manager, the screen saver, gnome-session, gnome-settings-daemon and others. I had numerous problems when I tried to setup everything without pulling the whole GNOME stack. At each GNOME update, something was broken: the screensaver didn t start automatically anymore until a full session restart or some keybindings were randomly hijacked by gnome-settings-daemon. Therefore, I have decided to get rid of most of those components. I have replaced GNOME Power Manager with system-level tools like sleepd and the PM utilities. I replaced the GNOME screensaver with i3lock and xautolock. GDM has been replaced by SLiM which now features ConsoleKit support3. I use ~/.gtkrc-2.0 and ~/.config/gtk-3.0/settings.ini to configure GTK+. The future will wait.

Terminal color scheme I am using rxvt-unicode as my terminal with a black background (and some light transparency). The default color scheme is suboptimal on the readability front. Sharing terminal color schemes seems a popular activity. I finally opted for the derp color scheme which brings a major improvement over the default configuration. Comparison of terminal color schemes I have also switched to Xft for font rendering using DejaVu Sans Mono as my default font (instead of fixed) with the following configuration in ~/.Xresources:
Xft.antialias: true
Xft.hinting: true
Xft.hintstyle: hintlight
Xft.rgba: rgb
URxvt.font: xft:DejaVu Sans Mono-8
URxvt.letterSpace: -1
The result is less crisp but seems a bit more readable. I may switch back in the future. Comparison of terminal fonts

Next steps My reliance to the mouse has been greatly reduced. However, I still need it for casual browsing. I am looking at luakit a WebKit-based browser extensible with Lua for this purpose.

  1. The console gets its own unique name. This allows awesome to reliably detect when it is spawned, even on restart. It is how the Quake console works in the mod of FVWM I was using.
  2. However, the layout is global, not per-window. If you are interested by a per-window layout, take a look at kbdd.
  3. Nowadays, you cannot really survive without ConsoleKit. Many PolicyKit policies do not rely on groups any more to grant access to your devices.

Next.