Installing cinnamon on LMDE

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.

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

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

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

Patching and rebuilding debian packages

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:

1. you tell quilt that you start working on a given patch
2. you work on that patch
3. 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

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.