[Mageia-dev] bumblebee in mageia (and mentoring)

Tue Apr 10 21:12:53 CEST 2012

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.
+
+> >> %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.
+
+> >> %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
+
+> >> %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 :-)
+
+> >> %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.
+
+> > --
+> > Anssi Hannula
+