Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 3:44 PM, demerphq demer...@gmail.com wrote:
12/19 karl williamson pub...@khwilliamson.com:
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
DEVELblead-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)
H.Merijn Brand wrote: Now that perl VCS has moved from perforce to git, the rsync address should also change. Note that the old address will still work, but it will have a considerable delay, as that will rsync itself from the new address Hello folks, Just a quick note to let you know that we're starting to update from the new rsync mirror -- all of our machines should be in sync in the next hour or so. We're mirroring twice an hour (on the hour and half hour, if that helps anyone), so there will be a noticeable delay if you're looking to smoke the latest bits. If you're not time-sensitive and a North American mirror works better for you, the old address will still work for you. If anyone notices any problems, please let me know and I'll take care of them. Cheers, kjw
Re: Change your rsync address(es)
2008/12/20 Craig A. Berry craig.a.be...@gmail.com:
On Fri, Dec 19, 2008 at 3:44 PM, demerphq demer...@gmail.com wrote:
12/19 karl williamson pub...@khwilliamson.com:
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
DEVELblead-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,
No, plain old git-describe produces output like the last item on the
perl5changes report.
LIke this:
GitLive-blead-26-g60bc010
perl-5.8.0-13291-g52ec13a
The only reason we have GitLive-blead there is because the last tag we
had was Perl5.8.0, and thus it was pretty confusing to see:
perl-5.8.0-13291-g52ec13a in a mail about commits to blead. So i
created GitLive-blead and etc, to mark the state when we went
GitLive.
However, as you can see there is enough information there to make the
description essentially unique. The tag corresponds to a specific
commit, the number is derived from a known tree walking algorithm, and
the sha1 prefix is there as a disambiguator. And the algorithm to walk
the commits is known to git. What is interesting is that while the
name is unambiguous, and probably also unique, it is contextual. If
you have extra tags your git-describe and my git-describe arent going
to be the same, even tho tho are both probably unambiguous.
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.
I think you are taking Rafaels comment out of context. I believe he
was speaking from the perspective of a simple numbering scheme, not
one which provides extra information.
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.
Well, IMO counting from 5.10.0 makes sense for blead until the release
of 5.11.0. However it also makes sense for maint-5.10, and thus would
be confusing, although probably still unambiguous. Adding the branch
name resolves that.
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.
Yes. We need to be able to take a set of .patch id's and order them.
Keep in mind that .patch files dont 1:1 correspond to commits. They
can't for various reasons. Not every commit will have a corresponding
patch file, or .patch rsync.
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.
Its the timestamp the .patch file was created. Again in order to make
them orderable.
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.
Full sha1 no. We need to think about this more. I think we have
different requirements from .patch files and from perl -V that just
happend to be simultaneously met by perforce revision numbers. We need
to be able to create the perl -V properly from the content of a .patch
file. We also need to be able to relate a .patch file to a diff as
there are people that expect diffs.
I think we should think about how you can effectively turn a nonlinear
dynamic source like git into a reliable way to create .patch files,
diffs that can be linearly applied, and perl -V output, and still be
useful before we rush to a decision.
Im happy to change the
Re: Change your rsync address(es)
On Fri, 19 Dec 2008 17:24:48 +0100, H.Merijn Brand h.m.br...@xs4all.nl wrote: Now that perl VCS has moved from perforce to git, the rsync address should also change. Note that the old address will still work, but it will have a considerable delay, as that will rsync itself from the new address For all your _config files, you will have to change the lines that look like source = public.activestate.com::perl-current, to source = perl5.git.perl.or::perl-current, ^ perl5.git.perl.org terribly sorry there -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.3, and 11.0, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Change your rsync address(es)
H.Merijn Brand wrote: On Fri, 19 Dec 2008 17:24:48 +0100, H.Merijn Brand h.m.br...@xs4all.nl wrote: Now that perl VCS has moved from perforce to git, the rsync address should also change. Note that the old address will still work, but it will have a considerable delay, as that will rsync itself from the new address For all your _config files, you will have to change the lines that look like source = public.activestate.com::perl-current, to source = perl5.git.perl.or::perl-current, ^ perl5.git.perl.org terribly sorry there 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.
Re: Change your rsync address(es)
Rafael Garcia-Suarez wrote: 2008/12/19 Jerry D. Hedden jdhed...@cpan.org: On Fri, Dec 19, 2008 at 12:24 PM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). It may work, but those type of change numbers are not human readable. You get the branch name, the timestamp, (on which you can do a lexicographic comparison), and the SHA1 of the head. How more human readable can we get ? 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 DEVELblead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2 built for i686-linux # (with 1 registered patch, see perl -V for more detail) # # Copyright 1987-2008, Larry Wall # # Perl may be copied only under the terms of either the Artistic License or the # GNU General Public License, which may be found in the Perl 5 source kit. # # Complete documentation for Perl, including FAQ lists, should be found on # this system using man perl or perldoc perl. If you have access to the # Internet, point your browser at http://www.perl.org/, the Perl Home Page. # # ' # expected /(?s-xim:This is perl, v5.11.0 (?:DEVEL\d+ )?built for i686\-linux.+Copyright.+Larry Wall.+Artistic License.+GNU General Public License)/
RE: Change your rsync address(es)
Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). From: Steve Hay [steve...@planit.com] Sent: 19 December 2008 15:56 To: Steve Hay Subject: Smoke [5.11.0] 200812191515071484878807271565689857 PASS MSWin32 WinXP/.Net SP3 (x86/2 cpu) Automated smoke report for 5.11.0 patch 200812191515071484878807271565689857 maldoror.bath.planit.group: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz(~2660 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP3 using cl version 12.00.8804 smoketime 27 minutes 58 seconds (average 13 minutes 59 seconds) Summary: PASS O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 200812191515071484878807271565689857 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - O O | +- -DDEBUGGING +--- no debugging Locally applied patches: DEVEL SMOKE200812191515071484878807271565689857 MANIFEST did not declare '.GITIGNORE' MANIFEST did not declare 'EXT/.GITIGNORE' MANIFEST did not declare 'EXT/B/.GITIGNORE' MANIFEST did not declare 'EXT/BYTELOADER/.GITIGNORE' MANIFEST did not declare 'EXT/COMPRESS/RAW/ZLIB/.GITIGNORE' MANIFEST did not declare 'EXT/DB_FILE/.GITIGNORE' MANIFEST did not declare 'EXT/DEVEL/.GITIGNORE' MANIFEST did not declare 'EXT/DEVEL/PPPORT/.GITIGNORE' MANIFEST did not declare 'EXT/DYNALOADER/.GITIGNORE' MANIFEST did not declare 'EXT/ENCODE/.GITIGNORE' MANIFEST did not declare 'EXT/ERRNO/.GITIGNORE' MANIFEST did not declare 'EXT/FCNTL/.GITIGNORE' MANIFEST did not declare 'EXT/FILE/.GITIGNORE' MANIFEST did not declare 'EXT/FILE/GLOB/.GITIGNORE' MANIFEST did not declare 'EXT/GDBM_FILE/.GITIGNORE' MANIFEST did not declare 'EXT/I18N/LANGINFO/.GITIGNORE' MANIFEST did not declare 'EXT/IO/.GITIGNORE' MANIFEST did not declare 'EXT/IPC/SYSV/.GITIGNORE' MANIFEST did not declare 'EXT/POSIX/.GITIGNORE' MANIFEST did not declare 'EXT/SDBM_FILE/SDBM/.GITIGNORE' MANIFEST did not declare 'EXT/SOCKET/.GITIGNORE' MANIFEST did not declare 'EXT/SYS/SYSLOG/.GITIGNORE' MANIFEST did not declare 'EXT/TIME/HIRES/.GITIGNORE' MANIFEST did not declare 'EXT/UNICODE/NORMALIZE/.GITIGNORE' MANIFEST did not declare 'EXT/WIN32CORE/.GITIGNORE' MANIFEST did not declare 'EXT/XS/.GITIGNORE' MANIFEST did not declare 'EXT/XS/APITEST/.GITIGNORE' MANIFEST did not declare 'LIB/.GITIGNORE' MANIFEST did not declare 'LIB/ARCHIVE/EXTRACT/T/SRC/.GITIGNORE' MANIFEST did not declare 'LIB/ARCHIVE/TAR/T/SRC/.GITIGNORE' MANIFEST did not declare 'LIB/CGI/T/.GITIGNORE' MANIFEST did not declare 'LIB/CPANPLUS/.GITIGNORE' MANIFEST did not declare 'POD/.GITIGNORE' MANIFEST did not declare 'PORTING/GIT-FIND-P4-CHANGE' MANIFEST did not declare 'T/.GITIGNORE' MANIFEST did not declare 'T/MODULE_PLUGGABLE/LIB/EDITORJUNK/PLUGIN/.GITIGNORE' MANIFEST did not declare 'T/MODULE_PLUGGABLE/LIB/ODDTEST/PLUGIN/.GITIGNORE' MANIFEST did not declare 'UTILS/.GITIGNORE' MANIFEST did not declare 'X2P/.GITIGNORE' Compiler messages(MSWin32): Cwd.xs(77) : warning C4101: 'symlink' : unreferenced local variable -- Report by Test::Smoke v1.36 build 1210 running on perl 5.11.0 (Reporter v0.033 / Smoker v0.041)
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 11:24 AM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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: Change your rsync address(es)
Craig A. Berry wrote: On Fri, Dec 19, 2008 at 11:24 AM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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. It's the spaces that cause the problem. If I change them to dashes it works. Here's a command line after the spaces have been changed. `sh cflags optimize='-O0 -g3' op.o` op.c CCCMD = cc -DPERL_CORE -c -DPERL_PATCHNUM=blead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2 -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O0 -g3 -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 11:19 AM, Rafael Garcia-Suarez rgarciasua...@gmail.com wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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, 19 Dec 2008 17:24:48 +0100, H.Merijn Brand h.m.br...@xs4all.nl wrote: Now that perl VCS has moved from perforce to git, the rsync address should also change. Note that the old address will still work, but it will have a considerable delay, as that will rsync itself from the new address For all your _config files, you will have to change the lines that look like source = public.activestate.com::perl-current, to source = perl5.git.perl.or::perl-current, ^ perl5.git.perl.org terribly sorry there -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00, 11.11, 11.23, and 11.31, SuSE 10.1, 10.3, and 11.0, AIX 5.2, and Cygwin. http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/
Re: Change your rsync address(es)
2008/12/19 karl williamson pub...@khwilliamson.com: 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.
RE: Change your rsync address(es)
Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). From: Steve Hay [steve...@planit.com] Sent: 19 December 2008 15:56 To: Steve Hay Subject: Smoke [5.11.0] 200812191515071484878807271565689857 PASS MSWin32 WinXP/.Net SP3 (x86/2 cpu) Automated smoke report for 5.11.0 patch 200812191515071484878807271565689857 maldoror.bath.planit.group: Intel(R) Core(TM)2 CPU 6700 @ 2.66GHz(~2660 MHz) (x86/2 cpu) onMSWin32 - WinXP/.Net SP3 using cl version 12.00.8804 smoketime 27 minutes 58 seconds (average 13 minutes 59 seconds) Summary: PASS O = OK F = Failure(s), extended report at the bottom X = Failure(s) under TEST but not under harness ? = still running or test results not (yet) available Build failures during: - = unknown or N/A c = Configure, m = make, M = make (after miniperl), t = make test-prep 200812191515071484878807271565689857 Configuration (common) -DINST_TOP=$(INST_DRV)\Smoke\doesntexist --- - O O | +- -DDEBUGGING +--- no debugging Locally applied patches: DEVEL SMOKE200812191515071484878807271565689857 MANIFEST did not declare '.GITIGNORE' MANIFEST did not declare 'EXT/.GITIGNORE' MANIFEST did not declare 'EXT/B/.GITIGNORE' MANIFEST did not declare 'EXT/BYTELOADER/.GITIGNORE' MANIFEST did not declare 'EXT/COMPRESS/RAW/ZLIB/.GITIGNORE' MANIFEST did not declare 'EXT/DB_FILE/.GITIGNORE' MANIFEST did not declare 'EXT/DEVEL/.GITIGNORE' MANIFEST did not declare 'EXT/DEVEL/PPPORT/.GITIGNORE' MANIFEST did not declare 'EXT/DYNALOADER/.GITIGNORE' MANIFEST did not declare 'EXT/ENCODE/.GITIGNORE' MANIFEST did not declare 'EXT/ERRNO/.GITIGNORE' MANIFEST did not declare 'EXT/FCNTL/.GITIGNORE' MANIFEST did not declare 'EXT/FILE/.GITIGNORE' MANIFEST did not declare 'EXT/FILE/GLOB/.GITIGNORE' MANIFEST did not declare 'EXT/GDBM_FILE/.GITIGNORE' MANIFEST did not declare 'EXT/I18N/LANGINFO/.GITIGNORE' MANIFEST did not declare 'EXT/IO/.GITIGNORE' MANIFEST did not declare 'EXT/IPC/SYSV/.GITIGNORE' MANIFEST did not declare 'EXT/POSIX/.GITIGNORE' MANIFEST did not declare 'EXT/SDBM_FILE/SDBM/.GITIGNORE' MANIFEST did not declare 'EXT/SOCKET/.GITIGNORE' MANIFEST did not declare 'EXT/SYS/SYSLOG/.GITIGNORE' MANIFEST did not declare 'EXT/TIME/HIRES/.GITIGNORE' MANIFEST did not declare 'EXT/UNICODE/NORMALIZE/.GITIGNORE' MANIFEST did not declare 'EXT/WIN32CORE/.GITIGNORE' MANIFEST did not declare 'EXT/XS/.GITIGNORE' MANIFEST did not declare 'EXT/XS/APITEST/.GITIGNORE' MANIFEST did not declare 'LIB/.GITIGNORE' MANIFEST did not declare 'LIB/ARCHIVE/EXTRACT/T/SRC/.GITIGNORE' MANIFEST did not declare 'LIB/ARCHIVE/TAR/T/SRC/.GITIGNORE' MANIFEST did not declare 'LIB/CGI/T/.GITIGNORE' MANIFEST did not declare 'LIB/CPANPLUS/.GITIGNORE' MANIFEST did not declare 'POD/.GITIGNORE' MANIFEST did not declare 'PORTING/GIT-FIND-P4-CHANGE' MANIFEST did not declare 'T/.GITIGNORE' MANIFEST did not declare 'T/MODULE_PLUGGABLE/LIB/EDITORJUNK/PLUGIN/.GITIGNORE' MANIFEST did not declare 'T/MODULE_PLUGGABLE/LIB/ODDTEST/PLUGIN/.GITIGNORE' MANIFEST did not declare 'UTILS/.GITIGNORE' MANIFEST did not declare 'X2P/.GITIGNORE' Compiler messages(MSWin32): Cwd.xs(77) : warning C4101: 'symlink' : unreferenced local variable -- Report by Test::Smoke v1.36 build 1210 running on perl 5.11.0 (Reporter v0.033 / Smoker v0.041)
Re: Change your rsync address(es)
2008/12/19 karl williamson pub...@khwilliamson.com: Craig A. Berry wrote: On Fri, Dec 19, 2008 at 11:24 AM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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. It's the spaces that cause the problem. If I change them to dashes it works. Here's a command line after the spaces have been changed. `sh cflags optimize='-O0 -g3' op.o` op.c CCCMD = cc -DPERL_CORE -c -DPERL_PATCHNUM=blead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2 -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O0 -g3 -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat I see. I'll change them to dashes then. But anyway Test::Smoke should be amended to cope with non-digits.
Re: Change your rsync address(es)
2008/12/19 Jerry D. Hedden jdhed...@cpan.org: On Fri, Dec 19, 2008 at 12:24 PM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). It may work, but those type of change numbers are not human readable. You get the branch name, the timestamp, (on which you can do a lexicographic comparison), and the SHA1 of the head. How more human readable can we get ?
Re: Change your rsync address(es)
Craig A. Berry wrote: On Fri, Dec 19, 2008 at 11:24 AM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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. It's the spaces that cause the problem. If I change them to dashes it works. Here's a command line after the spaces have been changed. `sh cflags optimize='-O0 -g3' op.o` op.c CCCMD = cc -DPERL_CORE -c -DPERL_PATCHNUM=blead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2 -DDEBUGGING -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -std=c89 -O0 -g3 -Wall -ansi -W -Wextra -Wdeclaration-after-statement -Wendif-labels -Wc++-compat
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 11:24 AM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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: Change your rsync address(es)
Rafael Garcia-Suarez wrote: 2008/12/19 Jerry D. Hedden jdhed...@cpan.org: On Fri, Dec 19, 2008 at 12:24 PM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). It may work, but those type of change numbers are not human readable. You get the branch name, the timestamp, (on which you can do a lexicographic comparison), and the SHA1 of the head. How more human readable can we get ? 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 DEVELblead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2 built for i686-linux # (with 1 registered patch, see perl -V for more detail) # # Copyright 1987-2008, Larry Wall # # Perl may be copied only under the terms of either the Artistic License or the # GNU General Public License, which may be found in the Perl 5 source kit. # # Complete documentation for Perl, including FAQ lists, should be found on # this system using man perl or perldoc perl. If you have access to the # Internet, point your browser at http://www.perl.org/, the Perl Home Page. # # ' # expected /(?s-xim:This is perl, v5.11.0 (?:DEVEL\d+ )?built for i686\-linux.+Copyright.+Larry Wall.+Artistic License.+GNU General Public License)/
Re: Change your rsync address(es)
H.Merijn Brand wrote: On Fri, 19 Dec 2008 17:24:48 +0100, H.Merijn Brand h.m.br...@xs4all.nl wrote: Now that perl VCS has moved from perforce to git, the rsync address should also change. Note that the old address will still work, but it will have a considerable delay, as that will rsync itself from the new address For all your _config files, you will have to change the lines that look like source = public.activestate.com::perl-current, to source = perl5.git.perl.or::perl-current, ^ perl5.git.perl.org terribly sorry there 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.
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 12:24 PM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). It may work, but those type of change numbers are not human readable.
Re: Change your rsync address(es)
On Fri, Dec 19, 2008 at 11:19 AM, Rafael Garcia-Suarez rgarciasua...@gmail.com wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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)
12/19 karl williamson pub...@khwilliamson.com: Rafael Garcia-Suarez wrote: 2008/12/19 Jerry D. Hedden jdhed...@cpan.org: On Fri, Dec 19, 2008 at 12:24 PM, Steve Hay steve...@planit.com wrote: Rafael Garcia-Suarez wrote: 2008/12/19 karl williamson pub...@khwilliamson.com: 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). It may work, but those type of change numbers are not human readable. You get the branch name, the timestamp, (on which you can do a lexicographic comparison), and the SHA1 of the head. How more human readable can we get ? 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 DEVELblead-20081219.17:05:08-b1fccde5a5d6d9eece3886ce5cb9dc7b9027bee2 built for i686-linux # (with 1 registered patch, see perl -V for more detail) # # Copyright 1987-2008, Larry Wall # # Perl may be copied only under the terms of either the Artistic License or the # GNU General Public License, which may be found in the Perl 5 source kit. # # Complete documentation for Perl, including FAQ lists, should be found on # this system using man perl or perldoc perl. If you have access to the # Internet, point your browser at http://www.perl.org/, the Perl Home Page. # # ' # expected /(?s-xim:This is perl, v5.11.0 (?:DEVEL\d+ )?built for i686\-linux.+Copyright.+Larry Wall.+Artistic License.+GNU General Public License)/ 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. There is an odd facet of Perforce, or at least the way we used it, there is no Perfoce commit that corresponds to the released versions. the released versions actually correspond to a state in between two commits we have. This will change with git, but give it some time. And yes, we can look into changing the contents of the patch file. Currently what is in there is for a good reason but clearly we, and the community as a whole, have to do some refinements. Anyway, baby steps leads to giant leaps forward, so bear with us here. -- perl -Mre=debug -e /just|another|perl|hacker/
