When release is not
Spent a weekend on a bug which looked like some interesting race, but in fact was just a simple logic error. Result is a trivial one line patch, I'm two days older and not an iota smarter.
BTW, our input subsystem is really convoluted. I'm not surprised bugs like this happen.
LOL X11
A minute ago I pulled a mouse out of my laptop and the X server crashed. The last messages in Xorg.0.log were:
(EE) Read error: No such device (19, -1 != 24)
(II) Microsoft Microsoft USB Wireless Mouse: Off
This happened because Xorg server 1.4.99.1 force-loads evdev contrary to my xorg.conf, and we all know that evdev is a crash city.
It's a good thing I was born and raised back when this sort of thing was expected every day, so X cannot catch me with a half-entered bug report in a browser. Also, it seems that Vim finally learned to remove dead .swp files without annoying users.
GNOME does something right
Today I plugged my iPod in, and Rawhide launched Rhythmbox, which chugged along for about half a minute, then crashed. At least it did not wipe the player's database. WTF, I thought I had all auto-run types set to off...
Looks like there were some changes. No more unchecking umpteenth type of crashware.
To compensate for a good thing, they worked extra hard to hide this panel. It's not reacheable from any parts of System menu. File Browser has to be started, and its Preferences adjusted.
UPDATE: The last part is untrue, I missed the right item. Thanks ucc_journal for the correction.
Syndicated 2008-02-12 21:24:21 (Updated 2008-02-13 04:40:52) from Pete Zaitcev
GNOME lies to me
Every time I log in, it promises not to show the message again, but then does.
I suppose I should clean some keys in gconf-editor, but which?
Also, tinkering with the registry is so Windows.
Centralized git at Xorg
One side effect of the multiply-repo organization of Xorg is that I cannot clone a local repository without editing git_xorg.sh. In kernel, I usually have just one repository which tracks Linus (linux-2.6), then clone and blow away repositories as needed (linux-2.6-ub, linux-2.6.24-rc7, linux-2.6.23-253424). In X, git_xorg.sh has a variable on top which encodes the parent, which is not so bad. But still... Obviously they just do it differently, but how? Keith was saying something about extensive use of branches, so maybe that's it.
Also, since we're on topic, git_xorg.sh itself is not in the git. Now that's really odd, because how do I know if it's changed? I don't even remember now whence I downloaded it.
P.S. Another thing, before blowing away a repo, I would look quickly with "git diff" if anything interesting was left in it. Needless to say, this is impossible in Xorg, so it's just more evidence that they never clone anything.
Syndicated 2008-02-03 19:14:15 (Updated 2008-02-04 20:25:57) from Pete Zaitcev
Have libsilc problem?
On one box, every run of yum update was complaining about something unavailable around libsilc... I wrote it down to mirror inconsistency and worked around with --exclude. Today I decided to look into it closer, and saw the following:
[root@simbelmyne zaitcev]# rpm -q pidgin fedora-release
pidgin-2.0.0-0.34.beta7devel.fc7.x86_64
fedora-release-8.90-3.noarch
[root@simbelmyne zaitcev]# yum update pidgin
Setting up Update Process
Could not find update match for pidgin
No Packages marked for Update
[root@simbelmyne zaitcev]#
An F7 package has no update when we're builing F9? [*]
[root@simbelmyne zaitcev]# rpm -q --queryformat "%{epoch}\\n" pidgin
2
[root@simbelmyne zaitcev]#
Suddenly the problem came into focus. The worst part of it, current pidgin is version 2.3.1, which is greater than 2.0.0. They could've kept epoch forever and nobody would've noticed... The changelog explains:
* Sat Apr 21 2007 Warren Togami <wtogami@redhat.com> 2.0.0-0.35.beta7devel
- upstream insists that we remove the Epoch
rawhide users might need to use --oldpackage once to upgrade
- remove mono and howl cruft
* Wed Jul 12 2006 Jesse Keating <jkeating@redhat.com> 2:2.0.0-0.6.beta3.1
- rebuild
Hmm... Not sure why "upstream" cares, but whatever.
Just for fun I ran rpm|grep|wc and found a ton of packages with non-empty Epoch. Epoch 0: 108 packages, Epoch 1: 79, other values: 52. The biggest number has aspell-en: Epoch 50! The changelog is:
* Wed Aug 11 2004 Adrian Havill <havill@redhat.com> 50:0.51-9
- sync epoch with other aspell dicts, upgrade to 0.51-1
Now that must be a pretty funny story, but I don't want to know.
[*] Actually we have a few packages from F7 which weren't rebuilt across the whole Fedora 8 cycle, for example grep.
Syndicated 2008-01-30 06:06:18 (Updated 2008-01-30 19:01:57) from Pete Zaitcev
Today, I hate... who?
Not sure who to hate today. At first I was going to hate Karsten, but I quickly realized that he's actually on the good side, fixing problems rather than causing them. But someone has to be responsible for the abomination known as libtool, right?
It all started when I wanted to run Hercules. I extracted my old images and hercules.cnf, ran "yum install hercules", and then... Hercules starts, but recognizes no devices, starting with the 3505.
The problem is in the so-called "dynamic load": emulators for devices are shared objects, and our stock Hercules on Fedora searches for them everywhere except where necessary:
write(4, "HHCCF065I Hercules: tid=2AD76E5C"..., 72) = 72
open("/hercules/hdt3505.la", O_RDONLY) = -1 ENOENT
open("/hercules/hdt3505", O_RDONLY) = -1 ENOENT
open("/lib/hdt3505.la", O_RDONLY) = -1 ENOENT
open("/usr/lib/hdt3505.la", O_RDONLY) = -1 ENOENT
open("hdt3505.la", O_RDONLY) = -1 ENOENT
access("/lib/hdt3505", R_OK) = -1 ENOENT
access("/usr/lib/hdt3505", R_OK) = -1 ENOENT
open("/etc/ld.so.cache", O_RDONLY) = 10
fstat(10, {st_mode=S_IFREG|0644, st_size=84779, ...}) = 0
mmap(NULL, 84779, PROT_READ, MAP_PRIVATE, 10, 0) = 0x2aaaaf55b000
close(10) = 0
open("/lib64/tls/hdt3505", O_RDONLY) = -1 ENOENT
open("/lib64/hdt3505", O_RDONLY) = -1 ENOENT
open("/usr/lib64/tls/hdt3505", O_RDONLY) = -1 ENOENT
open("/usr/lib64/hdt3505", O_RDONLY) = -1 ENOENT
munmap(0x2aaaaf55b000, 84779) = 0
write(4, "HHCCF042E Device type 3505 not r"..., 42) = 42
The real path is /usr/lib64/hercules/hdt3505.so. Did nobody ever test?!
So I download the source, configure with --disable-dynamic-load, build, everything works. After all, the whole /usr/lib64/hercules is only 240KB, who needs dynamic modules anyway? Then, I want to be good and try to build an RPM... It bombs with "ld: undefined hdl_genhdl".
It gets even more involved. Apparently, when I run configure by hand, libtool fails, falls back to linking from .a, and then everything works. But when I build an RPM, libtool succeeds, produces .so, then linking fails because...
So, spent a day trying to understand how libtool worked and why removal of rpath causes it to produce garbage, etc. until it was time to sleep. Today, filed a bug, moved on. Let Matthias to puzzle it out.
UPDATE 20080103: Hans de Goede fixed it.
Syndicated 2008-01-29 21:42:38 (Updated 2008-02-03 19:57:30) from Pete Zaitcev
Liberal pie in the sky
Spot outlined a laundry list of things that our next saviour will do, which includes this:
* Obama will deploy a modern communications infrastructure.
Some people know how to dream big. One royal decree, and millions of workers in blue suits descend upon America; overnight a modern communications infrastructure (whatever that means) gets deployed, never to become obsolete thereafter.
UPDATE: As pointed in comments, the infrastructure item is a bracket, explained by other items on Spot's list [link]. The astroturfing machine mangled the message in transmission and produced the funny above.
Syndicated 2008-01-29 19:59:10 (Updated 2008-01-30 01:14:09) from Pete Zaitcev
Thank heavens, I'm not Japanese...
... because if I were, I'd have trouble with web services. Even now, in 2008, a disturbing number of them are unable to handle the basics of UTF-8.
For example, I have a tag "らき☆すた" at del.icio.us. Everything is fine... except the link "all", which comes up empty, although I know that the tag is used.
If you think that del.icio.us is only a pitiful Internet sitelet which is hardly representative, the mighty Google Reader says this in response to an innocous tag: ""愛より青し" is not a valid tag name. Only letters, numbers, underscores and dashes may be used." Yes, those " appear in the AJAX dialog in all their glory.
Kindle is only doing what everyone else is doing, it seems.
BTW, my position always was that everyone who touches a computer has to learn English. It's not that difficult and is required to communicate on the Internet. But being a hypocrite that I am, I demand solid support for UTF-8 from applications, and feel no cognitive dissonanse about it whatsoever.
Besieged by daemons
When I end my GNOME session in Rawhide, the following processes are left behind:
USER PID VSZ RSS STAT COMMAND
zaitcev 2122 19148 1036 Ss /bin/dbus-daemon --fork ...
zaitcev 2152 171596 2900 S< /usr/bin/pulseaudio --log-ta...
zaitcev 2187 168208 3860 S /usr/libexec/gnome-vfs-daemon
zaitcev 2195 34864 1984 S /usr/libexec/gvfsd
zaitcev 2206 43176 2172 S /usr/libexec/gvfsd-trash --s...
zaitcev 6538 109260 4776 S /usr/libexec/gconfd-2 13
Notice though, Gamin is not among them.
UPDATE: Colin says, quit blog whining and file a bug.
Syndicated 2008-01-27 07:00:34 (Updated 2008-01-27 20:28:29) from Pete Zaitcev
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!