Bugzilla Bug 188477

Version 2.2.0 has been released.

Created an attachment (id=127854) [details]
Modification of the 2.0.3 ebuild to install Bacula 2.2.0 and add support for
BAT GUI

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 an attachment (id=127855) [details]
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 an attachment (id=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] 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 an attachment (id=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 ;-)