miket's notes

Installing cinnamon on LMDE

2011-12-25T13:45:00.000-08:00

Installs but does not run.... working on it... please comment if you've had better luck.

Follow instructions to upgrade to gnome-shell 3.2 here:

http://forums.linuxmint.com/viewtopic.php?f=197&t=89327

Dependencies, even on the debian package, have the wrong package name, though some of these can be upgraded -- look for equivalent packages in your debian repos (in sid and experimental as well).

once you've upgraded everything you can, and have downloaded cinnamon run something like this:

sudo dpkg --ignore-depends=libecal1.2-10,libedataserver1.2-15,libgjs0c,libmozjs185-1.0,libpulse-mainloop-glib0,libpulse0 -i Downloads/cinnamon_1.1.2_amd64.deb

Hades simulation framework.

2011-12-14T22:42:00.000-08:00

Taking a computer architecture class, I'm immersed regularly in something known as hades simulation framework. Whether or not the name was intentional matters not. This is like being in hell. An interesting hell, but not a user friendly one. If you don't know what it is, feel blessed. If you do, you know there's very little info about troubleshooting on the internet. Some quick and dirty notes:

If subdesigns don't show up properly, you can make your own .sym file and specify port locations, names, etc. An example is below:

hades.symbols.BboxRectangle 0 0 4000 2600
hades.symbols.Rectangle 0 0 4000 2600
hades.symbols.InstanceLabel 150 450 1bit4to1MUX
hades.symbols.PortLabel 150 350 I0
hades.symbols.PortSymbol 0 200 I0
hades.symbols.PortLabel 150 950 I1
hades.symbols.PortSymbol 0 800 I1
hades.symbols.PortLabel 150 1550 I2
hades.symbols.PortLabel 150 2150 I3
hades.symbols.PortSymbol 0 2000 I3
hades.symbols.PortSymbol 0 1400 I2
hades.symbols.PortLabel 2800 350 S0
hades.symbols.PortSymbol 4000 200 S0
hades.symbols.PortLabel 2800 950 S1
hades.symbols.PortSymbol 4000 800 S1
hades.symbols.PortLabel 2800 1550 Output
hades.symbols.PortSymbol 4000 1400 Output

There are a number of reasons subdesigns will appear to be non functional or not respond in a larger design... I'll try to add to these as I find more:

1. Output named "Y" -- I've had success with this, but it seems to be unpredictable. Avoid it.
2. Edits to subdesigns will sometimes disconnect ports in larger designs. An easy way to test if this has happened is to move the subdesign in the larger design... wires should stay connected, if they don't, well, there you go... delete segments nearest your connections and then add segments to the original wire and reconnect.
3. In your subdesigns, set all your Ipins to default to 0. Defaulting to undefined can cause problems in larger designs.
4. you can't depend on Ipin vectors to take default values. Plan ahead on how to get data in.

I'm sure that there are more tips, but the semester is over and hades is slowly seeping out of mind. However, if you've stumbled across this and are knee deep in hades issues, go ahead and send an email, maybe i can help.

Installing awn on LMDE XFCE without adding crazy gnome dependencies

2011-08-29T10:04:00.000-07:00

sudo apt-get install libdesktop-agnostic0 libdesktop-agnostic-vfs-gio libdesktop-agnostic-fdo-glib libdesktop-agnostic-cfg-gconf gconf2 libnotify4

now, download this package:
http://packages.debian.org/wheezy/libawn1

and
sudo dpkg -i libawn1_0.4.1~bzr830-1_amd64.deb

(modify for your arch, of course)

now download this package:
http://packages.debian.org/wheezy/all/avant-window-navigator-data/download

and sudo dpkg -i for the downloaded file.

Now, you should be able to download the actual avant-window-manager package from here:
http://packages.debian.org/wheezy/avant-window-navigator

and run dpkg like so:
sudo dpkg --ignore-missing gnome-applets --ignore-missing gnome-applets-data --ignore-missing gnome-control-center --ignore-missing gnome-panel --ignore-missing gnome-panel-data --ignore-missing gnome-session --ignore-missing nautilus --ignore-missing nautilus-data -i avant-window-navigator_0.4.1~bzr830-1_amd64.deb

Again, modified for your arch.

Now you have awn installed, but you're still not going to have very many applets... if you search through the repos, you will be able to install some of the applets without gnome dependencies, but many of them *depend* on gnome-applets. Not to worry, we can install that without proper gnome as well.

First we need gnome-applets-data, which does not require any extra gnome nastiness.
sudo apt-get install gnome-applets-data

Then download this package:
http://packages.debian.org/squeeze/gnome-applets

now run:
sudo dpkg --ignore-depends gnome-control-center --ignore-depends gnome-panel --ignore-depends gnome-panel-data --ignore-depends gnome-session --ignore-depends nautilus --ignore-depends nautilus-data -i gnome-applets_2.30.0-3_amd64.deb

As usual, modifying for your archicture. I found that installing the additional awn applet packages was slightly problematic and kept breaking things because gnome-applets keeps wanting to pull in gnome-panel. If you see this breakage, run:

sudo aptitude -f install

Allow it to uninstall gnome-applets and then re-run the install cmd above. Ultimately I had to download and install awn-applets-c-core with dpkg.

Now, not *everything* works. A few of the applets crash, but the vast majority of things work just as they do in gnome, but without pulling in and running gnome-session and nautilus which really screw with the xfce user experience. I will update this as I continue to debug some og the problems, but I'm happy to have a decent dock under xfce!

dpkg notes

2011-08-19T16:22:00.000-07:00

Search for what package a file came from: dpkg -S
Show installed version of a package: dpkg-query -l

Patching and rebuilding debian packages

2011-08-19T14:11:00.000-07:00

So i've been doing some bug fixes for packages in the linux mint debian edition and its been alot of fun. However, since they have kind of a small team and it takes awhile for patches to hit the distro, i thought it might be fun and helpful to roll my own .deb packages for people to "try at your own risk" until official packages are released.

So, for my own point of reference and as a quick reference to anyone who cares, here's a simple tutorial. You'll need normal debian buildtools and something called quilt that helps manage patches. Lets assume you've fixed your bug and made a diff against the original file and all that good stuff. I keep directories like so to keep track of what i'm working on, so you'll see them referenced:

~/bin (for binaries or ready-to-use scripts)
~/src (for debian source packages and in progress scripts)
~/diffs (for patches)

normally to get a debian source package, you would run something like:

voytek@voytek ~/src $ apt-get source package-name

in whatever directory you want to have the new source directory created. I'm working on the mintBackup tool which they don't have a debian source package for in the repos, so I'm pulling it directly from git:

voytek@voytek ~/src $ git clone git://github.com/linuxmint/mintbackup.git

Simple procedures for working with quilt come from this tutorial, however before you start using quilt for debian packages, you'll want to make sure you have a ~/.quiltrc file that at least has this line:

QUILT_PATCHES=debian/patches

This makes sure you're putting the patches where debian expects them. The tutorial tells us:

"quilt works in the source tree. There's no copying large trees around. There's also no need to always keep the source tree clean of unapplied changes just to be able to extract a diff with SVN.

To achieve this, however, quilt needs to know which files are contained in each patch. The workflow is as follows:

you tell quilt that you start working on a given patch
you work on that patch
you tell quilt that you're done"

So I move into the mintbackup src directory and I run:

voytek@voytek ~/src/mintbackup $ quilt new python-apt-api-changes.patch

You can name the patch anything you want, but I'm choosing to name mine descriptively. Next you would want to edit and/or patch the file, but first you have to tell quilt what file you're editing. To do this, you just run:

voytek@voytek ~/src/mintbackup $ quilt edit usr/lib/linuxmint/mintBackup/mintBackup.py

Now, this will open the file you've specified in whatever you have set as your $EDITOR. You could make your changes here, but I like to be organized and I tend to make mistakes when I don't have a way to test things nicely, so I'm going to use the patch I already made. So, I close my editor and quilt responds with:

File usr/lib/linuxmint/mintBackup/mintBackup.py added to patch python-apt-api-changes.patch

Good times!

The patch I'm using was originally created from my copy of the modified script in ~/bin applied to the unmodified version on my system, like so:

voytek@voytek ~ $ diff /usr/lib/linuxmint/mintBackup/mintBackup.py bin/mintBackup.py > diffs/mintBackup.py.diff

And to apply it, I will simply run:

voytek@voytek ~/src/mintbackup $ patch usr/lib/linuxmint/mintBackup/mintBackup.py ~/diffs/mintBackup.py.diff

Now we have to tell quilt that we're finished, which will output the following (cmd included):

voytek@voytek ~/src/mintbackup $ quilt refresh python-apt-api-changes.patch
Refreshed patch python-apt-api-changes.patch

Great, so our modified source is ready to be built into a package! This can be done from the root of the source tree by running:

voytek@voytek ~/src/mintbackup $ debuild -us -uc

Assuming we did everything correctly, this should create .deb packages for our modified sources in the parent directory. Thankfully, since the package I'm working on today doesn't have any compiled binaries, I also get a mintbackup_2.0.8_all.deb package which can install on any architecture.

mintbackup

2011-08-19T14:09:00.000-07:00

voytek@voytek ~/src $ git clone git://github.com/linuxmint/mintbackup.git
Cloning into mintbackup...
remote: Counting objects: 1343, done.
remote: Compressing objects: 100% (461/461), done.
remote: Total 1343 (delta 571), reused 1322 (delta 551)
Receiving objects: 100% (1343/1343), 335.08 KiB | 202 KiB/s, done.
Resolving deltas: 100% (571/571), done.

Freedesktop (Gnome, KDE, etc) menu specs and layouts

2009-01-06T08:31:00.000-08:00

Ok, so, more explanations later, but when I used to work at Google, I found keeping some notes on a blog really helpful for me when I was working on a project... so one of my current projects is to build a simple point and click launcher for ubuntu applications similar to the old "Launcher" application on Classic Mac OS, but with the ability to show a description for each program, and the ability to display multiple languages simultaneously.

I want to use python / pygtk to accomplish this and want it to require as little maintenance for new programs as possible. Looking at existing menus in Ubuntu (and any distrobution that follows the freedesktop.org specs), all the information we need is already in the existing menu system, but its not straightforward as to where to access the underlying info. After some digging, I found it, so I'm laying it down here for anyone else who wants to solve a similar problem.

I'll take a minute to explain *why* I want to build an app like this because inevitably if anyone is reading this, someone is thinking, "what's wrong with just using the menu system?" I volunteer at a community center on the southside of chicago, and a large part of the demographic we serve are adults who've never touched a computer before, many of whom speak only spanish, and some who have literacy problems. We also have a large youth population who are largely bilingual and a smaller core of volunteers and staff who are either bilingual, english or spanish speakers. To those of us who've been using computers for a long time, a menu system seems very natural, but in our computer classes we often have to teach people how to use a mouse, what a folder is, etc. So, if someone wants to use a computer but cannot attend one of our classes, its very intimidating for them. Having a simple launcher that can display application names with descriptions in multiple languages (in our case, english and spanish, but keeping it fairly easy to allow for any language that the system supports) is the goal, and all the information is here already.

So, the freedesktop.org manu spec is located here: http://standards.freedesktop.org/menu-spec/latest/ this has most of the info we need but is a little verbose. Here's the quick and dirty:

Top level menu definitions are defined here:


$XDG_CONFIG_DIRS

/menus/${XDG_MENU_PREFIX}applications.menu

Where $XDG_CONFIG_DIRS and ${XDG_MENU_PREFIX} are environment variables. On ubuntu, the xdg config dir is /etc/xdg/

So if i look in /etc/xdg/menus on my ubuntu machine, I see:
applications.menu gnome-screensavers.menu settings.menu
applications-merged kde-applications.menu
gnomecc.menu preferences.menu

All we're worried about for now is applications.menu. For the unified menu system on ubuntu, most window managers use this as their main top level menu. This file defines the categories displayed, etc. It's an XML file and if you look at it, its fairly straight forward. We're not going to use it much at the moment, but we'll want to remember it later when we get to traversing the menus with python.

Individual applications are defined in $XDG_DATA_DIRS/applications. On ubuntu, $XDG_DATA_DIRS defaults to:
/usr/local/share/:/usr/share/:/usr/share/gdm/

The majority of our apps in the main applications menu appear to be in /usr/share/applications... you'll see files for each app that's something like firefox.desktop... lets look at that for an example:

[Desktop Entry]
Version=1.0
Name=Firefox Web Browser
Name[ca]=Navegador web Firefox
Name[cs]=Firefox Webový prohlížeč
Name[es]=Navegador web Firefox
Name[fa]=ﻡﺭﻭﺭگﺭ ﺍیﻦﺗﺮﻨﺗی Firefox
Name[fi]=Firefox-selain
Name[fr]=Navigateur Web Firefox
Name[hu]=Firefox webböngésző
Name[it]=Firefox Browser Web
Name[ja]=Firefox ウェブ・ブラウザ
Name[ko]=Firefox 웹 브라우저
Name[nb]=Firefox Nettleser
Name[nl]=Firefox webbrowser
Name[nn]=Firefox Nettlesar
Name[no]=Firefox Nettleser
Name[pl]=Przeglądarka WWW Firefox
Name[pt]=Firefox Navegador Web
Name[pt_BR]=Navegador Web Firefox
Name[sk]=Internetový prehliadač Firefox
Name[sv]=Webbläsaren Firefox
Comment=Browse the World Wide Web
Comment[ca]=Navegueu per el web
Comment[cs]=Prohlížení stránek World Wide Webu
Comment[de]=Im Internet surfen
Comment[es]=Navegue por la web
Comment[fa]=ﺺﻔﺣﺎﺗ ﺶﺑکﻩ ﺞﻫﺎﻧی ﺍیﻦﺗﺮﻨﺗ ﺭﺍ ﻡﺭﻭﺭ ﻦﻣﺍییﺩ
Comment[fi]=Selaa Internetin WWW-sivuja
Comment[fr]=Navigue sur Internet
Comment[hu]=A világháló böngészése
Comment[it]=Esplora il web
Comment[ja]=ウェブを閲覧します
Comment[ko]=웹을 돌아 다닙니다
Comment[nb]=Surf på nettet
Comment[nl]=Verken het internet
Comment[nn]=Surf på nettet
Comment[no]=Surf på nettet
Comment[pl]=Przeglądanie stron WWW
Comment[pt]=Navegue na Internet
Comment[pt_BR]=Navegue na Internet
Comment[sk]=Prehliadanie internetu
Comment[sv]=Surfa på webben
GenericName=Web Browser
GenericName[ca]=Navegador web
GenericName[cs]=Webový prohlížeč
GenericName[es]=Navegador web
GenericName[fa]=ﻡﺭﻭﺭگﺭ ﺍیﻦﺗﺮﻨﺗی
Comment[fi]=Selaa Internetin WWW-sivuja
Comment[fr]=Navigue sur Internet
Comment[hu]=A világháló böngészése
Comment[it]=Esplora il web
Comment[ja]=ウェブを閲覧します
Comment[ko]=웹을 돌아 다닙니다
Comment[nb]=Surf på nettet
Comment[nl]=Verken het internet
Comment[nn]=Surf på nettet
Comment[no]=Surf på nettet
Comment[pl]=Przeglądanie stron WWW
Comment[pt]=Navegue na Internet
Comment[pt_BR]=Navegue na Internet
Comment[sk]=Prehliadanie internetu
Comment[sv]=Surfa på webben
GenericName=Web Browser
GenericName[ca]=Navegador web
GenericName[cs]=Webový prohlížeč
GenericName[es]=Navegador web
GenericName[fa]=ﻡﺭﻭﺭگﺭ ﺍیﻦﺗﺮﻨﺗی
GenericName[fi]=WWW-selain
GenericName[fr]=Navigateur Web
GenericName[hu]=Webböngésző
GenericName[it]=Browser Web
GenericName[ja]=ウェブ・ブラウザ
GenericName[ko]=웹 브라우저
GenericName[nb]=Nettleser
GenericName[nl]=Webbrowser
GenericName[nn]=Nettlesar
GenericName[no]=Nettleser
GenericName[pl]=Przeglądarka WWW
GenericName[pt]=Navegador Web
GenericName[pt_BR]=Navegador Web
GenericName[sk]=Internetový prehliadač
GenericName[sv]=Webbläsare
Exec=firefox %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=firefox-3.0
Categories=Application;Network;
MimeType=text/html;text/xml;application/xhtml+xml;application/xml;application/vnd.mozilla.xul+xml;application/rss+xml;application/rdf+xml;image/gif;image/jpeg;image/png;
StartupWMClass=Firefox
StartupNotify=true

Alright, so here we have everything we need for our app... we have the application name and a generic name in multiple languages, the info about the icon and the executeable, and a description or "Comment" in multiple languages that should be descriptive enough for most users. We also have the "Categories" section that shows us what submenu its part of (because we likely don't want to show all applications in our launcher, but may want to limit by submenu, or possibly have tabs for different categories).

Next up: we'll talk about how to traverse this info in python using python-gmenu and figure out how to use multiple languages simultaneously.