[OpenPKG] Version Tracking Report (2006-02-14 19:06)
OpenPKG Version Tracking Report === Reporting Time:2006-02-14 19:06 Tracking Duration: 1:18:59 (H:M:S) Tracking Input:1784 sources (929 packages) Tracking Result: 1688 up-to-date, 44 out-dated, 52 error The following 44 sources were determined to be out-dated because newer vendor versions were found. Upgrade the corresponding OpenPKG packages. - - - Package Old Version New Version - - - apache2 2.0.552.2.0 bochs 2.2.1 2.2.6 boost 1_33_01_33_1 coreutils:release 5.93 5.94 dhtml:scriptaculous 1.5.1 1.5.2 expect:expect 5.43.05.44.1 firefox 1.0.7 1.5.0.1 freeradius1.0.5 1.1.0 ganttproject 1.10.32.0 gdb 6.3 6.4 glibmm2.8.4 2.9.1 heartbeat 2.0.2 2.0.3 honeyd1.0 1.5 jboss 3.2.7 3.2.8 kde-arts 1.4.2 1.5.1 [1] kde-base 3.2.3 3.5.1 [2] kde-libs 3.4.2 3.5.1 [3] ksh 2005-02-022006-01-24 ksh:init 2005-02-022006-01-24 libdnet 1.10 1.11 libextractor 0.5.7 0.5.9 libnetdude0.7 0.8 libvncserver 0.7.1 0.8 lighttpd 1.4.9 1.4.10 mesa:MesaDemos6.2.1 6.4.2 mesa:MesaLib 6.2.1 6.4.2 mozilla-mplayer 3.15 3.21 papyrus 1.4.4 1.5.2 parrot0.4.0 0.4.1 pax 2005-02-022006-01-24 pax:init 2005-02-022006-01-24 pearpc0.3.1 0.4 popt 1.10.21.10.4[4] qt4 4.0.1 4.1.0 scribus 1.3.1 1.3.2 [5] smokeping 2.0.6 2.0.7 taskjuggler 2.1.1 2.2.0 wine 0.9.6 0.9.7 x11vnc0.7.2 0.8 xalan-c 1_6 1_10_0 xine-ui 0.99.30.99.4 xorg 6.8.2 7.0 xpdf:patchlevel 1 2 zope 2.8.5 2.9.0 - - - [1] kde-arts: thl/1.4.3: configure Qt (>= Qt 3.3 and < 4.0) (library qt-mt) not found, although qt-3.3.5 installed [2] kde-base: thl/3.4.3: requires kde-arts which is currently broken [3] kde-libs: thl/3.4.2: requires kde-arts which is currently broken [4] popt: rse: 1.10.3 has lots of files missing (depcomp, install.sh, ltmain, etc) [5] scribus: thl/1.3.1: scribus/libpostscript: No such file or directory The following 52 sources could not be successfully checked because an error occurred while processing. Keep at least an eye on them. - - - Package Old Version Error - - - apache:mod_security 1.8.7 regex didn't match (pro.. apachetop 0.12.5regex didn't match (pro.. ccache2.4 regex didn't match (pro.. cvs:cvslock 0.2 connection failed or ti.. enscript 1.6.3 regex didn't match (p [1] epm 3.7 2nd connection failed [2] gale 0.99fruit latest version online [3] gmime 2.1.182nd regex didn't match .. httrack 3.33 regex didn't match (pro.. ircd 2.11.1p1 connection failed or ti.. j2ee
Re: Spec file shtool/build policy
On Tue, Feb 14, 2006, Ralf S. Engelschall wrote:
>On Mon, Feb 13, 2006, Bill Campbell wrote:
>
>> I would like to suggest that any %{l_shtool} subst subsitutions don't
>> belong in the %setup section, but properly belong at the beginning of the
>> %build section.
>>
>> IHMO, the %setup section should only be for loading sources and applying
>> patches. Putting processing like substitutions in it makes the job of
>> building new patches more difficult as one cannot just to an ``rpm -bp''
>> operation to get clean sources from which one can generate diffs.
>
>Yes and no. Yes, because you're right, they make trouble and always
>have to be proceeded with an "exit 0" temporarily (that's what I do).
>No, because one could argue that substitutions are just a different
>technique of patching the sources and hence should be grouped together
>with the patch files.
I too use exit 0 when I encounter this.
On the other hand, many of the substitutions with shtool are target
dependent which varies from build to build.
>Although I usually always prefer consistency and grouping (where I would
>bundle "shtool subst" and "%patch"), I personally also tend to agree
>with you, Bill.
Since this is mostly a style issue, can we suggest as a matter of policy
that the substitutions be put in the %build section? It's not something
that changes the outcome of the build. In most cases, it's simply a matter
of moving the %build line to immediately precede the substitutions.
There are some packages, apache comes to mind, where the %setup section
conditionally installs source packages. In these cases the substitutions
may well be necessary in line with the setup.
>I also think the %prep sections should only contain %setup and %patch
>commands because (1) that's how the %prep section AFAIK was intended
>for by the RPM authors (2) the %prep section and especially its %setup
>macro is REALLY DEEP magic (e.g. its expanded "cd" part is sticky and
>automatically duplicates into all other sections, etc) and (3) it also
>simplifies the developer tasks.
Is there any way to figure this magic out other than reading the rpm source
code?
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
``People from East Germany have found the West so confusing. It's so much
easier when you have only one party.'' -- Linus Torvalde, Linux Expo Canada
when asked about confusion over many Linux distributions.
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Spec file shtool/build policy
On Tue, Feb 14, 2006, Bill Campbell wrote: > [...] > Since this is mostly a style issue, can we suggest as a matter of policy > that the substitutions be put in the %build section? Yes, I vote for doing it this way. > [...] > >I also think the %prep sections should only contain %setup and %patch > >commands because (1) that's how the %prep section AFAIK was intended > >for by the RPM authors (2) the %prep section and especially its %setup > >macro is REALLY DEEP magic (e.g. its expanded "cd" part is sticky and > >automatically duplicates into all other sections, etc) and (3) it also > >simplifies the developer tasks. > > Is there any way to figure this magic out other than reading the rpm source > code? I've assembled some of this magic some time ago in the file openpkg-dev.txt in the CVS. You can read it directly via URL http://cvs.openpkg.org/getfile/openpkg-doc/quickref/openpkg-dev.txt Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Spec file shtool/build policy
On Tue, Feb 14, 2006, Ralf S. Engelschall wrote: >On Tue, Feb 14, 2006, Bill Campbell wrote: > >> [...] >> Since this is mostly a style issue, can we suggest as a matter of policy >> that the substitutions be put in the %build section? > >Yes, I vote for doing it this way. I'll be doing several updates to CURRENT packages as I find changes necessary for OS X/darwin. Would there be any objections to my moving these if I find them? >> [...] >> >I also think the %prep sections should only contain %setup and %patch >> >commands because (1) that's how the %prep section AFAIK was intended >> >for by the RPM authors (2) the %prep section and especially its %setup >> >macro is REALLY DEEP magic (e.g. its expanded "cd" part is sticky and >> >automatically duplicates into all other sections, etc) and (3) it also >> >simplifies the developer tasks. >> >> Is there any way to figure this magic out other than reading the rpm source >> code? > >I've assembled some of this magic some time ago in the file >openpkg-dev.txt in the CVS. You can read it directly via URL >http://cvs.openpkg.org/getfile/openpkg-doc/quickref/openpkg-dev.txt Good stuff. Thanks. Bill -- INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676 ``We maintain that the very foundation of our way of life is what we call free enterprise,'' said Cash McCall, "but when one of our citizens show enough free enterprise to pile up a little of that profit, we do our best to make him feel that he ought to be ashamed of himself." -- Cameron Hawley __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Spec file shtool/build policy
On Tue, Feb 14, 2006, Bill Campbell wrote: > On Tue, Feb 14, 2006, Ralf S. Engelschall wrote: > >On Tue, Feb 14, 2006, Bill Campbell wrote: > > > >> [...] > >> Since this is mostly a style issue, can we suggest as a matter of policy > >> that the substitutions be put in the %build section? > > > >Yes, I vote for doing it this way. > > I'll be doing several updates to CURRENT packages as I find changes > necessary for OS X/darwin. Would there be any objections to my moving > these if I find them? > [...] No, feel free to move them, Bill. Ralf S. Engelschall [EMAIL PROTECTED] www.engelschall.com __ The OpenPKG Projectwww.openpkg.org Developer Communication List openpkg-dev@openpkg.org
Re: Spec file shtool/build policy
Bill Campbell<[EMAIL PROTECTED]> wrote on 2006-02-13 23:35:10:
> I would like to suggest that any %{l_shtool} subst subsitutions don't belong
> in the %setup section, but properly belong at the beginning of the %build
> section.
>
I remember we put some efforts into moving almost every patch-like "shtool
subst" construct into the %prep section to complement the %patch instructions.
Besides developer's convenience I do not see a reason why automated source
tweaking should be split and partially moved outside the %prep section.
Deferring substitions to the %build section sometimes inhibits repetitive
execution via "rpm --short-circuit" which means a shift would move the paint to
a different location with no real cure.
--
Thomas
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Spec file shtool/build policy
On Tue, Feb 14, 2006, Thomas Lotterer wrote:
>Bill Campbell<[EMAIL PROTECTED]> wrote on 2006-02-13 23:35:10:
>> I would like to suggest that any %{l_shtool} subst subsitutions don't belong
>> in the %setup section, but properly belong at the beginning of the %build
>> section.
>>
>I remember we put some efforts into moving almost every patch-like "shtool
>subst" construct into the %prep section to complement the %patch instructions.
>Besides developer's convenience I do not see a reason why automated source
>tweaking should be split and partially moved outside the %prep section.
>Deferring substitions to the %build section sometimes inhibits repetitive
>execution via "rpm --short-circuit" which means a shift would move the paint to
>a different location with no real cure.
I don't think that moving substitutions to %build would break most
short-circuits since they generally will have no effect when run a
second time as the substitutions will have already been made.
When I'm writing my own spec files, and want to do some kind of
substitutions, I often run a ``find | xargs grep -l ..> tmplist''
routine to create a list of the files to change before doing the
substitutions, then test for a non-empty list before running shtool
to make the substitutions.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Systems, Inc.
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
Giving money and power to government is like giving whiskey and car keys to
teenage boys -- P.J. O'Rourke
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
[OpenPKG] Version Tracking Report (2006-02-15 06:51)
OpenPKG Version Tracking Report === Reporting Time:2006-02-15 06:51 Tracking Duration: 1:08:33 (H:M:S) Tracking Input:1784 sources (929 packages) Tracking Result: 1476 up-to-date, 44 out-dated, 264 error The following 44 sources were determined to be out-dated because newer vendor versions were found. Upgrade the corresponding OpenPKG packages. - - - Package Old Version New Version - - - apache2 2.0.552.2.0 bochs 2.2.1 2.2.6 boost 1_33_01_33_1 coreutils:release 5.93 5.94 expect:expect 5.43.05.44.1 firefox 1.0.7 1.5.0.1 freeradius1.0.5 1.1.0 ganttproject 1.10.32.0 gdb 6.3 6.4 glibmm2.8.4 2.9.1 gnupg 1.4.2 1.4.2.1 heartbeat 2.0.2 2.0.3 honeyd1.0 1.5 jboss 3.2.7 3.2.8 kde-arts 1.4.2 1.5.1 [1] kde-base 3.2.3 3.5.1 [2] kde-libs 3.4.2 3.5.1 [3] ksh 2005-02-022006-01-24 ksh:init 2005-02-022006-01-24 libdnet 1.10 1.11 libextractor 0.5.7 0.5.9 libnetdude0.7 0.8 libvncserver 0.7.1 0.8 lighttpd 1.4.9 1.4.10 mesa:MesaDemos6.2.1 6.4.2 mesa:MesaLib 6.2.1 6.4.2 mozilla-mplayer 3.15 3.21 papyrus 1.4.4 1.5.2 parrot0.4.0 0.4.1 pax 2005-02-022006-01-24 pax:init 2005-02-022006-01-24 pearpc0.3.1 0.4 popt 1.10.21.10.4[4] qt4 4.0.1 4.1.0 scribus 1.3.1 1.3.2 [5] smokeping 2.0.6 2.0.7 taskjuggler 2.1.1 2.2.0 wine 0.9.6 0.9.7 x11vnc0.7.2 0.8 xalan-c 1_6 1_10_0 xine-ui 0.99.30.99.4 xorg 6.8.2 7.0 xpdf:patchlevel 1 2 zope 2.8.5 2.9.0 - - - [1] kde-arts: thl/1.4.3: configure Qt (>= Qt 3.3 and < 4.0) (library qt-mt) not found, although qt-3.3.5 installed [2] kde-base: thl/3.4.3: requires kde-arts which is currently broken [3] kde-libs: thl/3.4.2: requires kde-arts which is currently broken [4] popt: rse: 1.10.3 has lots of files missing (depcomp, install.sh, ltmain, etc) [5] scribus: thl/1.3.1: scribus/libpostscript: No such file or directory The following 264 sources could not be successfully checked because an error occurred while processing. Keep at least an eye on them. - - - Package Old Version Error - - - apache:mod_security 1.8.7 regex didn't match (pro.. apachetop 0.12.5regex didn't match (pro.. ccache2.4 regex didn't match (pro.. cgilib0.5 regex didn't match (pro.. cvs:cvslock 0.2 connection failed or ti.. enscript 1.6.3 regex didn't match (p [1] epm 3.7 2nd connection failed [2] gale 0.99fruit latest version online [3] gmime 2.1.182nd regex didn't match .. httrack 3.33 regex didn't match (pro.. irc
Re: Spec file shtool/build policy
On Tue, Feb 14, 2006, Thomas Lotterer wrote:
> Bill Campbell<[EMAIL PROTECTED]> wrote on 2006-02-13 23:35:10:
> > I would like to suggest that any %{l_shtool} subst subsitutions don't belong
> > in the %setup section, but properly belong at the beginning of the %build
> > section.
> >
> I remember we put some efforts into moving almost every patch-like "shtool
> subst" construct into the %prep section to complement the %patch instructions.
> Besides developer's convenience I do not see a reason why automated source
> tweaking should be split and partially moved outside the %prep section.
> Deferring substitions to the %build section sometimes inhibits repetitive
> execution via "rpm --short-circuit" which means a shift would move the paint
> to
> a different location with no real cure.
Ok, good points. But we should complete and final list of pros and
cons about this issue as it is recurring one. I still see more points
for moving the substititions into %build, but before we make a final
decision (and then cleanup all packages according to this) it is perhaps
better to prepare a pros and cons list.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
