Spec URL: http://pastebin.com/mHPT2T6n SRPM URL: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/bumblebee-3.0.0-1.fc17.src.rpm Description: Bumblebee daemon Bumblebee daemon is a rewrite of the original Bumblebee (https://github.com/Bumblebee-Project/Bumblebee-old) 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. See: https://github.com/Bumblebee-Project/Bumblebee http://bumblebee-project.org/ For more information. Fedora Account System Username:gsgatlin This is my first package and I need a sponsor.
Hi Gary I'm no sponsor, but I do have this hardware so happy to help out where I can. You'll need to package VirtualGL first. A few quick recommendations on the SPEC - use macros whereever possible ie. %name.conf %name. for bumblebee - drop GNU from the license - move the URL from the description to the URL tag e.g. URL: http://%{name}-project.org/ - align all your tags as the previous example for readablity - use %{optflags} in place of the CFLAGS you've specified - %{sysconfigdir} for /etc %{prefix} for /usr %{_libdir|, %{_bindir} etc whereerver possible http://fedoraproject.org/wiki/Packaging:RPMMacros - create a Source1: for your sysv init script - %clean is only required for EPEL5, similarly rm -rf in %install section, if you do not intend to build for EPEL5 reomve them - %defattr no longer required
Is it possible to get the .spec file elsewhere than from pastebin? For example on the server where you put your packages. Having a direct link on it may be easier for those who want to review your work... Especially when pastebin and such are blocked from work.
Hello, Thank you for your consideration. I have placed the spec file as it is now at: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/bumblebee.spec to make it easier to read. I will work this weekend to make the changes suggested by Brendan. Thank you for all the suggestions. One problem I am having is that the VirtualGL rpm that was packaged by PUIAS Linux or the package made by http://www.virtualgl.org/ will not build without a older libjpeg-turbo-1.1.1-1.1 (also from PUIAS Linux) installed. The problem was that VirtualGL wants a libturbojpeg.a in the building process... Perhaps I should wait a while before this could be accepted and work more on the VirtualGL problem? Perhaps I could make a libjpeg-turbo-1.1.1-1.1 that installs in /opt or some other place just to get VirtualGL to compile? Or is that a bad idea? The libjpeg-turbo that comes with fedora 17 doesn't have a libturbojpeg.a in libjpeg-turbo-static and if you make a symlink it still won't compile. :( The sources to the VirtualGL I was using are in that same directory but to build it I had to use rpm -Uvh --oldpackage libjpeg-turbo-1.1.1-1.1* and I know that would not be cool. Also, bumblebee doesn't even use "libjpeg-turbo" but I couldn't figure out how to build VirtualGL without that. Sorry about these issues.
I wouldn't spend to much time on this until you can build VirtualGL first. Perhaps you could patch VirtualGL to use the version that is Fedora and submit it upstream?
I made a specfile file for VirtualGL months ago: http://cheeselee.fedorapeople.org/VirtualGL.spec The %build section is simply: %cmake -DTJPEG_INCLUDE_DIR=%{_includedir} \ -DTJPEG_LIBRARY=%{_libdir}/libturbojpeg.so \ -DVGL_USESSL=ON -DVGL_LIBDIR=%{_libdir} \ -DVGL_DOCDIR=%{_docdir}/%{name}-%{version}/ \ -DVGL_FAKELIBDIR=%{_libdir}/fakelib/ . make %{?_smp_mflags} Then VirtualGL will link with libturbojpeg. I don't have time to test VirtualGL a little more at this moment. Feel free to submit review request of VirtualGL based on my specfile.
Robin, Thanks so much for all your help! I was not expecting this to be so pain free. I have the new VirtualGL rpms built for fedora 17, 16, 15 and RHEL 6 and in my test repo. I am testing it on my main system today (rhel 6) and will test further on the various fedoras later today and tomorrow. It builds great and I will submit it as a review request as soon as I finish testing it and I can contact the VirtualGL developers like I did the bumblebee folks. I'm still working on implementing the changes that Brendan suggested. I should have something to post up here soon after I get the VirtualGL stuff worked out.
Stupid question... How can I redifine: %{optflags} so that -fstack-protector is not included on 32 bit rhel 6? Nothing I am trying is working... Like: %define optflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables make %{?_smp_mflags} CFLAGS="%{optflags}" or %define __global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables make %{?_smp_mflags} CFLAGS="%{optflags}" still doesn't work. It compiles a buggy binary with -fstack-protector on rhel 6 32 bit. only with: make %{?_smp_mflags} CFLAGS="-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables" does it build correctly. Any help greatly appriciated as this is my first package.
Look here: http://fedoraproject.org/wiki/Packaging:DistTag#Conditionals You could try something like %ifarch x86 %define nostack %{?el6: -fno-stack-protector} %endif CFLAGS="%optflags %{?nostack}"
Thank you so much. This got me in the right direction. Through trial and error this seems to be the thing that works. If you leave out %define __global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables It does -fstack-protector and -fno-stack-protector in the same line which seems wrong. Also, this bug should affect older fedoras on 32 bit as well as rhel6. Also, I had to use %ifarch i686 becuase %ifarch x86 did not work with my rhel6 build area. So I went with the following: %ifarch i686 %if 0%{?fedora} >=15 make %{?_smp_mflags} %else %define __global_cflags -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 %define nostack -fno-stack-protector make %{?_smp_mflags} CFLAGS="%{optflags} %{?nostack}" %endif %else make %{?_smp_mflags} %endif Which seems to do the right thing on all platforms. I am continuing to work on fixing the specfile and should have something to post soon.
epel6 is what you use for building on RHEL. You can test it using mock or koji build --scratch dist-6E-epel some-package-srpm You still need to pass %optflags to all your other make lines I wouldn't concern your self with Fedora 15 - its reaching ending of life right now and no more builds are being accepted for it in Fedora. the -fno-stack-protector is correct - GC gives the last option precendence. This also works but I think is a little messy: CFLAGS=`echo %{optflags}|sed -e 's|-fstack-protector|-fno-stack-protector|'`
Hello. This is attempt #2. SRPM: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/bumblebee-3.0.0-2.fc17.src.rpm Specfile: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/2/bumblebee.spec This also fixes a problem with the manpages being left off that I missed before. Thanks a lot.
OK. VirtualGL added as review request at: https://bugzilla.redhat.com/show_bug.cgi?id=834127 Again, thanks so much Robin!
Hey Gary, in order to get sponsored, you should show, you're familiar with the packaging guidelines. Easiest way is to do some informal reviews as mentioned [1] and link them e.g. here. A potential sponsor can use this as easy reference, but esp. this may differ from sponsor to sponsor. [1] http://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Reviewing_packages
Hi, someone is working on this here http://downloads.aelys-info.net/fedora/
Hi Laurent, Check out: http://techies.ncsu.edu/wiki/bumblebee Feel free to use any of those packages/specs at that aelys project. That is my test repo and early attempt at documentation. I am hoping to work some on bumblebee and VirtualGL spec files some today on my day off. :) Cheers,
Greetings, Attempt #3 at a package. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/3/bumblebee.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/bumblebee-3.0.0-3.fc17.src.rpm I got rid of conditional build stuff since the stack smashing is a real bug. Instead there is a patch now for that. I still get warnings with rpmlint but I think they are ok to ignore? bumblebee.x86_64: W: only-non-binary-in-usr-lib I think this is ok becuase of https://bugzilla.redhat.com/show_bug.cgi?id=794777 If this is in fact a problem, does anyone know of a workaround for a unit-file? bumblebee.x86_64: W: no-manual-page-for-binary bumblebee-bugreport Yeah, they didn't provide a man page for this binary upstream. bumblebee.x86_64: W: dangerous-command-in-%trigger ln bumblebee.x86_64: W: dangerous-command-in-%trigger ln My understanding is that this is the proper way to do what I'm trying to do... I need to change where a symlink points, but only if another package: bumblebee-nvidia is installed. So thats why I used triggers. If there is a better way to do this does anyone know what it is? 1 packages and 0 specfiles checked; 0 errors, 4 warnings. Kind of stuck on things with VirtualGL but I did want to fix the problems this bumblebee package has. Further suggestions welcome.
http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/4/bumblebee.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/SRPMS/bumblebee-3.0.1-1.fc17.src.rpm Update bumblebee package and specfile to version 3.0.1.
http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora17/spec/5/bumblebee.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/SRPMS/bumblebee-3.0.1-2.fc18.src.rpm Adds patch for issues with kernel 3.7.6-202. See: https://github.com/Bumblebee-Project/Bumblebee/issues/283 for a discussion on the issue this patch fixes. Special thanks to Theodore Lee for doing all the work on this issue with the newest kernel in fedora and also for fixing the missing BuildRequires for autoconf, automake, and libX11-devel.
Created attachment 694937 [details] fixes bug with race condition
Here is attempt #4 at a package. This is the new version, 3.1. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/spec/2/bumblebee.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/SRPMS/ bumblebee-3.1-1.fc18.src.rpm Thanks for your consideration.
Any news here?
Since I currently have some reviews running, I'll take care of this one here maybe on next week or so...
Hello. Thank you. Here is the newest (current) version of the software I made a package for. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/spec/1/bumblebee.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora18/SRPMS/bumblebee-3.2.1-1.fc18.src.rpm Unfortunately, it (or any older versions) doesn't work with the nouveau driver due to issue 298. https://github.com/Bumblebee-Project/Bumblebee/issues/298 bumblebee does seem to work still with the closed source nvidia drivers. Waiting to hear back from the bumblebee developers (in that issue) on whether PRIME could be what is making it not work. So far no one has been able to figure it out. :( (I opened the bug at github when fedora 18 was still in beta...) Maybe someone looking at this bugzilla might be able to figure it out if they are hard core into graphics technology? I can't figure it out sadly. Seems to also be broken in the fedora 19 alpha and recently in fedora 17 as well. Cheers,
Issues: 1. You shouldn't mark manpages as %doc 2. RPM supports systemd macro, which can make your spec more clear. http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd 3. You should remove buildroot tag. 4. These lines: mv $RPM_BUILD_DIR/%{name}-%{version}/configure.ac $RPM_BUILD_DIR/%{name}-%{version}/configure-fix.ac sed -e "s|2.68|2.63|g" $RPM_BUILD_DIR/%{name}-%{version}/configure-fix.ac > $RPM_BUILD_DIR/%{name}-%{version}/configure.ac Well, why not using this: sed -e "s|2.68|2.63|g" configure.ac 5. This line: install -m 755 $RPM_BUILD_DIR/%{name}-%{version}/bumblebeed.svinit $RPM_BUILD_ROOT/%{_initddir}/bumblebeed should be install -pm 755 $RPM_BUILD_DIR/%{name}-%{version}/bumblebeed.svinit $RPM_BUILD_ROOT/%{_initddir}/bumblebeed 6. This line: install -m 644 $RPM_BUILD_DIR/%{name}-%{version}/scripts/systemd/bumblebeed.service $RPM_BUILD_ROOT/%{_unitdir}/ Why not using install -pm 644 scripts/systemd/bumblebeed.service $RPM_BUILD_ROOT/%{_unitdir}/ 7. And this: cp $RPM_BUILD_DIR/%{name}-%{version}/conf/%{name}.conf $RPM_BUILD_ROOT/%{_sysconfdir}/bumblebee/%{name}-nouveau.conf Why not cp conf/%{name}.conf $RPM_BUILD_ROOT/%{_sysconfdir}/bumblebee/%{name}-nouveau.conf As you can see there are many such lines, I don't know why you waste a lot of lines...I hope all lines with RPM_BUILD_DIR should be modified.
Christopher, Thanks so much for taking the time to review my package. Here is another attempt at fixing the problems with it: http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora19/spec/1/bumblebee.spec http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora19/SRPMS/bumblebee-3.2.1-2.fc19.src.rpm Cheers,
I think you don't have to include f17 systemd scripts as now is 19 and 17 is EOL. Besides it's a pain to read so many shell scripts ;) Another issue is : bumblebee.i686: E: zero-length /etc/bumblebee/xorg.conf.d/10-dummy.conf Why is it zero-length?
Hello. Using systemd macros I cannot get this to work correctly. The problem seems to be with this command: if [ $1 -eq 1 ] ; then # Initial installation /usr/bin/systemctl preset bumblebeed.service >/dev/null 2>&1 || : fi Which I think is expanded from "%systemd_post bumblebeed.service" After I install the package, the bumblebeed service is not running and I have to start it by hand every time I wish to use my nvidia graphics card with the following command: [root@localhost ~]# systemctl start bumblebeed.service I need for this service to be enabled and running by default after it is installed so I don't have to do that. How do I do that using approved of methods? Is there some other daemon that also includes upstart and systemd init scripts I could look at as an example? Is there a centralized list of services that bumblebeed need to be added to to make it auto startup? Thank you for your time and consideration.
Hello. Here is the newest version I worked on. http://install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora19/spec/2/bumblebee.spec install.linux.ncsu.edu/pub/yum/itecs/public/bumblebee/fedora19/spec/package/bumblebee-3.2.1-4.fc19.src.rpm Notice the #%else #%systemd_post bumblebeed.service I had to comment out and the lines: %else /bin/systemctl daemon-reload >/dev/null 2>&1 || : /bin/systemctl enable bumblebeed.service >/dev/null 2>&1 || : /bin/systemctl start bumblebeed.service >/dev/null 2>&1 || : I had to add back in to get it to auto start again. Any advice for correctly using the systemd macros would be greatly appreciated if this needs to change? :) As for /etc/bumblebee/xorg.conf.d/10-dummy.conf I was told on IRC by one of the developers that: 01:00:20 AM) amonakov: gsgatlin: to make sure Xorg accepts the directory as a xorg.conf.d directory. when I was reading the code, I got the impression that if the dir was empty, the option would be ignored. So that is why that particular file is being created. Because of Xorg. Hope that helps explain it. Please let me know if there are any changes I would need to make. Thanks a lot.
jgrulich's scratch build of kdevelop?#c8e2b9bc57f11e41f3dc6612cdbcc591078d9062 for f22-candidate and git://pkgs.fedoraproject.org/kdevelop?#c8e2b9bc57f11e41f3dc6612cdbcc591078d9062 completed http://koji.fedoraproject.org/koji/taskinfo?taskID=11212117
Hey, are you still interested in getting bumblebee into Fedora? I would be happy to review bumblebee packages as needed.
I will try to upload the current version + spec file to the website tomorrow and test Nouveau support to see if it still works in fedora 24. If it doesn't work I feel I can get it working again pretty easily. But also, see this thread: https://github.com/Bumblebee-Project/Bumblebee/issues/773 So it may no longer be appropriate for the fedora distribution? I can try to get clarification from the developers in that issue on github.com. Thanks for your kind offer to review this package. I'll update this ticket when everything is in place tomorrow and I'll try to get clarification about the future of Nouveau support.
Oh, I see. Yes, if the nouveau support in bumblebee is going to be removed and all that's left is bumblebee-nvidia, Fedora proper would not be able to package that. (As a user of systems with hybrid Nvidia graphics, I think that'd be a bit unfortunate, but oh well. The runtime power management stuff on the linked wiki page did not just work out of the box for me on a fresh Fedora installation, but I also didn't put much time into trying to debug it and just installed bumblebee+bbswitch instead).
bumblebee is already on the RPMFusion whislist. We've obviously to close here. Nouveau only does not seem to be the right option. > Why not in Fedora: Fedora does not support the proprietary Nvidia drivers. https://rpmfusion.org/Wishlist