[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] Patches


See http://www.bacula.org/en/rel-manual/Bacula_RPM_Packaging_FAQ.html
and
trunk/bacula/platforms/contrib-rpm directory

But the answer to your question, I did not find it.
I think (perhaps wrongly) that the way may be next.


Download bacula-2.4.3-1.src.rpm and install.
Download patch 2.4.3-cancel-after-network-outage.patch and manually apply it.

Or copy the patch to SOURCES directory and modify  bacula.spec:
...
Source5: bacula-2.2.7-postgresql.patch
Patch1: 2.4.3-cancel-after-network-outage.patch

% changelog
* Sun Oct 26 2008 Y. Timofeev <tim4dev@xxxxxxxxx>
- Add 2.4.3-cancel-after-network-outage.patch
...

and

rpmbuild-bb bacula.spec




2008/10/26 Timo Neuvonen <timo-news@xxxxxxxxxx>:
> "Kern Sibbald" <kern@xxxxxxxxxxx> kirjoitti viestissä
> news:200810260903.29174.kern@xxxxxxxxxxxxxx
>> On Saturday 25 October 2008 21:53:00 Ulrich Leodolter wrote:
>>> On Sat, 2008-10-25 at 21:11 +0200, Eric Bollengier wrote:
>>> > Le Saturday 25 October 2008 13:41:15 Ulrich Leodolter, vous avez écrit
>>> > :
>>> > > On Sat, 2008-10-25 at 11:32 +0200, Kern Sibbald wrote:
>>> > > > Hello,
>>> > > >
>>> > > > For some time now, I haven't really been happy with the Bacula
>>> > > > patch
>>> > > > procedure. Basically, when we fix a bug (either from a bug report
>>> > > > or
>>> > > > ourselves), we usually generate a patch, post it to the bug report,
>>> > > > if any, and upload it to the Bacula patches area of Source Forge.
>>> > > >
>>> > > > Providing you are subscribed to the bugs database and to the
>>> > > > bacula-patches release notification on Source Forge, you will see
>>> > > > these patches and can apply them if you deem necessary.
>>> > > >
>>> > > > The problems I have with this is that some people may not know
>>> > > > about
>>> > > > patches (we see this in bug reports where a problem is already
>>> > > > resolved with a patch), and there is no formal mechanism for
>>> > > > developers when generating a patch.
>>> > > >
>>> > > > We already have more work than we can handle, so any change needs
>>> > > > to
>>> > > > be simple and not time consuming for developers, but I am wondering
>>> > > > if anyone has suggestions how to improve this.  I can think of a
>>> > > > few:
>>> > > >
>>> > > > 1. Change nothing (signing up for bugs and patch notification is
>>> > > > already not bad).
>>> > > > 2. Announce patches to the bacula-devel list
>>> > > > 3. Announce patches to the bacula-devel list and the bacula-users
>>> > > > list 4. Announce patches to the bacula-announce list as well as the
>>> > > > other two lists.
>>> > > > 5. Put patches in the news (time consuming and I doubt that many
>>> > > > read
>>> > > > news). 6. Create an rss feed (I doubt that many users use rss, and
>>> > > > this also could be time consuming).
>>> > >
>>> > > Hello,
>>> > >
>>> > > One thing i am missing are patched packages, rpm and also deb
>>> > > packages
>>> > > have a mechanism to include patch files an apply during build
>>> > > process.
>>> > >
>>> > > For most bacula users it would be much easier to apply patches by
>>> > > "rpm
>>> > > -U ..." or "dpkg install ...".
>>> >
>>> > Yes, but you have to build, test and release a package for each disto
>>> > after each patch, this is a *huge* amount of work, we have something
>>> > like
>>> > 10 patches between two releases.
>>> >
>>> > If someone want to build, test and package 10 more often than before
>>> > for
>>> > free, no problem, but i prefere spend my time with new features and
>>> > bugs
>>> > hunting.
>>> >
>>> > > Operating systems like RedHat, CentOS, SLES, Debian, ... are always
>>> > > at
>>> > > least one step behind last official version.
>>> > >
>>> > > An official bacula package repository (yum, apt) would be great.
>>> >
>>> > Fedora, debian and ubuntu already provide this kind of repositor, and
>>> > often, they  have a backport branch.
>>
>> I was out yesterday, so will answer here in your second email.
>>
>> Yes, I think having full packages available is the best way to get
>> "patches".
>> We already sometimes do that.  However, as Eric pointed out, it is a lot
>> of
>> work.  The packaging is done by the community.  I release a new source tar
>> file and (with the exception of Win32), the community creates new packages
>> if
>> they want.  They always do so for new releases, and for what I designate
>> as
>> critical fixes, but possibly not for all the more minor patches.
>>
>
> I guess there are a number of users who are not familiar with the packaging
> process, partially that includes me, although I'm rather used to build many
> binaries from source rpms.
>
> One reasonable way to reduce the burden to the packagers might be, if they
> mostly concentrated (now I'm talking only about rpm packages, I don't know
> eg. debian) in building the source packages that could be expected to
> succesfully build into binaries. I understand that there is a lot of work
> after building the source package that somehow seriously can be expected to
> work, since the various final binaries preferably should also be installed
> in the target systems and tested there -at least to the point they start
> nicely. But when it's about "small" minor patches, it might be reasonable
> that an experienced packager views the patch and the spec file, and if it
> were expected that all this could result in a working binary package,
> building the binaries could be left to the end users -at least when it comes
> to the very minor patches.
>
> Currently, at least I am a little bit scared about the idea of building and
> installing into a "production environment" an application that was shipped
> as a source tarball, since it may conflict with the existing system, and I
> have some bad experiencies from the past how to uninstall some tarball
> installations (not speaking of Bacula now), though a bad rpm binary may be
> hard to uninstall as well.
>
> So, could a reasonable middle-way be releasing more source rpms, and include
> in the release notes an example how to build the binary rpm? Or, if a
> supposed-to-be-perfect spec file that can handle the patches is already
> included in the tarball, just include an example command sequence how to
> build a binary rpm all the way from the source tarball? This would reduce
> some raw shovel-level work from the packagers. Then, if the binary could not
> be built eg. due to some bug in the spec file, it would be up to the
> official packager again if he/she has resources to fix it at that point, or
> decides to wait until the next release.
>
> --
> TiN
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
>



-- 
with best regards
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.