Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 3:44 PM, demerphq wrote:
> 12/19 karl williamson :
>> And a test fails: t/run/switches.t It's looking for just a patch number:
>> # Failed at run/switches.t line 265
>> # got '
>> # This is perl, v5.11.0
>> DEVEL"blead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2"
>> built for i686-linux
> This is something that should change. Our build process should use
> git-describe if possible for the version string.
> However for that to be useful we have to change a bunch of other
> things, and have to start tagging.
Plain old git-describe with no options gives you the name of the most
recent tag on the current branch and the number of commits since that
tag, but there are at least two common situations where that's not
sufficient. As Rafael has explained more than once in various forums
(possibly not on public mailing lists -- I don't remember), the way
merges work means you can have two different ways to get the same
number of commits since the tag. Also, you can have situations (like
we have now with blead) where you have no relevant tag to count from.
The most recent tag visible from blead is 5.10.0 because 5.11.0 has
not been released, but that's not a very useful place to count from
for blead.
After a lot of discussion, I thought we had decided on parsing the
branch name and an abbreviated version of the SHA1 out of git describe
--all --long something like so:
% git describe --all --long
heads/maint-5.8-0-ga00da08
% git describe --all --long | perl -ne '$_ =~ m{^.+/(.+)-\d+-g(.+)$};
print "$...@$2\n";'
maint-...@a00da08
At least that's what we documented on the wiki before the switchover
and what was happening in the pre-release rsync set-up. What we're
seeing now is a little different, which is ok as long as it works and
gets settled soon.
I like the addition of the timestamp as long as it's the timestamp of
the push or pull from the perspective of the main repository and not
the timestamp of the original commit. If it were the latter, it could
shuffle backward and forward as people take varying amounts of time to
push their changes.
I'm not so fond of having the full SHA1 as part of the patchlevel
string that is going to show up every time someone types perl -V.
Does gitweb understand abbreviated SHA1 strings like everything else
in git? If so, there's no reason I can think of that we want the
whole thing. If not, I can see the utility of it since anyone
(hopefully Test::Smoke in the future) can construct meaningful URLs
from the SHA1.
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 11:19 AM, Rafael Garcia-Suarez wrote: > 2008/12/19 karl williamson : >> Two things: when I do as above using rsync, I merely get a list of the >> valid perl sources. If I change the :: to a slash, I actually get the >> files. However, .patch contains >> "blead 20081219.17:05:08 b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2" >> which doesn't compile well. > > What is exactly the problem with that ? I don't think anything relies > on .patch being an integer, but I might be wrong. Having spaces in what's appended to DEVEL in patchlevel.h will probably cause trouble. run/switches.t will fail because the new string will not match DEVEL\d+ in the output of perl -v. You can see what you're getting for the relevant variables with: % grep _patchlevel config.sh
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 11:24 AM, Steve Hay wrote: > Rafael Garcia-Suarez wrote: >> 2008/12/19 karl williamson : >>> Two things: when I do as above using rsync, I merely get a list of >>> the valid perl sources. If I change the :: to a slash, I actually >>> get the files. However, .patch contains >>> "blead 20081219.17:05:08 b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2" >>> which doesn't compile well. >> >> What is exactly the problem with that ? I don't think anything relies >> on .patch being an integer, but I might be wrong. > > Nothing wrong with it here. I did a little smoke test using the new > rsync source earlier, and it built fine (see attached). I think that's because Test::Smoke did it's own editing of patchlevel.h. It didn't blow up, but it also didn't really work. You'll notice all of the hex digits have been stripped from your SHA1. Since the timestamp is embedded in there it's reasonably safe but not entirely correct.
Re: Smoke [5.9.2] 23792 FAIL(M) openvms V7.2 (VAX/2 cpu)
At 11:20 PM +0100 1/17/05, Abe Timmerman wrote: >Okay, I forgot to build from the rooted logical. That gets me past ext/attrs > >But this doesn't look too good: >Cleaning current config before rebuilding Descrip.MMS ... I think you are getting the after effects of an existing descrip.mms rebuilding its own replacement. Probably time to make realclean from the top and start over. -- ________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
Re: Smoke [5.9.2] 23792 FAIL(M) openvms V7.2 (VAX/2 cpu)
At 7:48 AM -0600 1/14/05, Craig A. Berry wrote:
>At 12:05 PM +0100 1/14/05, Abe Timmerman wrote:
>
>>CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj FLOAT/G_FLOAT/
>>Define=("VERSION=""1.01""","XS_VERSION=""1.01""")/Include=([--])/NoList
>>ATTRS.c
>>%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
>> \ATTRS\
>>%MMK-F-ERRUPD, error status %X00038098 occurred when updating target ATTRS.OBJ
>>%MMK-F-ERRUPD, error status %X1C14803C occurred when updating target DYNEXT
>
>That needs to say
>
>/FLOAT=G_FLOAT
>
>instead of
>
>FLOAT/G_FLOAT
>
>The -Duser_c_flags=/FLOAT=G_FLOAT in your configuration looks right,
>so I'm not sure what's happening but will look into it.
I can't reproduce this doing a G_FLOAT build on Alpha. What do you see from
doing
$ search config.sh ccflags, config_args
and
$ search [.ext.attrs]descrip.mms ccflags
--
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Re: Smoke [5.9.2] 23792 FAIL(M) openvms V7.2 (VAX/2 cpu)
At 12:05 PM +0100 1/14/05, Abe Timmerman wrote:
>CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj FLOAT/G_FLOAT/
>Define=("VERSION=""1.01""","XS_VERSION=""1.01""")/Include=([--])/NoList
>ATTRS.c
>%DCL-W-MAXPARM, too many parameters - reenter command with fewer parameters
> \ATTRS\
>%MMK-F-ERRUPD, error status %X00038098 occurred when updating target ATTRS.OBJ
>%MMK-F-ERRUPD, error status %X1C14803C occurred when updating target DYNEXT
That needs to say
/FLOAT=G_FLOAT
instead of
FLOAT/G_FLOAT
The -Duser_c_flags=/FLOAT=G_FLOAT in your configuration looks right,
so I'm not sure what's happening but will look into it.
--
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
Re: Smoke [5.9.2] 23770 FAIL(m) openvms V7.2 (VAX/2 cpu)
At 9:52 PM +0100 1/9/05, Abe Timmerman wrote: >Doing variable substitutions on .SH files... >Extracting config.h (with variable substitutions) >%DCL-W-UNDSYM, undefined symbol - check validity and spelling > \USELARGEFILES\ Oops. My bad. For VAX and very old Alpha we don't even ask certain configuration questions, and when I added -Duselargefiles recently I didn't handle the cases where we don't ask the question. Try the following patch: --- configure.com;-1Sat Jan 8 17:57:19 2005 +++ configure.com Sun Jan 9 15:52:44 2005 @@ -48,6 +48,7 @@ $ use_vmsdebug_perl = "n" $ use64bitall = "n" $ use64bitint = "n" +$ uselargefiles = "n" $ C_Compiler_Replace = "CC=" $ Thread_Live_Dangerously = "MT=" $ use_two_pot_malloc = "N" @@ -2335,12 +2336,7 @@ $ echo "If this does not make any sense to you, just accept the default '" + bool_dflt + "'." $ rp = "Try to understand large files, if available? [''bool_dflt'] " $ GOSUB myread -$ IF ans -$ THEN -$ uselargefiles="define" -$ ELSE -$ uselargefiles="undef" -$ ENDIF +$ uselargefiles=ans $! $ ENDIF ! not VAX && >= 7.1 $! @@ -3012,6 +3008,12 @@ $ ELSE $ use64bitall = "undef" $ ENDIF +$ IF uselargefiles .OR. uselargefiles .EQS. "define" +$ THEN +$ uselargefiles = "define" +$ ELSE +$ uselargefiles = "undef" +$ ENDIF $! $ usemymalloc = "undef" $ if mymalloc then usemymalloc = "define" [end of patch] -- Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
Re: Smoke [5_8_6] 23493 FAIL(FM) openvms V7.3-1 (Digital_Personal_WorkStation_/1 cpu)
Abe Timmerman wrote: Op een grimmige herfstdag (Sunday 14 November 2004 04:09),schreef [EMAIL PROTECTED]: Automated smoke report for 5_8_6 patch 23493 BRIANA: Digital_Personal_WorkStation_ (Digital_Personal_WorkStation_/1 cpu) onopenvms - V7.3-1 using CC/DECC version 60590001 smoketime 8 hours 10 minutes (average 2 hours 2 minutes) Congratulations! We need to work on the hardware information a bit more (currently it comes from `show cpu/active`)... Let us know what you'd like to see and I'm sure you'll get several different ways to retrieve it. There is a new snapshot of Test-Smoke-1.19_52 available for you from http://www.test-smoke.org/download/ That'll solve the '5_8_6' version and the MANIFEST check I've got it and will give it a try. I'm interestet in how you've got automatic mail set up (I now use MIME::Lite) It's using the Mail::Sendmail that ships with Test::Smoke. I think I answered a configuration question to that effect but didn't do anything special to get it to work.
