From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/2012-April/014106.html | 905 ++++++++++++++++++++++++++++++ 1 file changed, 905 insertions(+) create mode 100644 zarb-ml/mageia-dev/2012-April/014106.html (limited to 'zarb-ml/mageia-dev/2012-April/014106.html') diff --git a/zarb-ml/mageia-dev/2012-April/014106.html b/zarb-ml/mageia-dev/2012-April/014106.html new file mode 100644 index 000000000..2d8136fc0 --- /dev/null +++ b/zarb-ml/mageia-dev/2012-April/014106.html @@ -0,0 +1,905 @@ + + + + [Mageia-dev] bumblebee in mageia (and mentoring) + + + + + + + + + +

[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
+ -- cgit v1.2.1