|Summary:||media-libs/svgalib should install svgalib_helper.h|
|Product:||Gentoo Linux||Reporter:||Andrew Savchenko <bircoph>|
|Component:||[OLD] Development||Assignee:||No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed>|
|Severity:||normal||CC:||bircoph, kiorky, rogerx.oss|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||405411|
Description Andrew Savchenko 2010-10-17 00:19:55 UTC
Comment 1 Andrew Savchenko 2010-10-17 00:20:55 UTC
Created attachment 250953 [details, diff] svgalib-1.9.25-r1.ebuild.patch Do not remove svgalib_helper.h and install it at include dir.
Comment 2 Pacho Ramos 2012-02-09 12:30:13 UTC
*** This bug has been marked as a duplicate of bug 369095 ***
Comment 3 Andrew Savchenko 2012-02-09 13:09:06 UTC
(In reply to comment #2) > > *** This bug has been marked as a duplicate of bug 369095 *** Why you marked this bug as a duplicate of #369095? Have you ever read this bug? This is a completely different issue: module itself builds well, what fails to build are applications using this module because of svgalib_helper.h is explicitly and mistakenly removed from sources in the ebuild.
Comment 4 Roger 2012-02-10 00:30:52 UTC
Can you please provide a package which fails to build against svgalib? (Currently, both mplayer and links seem to build fine.) ... providing a package failing to compile against the current svgalib might explain the problem to developers or did I miss something?
Comment 5 Andrew Savchenko 2012-02-10 14:23:24 UTC
(In reply to comment #4) > Can you please provide a package which fails to build against svgalib? To avoid further misunderstanding I must point out: svgalib contains two objects of interest: libvga library and svgalib_helper.ko kernel module. This bug is about the latter: there are problems with programs using svgalib_helper module, not just svga library itself. > (Currently, both mplayer and links seem to build fine.) > > ... providing a package failing to compile against the current svgalib might > explain the problem to developers or did I miss something? Mplayer from portage build for you only because current ebuild supports only svga library libvga and not the kernel module svgalib_helper. The helper module was supported earlier and removed by the maintainers due to their own reasons, perhaps just because it failed to build with svga. To reproduce the problem just: 1) fetch svn head of mplayer (or use any decent snapshot); 2) make sure svgalib[kernel-helper] is installed; 3) ./configure --enable-svgalib_helper && make; And you will get with portage's svgalib: make: *** [vidix/dha.o] Error 1 make: *** Waiting for unfinished jobs.... In file included from vidix/AsmMacros.h:80:0, from vidix/mtrr.c:28: vidix/sysdep/AsmMacros_x86.h:77:28: fatal error: svgalib_helper.h: No such file or directory compilation terminated. distcc ERROR: compile vidix/mtrr.c on localhost failed make: *** [vidix/mtrr.o] Error 1 Now it would be great if someone can explain me why to remove valid header file src/svgalib_helper.h at all? Ebuild says: # Have to remove for shared to build ... rm -f src/svgalib_helper.h However, without this removal shared library builds perfectly fine.
Comment 6 Roger 2012-02-10 18:59:09 UTC
Maybe there's a file conflict with another package? Going from memory, I think another package does already own "src/svgalib_helper.h"?
Comment 7 Roger 2012-02-10 19:01:31 UTC
Although they at least left a comment, would have been nice to be a little more specific as to why. I'm always complaining here on bugs.gentoo.org about using decent inline comments and einfo statements, and incrementing -rN when needed. Well, at least there's some comment to go on. :-/
Comment 8 Roger 2012-02-10 19:38:50 UTC
I just did a query on ALL bugs on bugs.gentoo.org reporting issues with "svgalib_helper.h". Of the only five to seven bugs, three confirmed and relevant ones with something to do with "svgalib_helper.h" in the "sharedlib" path/folder. Bug #42672 - Users upgrade linux headers which spurred a break. Unknown fix was performed. After a emerge sync after an hour or so, was mysteriously resolved. (2004) Bug #11092 - Seems the original svgalib ebuild author made note of including a kernel module here. And some other unknown fixes were implemented as well possibly solving this sharedlib path/folder issue here. (2002) Bug #117379 (More like a Brain Fart bug with CFLAGS) As you can see, the bugs were found back in 2002 and 2004, not including the brain fart with CFLAGS. This should help you narrow things down a big. I performed the initial searching using the simple search. https://bugs.gentoo.org/query.cgi And used quotes around "svgalib_helper.h". You could also probably include "sharedlib|shared lib" for your own search if you want. As usual, when fixing things, people should always document there bug fixing inline. Also note, bugs.gentoo.org might not always be around and might disappear -- even though including a bug number is a great reference!
Comment 9 Roger 2012-02-10 20:36:39 UTC
I have tested this patch and recompiled www-client/links and media-gfx/fbida against svgalib successfully. I think fbida uses the framebuffer (/dev/fb0) device and doesn't explicitly rely on svgalib driver. I have tested links after doing the following because links is still looking for ./dev/svga' and everything seems to work here. ln -s /dev/svga0 /dev/svga links -g -driver svgalib -mode 800x600x16M32 www.google.com Now, as to whether or not links and fbida still rely on svgalib for building it's usual framebuffer access as well is unknown to me. fb (or fbcon), directfb and svgalib are all separate video drivers. I use fb/fbcon here and am now realizing svgalib seems to have been a generic build pull-in. It would seem mplayer has dropped svgalib dependency when using fb/fbcon USE flags. # cat /var/tmp/portage/media-video/mplayer-1.0_rc4_p20110322-r1/work/mplayer-1.0_rc4_p20110322/config.log |grep svga --disable-svga --disable-svgalib_helper My best bet, mplayer was failing to build. The latest mplayer stable noted here disables svga and there doesn't seem to be an svga USE flag, at least anymore -- the flags may have been enabled as noted by default by enabling fbcon USE flag. I'm currently rebuilding mplayer & mplayer2, and will note here if they fail building for some odd reason, however doubt they will fail to build because of this. Just curious, what is svgalib still used for? Think most use fbcon (framebuffer), and for more unique desires directfb. And everybody uses the extravagant default X11/Xorg.
Comment 10 Andrew Savchenko 2012-02-11 10:32:10 UTC
(In reply to comment #9) > Just curious, what is svgalib still used for? Think most use fbcon > (framebuffer), and for more unique desires directfb. And everybody uses the > extravagant default X11/Xorg. svgalib kernel helper may be used for vidix output and helper module is needed if you want to do so without giving mplayer root privileges. Sometimes vidix output is faster than anything else, especially when integrated video card is not capable of handling opengl output. You may look for more details at vidix/README.dha in the MPlayer sources.
Comment 11 Roger 2012-02-11 18:35:37 UTC
http://en.wikipedia.org/wiki/Vidix The X Window System now includes the Direct Rendering Infrastructure, which provides similar functionality with broad hardware support. Kurshev continued to develop VIDIX through 2007, when version 1.0.0 of the software was released. However, this is still a bug that should be fixed. At this point, since there haven't been much other communication on this bug by now, I'm going to conclude it was the now non-existent mplayer configure svga options as I noted previously causing problems, which are now disabled by default and no longer available as mplayer USE flags. I think the patch should be imported into Portage as it brings this package back to defaults (what the svgalib developer originally intended), nor is it currently breaking anything either. It could have also been older kernel versions causing problems, and now fixed. The comment within the ebuild/script file concerning the 'rm' usage is unclear, too general and non-specific.
Comment 13 Pacho Ramos 2012-02-26 12:19:36 UTC
Please test ebuilds at bug 405411 because looks like no dev is willing to maintain this and I don't want to commit it without even confirming it builds (I don't have x86 to check that). The idea would be to try to solve current issues and, if possible, try to get the package proxy-maintained: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml If nobody cares in a month, I will probably try to hardmask this for removal if possible :/
Comment 14 Roger 2012-02-26 21:49:07 UTC
This builds fine here on x86. Think I've already stated svgalib builds fine with removing the two 'rm' statements and including the 'doins' for the header file "svgalib_helper.h" along side mplayer, etc. As far as masking for removal, although ancient, svgalib is still used. Especially for those of us who can't afford the newer computers, or even multiple computers for backup usage. ie. Need a cli browser with graphics capability when X11/Xorg is broken? www-client/links was always there for us. (I still constantly use www-client/elinks without graphics -- text only CLI browser.) It's used here primarily as a fallback method when all else fails, I still have something to work with -- and likely similar elsewhere. Granted, Xorg is more stable these days and someday this package will be removed. But you never know as some new XYZ video card might not have Linux drivers or stable drivers, and users will once again be forced to use the cli. Seems svgalib is used quite a bit elsewhere still: $ fgrep /usr/portage/* -r -e "svgalib" --exclude-dir="/usr/portage/distfiles" --exclude-dir="/usr/portage/packages" --exclude-dir="/usr/portage/metadata" --exclude-dir="/usr/portage/media-libs/svgalib" --exclude-dir="/usr/portage/profiles" --include=*\.ebuild You don't want to make the people who made your computer mad do you? Or do you?
Comment 15 Andrew Savchenko 2012-02-26 22:43:57 UTC
(In reply to comment #13) > Please test ebuilds at bug 405411 I do not see any attaches files in 405411, as for blocked bugs: 339873 contains no patches; 341393 (this ebuild) works well; 344663 works fine at least on 220.127.116.11 and 18.104.22.168; As for 402831, I haven't tested it yet and will report later > because looks like no dev is willing to > maintain this and I don't want to commit it without even confirming it builds > (I don't have x86 to check that). The real problem is in bundled sys-libs/lrmi build; lrmi does not work on anything aside i386. Though dev-libslibx86 provides lrmi interface and works on both x86 and amd64. It looks like svgalib may be tweaked to use system libx86 instead of bundled lrmi, though this will require some effort. > The idea would be to try to solve current issues and, if possible, try to get > the package proxy-maintained: > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml If you can proxy this package for me, I will try to maintain it.
Comment 16 Andrew Savchenko 2012-02-26 23:09:41 UTC
(In reply to comment #15) > As for 402831, I haven't tested it yet and will report later Seems to work fine here.
Comment 17 Pacho Ramos 2012-02-27 19:55:54 UTC
(In reply to comment #15) > (In reply to comment #13) > > Please test ebuilds at bug 405411 > > I do not see any attaches files in 405411, as for blocked bugs: > Oops, just attached, looks it failed when I opened the bug > 339873 contains no patches; > 341393 (this ebuild) works well; > 344663 works fine at least on 22.214.171.124 and 126.96.36.199; > > As for 402831, I haven't tested it yet and will report later > > > because looks like no dev is willing to > > maintain this and I don't want to commit it without even confirming it builds > > (I don't have x86 to check that). > > The real problem is in bundled sys-libs/lrmi build; lrmi does not work on > anything aside i386. Though dev-libslibx86 provides lrmi interface and works on > both x86 and amd64. It looks like svgalib may be tweaked to use system libx86 > instead of bundled lrmi, though this will require some effort. > > > The idea would be to try to solve current issues and, if possible, try to get > > the package proxy-maintained: > > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml > > If you can proxy this package for me, I will try to maintain it. Fine with me, please give a try to attached ebuild+patches ;) Thanks
Comment 18 Pacho Ramos 2012-03-03 12:38:19 UTC
*svgalib-1.9.25-r2 (03 Mar 2012) 03 Mar 2012; Pacho Ramos <firstname.lastname@example.org> +files/svgalib-1.9.25-build2.patch, +files/svgalib-1.9.25-fPIC.patch, +files/svgalib-1.9.25-linux2.6.36-r1.patch, +files/svgalib-1.9.25-segfault.patch, +svgalib-1.9.25-r2.ebuild: Respect LDFLAGS (bug #339873 by Andrew Savchenko), install svgalib_helper.h (bug #341393 by Andrew Savchenko), fix build with recent kernels (bug #344663 by Rene Hertell), fix segfault (bug #402831 by O.Sezer). Anyway, this package needs a maintainer to get things fixed sooner. I can be your proxy maintainer if you want: http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml
Comment 19 Andrew Savchenko 2012-04-07 08:42:09 UTC
1.9.25-r2 installs a broken symlink instead of the file. Proposed patch fixes this. (In reply to comment #18) > Anyway, this package needs a maintainer to get things fixed sooner. I can be > your proxy maintainer if you want: > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml As for proxy maintaining of this package, I can try it, but what is the preferred way to communicate? Should I send patches to email@example.com or to you directly?
Comment 20 Andrew Savchenko 2012-04-07 08:43:57 UTC
Created attachment 308071 [details, diff] svgalib-1.9.25-r2.ebuild.patch installs the actual file, not a symlink
Comment 21 Pacho Ramos 2012-04-07 12:11:17 UTC
(In reply to comment #19) > 1.9.25-r2 installs a broken symlink instead of the file. > Proposed patch fixes this. Thanks. +*svgalib-1.9.25-r3 (07 Apr 2012) + + 07 Apr 2012; Pacho Ramos <firstname.lastname@example.org> +svgalib-1.9.25-r3.ebuild, + -svgalib-1.9.25-r2.ebuild, metadata.xml: + Fix link installation (#341393#c19), this is now proxy maintained. + > > (In reply to comment #18) > > Anyway, this package needs a maintainer to get things fixed sooner. I can be > > your proxy maintainer if you want: > > http://www.gentoo.org/proj/en/qa/proxy-maintainers/index.xml > > As for proxy maintaining of this package, I can try it, but what is the > preferred way to communicate? Should I send patches to > email@example.com or to you directly? Open bugs for all requests, they will be properly assigned as it's now indicated in metadata.xml Best regards