[packagers] Re: [Fwd: [svn] r8760 - in /trunk/rpms/mod_rivet: ./ README makelatest.sh mod_rivet.spec]

Yury V. Zaytsev yury at shurup.com
Mon May 3 15:42:13 CEST 2010


Hi!

I merged the latest updates from you, thanks. 

Note that this hunk is wrong. Try it out with

rpm --eval "%{buildroot}%{_sysconfdir}/httpd/conf.d"

@@ -63,13 +68,13 @@
 rm -f %{buildroot}%{_libdir}/httpd/rivet%{version}/librivet*.la

 # Create an Apache conf include
-mkdir -p %{buildroot}%{_sysconfdir}/httpd/conf.d
-cat <<EOT >%{buildroot}%{_sysconfdir}/httpd/conf.d/rivet.conf
+mkdir -p %{buildroot}/%{_sysconfdir}/httpd/conf.d
+cat <<EOT >%{buildroot}/%{_sysconfdir}/httpd/conf.d/rivet.conf
 
-- 
Sincerely yours,
Yury V. Zaytsev

On Thu, 2010-04-29 at 11:43 -0500, Jeff Lawson wrote:
> Yury, I've updated my spec file for the official Rivet 2.0.0 that was
> just released today.
> 
> http://github.com/bovine/rivet-rpm
> 
> Notice that you can delete the "makelatest.sh" script that I was
> previously using to track the latest snapshot.
> 
> 
> On Thu, Apr 15, 2010 at 1:47 PM, Jeff Lawson <jeff at bovine.net> wrote:
>         On Thu, Apr 15, 2010 at 1:21 PM, Yury V. Zaytsev
>         <yury at shurup.com> wrote:
>         > On Thu, 2010-04-15 at 13:14 -0500, Jeff Lawson wrote:
>         >
>         >> How long do need tarballs to remain available?  Apache
>         seems to have a
>         >> crontab that takes snapshots 4 times a day, and keeping the
>         last 4, so
>         >> if you pick the latest tarball it should remain online for
>         at least
>         >> 18-24 hours.
>         >
>         > I would say at least for a few weeks. 24 hours will
>         certainly not cut
>         > it, because only one person has the control over the build
>         system and
>         > the builds are triggered manually.
>         >
>         > If you can decide on which snapshot is "best" and mirror it
>         I can update
>         > the package.
>         >
>         
>         
>         I will talk with the Rivet developers to get them to make an
>         official
>         release or snapshot and let you know the outcome.
>         
>         
>         >> On my system, the -i option causes this error:
>         >
>         > Well, then I would just drop it. As far as I can tell it's a
>         good
>         > practice to stick with this set of options, unless there's a
>         libtool
>         > mismatch (which is exactly the case) or something like
>         that... But then
>         > you just drop --install (if it works this way), because
>         relibtoolizing
>         > the whole thing is a hell.
>         >
>         
>         
>         Removing the -i is the best option then.





More information about the packagers mailing list