Well, seems the latest version of gentoolkit removed the venerable "qpkg" in favour of.. eewrhg. equery.
equery is slow, appears bloated in its output, likes fancy colours just as much as qpkg did, and appears to be fond of polluting a simple "list" (oh sorry, "files" ) output with several lines of headers, even when its told to be quiet.
Did I mention that its slow?
so, here's a ++ for our old friend, app-portage/epm its fast and doesn't try to be overly smart.
where you with equery have to do :
equery -C -q l '.*gnome*.'
* installed packages
[I--] [ ] app-admin/gnome-system-tools-1.2.0 (0)
[I--] [ ] app-pda/gnome-pilot-conduits-2.0.12 (0)
[I--] [ ] app-pda/gnome-pilot-2.0.12 (0)
..
to get a non-coloured output, with epm it is :
epm -qa |grep gnome . Though bear in mind, this doesn't match category, only package name.
However.. its fast and appears consistent. I like that.
Hmm. Package building commencing, unfortunately cdrtools requires to be built with USE="unicode" so I'm having to install exceptions into etc/portage/package.use which I'm loathe to do.
However, now that my scripts have some infrastructure for it, I'm a bit closer to fixing up the "desktop only" and "server only" releases for future dates. or something ;)
We have blogs, lets replicate USENet and do it suckily!
response to spyderous post about on/off topicness, originally as a reply on LJ, now here.
*slaps p g o for being silly*
---
Blergh.
Personally, I disagree with the "keep things on topic" here, I -like- reading other devs personal/random musings, since I don't hang much on IRC anymore, and mail is just impersonal..
it supplies just the level of contact that I want from a Blog.
Effing buerau-crazy.
So, I'm in the process of trying to get a "flashy desktop" to show off. This doesn't need to be 100% survivable for day-to-day, but is more a proof of concept.
My basic ideas so far include :
gnome-extra/gdesklets-core, with the pager + RSS reader in the background.
x11-misc/3ddesktop To change virtual desktops.
Some music player with visualizations.
xscreensaver + glmatrix? I want a Gl screensaver that responds to the sound. Is it doable?
Gnome for the basic applications with some flashy theme, recommendations?
E, perhaps Just for the classical goodie feeling?
Fyre to generate a series of backgrounds.
Or perhaps x11-misc/electricsheep for the desktop background in animation mode and screensaver?
x11-misc/xcompmgr for the new flashiness?
Please, come with input...
Recommendations
Thanks to the rpm folks (who's perl-scanner I conveniently ripped off, bless the GPL :) I now have perl support in my depreverse scripts.
I've also added a convenience wrapper called finder.sh ; run as :
./finder.sh gtk2-perl
and it will call "etcat" to get a list of files inside gtk2-perl, resolve theese to depended on files, and resolve those back to packages. Wee hee.
Thinking about gtk2-perl..
dev-lang/perl
dev-libs/atk
dev-libs/expat
dev-libs/glib
dev-perl/glib-perl
dev-perl/gtk2-perl
media-libs/fontconfig
media-libs/freetype
sys-libs/glibc
sys-libs/zlib
x11-base/xorg-x11
x11-libs/gtk+
x11-libs/pango
./finder.sh gtk2-perl 84.20s user 4.36s system 83% cpu 1:46.53 total
okay, so I spent most of the afternoon/evening hacking on a tool to extract "real" reverse dependencies for files.
It takes a list of files as input, and returns a list of files the first list "need" to run.
Currently it covers libraries/binaries (elf, using ldd ) scripts #!/... ( file + head+grep magic ) and python "import" lines ( more magic)
it will miss conditional depends in python, it doesn't support perl yet ( I dont know how to extract the perl include path, or the mapping of module->filename in perl ) so thats necessary.
Basically, you can take this, feed it a package's installed files, resolve the output to packages, and compare the "real" dependencies to the "theoretical" ones. If "theoretical" missess something, its bad.
Appears though that ferringb made something similar to the ldd hack for the next generation portage (still in cvs ) that will work on libraries/binaries.
However, my code is here:
on the gentoo cvs
Just a note that the Chinstrap server appears back online and working.
and floods your disk.
http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00099.html
Actually, its the case of caches that never get reclaimed. Applications that do this include most graphics related things that follow the thumbnail spec, since they never clean out or remove the thumbnails, wether they live or not.
gqview has a tool to parse all theese thumbnails, find the ones that fit files that are no longer accessible and remove those. This saved over 100 Mb on my machine.
The second beast was evilution, however, here you can simply wipe old items from the cache :
find ~/.evolution/mail/imap/*/folders \( -name '[0-9]*.' -o -name '[0-9]*.HEADER' \) -atime +7 -print0
and pipe that to xargs -0 rm and you're off....
Now, implementing a function that checks diskspace avaiability in Gnome ough to be simple. The question is, where does it live? gnome-settings-daemon is the one that strikes me as "obvious" ... or nautilus, perhaps?
Implementing cache purge in Evolution comes next, doesn't sound too bad that either. A timeout ought to solve it ( one week/ ten days or just per-session? )
Purging "old" thumbnails? hmm, dunno. Making sure all applications that deal with graphics actually remove the thumbnail when they remove the file is an idea. Ought to be simple enough to hook into the obvious badguys ( gimp, gthumb, nautilus, gqview, eog ) . "stealing" gqview's purge function and adding it as a cleanup routine might work too, nice it hard enough and it might be unnoticed.
..is how long it took to rebuild the packages obviously affected by the libtool path issues.
I'm happy.
However, uploads are now in progress, hopefully I can start to work on the rest now soonish.
...oh, hi Planet
is the optimum time that a Chinstrap build can go on for 2005.0. That means that -no- packages need to be rebuilt, and everything is just unpacked and installed.
This is the case for 493 packages (currently). This number goes up when I have to update the snapshot (rsync + tarball + ....) or when there is any software updated ( download of source, unpack, compile , compress , install )
However, it isn't bad in that it doesn't require me to do much but check the status and review the changes files afterwards. And of course, fix breakages.
However, a machine with more RAM and better IO would be -very- welcome.
yey.
grep 3.3.5 /usr/bin/libtool outputs the hard paths to the old gcc.
Effing shite. And for the record, I didn't name the bug I hate libtool. But I was tempted to :)
Now, the art of forcing libtool recompiles. :-/
that I hate libtool? If not, its time to do that.
I hate libtool
There. Said. Again.
This time, it finds the gcc g++ include path -somewhere- for some reason unbeknowst to man, inside its own files. Where? Dunno. It just does that.
Problem: apmd's libapm fails to link due to missing .S files in the gcc directory
The fix: rebuild libtool.
Reason: libtool sucks
okay, Going to try and track this down. I HATE THIS PIECE OF SHIT.
Okay, In a happy happy stroke I just today saw that.. oh wonder, shiney hiney of wonders.. gcc was updated to a new snapshot.
This is fun, because it means I'll be rebuilding a -LOT- of Chinstrap packages during the day. Why?
Libtool.
We like libtool. Libtool stores complete paths to gcc-lib's in its .la files. Once a package is installed, its a simple simple quick "fix_libtool_files.sh" to just recurse over your files and change the path.
It isn't the case when you're doing binaries, since if the path is stored inside the binaries, and binaries usually get installed after gcc , well what do you have? Ah yes, a system that is broken because the script needs to be re-run each time.
Fortunately, its simple to find all .la files with paths in them once gcc is installed, and then simply remove those packages.
However, I'm not happy about libtool.
( Perhaps I should push for gcc being made version independent? )
forced rebuilds :
app-office/abiword
app-text/aspell
app-text/enchant
dev-cpp/gconfmm
dev-cpp/gtkmm
dev-cpp/libglademm
dev-cpp/libgnomecanvasmm
dev-cpp/libgnomemm
dev-cpp/libgnomeuimm
dev-libs/DirectFB
dev-libs/libsigc++
gnome-base/gnome-vfs
gnome-base/nautilus
kde-base/arts
kde-base/kdeaddons
kde-base/kdeadmin
kde-base/kdeartwork
kde-base/kdebase
kde-base/kdeedu
kde-base/kdegames
kde-base/kdegraphics
kde-base/kdelibs
kde-base/kdemultimedia
kde-base/kdenetwork
kde-base/kdepim
kde-base/kdetoys
kde-base/kdeutils
kde-base/kdewebdev
media-gfx/imagemagick
media-libs/faad2
media-libs/gdk-pixbuf
media-libs/gst-plugins
media-libs/id3lib
media-libs/imlib
media-libs/imlib2
media-libs/libsdl
media-libs/musicbrainz
media-libs/sdl-ttf
media-libs/taglib
media-libs/tiff
media-libs/tunepimp
media-video/avifile
media-video/mjpegtools
media-video/transcode
net-print/gnome-cups-manager
sys-apps/apmd
Okay, this might not be the best of sane things, but anyhow. I recently dug up an oooold copy of Kohan: Immortal Sovereigns as it was ported by Loki back in the ninties.
Unortunately, even though the game installs, it is unplayable on todays Gentoo systems. It hard locks and segfaults. Bleh.
So, I decided to get it to work anyhow. First, installing sys-libs/lib-compat-loki will provide you with an ancient copy of glibc, necessary to run the ancient game.
This, you symlink into the game directory, something like this:
ld-linux.so.2 -> /lib/loki_ld-linux.so.2
libc.so.6 -> /usr/lib/loki_libc.so.6
libnss_files.so.2 -> /usr/lib/loki_libnss_files.so.2
Then you run the game with something like the following shellscript:
#!/bin/bash
export LD_LIBRARY_PATH=$_DIRECTORY_WHERE_I_INSTALLED_MY_GAME
./kohan --nocdrom --nomovies
Admitted, not a pretty solution.
Okay. then there is the bloody updater. It -will- fail no matter what. Sheesh. however, this can be hacked around :
install : games-util/loki_patch
Which will give you a local, working, binary copy of the loki patch utility.
Then download the patches ( Remember, you need the cumulative patches, ie. All versions ) for the game in question:
ftp://sunsite.dk/mirrors/lokigames/updates/kohan/
( or any of the other mirrors. planetmirror has them too )
Download the .run files, the md5sums and check.
export _POSIX2_VERSION="199209"
chmod +x kohan-1.2.0-x86.run
./kohan-1.2.0-x86.run --target patch
After which you get a pretty error :
loki_patch: dynamic-link.h:57: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed.
"yey"
Now lets fix that :)
cd patch
cp /usr/bin/loki_patch bin/Linux/x86/loki_patch
./update.sh
--
Yey! it worked. Rinse and repeat.
My thoughts of the game? I like it, somewhat too simplistic controls over your men (takes too much clicking to make it "work" ) I miss the real 3D view of modern games (map rotation and tilt) And so on. For a game of the era, its nice.
There are still bugs, fex. whenever the game tries to change mode it gets an interlaced thing? Eew. fortunately ctrl+alt+return, ctrl+alt-+ until I have a 1024x768 resolution, then ctrl+alt+return again makes it sane.
Other issues is that it crashes / hangs from time to time. Especially if you cancel a mission, or progress from a mission with the status screen on. And that the videos crap up the resolution bigtime.
Questions?
okay, back. builds ongoing. Nothing much new, will see about the suggested packages from the post to gentoo-user.
That and a bugreport about unixODBC needing binaries.
okay, checked up on the Chinstrap builds, things seem ok. Scrapped openoffice-bin (why make binaries of binaries? They waste diskspace for us, thats about it, there's no efficiency in having them.)
Now, A weekends break, building will commence on sunday.