[Mageia-dev] bumblebee in mageia (and mentoring)
simple w8
simplew8 at gmail.com
Tue Apr 10 21:28:19 CEST 2012
2012/4/10 Maarten Vanraes <alien at rmail.be>:
> i have some sparsely extra comments, i hope i'm correct on this...
>
>
> Op dinsdag 10 april 2012 20:35:26 schreef simple w8:
>> 2012/4/10 Anssi Hannula <anssi at mageia.org>:
>> > 10.04.2012 07:46, simple w8 kirjoitti:
>> >> Currently i dont have any account to be able to comit these new
>> >> packages for the distro so i ask if someone can review the specs so
>> >> that these packages can start existing in the distro, and i also ask
>> >> if theres someone that can help me with mentoring
>> >
>> > Reviewed below. However, there looks to be quite a lot of work
>> > remaining, so I don't think I'll be able to help you personally with the
>> > issues. I hope you'll find a mentor who'll help you through.
>> >
>> >> Name: libbsd
>> >> Summary: Library providing BSD-compatible functions for portability
>> >>
>> >>[...]
>> >>
>> >> %{_libdir}/libbsd.so.%{major}*
>> >
>> > [...]
>> >
>> >> %{_libdir}/libbsd.so
>> >
>> > [...]
>> >
>> > We already have libbsd.a from glibc-devel, which would conflict with
>> > this. If they are really different libraries, something drastic would
>> > have to be done (e.g. renaming or dropping one). I suspect they are the
>> > same, though, in which case this isn't needed.
>> >
>> >> %prep
>> >> %setup -q
>> >> # fix encoding of flopen.3 man page
>> >> for f in src/flopen.3; do
>> >> iconv -f iso8859-1 -t utf-8 $f >$f.conv
>> >> touch -r $f $f.conv
>> >> mv $f.conv $f
>> >> done
>> >>
>> >> %build
>> >> %make
>> >
>> > %optflags not used.
>> >
>> >> %install
>> >> make install DESTDIR=%{buildroot} \
>> >
>> > %makeinstall_std
>>
>> Here you really need to spefify them, with %makeinstall_std fails
>>
>> >> libdir=%{_libdir} \
>> >> usrlibdir=%{_libdir} \
>> >> exec_prefix=%{_prefix}
>> >
>> > [...]
>> >
>> >> optidesk.spec
>> >>
>> >>
>> >> Name: optidesk
>> >> Summary: Tool to configure .desktop files to run with optirun
>> >> Group: Graphical desktop/Other
>> >> Version: 0.1
>> >> Release: 1
>> >> URL: https://github.com/Bumblebee-Project/optidesk
>> >> License: GPLv3
>> >> # source from git repo git://github.com/Bumblebee-Project/optidesk.git
>> >> Source0: %{name}.tar.xz
>> >
>> > Tarball needs to be versioned.
>>
>> I did add a comment saying its from git, but i usually use to create a
>> macro and put some like this:
>>
>> Source0: %{?git:%{name}}%{!?git:%{name}-%{version}}.tar.xz
>>
>> but still there isnt any version released
>>
>> >> Requires: bumblebee
>> >>
>> >> %description
>> >> This tool is intended to be an easy way of configuring your desired
>> >> applications to be run through Bumblebee. It will allow to create
>> >> and modify a menu entry with an alternative (Optirun) version of the
>> >> default launcher.
>> >>
>> >> %files
>> >> %{_bindir}/%{name}
>> >>
>> >>
>> >> %prep
>> >> %setup -qn %{name}
>> >>
>> >> %build
>> >> autoreconf -fi
>> >> %configure
>> >
>> > %configure2_5x
>>
>> I also use to use configure2_5X~but here would not make any
>> difference, but yes here i didnt put because i missed ateention on
>> this line
>>
>> >> %make
>> >
>> > [...]
>> >
>> >> %changelog
>> >> * Mon Mar 19 2012 Simple <simplew8 at gmailcom> 3.0-1
>> >> - initial package
>> >
>> > No single-entry changelog needed for imported packages, it will be
>> > created from the import commit message. (applies to all .specs)
>>
>> Even so i do add an entry in changelog for my personall reports.
>>
>> >> dkms-bbswitch.spec
>> >>
>> >>
>> >> %define oname bbswitch
>> >>
>> >> Name: dkms-%{oname}
>> >> Summary: bbswitch - Optimus GPU power switcher
>> >> Group: System/Kernel and hardware
>> >> Version: 0.4.1
>> >> Release: %mkrel 1
>> >> License: GPLv3
>> >> URL: https://github.com/Bumblebee-Project/bbswitch
>> >> # source from git repo git://github.com/Bumblebee-Project/bbswitch.git
>> >> Source0: %{oname}.tar.xz
>> >
>> > Tarball needs to be versioned.
>>
>> This is from git and already explained that there was no release
>
> i like to add that if it's a git version, it's best if to have some kind of
> git version on it. so it can be uniquely named. same git version should also
> be used in the version or release.
>
>> >> BuildArch: noarch
>> >> Requires(post): dkms
>> >> Requires(preun):dkms
>> >
>> > Needs to require dkms.
>>
>> AFAIK dkms its only used in post and preun scriptlets., so why add
>> another plain require?
>
> it's in the policy, if you think the policy is incorrect, you should send a
> separate email about it.
>
> better to follow the policy.
I dont know about mageia policies, but i will read about them so i can
start using them from now on.
>> >> %description
>> >> bbswitch is a kernel module which automatically detects the required
>> >> ACPI calls for two kinds of Optimus laptops. It has been verified to
>> >> work with "real" Optimus and "legacy" Optimus laptops (at least, that
>> >> is how I call them).
>> >>
>> >> %files
>> >> %{_usrsrc}/%{oname}-%{version}/*
>> >>
>> >> %post
>> >> set -x
>> >> dkms add -m %{oname} -v %{version} --rpm_safe_upgrade || :
>> >> dkms build -m %{oname} -v %{version} --rpm_safe_upgrade || :
>> >> dkms install -m %{oname} -v %{version} --rpm_safe_upgrade || :
>> >> /sbin/modprobe %{oname} || :
>> >>
>> >> %preun
>> >> dkms remove --binary -m %{oname} -v %{version} --rpm_safe_upgrade --all
>> >> || :
>> >
>> >> /sbin/rmmod %{oname} || :
>> > These scripts are a bit incorrect, see
>> > https://wiki.mageia.org/en/DKMS_packaging_policy
>> > (some || : should be replaced with &&)
>>
>> Well i dont think its incorrect, bow if mageia prefers to use another
>> code its a different issue.
>>
>> >> %prep
>> >> %setup -qn %{oname}
>> >> sed -i 's/#MODULE_VERSION#/%{version}/g' dkms/dkms.conf
>> >>
>> >> %install
>> >> rm -rf %{buildroot}
>> >> mkdir -p %{buildroot}%{_usrsrc}/%{oname}-%{version}
>> >> cp *.c %{buildroot}%{_usrsrc}/%{oname}-%{version}
>> >> cp Makefile %{buildroot}%{_usrsrc}/%{oname}-%{version}
>> >> cp dkms/dkms.conf %{buildroot}%{_usrsrc}/%{oname}-%{version}/dkms.conf
>> >>
>> >> %changelog
>> >> * Mon Mar 19 2012 Simple <simplew8 at gmail.com> 0.4.1-1
>> >> - initial package
>> >>
>> >>
>> >> bumblebee.spec
>> >>
>> >>
>> >> Name: bumblebee
>> >> Summary: Bumblebee - support for NVidia Optimus laptops on Linux!
>> >> Group: System/Kernel and hardware
>> >> Version: 3.0
>> >> Release: 1
>> >
>> > Missing %mkrel.
>>
>> Yes its a typo that escaped me.
>>
>> >> URL: https://github.com/Bumblebee-Project/bumblebee
>> >> License: GPLv3
>> >
>> > Incorrect license, see license policy:
>> > https://wiki.mageia.org/en/Licensing_policy
>> >
>> > AFAICS should be GPLv3+. I didn't check other packages, they may have
>> > wrong tags as well.
>>
>> I need to read it, i didnt knew about it.
>>
>> >> # source from git repo git://github.com/Bumblebee-Project/Bumblebee.git
>> >> Source0: Bumblebee.tar.xz
>> >
>> > Needs to be versioned.
>> >
>> >> BuildRequires: X11-devel
>> >> BuildRequires: pkgconfig(glib-2.0)
>> >> BuildRequires: pkgconfig(libbsd)
>> >> BuildRequires: help2man
>> >> Requires(pre): update-alternatives
>> >> Requires(post): systemd-units
>> >> Requires(preun):systemd-units
>> >> Requires(postun):systemd-units
>> >> Requires: virtualgl
>> >> Requires: x11-driver-video-nvidia-current
>> >
>> > I thought this worked with nouveau as well?
>>
>> Well so far the tests i performed always missed with noveau when
>> running optirun, Anyway, bumblebee is configured by default to use
>> nvidia driver.
>>
>> >> Requires: dkms-bbswitch
>> >> Requires: dkms-acpi_call
>> >
>> > Packages can't require dkms packages directly, see the aforementioned
>> > DKMS policy (use kmod() instead). Requiring them directly breaks binary
>> > dkms packages.
>>
>> This one i didnt knew :)
>
> you can afterwards make a kmod-bbswitch and kmod-acpi_call packages that make
> prebuilt modules for all available kernels.
Yeap, i have seen those kind of packages and that way theres no need
to use a dkms.
>> >> %description
>> >> Bumblebee daemon is a rewrite of the original Bumblebee service,
>> >> providing an elegant and stable means of managing Optimus hybrid
>> >> graphics chipsets.
>> >> A primary goal of this project is to not only enable use of the
>> >> discrete GPU for rendering, but also to enable smart power management
>> >> of the dGPU when it's not in use.
>> >>
>> >> %prep
>> >> %setup -qn Bumblebee
>> >>
>> >> %build
>> >> autoreconf -fi
>> >> %configure \
>> >> CONF_DRIVER=nvidia \
>> >> CONF_DRIVER_MODULE_NVIDIA=nvidia-current \
>> >> CONF_LDPATH_NVIDIA=/usr/lib/nvidia-current:/usr/lib64/nvidia-current \
>> >> CONF_MODPATH_NVIDIA=/usr/lib/nvidia-current/xorg,/usr/lib64/nvidia-curre
>> >> nt/xorg,/usr/lib/xorg/modules,/usr/lib64/xorg/modules,/usr/lib/xorg/extr
>> >> a-modules,/usr/lib64/xorg/extra-modules
>> >
>> > Use %{_libdir}, %ifarch and %{_prefix}/lib. 32-bit builds need only
>> > %{_libdir}, 64-bit builds (%ifarch x86_64) need both %{_libdir} and
>> > %{_prefix}/lib.
>> >
>> >> %make
>> >>
>> >> %install
>> >> rm -rf %{buildroot}
>> >> %makeinstall_std
>> >>
>> >> install -m644 -D scripts/systemd/bumblebeed.service
>> >> %{buildroot}%{_sysconfdir}/systemd/system/bumblebeed.service install
>> >> -m644 -D scripts/sysvinit/bumblebeed
>> >> %{buildroot}%{_initrddir}/%{name}/bumblebeed
>> >>
>> >> %files
>> >> %doc README.markdown doc/RELEASE_NOTES_3_0
>> >> %config(noreplace) %{_sysconfdir}/bash_completion.d/bumblebee
>> >
>> > This shouldn't be %config.
>> >
>> >> %dir %{_sysconfdir}/bumblebee/
>> >> %config(noreplace) %{_sysconfdir}/bumblebee/bumblebee.conf
>> >> %config(noreplace) %{_sysconfdir}/bumblebee/xorg.conf.nouveau
>> >> %config(noreplace) %{_sysconfdir}/bumblebee/xorg.conf.nvidia
>> >> %{_sysconfdir}/systemd/system/bumblebeed.service
>> >> %{_initrddir}/%{name}/
>> >
>> > Extra '/'?
>>
>> This one was a typo.
>>
>> >> %{_sbindir}/bumblebeed
>> >> %{_bindir}/optirun
>> >> %{_bindir}/bumblebee-bugreport
>> >> %{_mandir}/man1/bumblebeed.1*
>> >> %{_mandir}/man1/optirun.1*
>> >>
>> >> %pre
>> >> %_pre_groupadd %{name}
>> >> if [ "$1" -eq "1" ];then
>> >> /usr/sbin/update-alternatives --set gl_conf
>> >> %{_sysconfdir}/ld.so.conf.d/GL/standard.conf fi
>> >
>> > Forcibly changing configuration in %pre seems quite bad to me, though I
>> > do not see much better solutions (except making XFdrake aware of
>> > bumblebee, which is quite some work).
>>
>> I did asked you about what would be the best option here and you said
>> that --set would be the best choice.
>>
>> >> %post
>> >> %_post_service bumblebeed
>> >
>> > [...]
>> >
>> >> if [ $1 -eq 1 ]; then
>> >> # Initial set
>> >> # Enable (but don't start) the unit by default
>> >> /bin/systemctl enable bumblebeed.service
>> >> fi
>> >
>> > I don't think this stuff is needed on Mageia, that is done by default.
>>
>> Really? I didnt knew about it, is there any page documenting that?
>> Im quite curious about how is done :)
>
> perhaps filetriggers or the post and preun service helpers do all this
> automagically... i don't know, i usually just look at other packages.
>
> i think a provided existing service file is picked up by filetriggers
I do see one systemd filetrigger: systemd-daemon-reload.script
but i would like to know hows processed, so far for what i have seen i
dont see how that is possible, to put systemd running services without
put them in the scripts.
And to remember that bumblebee is provided with service files for
systemd and sysvinit, i did had that caution, thats why i put in
scripts bbbbboth usage.
Still i think it would be better to simply keep the ones for systemd,
since its the one used by default.
>> >> %preun
>> >> %_preun_service bumblebeed
>> >
>> > [...]
>> >
>> >> if [ $1 -eq 0 ]; then
>> >> # Package removal, not upgrade
>> >> /bin/systemctl --no-reload disable bumblebeed.service
>> >> /bin/systemctl stop bumblebeed.service
>> >> fi
>> >
>> > That is done by %_preun_service already.
>>
>> How come?
>> ~]$ rpm -E %_preun_service
>> /usr/share/rpm-helper/del-service %{name} $1
>>
>> >> %postun
>> >> %_postun_groupdel %{name}
>> >>
>> >> /bin/systemctl daemon-reload
>> >
>> > Already done by filetriggers.
>> >
>> >> if [ $1 -ge 1 ]; then
>> >> # Package upgrade, not uninstall
>> >> /bin/systemctl try-restart bumblebeed.service
>> >> fi
>> >
>> > Already done by %_post_service.
>>
>> I dont get why you said that again when:
>>
>> ]$ rpm -E %_post_service
>> /usr/share/rpm-helper/add-service %{name} $1
>>
>> >> %changelog
>> >> * Mon Mar 19 2012 Simple <simplew8 at gmailcom> 3.0-1
>> >> - 3.0 (from git), initial package
>> >>
>> >>
>> >> bumblebee-ui.spec
>> >>
>> >>
>> >> Name: bumblebee-ui
>> >> Summary: Bumblebee User Interface
>> >> Group: System/Configuration/Other
>> >> Version: 1.0
>> >> Release: %mkrel 1
>> >> URL: https://github.com/Bumblebee-Project/bumblebee-ui
>> >> License: GPLv3
>> >> # source from git repo
>> >> git://github.com/Bumblebee-Project/bumblebee-ui.git Source0:
>> >> %{name}.tar.xz
>> >
>> > Needs to be versioned.
>> >
>> >> BuildArch: noarch
>> >> Requires: bumblebee
>> >>
>> >> %description
>> >> This is a user interface for bumblebee.
>> >> A complete explanation of the feature of this user interface are
>> >> explained here :
>> >> https://github.com/Bumblebee-Project/bumblebee-ui/wiki
>> >> Please give it a try and report bugs to:
>> >> https://github.com/Bumblebee-Project/bumblebee-ui/issues
>> >
>> > "Please give it a try" is inappropriate in a %description. This should
>> > also briefly explain what bumblebee is.
>>
>> I just copied whats in the bumblebee page
>>
>> >> %files
>> >> %{_sysconfdir}/xdg/autostart/bumblebee-indicator.desktop
>> >> %{_bindir}/bumblebee*
>> >> %{_datadir}/%{name}/
>> >> %{_datadir}/applications/*
>> >> %{_iconsdir}/hicolor/*
>> >>
>> >> %prep
>> >> %setup -qn %{name}
>> >>
>> >> %install
>> >> rm -rf %{buildroot}
>> >> mkdir -p %{buildroot}%{_iconsdir}/hicolor/48x48/apps/
>> >> cp icons/*.* %{buildroot}%{_iconsdir}/hicolor/48x48/apps/
>> >> mkdir -p %{buildroot}%{_datadir}/{%{name},applications}
>> >> cp app/*.* %{buildroot}%{_datadir}/%{name}
>> >> cp bumblebee-app-settings.desktop %{buildroot}%{_datadir}/applications/
>> >> cp bumblebee-indicator.desktop %{buildroot}%{_datadir}/applications/
>> >> mkdir -p %{buildroot}%{_bindir}
>> >> ln -s %{_datadir}/%{name}/AppSettings.py
>> >> %{buildroot}%{_bindir}/bumblebee-app-settings ln -s
>> >> %{_datadir}/%{name}/Bumblebee-Indicator.py
>> >> %{buildroot}%{_bindir}/bumblebee-indicator
>> >>
>> >> chmod +x
>> >> %{buildroot}%{_datadir}/applications/bumblebee-app-settings.desktop
>> >> chmod +x
>> >> %{buildroot}%{_datadir}/applications/bumblebee-indicator.desktop chmod
>> >> +x -R %{buildroot}%{_datadir}/%{name}
>> >>
>> >> # Always start in boot
>> >> mkdir -p %{buildroot}%{_sysconfdir}/xdg/autostart
>> >> cp bumblebee-indicator.desktop %{buildroot}%{_sysconfdir}/xdg/autostart
>> >>
>> >>
>> >> %changelog
>> >> * Mon Mar 19 2012 Simple <simplew8 at gmail.com> 1.0-1
>> >> - initial package
>> >>
>> >>
>> >> dkms-acpi_call.spec
>> >>
>> >>
>> >> %define modname acpi_call
>> >>
>> >> Name: dkms-%{modname}
>> >> Summary: A kernel module that enables you to call ACPI methods
>> >> Group: System/Kernel and hardware
>> >> Version: 0.1
>> >> Release: %mkrel 1
>> >> URL: https://github.com/Bumblebee-Project/acpi_call
>> >> License: GPL
>> >> # source from git repo git://github.com/Bumblebee-Project/acpi_call.git
>> >> Source0: %{modname}.tar.xz
>> >
>> > Needs to be versioned.
>> >
>> >> BuildArch: noarch
>> >> Requires(post): dkms
>> >> Requires(preun):dkms
>> >
>> > Needs to require dkms.
>>
>> Again i dont get why when dkms is only used in post/preun scripts
>>
>> >> %description
>> >> A kernel module that enables you to call ACPI methods by writing the
>> >> method name followed by arguments to /proc/acpi/call.
>> >>
>> >> %files
>> >> %doc README
>> >> %{_usrsrc}/%{modname}-%{version}-%{release}/*
>> >>
>> >> %post
>> >> set -x
>> >> /usr/sbin/dkms add -m %{modname} -v %{version}-%{release}
>> >> --rpm_safe_upgrade || : /usr/sbin/dkms build -m %{modname} -v
>> >> %{version}-%{release} --rpm_safe_upgrade || : /usr/sbin/dkms install -m
>> >> %{modname} -v %{version}-%{release} --rpm_safe_upgrade || :
>> >
>> >> /sbin/modprobe %{modname} || :
>> > Same comments as for the previous dkms package, see mentioned policy.
>> >
>> >> %preun
>> >> dkms remove --binary -m %{modname} -v %{version}-%{release}
>> >> --rpm_safe_upgrade --all || : /sbin/rmmod %{modname} || :
>> >>
>> >> %prep
>> >> %setup -qn %{modname}
>> >>
>> >> %install
>> >> rm -rf %{buildroot}
>> >>
>> >> mkdir -p -m755 %{buildroot}%{_usrsrc}/%{modname}-%{version}-%{release}
>> >> cp -a * %{buildroot}%{_usrsrc}/%{modname}-%{version}-%{release}
>> >> # DKMS config
>> >> cat > %{buildroot}%{_usrsrc}/%{modname}-%{version}-%{release}/dkms.conf
>> >> << 'EOF' PACKAGE_NAME="%{modname}"
>> >> PACKAGE_VERSION="%{version}-%{release}"
>> >> MAKE[0]="make default KERNELPATH=${kernel_source_dir}"
>> >>
>> >> MAKE_MATCH[0]="make load KERNELPATH=${kernel_source_dir}"
>> >
>> > MAKE_MATCH[#] is a regular expression field, you have something very
>> > different in there. MAKE_MATCH[#] line is unneeded here.
>>
>> That line shouldnt be there, seams i didnt attach the most updated spec...
>>
>> >> BUILT_MODULE_NAME[0]="%{modname}"
>> >> DEST_MODULE_LOCATION[0]="/kernel/drivers/acpi"
>> >> REMAKE_INITRD="no"
>> >> AUTOINSTALL="yes"
>> >> EOF
>> >>
>> >> %changelog
>> >> * Mon Mar 19 2012 Simple <simplew8 at gmailcom> 1.0-1
>> >> - initial package
>> >>
>> >>
>> >> libindicator.spec
>> >>
>> >>
>> >> %define major 7
>> >> %define libtool %mklibname indicator3
>> >> %define libname %mklibname indicator3_ %{major}
>> >> %define libdevel %mklibname indicator3 -d
>> >>
>> >> Name: libindicator
>> >> Summary: A set of symbols and convience functions for indicators
>> >> Group: System/Libraries
>> >> Version: 0.4.93
>> >> Release: %mkrel 1
>> >> License: GPL-3.0
>> >
>> > Incorrect license tag.
>> >
>> >> URL: http://launchpad.net/libindicator
>> >> Source0:
>> >> http://launchpad.net/libindicator/0.5/0.4.93/+download//%{name}-%{vers
>> >> ion}.tar.gz BuildRequires: pkgconfig(gtk+-3.0)
>> >>
>> >> %description
>> >> A set of symbols and convience functions that all indicators would like
>> >> to use. Not of real use outside of the Ayatana indicators project.
>> >>
>> >> #--------------------------------------------------------------------
>> >> %package -n %{libname}
>> >> Summary: libindicator3 library
>> >> Group: System/Libraries
>> >>
>> >> %description -n %{libname}
>> >> Library for libindicator3.
>> >>
>> >> %files -n %{libname}
>> >> %{_libdir}/libindicator3.so.%{major}*
>> >>
>> >> #--------------------------------------------------------------------
>> >> %package -n %{libtool}-tools
>> >> Summary: libindicator3 tool
>> >> Group: System/Libraries
>> >>
>> >> %description -n %{libtool}-tools
>> >> Tool to load libindicator3 plugins.
>> >>
>> >> %files -n %{libtool}-tools
>> >> %{_libdir}/indicator-loader3
>> >> %{_libdir}/libdummy-indicator-blank.so
>> >> %{_libdir}/libdummy-indicator-entry-func.so
>> >> %{_libdir}/libdummy-indicator-null.so
>> >> %{_libdir}/libdummy-indicator-signaler.so
>> >> %{_libdir}/libdummy-indicator-simple.so
>> >> %{_libdir}/libdummy-indicator-visible.so
>> >>
>> >> #--------------------------------------------------------------------
>> >> %package -n %{libdevel}
>> >> Summary: libindicator3 development files
>> >> Group: Development/GNOME and GTK+
>> >> Requires: %{libname} >= %{version}
>> >
>> > Shouldn't this be "="?
>>
>> I think >= is better than just =
>
> i think we all use = for such a case, better to follow conventions on this. at
> least it would enforce the same version, (i also use mostly =
> %{version}-%{release} )
>
> if using this to build something it would theoretically allow disjoint
> versions of both lib and devel to be used for building a dependant app?
> (unsure)
>
> in any case, better safe than sorry.
>
>> >> %description -n %{libdevel}
>> >> Development files needed by libindicator3.
>> >>
>> >> %files -n %{libdevel}
>> >> %doc AUTHORS ChangeLog COPYING INSTALL
>> >> %{_includedir}/libindicator3-0.4/libindicator/
>> >> %{_libdir}/libindicator3.so
>> >> %{_libdir}/pkgconfig/indicator3-0.4.pc
>> >> %{_datadir}/libindicator/80indicator-debugging
>> >>
>> >> #--------------------------------------------------------------------
>> >> %prep
>> >> %setup -q
>> >>
>> >> %build
>> >> %configure \
>> >> --disable-static
>> >> %make
>> >>
>> >> %install
>> >> %makeinstall_std
>> >>
>> >> # Clean .la files
>> >> find %{buildroot}%{_libdir} -name '*.la' -delete -print
>> >>
>> >>
>> >> %changelog
>> >> * Sun Mar 18 2012 Simple <simplew8 at gmail.com> 0.4.93-1
>> >> - first package
>> >>
>> >>
>> >> virtualgl.spec
>> >>
>> >>
>> >> %define oname VirtualGL
>> >> %define libname %mklibname %{name}
>> >>
>> >> Name: virtualgl
>> >> Summary: A toolkit for displaying OpenGL applications to thin
>> >> clients Group: Networking/Other
>> >> Version: 2.3
>> >> Release: %mkrel 1
>> >> URL: http://www.virtualgl.org
>> >> License: wxWindows Library License v3.1
>> >
>> > Incorrect tag, see license policy as mentioned previously.
>> >
>> >> Source0:
>> >> http://prdownloads.sourceforge.net/virtualgl/%{oname}-%{version}.tar.g
>> >> z Patch0: vgl_2.3_patch0
>> >
>> > Please name this properly, and with a .patch extension.
>>
>> Again a typo...
>>
>> >> BuildRequires: X11-devel
>> >> BuildRequires: jpeg-devel
>> >> BuildRequires: cmake
>> >>
>> >>
>> >> %description
>> >> VirtualGL is a library which allows most Linux OpenGL applications to be
>> >> remotely displayed to a thin client without the need to alter the
>> >> applications in any way. VGL inserts itself into an application at run
>> >> time and intercepts a handful of GLX calls, which it reroutes to the
>> >> server's display (which presumably has a 3D accelerator attached.)
>> >> This causes all 3D rendering to occur on the server's display. As
>> >> each frame is rendered by the server, VirtualGL reads back the pixels
>> >> from the server's framebuffer and sends them to the client for
>> >> re-compositing into the appropriate X Window. VirtualGL can be used to
>> >> give hardware-accelerated 3D capabilities to VNC or other remote
>> >> display environments that lack GLX support. In a LAN environment, it
>> >> can also be used with its built-in motion-JPEG video delivery system to
>> >> remotely display full-screen 3D applications at 20+ frames/second.
>> >>
>> >> VirtualGL is based upon ideas presented in various academic papers on
>> >> this topic, including "A Generic Solution for Hardware-Accelerated
>> >> Remote Visualization" (Stegmaier, Magallon, Ertl 2002) and "A Framework
>> >> for Interactive Hardware Accelerated Remote 3D-Visualization" (Engel,
>> >> Sommer, Ertl 2000.)
>> >>
>> >> %files
>> >> %{_bindir}/*
>> >> %{_defaultdocdir}/%{name}/
>> >
>> > Mark docs as %doc.
>>
>> Correct, that also missed my attention.
>>
>> >> #--------------------------------------------------------------------
>> >> %package -n %libname
>> >> Summary: Libraries injected by VirtualGL into applications that are ran
>> >> through it Group: System/Libraries
>> >>
>> >> %description -n %libname
>> >> Libraries injected by VirtualGL into applications that are ran throught
>> >> it. Lib package allow installing 32 and 64 bits libraries at the same
>> >> time.
>> >>
>> >> %files -n %libname
>> >> %dir %{_libdir}/fakelib/
>> >> %{_libdir}/fakelib/libGL.so
>> >> %{_libdir}/librrfaker.so
>> >> %{_libdir}/libdlfaker.so
>> >> %{_libdir}/libgefaker.so
>> >
>> > This will need %_provides_exceptions or %_exclude_files_from_autoprov so
>> > that devel(GL) won't be provided. This would confuse the -devel
>> > dependencies of the distribution, and libvirtualgl could sometimes be
>> > installed when libmesagl-devel is intended.
>> >
>> >> #--------------------------------------------------------------------
>> >> %package devel
>> >> Summary: A toolkit for displaying OpenGL applications to thin
>> >> clients Group: Networking/Other
>> >> Requires: %{libname} >= %{version}
>> >
>> > Should be '=' AFAICS.
>> >
>> >> %description devel
>> >> VirtualGL is a library which allows most Linux OpenGL applications to be
>> >> remotely displayed to a thin client without the need to alter the
>> >> applications in any way. VGL inserts itself into an application at run
>> >> time and intercepts a handful of GLX calls, which it reroutes to the
>> >> server's display (which presumably has a 3D accelerator attached). This
>> >> causes all 3D rendering to occur on the server's display. As each frame
>> >> is rendered by the server, VirtualGL reads back the pixels from the
>> >> server's framebuffer and sends them to the client for re-compositing
>> >> into the appropriate X Window. VirtualGL can be used to give hardware-
>> >> -accelerated 3D capabilities to VNC or other remote display
>> >> environments that lack GLX support. In a LAN environment, it can also
>> >> be used with its built-in motion-JPEG video delivery system to remotely
>> >> display full-screen 3D applications at 20+ frames/second.
>> >> VirtualGL is based upon ideas presented in various academic papers on
>> >> this topic, including "A Generic Solution for Hardware-Accelerated
>> >> Remote Visualization" (Stegmaier, Magallon, Ertl 2002) and "A Framework
>> >> for Interactive Hardware Accelerated Remote 3D-Visualization" (Engel,
>> >> Sommer, Ertl 2000.)
>> >>
>> >> %files devel
>> >> %{_includedir}/rrtransport.h
>> >> %{_includedir}/rr.h
>> >>
>> >> #--------------------------------------------------------------------
>> >> %prep
>> >> %setup -qn %{oname}-%{version}
>> >> %patch0 -p1
>> >>
>> >> %build
>> >> cmake -G "Unix Makefiles" \
>> >> -DCMAKE_INSTALL_LIBDIR:PATH=%{_libdir} \
>> >> -DCMAKE_INSTALL_PREFIX=%{_prefix} \
>> >> -DVGL_DOCDIR=%{_defaultdocdir}/%{name} \
>> >> -DVGL_LIBDIR=%{_libdir} \
>> >> -DTJPEG_INCLUDE_DIR=%{_includedir} \
>> >> -DTJPEG_LIBRARY=%{_libdir}/libturbojpeg.so
>> >
>> > Should use %cmake.
>>
>> In this case that is not possible, i did tried %cmake but fails.
>
> iinm you can also add extra option to %cmake. if it's possible it'd be nice to
> have %cmake in it. if there would be systemwide changes at a later time,
> possibly due to changed newer cmake behavior, or whatever, it can be picked up
> without much effort.
>
> also it looks better to me, having all cmake packages using %cmake :-)
Did you read what i wrote?
i did tried to use %cmake but build fails, so its really need to use
it explicitely like its currently, and the same goes for when i did
not used %makeinstall_std in libbsd.
>> >> %make
>> >>
>> >> %install
>> >> rm -rf %{buildroot}
>> >> %makeinstall_std
>> >>
>> >> rm -rf %{buildroot}%{_prefix}/fakelib
>> >> mkdir -p %{buildroot}%{_libdir}/fakelib
>> >> ln -sf ../librrfaker.so %{buildroot}%{_libdir}/fakelib/libGL.so
>> >> mv -f %{buildroot}%{_bindir}/glxinfo %{buildroot}%{_bindir}/glxinfo2
>> >>
>> >>
>> >> %changelog
>> >> * Mon Mar 19 2012 Simple <simplew8 at gmail.com> 2.3-1
>> >> - first package
>
> you likely know this, but for first import we keep older changelog, but in
> general no %changelog is wanted. the commits used for the svn, will be used as
> %changelog automatically, so having this here would give double changelog.
Yeap, thanks for the hints.
>> > --
>> > Anssi Hannula
More information about the Mageia-dev
mailing list