Posts
| « | November 2024 | » | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
| « | November 2024 | » | ||||
|---|---|---|---|---|---|---|
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
As I talked about earlier, I have a patch for showing inplace tooltips on a gtk+ treeview. Furthermore as it's nearing time to update it, I wanted to record the steps necessary to do so and to apply it.
Most of what I know about quilt I learned from this quilt howto hosted on alioth. So I'm by no means an expert; rather I know just enough to be dangerous. So here are the steps a Debian user can use to update and refresh my inplace tooltips patch.
First: set up quilt. Here's my modified /etc/quilt/quiltrc but feel free to put the equivalent in your own ~/.quiltrc instead. The first line is critical; the others just simplify the patches.
QUILT_PATCHES=debian/patches QUILT_DIFF_ARGS="--no-timestamps --no-index" QUILT_REFRESH_ARGS="--no-timestamps --no-index"
Second: get the build dependencies and source.
% sudo apt-get build-dep libgtk2.0-0 Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. % apt-get source libgtk2.0-0 Reading package lists... Done Building dependency tree Reading state information... Done Need to get 23.6MB of source archives. Get:1 http://http.us.debian.org unstable/main gtk+2.0 2.12.7-1 (dsc) [1565B] Get:2 http://http.us.debian.org unstable/main gtk+2.0 2.12.7-1 (tar) [23.5MB] Get:3 http://http.us.debian.org unstable/main gtk+2.0 2.12.7-1 (diff) [89.4kB] Fetched 23.6MB in 54s (430kB/s) dpkg-source: extracting gtk+2.0 in gtk+2.0-2.12.7 dpkg-source: unpacking gtk+2.0_2.12.7.orig.tar.gz dpkg-source: applying ./gtk+2.0_2.12.7-1.diff.gz
Third: apply the patch.
% cd gtk+2.0-2.12.7 % quilt import ../gtk+2.0-2.12.5/debian/patches/mu-inplace-tips.patch Importing patch ../gtk+2.0-2.12.5/debian/patches/mu-inplace-tips.patch (stored as mu-inplace-tips.patch)
Fourth: update debian/changelog. You'll want to fix the conflict, revert the changes, or update the number.
% quilt push mu-inplace-tips.patch % quilt edit debian/changelog [...] % quilt refresh Refreshed patch mu-inplace-tips.patch
Fifth: build the packages. This takes a while.
% dpkg-buildpackage -us -uc [...]
If anything breaks you'll probably have to run quilt pop mu-inplace-tips.patch, edit the patch to resolve the build failure, run quilt refresh, and try the build again.
Sixth: install the package, and optionally put it on hold. Note that you need only the libgtk2.0-0 package if you haven't bumped up the version in the changelog; you don't really need the others if you have, but they have tightly coupled version dependencies that complain if you don't use them.
% cd .. % sudo dpkg -i libgtk2.0-0_2.12.7-1+0mu_i386.deb libgtk2.0-dev_2.12.7-1+0mu_i386.deb gtk2-engines-pixbuf_2.12.7-1+0mu_i386.deb [...] % echo libgtk2.0-0_2.12.7-1+0mu_i386.deb hold | sudo dpkg --set-selections % echo libgtk2.0-dev_2.12.7-1+0mu_i386.deb hold | sudo dpkg --set-selections % echo gtk2-engines-pixbuf_2.12.7-1+0mu_i386.deb hold | sudo dpkg --set-selections
Finally restart any gtk+ programs you want to use your freshly updated gtk+ library.
) (0 Trackbacks)
debian
freesoftware
gtk+
quilt
A long time ago I started work to port my rudimentary treeview hack from its TreeViewHints python implementation in Quod Libet to a much more solid inplace-tooltips implementation in gtk+ itself. Inplace-tooltips are the little tips that appear as you move your cursor over items that aren't fully visible, and often appear immediately instead of after a hover delay.
For whatever reasons the patch has neither been nurtured and accepted nor denied, and has languished for most of the 19 months since I first filed the feature request. I personally suspect things varying from confusion over the term tooltips
being in the name to malevolent negligence, but claiming either of those doesn't help the situation anyway.
Eight months ago I found a much better approach to it, which wrangled out some superficial bugs for free, and updated the patch. Finally over the past two weeks, I found that Debian's gtk+ package had changed its build procedure, and this time was able to figure out how to integrate my patch. Wow, what a difference it makes to use it full time. In under two weeks I'd found and filled some important gaps in my initial implementations, including fixing the tip's position when a tree is scrolled horizontally.
But building my own Debian packages comes at a price. Not only does it take significant time to build the packages, there are three options each with disadvantages.
By applying just the code patch I get all the behavior changes I want...so long as I don't run a package update. If I run a package update, the original libgtk2.0-0 package takes precedence over my package, and offers to reinstall.
When Ubuntu makes packages, they apply a suffix to ensure that Debian's packages of the same version do not override theirs, but a newer Debian package can (so long as all dependencies are satisfied). This prevents the official package from overwriting my patched packages. However doing this causes the policy of my package to move past the testing archive and into the limbo which pulls in packages from unstable. It also requires I install some auxiliary packages due to tight version dependencies in the core gtk+ related packages.
An epoch is a special version indication that would let me continue to call my package by the same version the rest of gtk+ does, but tell the package management system it's newer than the official package. Assuming Debian never needs to bump their epoch, this would insulate me from the testing–>unstable bump, as my packages would always be even newer than the ones in unstable. However because of that it would be much harder to track when it was time to upgrade my own packages.
Currently I gave up on the first, and am still trying the second. I've run into one major hitch: aptitude doesn't work how I want it to. In particular I'm running with my suffixed package version 2.12.5-2+0mu, and unstable now has 2.12.7-1:
% apt-cache policy libgtk2.0-0
libgtk2.0-0:
Installed: 2.12.5-2+0mu
Candidate: 2.12.7-1
Version table:
2.12.7-1 0
601 http://http.us.debian.org unstable/main Packages
*** 2.12.5-2+0mu 0
100 /var/lib/dpkg/status
2.12.5-2 0
900 http://http.us.debian.org testing/main PackagesBecause I'm beyond testing (which I have as my default), apt and aptitude want to attempt to keep me at unstable (my fallback) because it appears that's where I was before the update. I'm not ready to make this leap; I want to make it when 2.12.7 reaches testing. So I employ the next trick in the book: hold.
Hold is supposed to tell aptitude to ignore this package during normal upgrades until I explicitly tell it to install a newer version. But it just doesn't work. If you visit aptitude's bug page and search for hold
it becomes obvious that there have been lots of problems with hold, and most of them are still unresolved. Most of them have to do with synchronizing aptitude's list of holds with dselect (and apt's) list. But if that were all, I could work around it. Instead aptitude doesn't even follow its own holds:
% dpkg --get-selections | egrep 'gtk2-engines-pixbuf|libgtk2.0-0|libgtk2.0-dev' gtk2-engines-pixbuf hold libgtk2.0-0 hold libgtk2.0-dev hold % sudo aptitude unhold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev [...] % sudo aptitude hold gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev [...] % sudo aptitude safe-upgrade [...] The following packages will be upgraded: gtk2-engines-pixbuf libgtk2.0-0 libgtk2.0-dev 3 packages upgraded, 0 newly installed, 0 to remove and 2 not upgraded. Need to get 6061kB of archives. After unpacking 12.3kB will be used. Do you want to continue? [Y/n/?] n Abort.
Now that I've seen this sloppy behavior among others, and seen just how many long standing bugs there are against aptitude, I think it's time to go back to dselect, apt-get, and deborphan. Too bad; aptitude seemed like a good idea at the time.
My favorite Japanese input method for gtk+, im-ja, broke when I updated to Debian's gtk+ 2.10 packages. Since there's no upstream activity to speak of (much less new packages), and I can't seem to find this on the web anywhere else, here's the solution I eventually found. No doubt there's a better one out there that updates the package to use the new debhelper support for gtkimmodules to create this file, but I made mine by hand:
% cat /usr/lib/gtk-2.0/2.10.0/immodule-files.d/imja.immodules # edited by hand "/usr/lib/gtk-2.0/2.4.0/immodules/im-ja.so" "im-ja" "Japanese" "gtk+" "/usr/share/locale" "ja"
I had tried compiling a new version of the existing package that would go into the 2.10.0 immodules folder, but that didn't help. When I wired that version up with the slight mode to the above file, it crashed applications that tried to use it. But the original im-ja package is still kicking!