Bug 827167 - Review Request: bumblebee - Bumblebee daemon
Summary: Review Request: bumblebee - Bumblebee daemon
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nobody's working on this, feel free to take it
QA Contact: Fedora Extras Quality Assurance
Depends On: 834127
TreeView+ depends on / blocked
Reported: 2012-05-31 19:40 UTC by Gary Gatling
Modified: 2017-02-06 21:42 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2017-02-06 21:42:52 UTC
Type: ---
projects.rg: fedora-review-

Attachments (Terms of Use)
fixes bug with race condition (606 bytes, patch)
2013-02-08 05:24 UTC, Gary Gatling
no flags Details | Diff

Description Gary Gatling 2012-05-31 19:40:06 UTC
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
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

For more information.

Fedora Account System Username:gsgatlin

This is my first package and I need a sponsor.

Comment 1 Brendan Jones 2012-06-01 12:56:47 UTC
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

Comment 2 Mohamed El Morabity 2012-06-01 13:06:54 UTC
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.

Comment 3 Gary Gatling 2012-06-01 15:04:20 UTC

Thank you for your consideration. I have placed the spec file as it is now at:


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.

Comment 4 Brendan Jones 2012-06-01 15:37:44 UTC
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?

Comment 5 Robin Lee 2012-06-04 02:52:01 UTC
I made a specfile file for VirtualGL months ago:

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.

Comment 6 Gary Gatling 2012-06-06 09:39:31 UTC
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.

Comment 7 Gary Gatling 2012-06-09 22:56:30 UTC
Stupid question...

How can I redifine:


so that -fstack-protector is not included on 32 bit rhel 6? Nothing I am trying is working...


%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}"


%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.

Comment 8 Brendan Jones 2012-06-09 23:44:44 UTC
Look here: http://fedoraproject.org/wiki/Packaging:DistTag#Conditionals

You could try something like

%ifarch x86
%define nostack %{?el6: -fno-stack-protector}

CFLAGS="%optflags %{?nostack}"

Comment 9 Gary Gatling 2012-06-10 02:36:44 UTC
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


%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}
%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}"
make %{?_smp_mflags}

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.

Comment 10 Brendan Jones 2012-06-10 06:10:53 UTC
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|'`

Comment 11 Gary Gatling 2012-06-10 22:24:28 UTC
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.

Comment 12 Gary Gatling 2012-06-20 22:40:08 UTC
OK. VirtualGL added as review request at:


Again, thanks so much Robin!

Comment 13 Matthias Runge 2012-06-21 09:23:44 UTC
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

Comment 14 Laurent Boualit 2012-07-04 15:34:29 UTC
Hi, someone is working on this here http://downloads.aelys-info.net/fedora/

Comment 15 Gary Gatling 2012-07-04 16:05:59 UTC
Hi Laurent,

Check out:


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. :)


Comment 16 Gary Gatling 2012-08-06 15:02:29 UTC
Greetings, Attempt #3 at a package.



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.

Comment 18 Gary Gatling 2013-02-08 05:22:57 UTC


Adds patch for issues with kernel 3.7.6-202. See:


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.

Comment 19 Gary Gatling 2013-02-08 05:24:35 UTC
Created attachment 694937 [details]
fixes bug with race condition

Comment 20 Gary Gatling 2013-02-26 18:55:12 UTC
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/SRPMS/	bumblebee-3.1-1.fc18.src.rpm

Thanks for your consideration.

Comment 21 Christopher Meng 2013-05-21 10:28:05 UTC
Any news here?

Comment 22 Björn 'besser82' Esser 2013-05-21 10:53:33 UTC
Since I currently have some reviews running, I'll take care of this one here maybe on next week or so...

Comment 23 Gary Gatling 2013-05-21 13:32:59 UTC
Hello. Thank you. Here is the newest (current) version of the software I made a package for.



Unfortunately, it (or any older versions) doesn't work with the nouveau driver due to issue 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,

Comment 24 Christopher Meng 2013-07-18 03:13:33 UTC

1. You shouldn't mark manpages as %doc

2. RPM supports systemd macro, which can make your spec more clear.


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.

Comment 25 Christopher Meng 2013-07-18 03:13:33 UTC

1. You shouldn't mark manpages as %doc

2. RPM supports systemd macro, which can make your spec more clear.


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.

Comment 26 Gary Gatling 2013-07-24 16:01:39 UTC

Thanks so much for taking the time to review my package. Here is another attempt at fixing the problems with it:




Comment 27 Christopher Meng 2013-07-25 01:27:22 UTC
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?

Comment 28 Gary Gatling 2013-07-29 02:51:12 UTC
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 || : 

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.

Comment 29 Gary Gatling 2013-07-29 17:30:23 UTC
Hello. Here is the newest version I worked on.



Notice the 

#%systemd_post bumblebeed.service

I had to comment out and the lines:

/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 


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.

Comment 30 Upstream Release Monitoring 2015-09-24 15:04:20 UTC
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

Comment 31 Ben Rosser 2016-06-01 03:34:40 UTC
Hey, are you still interested in getting bumblebee into Fedora?

I would be happy to review bumblebee packages as needed.

Comment 32 Gary Gatling 2016-06-01 04:36:31 UTC
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:


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.

Comment 33 Ben Rosser 2016-06-01 16:03:48 UTC
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).

Comment 34 Raphael Groner 2017-02-06 21:42:52 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.