Spec URL: http://home.bawue.de/~ixs/bacula/bacula.spec SRPM URL: http://home.bawue.de/~ixs/bacula/bacula-2.0.2-2.el5.src.rpm Unpacked SRPM: http://home.bawue.de/~ixs/bacula/ Description: Bacula is a set of programs that allow you to manage the backup, recovery, and verification of computer data across a network of different computers. It is based on a client/server architecture and is efficient and relatively easy to use, while offering many advanced storage management features that make it easy to find and recover lost or damaged files. Please do keep in mind, this is just a preliminary submission. There are still going to besome minor changes in the initscripts and some file locations might be changed a bit. However, this is in general the package I'll finally submit in a few days but put in here already so mmcgrath can take a look at it already.
Running "alternatives" in the init-scripts to get the database backend must be done with LANG=C or the grep in the pipe will find nothing on non-english locales.
I'm glad to see that, unlike upstream, you've split the storage daemon off from the director package. I can't look at this in detail at the moment as I'm very busy with $DAYJOB but I'll keep an eye on this ticket and will hopefully be able to comment more later on.
[Tue Mar 06 18:05:00 2007] [error] [client 127.0.0.1] PHP Fatal error: Smarty error: unable to write to $compile_dir '/usr/share/bacula-web/templates_c'. Be sure $compile_dir is writable by the web server user. in /usr/share/bacula-web/external_packages/smarty/Smarty.class.php on line 1088 Need to make sure apache can write to that dir
(In reply to comment #3) > [Tue Mar 06 18:05:00 2007] [error] [client 127.0.0.1] PHP Fatal error: Smarty > error: unable to write to $compile_dir '/usr/share/bacula-web/templates_c'. Be > sure $compile_dir is writable by the web server user. > in /usr/share/bacula-web/external_packages/smarty/Smarty.class.php on line > 1088 > > > Need to make sure apache can write to that dir A couple of comments on that: 1. Smarty is availanle in Extras (php-Smarty), so the version in Extras should be used instead of the bundled version. 2. It shouldn't be writing anything under /usr; I suggest creating /var/cache/bacula-web and making /usr/share/bacula-web/templates_c a symlink to it; /var/cache/bacula-web should be writable by apache and will need an SELinux context type of httpd_cache_t.
The changelog dates are wrong (unless you did use a time machine). Before adding the package to Fedora, please update the version number to 2.0.3 as this release fixed a dataloss bug when using the new encryption mechanisms.
Thanks for the comments so far. I've been to cebit in germany the last week, so there was no time to work on the package. Sorry for that. Thanks for the suggestion handling the web-package. I think putting the data to /var is actually a good idea but this is best handled not with a symlink but by changing the location in the code. Using the system-wide smarty package is certainly a good idea. And about the dates in the changelog, yeah, they are wrong. :D It's 2007 and not 2006. This has been fixed in the meantime, but I did not update the package on the web yet.
It looks like that no subpackage creates the directory /var/log/bacula and that makes logrotate to fail there.
Another issue I see in using generic names for executables as gnome-console and wxconsole. They should probably use something like bac-foo or bacula-foo and this should be also moved upstream.
Any updates available?
Mostly research up to mid-April. Lately I started on a new spec file, for various reasons... 1. Comment #5 but no update made for 2.0,3, 2. IMO, bacula-docs should be a package on it's own, 3, Trying to understand why the bacula-storage-<database> packages exist, and 4. For my own spec file practice. Went through a couple rounds with mach build. It still needs work. though I hope to have it in decent shape in a few days.
What happend to Andreas Thienemanns work? According to #6 he did some internal improvements. Jerry, do have access to these improvements? Furthermore, Andreas' spec file looks quite good, so only minor updates (and maybe some extensions) are needed IMHO. Updating to 2.0.3 should be trivial. bacula-storage is split up into multiple packages due to different database backends. The package contains bcopy and btape which are linked against specific database libraries.
Well, I do not know what happened to my specfile, I also have no idea who Jerry is and why he is creating a new specfile from scratch. Anyway, be that as it may, there's an updated bacula package at <http://home.bawue.de/~ixs/bacula/bacula-2.0.3-2.el5.src.rpm> or the spec at <http://home.bawue.de/~ixs/bacula/bacula.spec>. Take a look, it's basically finished and I'd like to see some last comments before I'll ask for a review.
(In reply to comment #12) > Well, I do not know what happened to my specfile, I also have no idea who Jerry > is and why he is creating a new specfile from scratch. I'm Jerry, and I'm also sorry! I didn't mean to step on toes. But there'd been little activity lately, and I get nervous when mmcgrath bumps the severity to medium! :-) Anyway, thank you for the updated package... I also see the reason for bacula-storage, so my mumbling in Comment #10 can be ignored.
(In reply to comment #13) Hi Jerry :-D Don't worry, you are free to work on the bacula.spec as long as you wish. No toes to step on. :D I was just trying to answer Felix's question. *g*
There's a minor difference with 2.0.3-verify.patch - please refresh from sf.net for the next round.
(In reply to comment #15) > There's a minor difference with 2.0.3-verify.patch - please refresh from > sf.net for the next round. Nope. The patch from sf.net will not apply as the first hunk fails. As it's just a change in the copyright comments at th start of the file, I removed hunk 1.
Just a quick note, I've removed Jerry as the bug assignee as he is not sponsored into cvsextras (https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsextras&format=html)
Please re-consider not using fedora-usermgmt as it makes the SRPM and RPMs incompatible with any other distribution.
i second not using fedora-usermgmt
Also /var/spool/bacula/log should be moved to /var/log/bacula/ with a logrotate (if bacula does not already do a log rotation)
The database backend for the SD is not correctly detected if one uses a locale other than LANG=C. I had to do a 'export LANG=C' before the alternatives-line in /etc/init.d/bacula-sd
(In reply to comment #21) > The database backend for the SD is not correctly detected if one uses a locale > other than LANG=C. I had to do a 'export LANG=C' before the alternatives-line in > /etc/init.d/bacula-sd already found, see #1 :-)
Ok, next time I read all the comments before posting ;-) Just a side note: the release announced in comment #12 (bacula-2.0.3-2.el5.src.rpm) still has the locale problem mentioned in comment #1. The script /usr/libexec/bacula/make_catalog_backup only works for the mysql-backend. It should be rewritten to use the alternatives system. I have installed the following director packages: rpm -qa | grep bacula-dir bacula-director-common-2.0.3-2.fc7 bacula-director-postgresql-2.0.3-2.fc7 I had to edit make_catalog_backup to make it work for postgresql.
(In reply to comment #18) > Please re-consider not using fedora-usermgmt as it makes the SRPM and RPMs > incompatible with any other distribution. I like fedora-usermgmt as it provides some additional possibilites for administrators and this should become a Fedora RPM (even EPEL has fedora-usermgmt). But there seems to be another problem: I built RPMs from your SRPM on CentOS 5 (i386) but I get these errors when doing a 'yum install ...': --> Running transaction check --> Processing Dependency: /usr/afsws/bin/pagsh for package: bacula-common --> Finished Dependency Resolution Error: Missing Dependency: /usr/afsws/bin/pagsh is needed by package bacula-common This seems to be an issue within dependency calculation in rpmbuild as noted in http://www.bacula.org/dev-manual/Bacula_RPM_Packaging_FAQ.html: "5. I'm building my own rpms but on all platforms and compiles I get an unresolved dependency for something called /usr/afsws/bin/pagsh." Do I need additional rpmbuild defines? Do you experience the same issue?
AFS dependency removal: -------------------------------------------- --- bacula.spec 2007-06-11 16:43:58.000000000 +0200 +++ bacula.modified.spec 2007-06-11 16:12:49.000000000 +0200 @@ -324,6 +324,8 @@ %patch8 -p0 popd +rm -f bacula-2.0.3/examples/afs-bacula + # We are building the source several times, each with a different storage backend mkdir bacula-mysql bacula-postgresql bacula-sqlite -------------------------------------------- Furthermore, I think that packaging the examples directory in bacula-common leads to some perl dependencies which could be omitted: perl-Net-Telnet, perl-TermReadKey (only available in F7 afaik!), perl-Time-modules and perl-TimeDate.
(In reply to comment #25) > > Furthermore, I think that packaging the examples directory in bacula-common > leads to some perl dependencies which could be omitted: perl-Net-Telnet, > perl-TermReadKey (only available in F7 afaik!), perl-Time-modules and perl-TimeDate. Anything marked as %doc should not be create any additional requirements. In most cases, it's easy enough to prevent that from happening by removing the execure bits from the files.
logrotate gives an error because /var/log/bacula does not exist as configured in /etc/logrotate.d/bacula: error: error accessing /var/log/bacula: No such file or directory error: bacula:3 glob failed for /var/log/bacula/*.log error: found error in /var/log/bacula/*.log , skipping
I'm interested in co-maintaining this package if you'd like some help.
I got the ok to assist in co-maintaining this package. Here's the latest: SPEC: http://mmcgrath.net/~mmcgrath/bacula/bacula.spec SRPM: http://mmcgrath.net/~mmcgrath/bacula/bacula-2.0.3-3fc6.src.rpm Changes: - Chmod -x the example scripts to remove any unwanted requires - Added a LANG=C above alternatives in the init scripts
Thanks for fixing the doc/requires issue. I recompiled Andreas' SRPM on CentOS 5 (with clients for CentOS 4 i386 and FC 6 x86_64) and so far it worked flawlessly in a small office environment with MySQL (besides the hopefully fixed LANG issues).
i will review this
(In reply to comment #31) > i will review this thanks. final upload is at http://home.bawue.net/~ixs/bacula/bacula-2.0.3-4.src.rpm Please review that build, it has the known problems basically fixed, the major rpmlint problems have been fixed, the remaining warnings and errors should be ignorable.
(In reply to comment #23) > The script /usr/libexec/bacula/make_catalog_backup only works for the > mysql-backend. It should be rewritten to use the alternatives system. I have > installed the following director packages: Noticed that problem. During building different variables are changed in the file. I'm not sure what the right solution is ATM, whether I'll just roll a new backup-catalog script to select the right database at runtime or if the script should be packaged for each backend and added to the alternatives system. This will be fixed before initial import into fedora though and should not be a blocker for the review.
http://home.bawue.de/~ixs/bacula/bacula-2.0.3-4.src.rpm is the right url.
Created attachment 159155 [details] fix Provides and Requires I was not able to update bacula 2.0.2 to 2.0.3 with "rpm -Fvh bacula*.rpm" on my FC6/x86_64 machine. There were strange dependency problems. This patch should fix them.
Thx Dan, good catch. http://home.bawue.de/~ixs/bacula/bacula-2.0.3-5.src.rpm has fixed the problem
Created attachment 159202 [details] fix for %preun scriptlets a copy'n'paste bug that makes the %preun scriptlets fail
http://home.bawue.de/~ixs/bacula/bacula-2.0.3-6.src.rpm
I believe there is a missing BuildRequires for sqlite2-devel. I'm trying to build this package on FC6 PPC and get the following message: "configure: error: Unable to find sqlite.h in standard locations"
(In reply to comment #39) > I believe there is a missing BuildRequires for sqlite2-devel. Mhm, don't think so. For every current fedora release sqlite 3 is used. Only RHEL4 needs sqlite 2. But luckily the devel packages are are named sqlite-devel. Requiring sqlite2-devel is not needed on fedora, as sqlite3 is already pulled in on fedora and sqlite2 get's pulled in by the sqlite-devel dependency on RHEL4. The difference between sqlite2 and 3 thus lies not in the BuildRequire line but in the way configure gets called. For sqlite2 it's --with-sqlite and for sqlite3 it has to be --with-sqlite3. > I'm trying to build this package on FC6 PPC and get the following message: > "configure: error: Unable to find sqlite.h in standard locations" This looks very much as if the configure call is incorrect. I just checked the package in a mock build for fc6-x86_64 and it builds fine. I guess you did not build the package in mock but simply used rpmbuild --rebuild? In this case, please pass at least --define 'fedora 6' and maybe --define 'dist fc6' to your rpmbuild call. That way the right argument for the %configure macro can be selected.
Andreas is right, look for "# Build sqlite director" in the spec file. Similar define is needed for RHEL.
ok still alot of rpmlint noise. permissions are ok config files should be noreplace initscripts really should have incoherent warnings fixed E: bacula-common wrong-script-interpreter /usr/share/doc/bacula-common-2.0.3/examples/afs-bacula "/usr/afsws/bin/pagsh" make this non executable Builds fine in mock on FC-6 package naming is ok %if 0%{?fedora} %if "%{fedora}" >= "7" BuildRequires: tcp_wrappers-devel %else BuildRequires: tcp_wrappers %endif %endif should really be %if "%{?fedora}" >= "7" BuildRequires: tcp_wrappers-devel %else BuildRequires: tcp_wrappers %endif since im sure we will want tcp_wrappers for epel. nothing owns /etc/bacula/ or /usr/libexec/bacula/
(In reply to comment #42) > %if 0%{?fedora} > %if "%{fedora}" >= "7" > BuildRequires: tcp_wrappers-devel > %else > BuildRequires: tcp_wrappers > %endif > %endif > > should really be > %if "%{?fedora}" >= "7" > BuildRequires: tcp_wrappers-devel > %else > BuildRequires: tcp_wrappers > %endif > > since im sure we will want tcp_wrappers for epel. This could actually be simplified right down to: BuildRequires: /usr/include/tcpd.h That would work for all distribution releases without needing any of the conditionals.
(In reply to comment #42) > ok still alot of rpmlint noise. permissions are ok The noise is basically the following line: "W: bacula unversioned-explicit-provides bacula-director-%{version}-%{release}" Looks like an ignorable problem with rpmlint as it does no variable expansion. > config files should be noreplace Most of the config files are marked as noreplace. I did leave it out for security relevant files such as /etc/pam.d/gnome-console in order to be able to fix problems with a package update and make sure they are applied and not put into a .rpmnew file. Do we have a policy on that? Same goes for the logwatch files: W: bacula-director-common conffile-without-noreplace-flag /etc/logwatch/conf/logfiles/bacula.conf W: bacula-director-common conffile-without-noreplace-flag /etc/logwatch/conf/services/bacula.conf The logformat does change from time to time. That way we can update the definitions. > initscripts really should have incoherent warnings fixed W: bacula-client incoherent-subsys /etc/rc.d/init.d/bacula-fd $prog The executable is stored in a variable. rpmlint -i gives "It is also possible that rpmlint gets this wrong, especially if the init script contains nontrivial shell variables and/or assignments. These cases usually manifest themselves when rpmlint reports that the subsys name starts a with '$'; in these cases a warning instead of an error is reported and you should check the script manually." If that's important one could change the initscripts. About the incoherent names: This might not be that easy. We could change the names from the upstream used bacula-fd, -sd and -dir, to bacula-client, bacula-storage and bacula-director, which would conform to the bacula package names. This would however not remove the rpmlint warnings as the real package names are bacula-{director,storage}-{mysql,sqlite,postgresql} and the init script is packaged in the -common file getting its runtime information from the alternatives subsystem. Either way, the warning won't go away. However, I'm open to renaming the initscripts to conform to the package names although the current names are what upstream has been using in the past. > E: bacula-common wrong-script-interpreter > /usr/share/doc/bacula-common-2.0.3/examples/afs-bacula "/usr/afsws/bin/pagsh" > > make this non executable It actually is. -rw-r--r-- /usr/share/doc/bacula-common-2.0.3/examples/afs-bacula rpmlint issue, ignoring. > %if 0%{?fedora} > %if "%{fedora}" >= "7" > BuildRequires: tcp_wrappers-devel > %else > BuildRequires: tcp_wrappers > %endif > %endif > > should really be > %if "%{?fedora}" >= "7" > BuildRequires: tcp_wrappers-devel > %else > BuildRequires: tcp_wrappers > %endif > > since im sure we will want tcp_wrappers for epel. Right. > nothing owns /etc/bacula/ or /usr/libexec/bacula/ Thx. Try -7 at http://home.bawue.de/~ixs/bacula/bacula-2.0.3-7.src.rpm
(In reply to comment #44) > (In reply to comment #42) > > > ok still alot of rpmlint noise. permissions are ok > > The noise is basically the following line: > "W: bacula unversioned-explicit-provides bacula-director-%{version}-%{release}" > Looks like an ignorable problem with rpmlint as it does no variable expansion. Is there some particular reason you're using this style of virtual provide? How about: Provides: bacula(director) = %{version}-%{release} rpmlint might be happier with that.
> Is there some particular reason you're using this style of virtual provide? How > about: > > Provides: bacula(director) = %{version}-%{release} > > rpmlint might be happier with that. Actually, that is a very good question. And taking a closer look, I applied rpmlint to older rpms which had fucked up require lines. The current srpms have been fixed by applying the patches from Dan. Rebuilding them in mock and running rpmlint on them looks much better and this junk never appeared. Sorry about that, I guess I should just go to bed for today. :-)
http://home.bawue.de/~ixs/bacula/bacula-2.0.3-8.src.rpm * Wed Jul 19 2007 Andreas Thienemann <andreas> 2.0.3-8 - Moved some files around in the %%files section and refactored spec parts a bit - Fixed up the catalog-backup scripts by including them in the alternatives system - Applied tls patch fixing some tls disconnection issues.
Looks good now. sha1sum matches upstream ef58c91243bd819e0ac278b91aeae16639d6c8ce bacula-2.0.3.tar.gz ef58c91243bd819e0ac278b91aeae16639d6c8ce bacula-2.0.3.tar.gz Approved
New Package CVS Request ======================= Package Name: bacula Short Description: Cross platform network backup for Linux, Unix, Mac and Windows Owners: andreas,mmcgrath Branches: FC-6 F-7 EL-5 EL-4 InitialCC:
Package has been built successfully for F7, FC-6 and rawhide. EL-4 and EL-5 still have unmet dependencies, which should be fixed soon however. Thx for all the comments and the review.