seom is required for example for the beryl vidcap plugin and yukon (http://neopsis.com/projects/yukon/), a C-source file and a script and that can be used to set up a fake libGL.so library to allow to capture OpenGL games.
Created attachment 100033 [details] x11-libs/seom ebuild, version 1.0.69 I don't know where this ebuild should go into, I found x11-libs to be the right place, correct me if I'm wrong.
The makefile sucks... Doesn't respect CFLAGS/LDFLAGS, has hardcoded gcc (will fail on crosscompile) and it compiles in src_install()
(In reply to comment #2) > The makefile sucks... Doesn't respect CFLAGS/LDFLAGS, has hardcoded gcc (will > fail on crosscompile) and it compiles in src_install() > The LDFLAGS/CFLAGS/hardcoded gcc could be fixed (though I really don't want to use autotools). It compiles in 'make install' - but only because make doesn't understand that the targets have been already built.. I guess make chokes on this construct: APPS = filter player server $(APPS): libseom.la $(CC) [...] -o seom-$@ [...] care to suggest how I could fix this instead of complaining?
Created attachment 101048 [details, diff] files/seom-makefile.diff - Makefile patch to fix the above issues
Created attachment 101049 [details] x11-libs/seom-9999.ebuild fixed ebuild
(In reply to comment #4) > Created an attachment (id=101048) [edit] > files/seom-makefile.diff > > - Makefile patch to fix the above issues > Thanks for the patch, I committed it to the SVN repo.
(In reply to comment #5) > x11-libs/seom-9999.ebuild couple of questions... CC=$(tc-getCC), will that allow to build the 32bit version on amd64 (eg. will that make the seom multilib-aware?). That's quite important for all those who have amd64 and play 32bit games (windows games under wine/cedega), yukon can already be easily cross-compiled so seom is the only missing piece in the chain. why 'emake' when compiling but 'make' when installing?
(In reply to comment #7) > > CC=$(tc-getCC), will that allow to build the 32bit version on amd64 (eg. will > that make the seom multilib-aware?). Has nothing to do w/ that multilib stuff. It allows for a proper cross-compile (unlike the original makefile w/ a hardcoded CC = gcc). For similar questions, please ask amd64 folks at #gentoo-amd64, sorry I can't help with this. > why 'emake' when compiling but 'make' when installing? Shrug... Not something that'd be important, feel free to change it. BTW, if this goes to portage, we'll need either a regular release or a SVN snapshot, we're not much into live CVS/SVN stuff. (Also, beryl-vidcap Makefile suffers from identical issues - doesn't respect CFLAGS/LDFLAGS, hardcodes gcc)
(In reply to comment #8) > BTW, if this goes to portage, we'll need either a regular release or a SVN > snapshot, we're not much into live CVS/SVN stuff. I could make tags whenever I feel it's stable enough. But I guess you mean create tarballs... But the SVN server can handle the load as I don't think that many people will start using beryl-vidcap. Does the gentoo release team (or someone else) have a make-tarball-from-svn-and-create-ebuild script at hand? Would be nice to have such a script to be able to quicky create both the tarball and the ebuild. > (Also, beryl-vidcap Makefile suffers from identical issues - doesn't respect > CFLAGS/LDFLAGS, hardcodes gcc) > I don't know much about Makefiles.. I'm able to write a simple one for a 'hello world' app, but anything that goes beyond that is above my skills. But feel free to send me patches, or alternatively you can go into #beryl-dev and tell someone with write-rights to commit your patch.
(In reply to comment #4) > - Makefile patch to fix the above issues > Strange that you only change 'CC' but not 'PREFIX', but both variables are overridden on the make command line. When I use 'CC ?= gcc' then CC gets defined as 'cc', if I revert it back to 'CC = gcc' then I still can override CC from the commandline and if I don't specify anything then CC gets 'gcc', as expected. I also couldn't find anything that would explain the ?= syntax. Also, users have been reporting problems with libtool, don't know if it's related to the Makefile change, see http://forum.beryl-project.org/post-50852#p50852
(In reply to comment #10) Eh, just revert it to CC = gcc, it works as well. Prefix needs to be overriden in the ebuild, will bomb out w/ sandbox otherwise. (I'd suggest to move this debate somewhere else, this is not exactly a place to debate autotools and makefiles.)
Comment on attachment 101048 [details, diff] files/seom-makefile.diff No longer needed, fixed upstream.
Created attachment 101727 [details] x11-libs/seom-9999.ebuild
Created attachment 103330 [details] updated ebuild updated ebuild that uses ARCH to optimize for amd64 and x86 architectures
Created attachment 103331 [details] updated ebuild updated ebuild that uses ARCH to optimize for amd64 and x86 architectures
Created attachment 104246 [details] updated ebuild (Dec. 17, 2006) ARCH also needs to be set when we're installing seom, otherwise it will compile some files in the install stage.
WTH... You might want to fix this thing in SVN to NOT install /usr/lib/pkgconfig as a *file* (see Bug 162456) $ cat /var/tmp/portage/x11-libs/seom-9999/image/usr/lib/pkgconfig Name: seom Description: seom video capturing library Version: 1.0- Libs: -L/var/tmp/portage/x11-libs/seom-9999/image//usr/lib -lseom Cflags: -I/var/tmp/portage/x11-libs/seom-9999/image//usr/include
fixed.. but the ebuild needs an update, too. It needs to use PREFIX and DESTDIR correctly, eg. in src_install() it should be: emake [..] DESTDIR="${D}" PREFIX="/usr" otherwise the paths in the seom pkgconfig file will be bad.
Created attachment 107228 [details] updated ebuild (Jan. 17, 2007) fix usage of PREFIX and DESTDIR
>>> Compiling source in /var/tmp/portage/x11-libs/seom-9999/work/trunk ... Makefile:17: config.make: No such file or directory Makefile:57: *** missing separator. Stop.
Created attachment 107397 [details] updated ebuild (Jan. 19, 2007) this ebuild should work again.
Created attachment 111383 [details] updated ebuild (2007-02-27) The dev-lang/yasm is required to compile this package Added in RDEPEND
Stuff that's required to compile something is DEPEND, not RDEPEND.
Created attachment 119705 [details] Updated ebuild (2007-05-19) Now build all ABIs on amd64, don't know how it behaves on x86 systems.
ebuild is in the sunrise overlay: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/x11-libs/seom
Tried the sunrise version, but version 1.0.179 cannot be downloaded anymore. Current (and only) version seems to be 1.0.192, which needs a few adjustments in the ebuild, patch attached. After that it still does not work, because "x86-64 architecture of input file `src/arch/amd64/frame.o' is incompatible with i386 output", buildlog attached.
Created attachment 130693 [details, diff] Patch to make ebuild "192 compatible"
Created attachment 130695 [details] Logfile of the failed build
Created attachment 130697 [details, diff] Patch to make ebuild "192 compatible" Sorry for the noise. Here comes the fix for my build problems.
Failed for me on x86. Log file and emerge --info are here: http://mlodyinteligent.pl/~lazy_bum/tmp/
was something changed in portage? Or why does your $(get_install_abis) contain 'default'? The offending code is this: for ABI in $(get_install_abis); do econf --arch="${ABI}" --prefix="/usr" || die "econf failed" done ABI is set to 'default', which is wrong. It should be either 'x86' or 'amd64'. Someone who knows the portage internals would have to look into it.
The HOMEPAGE & SRC_URI are dead, and I am unable to find a reference of a new one. Unless somebody fixes that, the ebuild will be masked for removal in 30 days.
The new homepage is: https://devel.neopsis.com/projects/seom
(In reply to comment #33) > The new homepage is: https://devel.neopsis.com/projects/seom Are there any official tarballs/snapshots around?
Created attachment 278219 [details] Build.log # emerge --info =x11-libs/seom-1.0.192 Portage 2.2.0_alpha41 (default/linux/amd64/10.0, gcc-4.6.0, glibc-2.13-r2, 2.6.39.1 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-2.6.39.1-x86_64-Intel-R-_Core-TM-2_CPU_6300_@_1.86GHz-with-gentoo-2.0.3 Timestamp of tree: Sat, 25 Jun 2011 21:45:01 +0000 ccache version 3.1.5 [enabled] app-shells/bash: 4.2_p10 dev-lang/python: 2.4.6, 2.7.1-r1, 3.2 dev-util/ccache: 3.1.5 dev-util/cmake: 2.8.4-r1 sys-apps/baselayout: 2.0.3 sys-apps/openrc: 0.8.3 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.10.3, 1.11.1-r1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.5.2, 4.6.0 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r1 sys-kernel/linux-headers: 2.6.38 (virtual/os-headers) sys-libs/glibc: 2.13-r2 Repositories: gentoo roslin xarthisius sunrise Installed sets: ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="* -@EULA" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=nocona -mno-sse3 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=nocona -mno-sse3 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache distlocks ebuild-locks fixlafiles fixpackages news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="http://distfiles.ift.uni.wroc.pl/" LANG="pl_PL.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" 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/roslin /var/lib/layman/xarthisius /var/lib/layman/sunrise" SYNC="rsync://rsync1.pl.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt cxx dri fortran gdbm iconv ipv6 mmx modules mudflap multilib ncurses nptl nptlonly openmp pam pcre perl pppd python readline session sse sse2 ssl sysfs tcpd unicode xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" 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" CALLIGRA_FEATURES="braindump flow karbon kexi kpresenter krita tables words" CAMERAS="ptp2" 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 evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga neomagic nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" 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, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS # emerge -pqv =x11-libs/seom-1.0.192 [ebuild N ] dev-python/cython-0.14.1 USE="-doc -examples" [ebuild N ] dev-lang/yasm-1.1.0-r1 USE="python -nls" [ebuild N ] x11-libs/seom-1.0.192
Note that seom is unsupported now and no longer being actively worked on. As to your issue, it looks like you need to install the opengl headers. It's probably a missing dependency in the seom ebuild.
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
Upstream has abandoned this project as stated above by the main developer himself: https://bugs.gentoo.org/151988#c36 Also see my notes on https://bugs.gentoo.org/181216#c12 with more evidence that this package and the only one pulling it as a dependency are both abandoned by the same upstream.
