Improved Ebuild for bubblemon that uses gtk2 instead of gtk1 if the gtk2 use flag is on. The effect of the use flag is that a patch is applied, so bubblemon compiles fine against gtk2, and the dependency on gtk1 is bypassed. Reproducible: Always
Created attachment 117098 [details] Improved ebuild with gtk2 use flag
Created attachment 117100 [details] The patch to compile against gtk2
Tested only in amd64 and x86 (Linux), I had to clean some things to avoid warnings (and potential errors in non-x86 arches). I have no idea if the patch is safe for other OS in which bubblemon compiles. -- Jesús Guerrero
(In reply to comment #3) > Tested only in amd64 and x86 (Linux), I had to clean some things to avoid > warnings (and potential errors in non-x86 arches). I have no idea if the patch > is safe for other OS in which bubblemon compiles. > > -- Jesús Guerrero > There is no more USE="gtk2" used in Portage, it's deprecated.. so your patch would have to go in unconditionally. It builds and works here too, but I'm a bit concerned about.. bubblemon.c: In function ‘render_secondary’: bubblemon.c:1070: warning: format ‘%6ld’ expects type ‘long int’, but argument 4 has type ‘u_int64_t’ bubblemon.c:1072: warning: format ‘%6ld’ expects type ‘long int’, but argument 4 has type ‘u_int64_t’ bubblemon.c:1079: warning: format ‘%6ld’ expects type ‘long int’, but argument 4 has type ‘u_int64_t’ bubblemon.c:1081: warning: format ‘%6ld’ expects type ‘long int’, but argument 4 has type ‘u_int64_t’ sys_linux.c: In function ‘system_cpu’: sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but argument 4 has type ‘u_int64_t *’ sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but argument 5 has type ‘u_int64_t *’ sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but argument 6 has type ‘u_int64_t *’ sys_linux.c: In function ‘system_memory’: sys_linux.c:98: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:103: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:108: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:113: warning: format ‘%ld’ expects type ‘long int *’, but argument 3 has type ‘u_int64_t *’ gcc: -lgdk-x11-2.0: linker input file unused because linking not done gcc: -lgdk-x11-2.0: linker input file unused because linking not done
Well, I can remove that use flag and make it unconditional. I left it around in case someone wanted to use gtk1 instead. (In reply to comment #4) > bubblemon.c: In function ‘render_secondary’: > bubblemon.c:1070: warning: format ‘%6ld’ expects type ‘long int’, but > argument 4 has type ‘u_int64_t’ > bubblemon.c:1072: warning: format ‘%6ld’ expects type ‘long int’, but > argument 4 has type ‘u_int64_t’ > bubblemon.c:1079: warning: format ‘%6ld’ expects type ‘long int’, but > argument 4 has type ‘u_int64_t’ > bubblemon.c:1081: warning: format ‘%6ld’ expects type ‘long int’, but > argument 4 has type ‘u_int64_t’ > sys_linux.c: In function ‘system_cpu’: > sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but > argument 3 has type ‘u_int64_t *’ > sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but > argument 4 has type ‘u_int64_t *’ > sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but > argument 5 has type ‘u_int64_t *’ > sys_linux.c:37: warning: format ‘%ld’ expects type ‘long int *’, but > argument 6 has type ‘u_int64_t *’ > sys_linux.c: In function ‘system_memory’: > sys_linux.c:98: warning: format ‘%ld’ expects type ‘long int *’, but > argument 3 has type ‘u_int64_t *’ > sys_linux.c:103: warning: format ‘%ld’ expects type ‘long int *’, but > argument 3 has type ‘u_int64_t *’ > sys_linux.c:108: warning: format ‘%ld’ expects type ‘long int *’, but > argument 3 has type ‘u_int64_t *’ > sys_linux.c:113: warning: format ‘%ld’ expects type ‘long int *’, but > argument 3 has type ‘u_int64_t *’ > gcc: -lgdk-x11-2.0: linker input file unused because linking not done > gcc: -lgdk-x11-2.0: linker input file unused because linking not done > I can't reproduce this. What artch and gcc version are you using? -- Jesús Guerrero
(In reply to comment #5) > I can't reproduce this. What artch and gcc version are you using? Portage 2.1.2.5 (default-linux/x86/2007.0, gcc-4.1.2, glibc-2.5-r2, 2.6.21-rc7-git4 i686) FLAGS="-O2 -march=athlon-xp -pipe" CXXFLAGS="${CFLAGS}" LDFLAGS="-Wl,-O1,--as-needed"
# Samuli Suominen <drac@gentoo.org> (14 May 2007) # Masked for removal in 30 days unless bug 175730 # gets solved. Bug has unfinished patch to port # this for GTK+-2.0. x11-misc/bubblemon 6thpink, I hope you get some sense of those warnings.
drac, can you try the slightly modified patch here? http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-misc/bubblemon/files/bubblemon-1.46-gtk2.patch?format=txt
(In reply to comment #8) > drac, can you try the slightly modified patch here? > > http://overlays.gentoo.org/proj/alt/browser/trunk/prefix-overlay/x11-misc/bubblemon/files/bubblemon-1.46-gtk2.patch?format=txt > sys_linux.c: In function ‘system_cpu’: sys_linux.c:37: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:37: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 4 has type ‘u_int64_t *’ sys_linux.c:37: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 5 has type ‘u_int64_t *’ sys_linux.c:37: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 6 has type ‘u_int64_t *’ sys_linux.c: In function ‘system_memory’: sys_linux.c:98: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:103: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:108: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 3 has type ‘u_int64_t *’ sys_linux.c:113: warning: format ‘%zd’ expects type ‘signed size_t *’, but argument 3 has type ‘u_int64_t *’ bubblemon.c: In function ‘render_secondary’: bubblemon.c:1070: warning: format ‘%6zu’ expects type ‘size_t’, but argument 4 has type ‘u_int64_t’ bubblemon.c:1072: warning: format ‘%6zu’ expects type ‘size_t’, but argument 4 has type ‘u_int64_t’ bubblemon.c:1079: warning: format ‘%6zu’ expects type ‘size_t’, but argument 4 has type ‘u_int64_t’ bubblemon.c:1081: warning: format ‘%6zu’ expects type ‘size_t’, but argument 4 has type ‘u_int64_t’ gcc: -lgdk-x11-2.0: linker input file unused because linking not done gcc: -lgdk-x11-2.0: linker input file unused because linking not done
(In reply to comment #7) > # Samuli Suominen <drac@gentoo.org> (14 May 2007) > # Masked for removal in 30 days unless bug 175730 > # gets solved. Bug has unfinished patch to port > # this for GTK+-2.0. > x11-misc/bubblemon > > 6thpink, I hope you get some sense of those warnings. > Sorry, I've been a bit busy with real life. I'll see if I can fix it in a couple of days. It must be some stupid thing, since those warnings don't appear in my amd64 gentoo. -- Jesús Guerrero
ok, the problem is that on 64-bit platforms u_int64_t is something else than on 32-bit platforms. The original patch throws a bit too much away (like ifdeffed solaris code that can just stay). Removing the formatting changes from the patch makes it compile fine with CFLAGS="-m32", given that you use the CFLAGS hunk from my patch, which basically does += instead of = to sort of respect the user's CFLAGS. I think the solution is to either use a define with the right format, or just use another typedef that is set based on some ifdefs for the 32 vs 64-bit case.
x11-plugins/bfm seems to be same deal but with GTK+-2.0.. is there a point keeping this around?
I thought this thing was bubblefishymon (bfm) which seems to compile and run fine on amd64/x86 with gtk2 already. bfm actually docks, which I use, so I'm not interested in this app any more. Maybe someone else is.
(In reply to comment #13) > I thought this thing was bubblefishymon (bfm) which seems to compile and run > fine on amd64/x86 with gtk2 already. bfm actually docks, which I use, so I'm > not interested in this app any more. Maybe someone else is. > I didn't know about that one. Anyway, while it compiles fine, it also segfaults around one second after starting the applet, and exits. I can see some purple-ish fishes and the yellow duck appearing on the water, but they soon disappear when the app dies. This is in amd64 and gcc-4.1.2, no fancy C/LDFLAGS. Fixing bubblemon should not be difficult (I know nothing about bfm, though I don't think they are too different). But it is getting really late here and it's been a busy work, so the duck will have to wait until I have time to toy around with bubblefish or time to gdb bubblefishymon a bit. Surelly, in both cases amd64 is in the middle of the problem. -- Jesús Guerrero
bfm is more or less a hacked version of bubblemon, with a few more features (from fishmon), but as 6thpink mentioned, it segfaults when free memory is low (thank you Java!). If bubblemon finally stays in portage, here are my ebuild and gtk2 patch for it (if not, they're already in my overlay ;) ).
Created attachment 120522 [details, diff] GTK2 patch based on bfm code
Created attachment 120523 [details] Cleaned up ebuild
(In reply to comment #15) > If bubblemon finally stays in portage, here are my ebuild and gtk2 patch for it > (if not, they're already in my overlay ;) ). Thanks Bernard. It's definately staying after these efforts and should be unmasked in CVS now. Thank you others too!
(In reply to comment #16) > Created an attachment (id=120522) [edit] > GTK2 patch based on bfm code > Removed prestripping from your patch but other than that it went unchanged.
