Version 2.2.0 has been released.
Created attachment 127854 [details] Modification of the 2.0.3 ebuild to install Bacula 2.2.0 and add support for BAT GUI Save file as 'bacula-2.2.0.ebuild' in /usr/portage/app-backup/bacula/ Modified 2.0.3 ebuild to install Bacula 2.2.0. Tested by installing the file daemon, storage daemon, director and bat gui while using a MySQL backend. Other database backends are untested (but as they are similar to 2.0.3 they should still work). Documentation untested. Needed path will be posted next. Please note that I have included some messages/spam in the ebuild as this one is posted on the bacula-devel list as well.
Created attachment 127855 [details, diff] Patch to change the paths in Bacula 2.2.0 for Gentoo standards Needed patch for attachment 127854 [details]. Please put bacula-2.2.0-default-configs.patch in app-backup/bacula/files Note on attachment 127854 [details]: put this ebuild in app-backup/bacula/
For the testers who might not know this: After inserting the ebuild and patch file in the right place, run 'ebuild bacula-2.2.0.ebuild digest' in /usr/portage/app-backup/bacula to enable the ebuild (and prevent errors in emerge). Note: bacula-2.2.0.ebuild is not masked as this ebuild installs fine on all my testing systems. When inserted into Portage officially it might be a good idea to mask it for a while and unmask after a month or so if it installs fine everywhere. Note: according to the development team, this version is tested in production environments longer and better than any other version and as it fixes some potential (security) problems it is recommended to stabilize ASAP.
Last instruction: copy the 2.0.3 folder and name it 2.2.0 (all scripts can be reused AFAIK). It can be found in /usr/portage/app-backup/bacula/files/
This and the old ebuild USE flag seems a bit funky. USE="gnome" emerge bacula Has no effect. USE="gnome bacula-console" emerge bacula Now you get gnome-console Is this really okay behavior? Otherwise this 2.2.0 ebuild seems fine.
(In reply to comment #5) > Otherwise this 2.2.0 ebuild seems fine. I take that back, bacula make doesn't break on errors, so at first it looked fine. I'll do a better bug report on it in a few, but it seems bacula depends on qwt compiled against qt4, but as far as I can tell qwt in Gentoo is qt3 based. That silently breaks bacula-bat.
(In reply to comment #6) > I'll do a better bug report on it in a few, but it seems bacula depends on qwt > compiled against qt4, but as far as I can tell qwt in Gentoo is qt3 based. All I got is that qt on my system is compiled without qmemarray.h and that breaks qt-console in Bacula 2.2.0. I don't even know if qt-console is actually used for anything, so I think my time is better of elsewhere, hope someone else has the time and/or experience to clean it up. The ebuild seems to need improvements in it's use flag handling and Bacula really need someone who cares to maintain an ebuild for it, it seems fairly tricky, otherwise this seems like a lost cause with nothing but kinda working ebuilds in the future.
(In reply to comment #7) > (In reply to comment #6) > > I'll do a better bug report on it in a few, but it seems bacula depends on qwt > > compiled against qt4, but as far as I can tell qwt in Gentoo is qt3 based. Possible but on my testing system (which i used on kde4 so i had everything up and running) everything worked fine. > All I got is that qt on my system is compiled without qmemarray.h and that > breaks qt-console in Bacula 2.2.0. See my comment above - with some research it should be possible to get this fixed. > I don't even know if qt-console is actually used for anything, so I think my > time is better of elsewhere, hope someone else has the time and/or experience > to clean it up. Kern Sibbald (the main dev) once came up with this funcky naming scheme but they had a discussion on the dev list about renaming the directories. Rather I think we could rename the use flags to match the application name while the configure script still uses the old funky names. On a side note: qt-console is the code name for BAT: the new gui for bacula and this time its a proper gui with graphs and graphical stuff for loads of things. The other 'guis' don't deserve their title in my opinion for the simple reason that in fact they are not more than graphical shells on top of the console - providing the same functionality as the text based console... In short - BAT should be properly supported imho. > The ebuild seems to need improvements in it's use flag handling and Bacula > really need someone who cares to maintain an ebuild for it, it seems fairly > tricky, otherwise this seems like a lost cause with nothing but kinda working > ebuilds in the future. I'm sort of working on it. Next weekend 2.2.1 will be released. This has some minor bug fixes which are important for stable usage (even though I had no problems in a production evironment with 2.2.0). I will try to address the use flag issues and the qt4 + qwt problems. On a side note: this is my first ebuild ever and even though I have a faint idea of what I am doing, can someone point me to some documentation on how ebuilds are being put together? Reverse engineering gets tiresome real fast...
The ebuild is working for me with 2.2.1, too. Although I'm not using BAT, so I can't say anything about the qt/qwt problem :).
2.2.2 working for me with this ebuild, including bat, with >=x11-libs/qwt-5
2.2.1 working but needs >=x11-libs/qwt-5 and as qwt is slotted version <x11-libs/qwt-5 need to be prohibited as when it is installed bat searches for qwt header files in /usr/include/qwt where are located f.ex. 4.2 version files and then crashes.
Bacula version 2.2.3 was released on Sept 10, 2007 primarily to fix a serious bug with restoration. See: http://sourceforge.net/project/shownotes.php?group_id=50727&release_id=538524 for details. It would be wise to wait for a bit then add this version to portage.
Created attachment 130768 [details] app-backup/bacula/bacula-2.2.3.ebuild Updated ebuild, includes DEPEND >=x11-libs/qwt-5 and RDEPEND !<x11-libs/qwt-5 for bat. To re-iterate previous instructions: - Download attachment 127855 [details, diff] and save as app-backup/bacula/files/bacula-2.2.3-default-configs.patch - Copy app-backup/bacula/files/2.0.3 to app-backup/bacula/files/2.2.3 - Build digest - Merge Solid for me so far on x86 and amd64.
And working for 2.2.4
Note that a serious restoration bug is present in 2.0.3. I am not aware of any patches for 2.0.x, but this bug was fixed in 2.2.3 as mentioned. This should influence the severity of this bugzilla bug, right? Now, as there are two weeks since 2.2.3 and a new 2.2.4 is out, I think it is a good time to include the new ebuild.
(In reply to comment #15) > Note that a serious restoration bug is present in 2.0.3. I am not aware of any > patches for 2.0.x, but this bug was fixed in 2.2.3 as mentioned. This should > influence the severity of this bugzilla bug, right? Now, as there are two weeks > since 2.2.3 and a new 2.2.4 is out, I think it is a good time to include the > new ebuild. > There is an untested, partial fix for the 2.0.x tree but as the fix might create new issues in the 2.0.x branch, it was decided to remove the 2.0.x branch from SF as users should upgrade to 2.2.x for the latest fixes anyways (note that new features were added but a 2.0.x can be replaced with 2.2.x without changing any configs or other modifications). It looks like 2.2.4 is pretty stable. It runs for me on amd64 and x86 on multiple servers for a while now.
Created attachment 132430 [details] app-backup/bacula/bacula-2.2.4.ebuild Minor update - fowners root:bacula on /var/libexec/bacula/* to ensure that the daemons can execute the scripts there. Other than that, rock solid on x86 and amd64 since 20070919 under various scenarios...
2.2.4 is in CVS now. I had to remove sparc, ppc and hppa from KEYWORDS for now due to =x11-libs/qwt-5* KEYWORDS missing those, thus repoman complaining about DEPEND. Sorry, I haven't found a saner solution for that yet.
Great stuff, thanks Wolfram... incidentally, 2.2.5 was released today, I will test and report back when everything works.
(In reply to comment #19) > Great stuff, thanks Wolfram... incidentally, 2.2.5 was released today, I will > test and report back when everything works. Oh, I just committed 2.2.5 a minute ago ;-)
