Hello, Current svgalib-1.9.25-r1 ebuild removes svgalib_helper.h header, this is wrong and breaks build of software relying on its interface, like custom build of mplayer (not from the portage tree). In ebuild it is noted that this header should be removed otherwise shared libraries can't be build. But as of current version with this header present shared libraries are built without any problems. And installation of this header helps to compile related software. $ emerge --info Portage 2.2_rc96 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.12.1-r1, 2.6.35.7-yoruichi i686) ================================================================= System uname: Linux-2.6.35.7-yoruichi-i686-AMD_Athlon-tm-_XP_3200+-with-gentoo-2.0.1 Timestamp of tree: Fri, 15 Oct 2010 17:30:14 +0000 distcc 3.1 i686-pc-linux-gnu [enabled] ccache version 2.4 [enabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11 dev-lang/python: 2.6.6-r1, 3.1.2-r4 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.4_p6-r1, 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 3.3.6-r1, 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) Repositories: gentoo science java-overlay sunrise local ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -m32 --param l1-cache-line-size=64 --param l1-cache-size=64 --param l2-cache-size=512 -O2 -funswitch-loops -fpredictiv e-commoning -fgcse-after-reload -fomit-frame-pointer -ftree-loop-linear -floop-interchange -floop-strip-mine -mfpmath=sse -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb /usr/share/config /var/bind /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache 2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/lang uage.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -m32 --param l1-cache-line-size=64 --param l1-cache-size=64 --param l2-cache-size=512 -O2 -funswitch-loops -fpredict ive-commoning -fgcse-after-reload -fomit-frame-pointer -ftree-loop-linear -floop-interchange -floop-strip-mine -mfpmath=sse -pipe" DISTDIR="/usr/portage/distfiles" EMERGE_DEFAULT_OPTS="--keep-going --with-bdeps y" FEATURES="assume-digests binpkg-logs candy ccache collision-protect distcc distlocks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" FFLAGS="-march=athlon-xp -m32 --param l1-cache-line-size=64 --param l1-cache-size=64 --param l2-cache-size=512 -O2 -funswitch-loops -fpredictive-commoning -fgcse-after-reload -fomit-frame-pointer -ftree-loop-linear -floop-interchange -floop-strip-mine -mfpmath=sse -pipe" GENTOO_MIRRORS=" ftp://orionis/distributions/1Linux/gentoo/portage ftp://10.51.13.243/public/gentoo ftp://ftp.chg.ru/pub/Linux/gentoo http://mi rror.yandex.ru/gentoo-distfiles ftp://ftp.corbina.net/pub/Linux/gentoo http://distfiles.gentoo.org http://mirror.netcologne.de/gentoo" LANG="en_US.UTF-8" LC_ALL="" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="ru en ja" MAKEOPTS="-j4 --load-average=5" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/science /var/lib/layman/java-overlay /var/lib/layman/sunrise /usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X a52 aac aalib acl acpi adns afs aften aim aio alsa amr amrnb amrwb ao artworkextra audiofile bash-completion bcmath bidi binfilter blas bluetooth branding bzip2 cairo calendar caps ccache cddb cdinstall cdparanoia cdr chasen chm cjk cleartype cli clisp colordiff cracklib crypt cscope css ctype cups curl curlwrappers cvs cxx cyrillic dbus device-mapper dga dhcp dia dirac directfb djvu dmx doc dri dts dv dvd dvdr dvdread dvi ebook editor elf emf enca encode enscript ermt examples exif expat faac faad fbcon festival ffmpeg fftw firefox flac flash fontconfig foomaticdb fortran fpx freetds freetype ftp gcj gcrypt gd gdbm geoip ggi gif gimp ginac git glibc-omitfp glitz glut gmp gnuplot gnutls gpgme gphoto2 gpm gps graphite graphviz gs gsl gsm gtk gucharmap h224 h281 h323 hdf5 hdri iconv icq icu id3tag idn imagemagick imap imlib immqt-bc inkjar ipod iproute2 ipv6 jabber jack jadetex java6 javascript jbig jingle jpeg jpeg2k kdehiddenvisibility kerberos keyscrub kpathsea kqemu ladspa lame lapack lash latex lcms libcaca libnotify libsamplerate libwww lm_sensors logrotate lzma lzo mad maildir mailwrapper matroska md5sum mhash mikmod mime mjpeg mmap mmx mng modplug modules mp3 mpeg mplayer msn mudflap musepack musicbrainz mysql mysqli nas ncurses netcdf network network-cron nls nntp nocd nodrm nptlonly nsplugin nuv objc objc++ offensive ogg openal opencore-amr openexr opengl optimized-qmake oscar otr pam pango pcntl pcre pdf perl pgf plotutils png pop portaudio posix postproc postscript ppds pppd pronounce pstricks qt3support qt4 quicktime raw rdesktop readline recode reflection restrict-javascript rfc3779 rle rrdtool samba scanner schroedinger sdl session sharedmem shorten sip sipim slang slp smi smime sms smtp sndfile sockets socks5 soundtouch sox sparse speex spell sqlite sqlite3 srtp sse ssl startup-notification strong-optimization subversion supernodal svg svga sysfs syslog szip t1lib taglib tcpd theora tiff timezone timidity tordns truetype twolame type3 unicode usb utempter utils v4l v4l2 vamp vcd videos vim vim-syntax vnc vorbis wav wavpack wifi win32codecs wireshark wmf x264 x86 xattr xcb xface xft xinerama xml xorg xosd xpm xprint xrandr xscreensaver xv xvid yahoo yaz ziffy zlib" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="ru en ja" PHP_TARGETS="php-5.2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa nouveau" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, INSTALL_MASK, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
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
