sometime recently bbapm has started failing to run, instead giving a segmentation fault. i re-emerged it just in case and got the same result. notable upgrades that i can think of recently include switching from a 2.4.18-xfs kernel to 2.4.20-xfs-r3 as well as xfree being updated from 4.2 to 4.3 but it could easily have been something else as i don't know exactly when it started failing. this is a minor bug; there are zillions of X11 apm monitors. i will attach an strace of bbapm. next time i reboot this system i'll try the old kernel and see if that makes a difference.
Created attachment 11318 [details] strace output for "bbapm" when it fails
I tried it with my old kernel and the same thing happens. it appears to be something else.
(gdb) run Starting program: /usr/bin/bbapm (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x4bf9c0a0 in free () from /lib/libc.so.6 (gdb) bt #0 0x4bf9c0a0 in free () from /lib/libc.so.6 #1 0x4bef06a4 in __builtin_vec_delete () from /usr/lib/libstdc++-libc6.2-2.so.3 #2 0x0804f760 in XInstallColormap () #3 0x0804f2b7 in XInstallColormap () #4 0x0804eec7 in XInstallColormap () #5 0x0804adc6 in XInstallColormap () #6 0x4bf43571 in __libc_start_main () from /lib/libc.so.6
i've just made a quick change to the -r3 ebuild that makes it more friendly with gcc3.x systems. can you try emerging it again and see what happens?
scratch that. i just got around to trying -r3 on my lappy and i'm in segfault land too. my strace shows i'm getting a little further then you. looks like yours stops right after trying to read your ~/.blackboxrc file. mine gets past that, reads my current style file, and then segs with about as much explaination as yours does. i don't have gdm on this machine atm, but i suspect that it's output would be about as helpful as your as well. i notice the end of your ends on mentions of libc.so.6, which is part of glibc, which could be a larger problem. *shrug*
Oh the Problem is not solved yet :( ...if I start bbapm, it segfaults immediately. [root@lato]# bbapm & Segmentation fault strace shows it crashes, when /usr/share/bbtools/bbapm.conf is accessed: Look here: http://www.osnanet.de/craig/gentoo/log.txt So I think it somehow might depend on the configuration file...
http://marc.theaimsgroup.com/?l=gentoo-dev&m=109233643723408&w=2
This thing has not seen a new release for 6 years and is broken, remove it from portage.
Did you fail to notice the lynching I got when I tried that?
(In reply to comment #9) > Did you fail to notice the lynching I got when I tried that? Indeed I did fail, some link except for the above? Why do we need six years unmaintained, dead and segfaulting crap in portage?
Okay, your job is to mail -dev and say "we're having a tidy-up of bb* apps. The following will be purged unless someone steps up and fixes them:".
(In reply to comment #11) > Okay, your job is to mail -dev and say "we're having a tidy-up of bb* apps. The > following will be purged unless someone steps up and fixes them:". That's a good idea, but not the right person to do the job: $ herdstat --metadata bbapm Package: x11-misc/bbapm Herds(1): commonbox $ herdstat commonbox Herd: commonbox Email: commonbox@gentoo.org Description: Blackbox and derivative works Developers(4): ciaranm ka0ttic pyrania superlag
The only reason there's a commonbox herd is that no-one has split it up yet... It doesn't make sense now that there's no shared code or data between Fluxbox, Blackbox and Openbox.
This debate starts to go around. Either commonbox maintains this and then I can't see any reason why maintainer cannot punt a broken package from portage; or commonbox does not maintain it and then it's pretty easy to change metadata.xml to maintainer-needed so that someone else can remove the broken thing from portage. TIA.
Two weeks from last rites email on -dev ml gone, please p.mask/remove.
@x86 - this crap is marked stable on your arch, yet it doesn't work at all. Please, remove the keyword since maintainer refuses to package.mask and remove this stuff.
Please don't CC archs to remove a keyword. This should be gone about properly and be p.masked.
(In reply to comment #17) > Please don't CC archs to remove a keyword. This should be gone about properly > and be p.masked. OK, so arches don't care about keywords beyond the point when keywords are being added/things being marked stable? Hmmm, strange. Well, CCing QA then, maybe they could care about obviously broken stuff.
Jakub, quit wasting everyone's time. If you're not going to handle the issue properly, don't handle it at all.
Pmasked, Removal scheduled for 30 days from today.
Do this properly or not at all. bbapm is not the most h0rked of the blackbox applets by a long shot. If you're going to do a cleanup, do a proper one.
And it was punted today.
