| 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> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bircoph, kiorky, rogerx.oss |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 405411 | ||
| Bug Blocks: | |||
| Attachments: |
svgalib-1.9.25-r1.ebuild.patch
svgalib-1.9.25-r2.ebuild.patch |
||
|
Description
Andrew Savchenko
2010-10-17 00:19: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.
*** This bug has been marked as a duplicate of bug 369095 *** (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. 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? (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[7134] 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. Maybe there's a file conflict with another package? Going from memory, I think another package does already own "src/svgalib_helper.h"? 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. :-/ 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! 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. (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. 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.[4] 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. Please go to bug 405411 and check its ebuild 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 :/ 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? (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 2.6.38.7 and 2.6.39.4; 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. (In reply to comment #15) > As for 402831, I haven't tested it yet and will report later Seems to work fine here. (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 2.6.38.7 and 2.6.39.4; > > 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 *svgalib-1.9.25-r2 (03 Mar 2012) 03 Mar 2012; Pacho Ramos <pacho@gentoo.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 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 proxy-maint@gentoo.org or to you directly? Created attachment 308071 [details, diff]
svgalib-1.9.25-r2.ebuild.patch
installs the actual file, not a symlink
(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 <pacho@gentoo.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 > proxy-maint@gentoo.org or to you directly? Open bugs for all requests, they will be properly assigned as it's now indicated in metadata.xml Best regards |