You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2011/10/20 05:42:36 UTC
[lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Hello,
Release candidate 1 for Apache Lucy (incubating) version 0.2.2 can
be found at:
http://people.apache.org/~karpet/apache-lucy-incubating-0.2.2-rc1/
See the CHANGES file at the top level of the archive for information about the
content of this release.
This candidate was assembled according to the process documented at:
http://wiki.apache.org/lucy/ReleaseGuide
It was cut from an "svn export" of the tag at:
https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-0.2.2-rc1
Please vote on releasing this candidate as Apache Lucy (incubating) version
0.2.2. The vote will be held open for at least the next 72 hours.
All interested parties are welcome to inspect the release candidate and
express approval or disapproval. Votes from members of the Lucy PPMC and/or
Incubator PMC are binding; the vote passes if there are at least three binding
+1 votes and more +1 votes than -1 votes.
Should this vote pass, a ratifying vote of the Incubator PMC will be held on
general@incubator.a.o. Any votes cast by Incubator PMC members here will be
carried forward into that vote.
For suggestions as to how to evaluate Apache Lucy release candidates, and for
information on ASF voting procedures, see:
http://wiki.apache.org/lucy/ReleaseVerification
http://wiki.apache.org/lucy/ReleasePrep
http://www.apache.org/foundation/voting.html
[ ] +1 Release RC 1 as Apache Lucy (incubating) version 0.2.2.
[ ] +0
[ ] -1 Do not release RC 1 as Apache Lucy (incubating) version 0.2.2 because...
Thanks!
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
Hi Peter,
+1.
* Changelog looks good.
* MD5 Checksums OK:
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann% openssl md5 apache-lucy-incubating-0.2.2.tar.gz
MD5(apache-lucy-incubating-0.2.2.tar.gz)= 7c58ba5fa2f729b7dfb2606c1b82c604
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann% cat *.md5
apache-lucy-incubating-0.2.2.tar.gz: 7C 58 BA 5F A2 F7 29 B7 DF B2 60 6C 1B 82
C6 04
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann%
* SHA checksum weird:
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann% !cat
cat *.sha
apache-lucy-incubating-0.2.2.tar.gz: 54D6AB4A AC7EFB65 DF44C5E9 5C684935
48631A35 6D9CB9E8 8C53862A 01DD15FE
520D54D4 A9C1A848 D4F52212 CB53EBC2
A9850DAB 5AABA783 DB1E0CDB 2B4DF206
No clue what's up there, but not a blocker in my mind.
* Signature looks good:
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann% curl -O http://www.apache.org/dist/incubator/lucy/KEYS
gpg --import KE % Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 8807 100 8807 0 0 2923 0 0:00:03 0:00:03 --:--:-- 25453YS
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann% gpg --import KEYS
gpg: key B876884A: "Chris Mattmann (CODE SIGNING KEY) <ma...@apache.org>" not changed
gpg: key D8408955: "Marvin Humphrey (CODE SIGNING KEY) <ma...@apache.org>" not changed
gpg: key 4A7DB092: public key "Peter Karman (CODE SIGNING KEY) <ka...@apache.org>" imported
gpg: Total number processed: 3
gpg: imported: 1 (RSA: 1)
gpg: unchanged: 2
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann% gpg --verify apache-lucy-incubating-0.2.2.tar.gz.asc
gpg: Signature made Wed Oct 19 23:37:37 2011 EDT using RSA key ID 4A7DB092
gpg: Good signature from "Peter Karman (CODE SIGNING KEY) <ka...@apache.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 52CF C03E D308 A026 33B2 4258 2625 1987 4A7D B092
[chipotle:~/tmp/lucy-0.2.2-rc1] mattmann%
* Builds OK and all tests PASS
Manifying blib/lib/LucyX/Index/ByteBufDocReader.pm -> blib/libdoc/LucyX::Index::ByteBufDocReader.3pm
Manifying blib/lib/Lucy/Docs/Cookbook/CustomQueryParser.pod -> blib/libdoc/Lucy::Docs::Cookbook::CustomQueryParser.3pm
Manifying blib/lib/Lucy/Index/LexiconReader.pod -> blib/libdoc/Lucy::Index::LexiconReader.3pm
Manifying blib/lib/Lucy/Search/MatchAllQuery.pod -> blib/libdoc/Lucy::Search::MatchAllQuery.3pm
Manifying blib/lib/Lucy/Store/Lock.pod -> blib/libdoc/Lucy::Store::Lock.3pm
Manifying blib/lib/Lucy/Search/PolyQuery.pod -> blib/libdoc/Lucy::Search::PolyQuery.3pm
t/core/531-or_query..................ok
All tests successful, 3 tests and 10 subtests skipped.
Files=169, Tests=11246, 23 wallclock secs (17.35 cusr + 2.41 csys = 19.76 CPU)
Looks great! Sorry it took me so long! Great job Peter!
Cheers,
Chris
On Oct 19, 2011, at 11:42 PM, Peter Karman wrote:
> Hello,
>
> Release candidate 1 for Apache Lucy (incubating) version 0.2.2 can
> be found at:
>
> http://people.apache.org/~karpet/apache-lucy-incubating-0.2.2-rc1/
>
> See the CHANGES file at the top level of the archive for information about the
> content of this release.
>
> This candidate was assembled according to the process documented at:
>
> http://wiki.apache.org/lucy/ReleaseGuide
>
> It was cut from an "svn export" of the tag at:
>
>
> https://svn.apache.org/repos/asf/incubator/lucy/tags/apache-lucy-incubating-0.2.2-rc1
>
> Please vote on releasing this candidate as Apache Lucy (incubating) version
> 0.2.2. The vote will be held open for at least the next 72 hours.
>
> All interested parties are welcome to inspect the release candidate and
> express approval or disapproval. Votes from members of the Lucy PPMC and/or
> Incubator PMC are binding; the vote passes if there are at least three binding
> +1 votes and more +1 votes than -1 votes.
>
> Should this vote pass, a ratifying vote of the Incubator PMC will be held on
> general@incubator.a.o. Any votes cast by Incubator PMC members here will be
> carried forward into that vote.
>
> For suggestions as to how to evaluate Apache Lucy release candidates, and for
> information on ASF voting procedures, see:
>
> http://wiki.apache.org/lucy/ReleaseVerification
> http://wiki.apache.org/lucy/ReleasePrep
> http://www.apache.org/foundation/voting.html
>
> [ ] +1 Release RC 1 as Apache Lucy (incubating) version 0.2.2.
> [ ] +0
> [ ] -1 Do not release RC 1 as Apache Lucy (incubating) version 0.2.2 because...
>
> Thanks!
>
>
> --
> Peter Karman . http://peknet.com/ . peter@peknet.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Re: [lucy-dev] Re: [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by "Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>.
I hear you -- I will take a look tomorrow, sorry have been busy.
Cheers,
Chris
On Oct 23, 2011, at 7:05 PM, Peter Karman wrote:
> Peter Karman wrote on 10/19/11 10:42 PM:
>
>>
>> Should this vote pass, a ratifying vote of the Incubator PMC will be held on
>> general@incubator.a.o. Any votes cast by Incubator PMC members here will be
>> carried forward into that vote.
>
> Would be nice to hear from more IPMC members on this lucy-dev VOTE thread.
>
> Thanks.
>
> --
> Peter Karman . http://peknet.com/ . peter@peknet.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW: http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
[lucy-dev] Re: [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Peter Karman <pe...@peknet.com>.
Peter Karman wrote on 10/19/11 10:42 PM:
>
> Should this vote pass, a ratifying vote of the Incubator PMC will be held on
> general@incubator.a.o. Any votes cast by Incubator PMC members here will be
> carried forward into that vote.
Would be nice to hear from more IPMC members on this lucy-dev VOTE thread.
Thanks.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Dan Markham <dm...@gmail.com>.
+1
All tests successful.
Files=169, Tests=11246, 28 wallclock secs ( 2.10 usr 0.49 sys + 21.70 cusr 2.50 csys = 26.79 CPU)
Result: PASS
-Dan
On Oct 19, 2011, at 10:40 PM, David E. Wheeler wrote:
> On Oct 19, 2011, at 8:42 PM, Peter Karman wrote:
>
>> [X] +1 Release RC 1 as Apache Lucy (incubating) version 0.2.2.
>> [ ] +0
>> [ ] -1 Do not release RC 1 as Apache Lucy (incubating) version 0.2.2 because...
>
> MD5 checks out, all tests pass:
>
> Files=169, Tests=11246, 29 wallclock secs ( 1.73 usr 0.57 sys + 17.49 cusr 3.19 csys = 22.98 CPU)
> Result: PASS
>
> Best,
>
> David
>
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Oct 19, 2011, at 8:42 PM, Peter Karman wrote:
> [X] +1 Release RC 1 as Apache Lucy (incubating) version 0.2.2.
> [ ] +0
> [ ] -1 Do not release RC 1 as Apache Lucy (incubating) version 0.2.2 because...
MD5 checks out, all tests pass:
Files=169, Tests=11246, 29 wallclock secs ( 1.73 usr 0.57 sys + 17.49 cusr 3.19 csys = 22.98 CPU)
Result: PASS
Best,
David
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1 (cleanup)
Posted by Marvin Humphrey <ma...@rectangular.com>.
Hi Moritz, thanks for reviewing the release candidate and reporting your
findings!
On Sat, Oct 22, 2011 at 08:26:15PM +0200, Moritz Lenz wrote:
> FWIW all tests pass on Debian GNU/Linux stable with a custom perl
> 5.14.1, same with the system perl (5.10.1).
:)
> However I had to wipe out the directory between the two tests, because
> the build and configuration left some files behind which ./Build clean
> in the perl/ subdirectory did not clean, and which caused some @INC
> paths to be set up wrongly.
I believe that this patch to the 0.2 branch would produce your desired
behavior:
--- perl/buildlib/Lucy/Build.pm (revision 1187752)
+++ perl/buildlib/Lucy/Build.pm (working copy)
@@ -716,8 +716,8 @@
sub ACTION_clean {
my $self = shift;
if ( -e $CLOWNFISH_BUILD ) {
- system("$^X $CLOWNFISH_BUILD clean")
- and die "Clownfish clean failed";
+ system("$^X $CLOWNFISH_BUILD realclean")
+ and die "Clownfish realclean failed";
}
$self->_run_make( dir => $CHARMONIZER_ORIG_DIR, args => ['clean'] );
$self->SUPER::ACTION_clean;
I'm not sure that's technically "correct", because I think you are supposed to
supposed to invoke './Build realclean' rather than './Build clean' when
switching Perl executables. However, it seems that './Build clean' works
under ordinary circumstances whether or not it ought to, and so +1 to make it
work for Lucy.
Can you please open a ticket?
http://issues.apache.org/jira/browse/LUCY
Marvin Humphrey
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1 (cleanup)
Posted by Moritz Lenz <mo...@faui2k3.org>.
FWIW all tests pass on Debian GNU/Linux stable with a custom perl
5.14.1, same with the system perl (5.10.1).
However I had to wipe out the directory between the two tests, because
the build and configuration left some files behind which ./Build clean
in the perl/ subdirectory did not clean, and which caused some @INC
paths to be set up wrongly.
Here is the list of files that remain after a
$ cd perl/
$ perl Build.PL
$ ./Build test
$ ./Build clean
list of files:
# clownfish/Build
# clownfish/MYMETA.json
# clownfish/MYMETA.yml
# clownfish/_build/
# perl/Build
# perl/MYMETA.json
# perl/MYMETA.yml
# perl/_build/
In particular the clownfish/Build script contains a path to the perl
binary that was used to run Build.PL in the perl/ directory, but when
running the perl/Build.PL with a different perl binary again, the
clownfish/Build file is not regenerated.
So this is a relative obscure case, and I don't think it should hold off
the release, but it would be nice if './Build clean' was a bit more
thorough -- at least the {perl,clownfish/_build/ directories should be
cleaned, IMHO. The MYMETA files are harmless.
Cheers,
Moritz
[lucy-dev] [RESULTS] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Peter Karman <pe...@peknet.com>.
Peter Karman wrote on 10/19/11 10:42 PM:
> Release candidate 1 for Apache Lucy (incubating) version 0.2.2
The VOTE for 0.2.2 is now closed. The release candidate 1 is approved with seven
+1 votes:
David Wheeler *
Dan Markham
Peter Karman *
Marvin Humphrey *+
Moritz Lenz
Chris Hostetter *+
Chris Mattmann *+
* indicates Lucy PPMC member
+ indicates Incubator PMC member
Thanks for voting.
pek
--
Peter Karman . http://peknet.com/ . peter@peknet.com
[lucy-dev] Generating checksums chewable by md5sum/shasum
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Nov 01, 2011 at 10:15:09AM -0700, Chris Hostetter wrote:
> 0) (as noted on the wiki) the SHA and MD5 sig formats don't match any
> format i've ever seen before -- making them impossible to check in an
> automated fasion using things like "md5sum -c" or "sha512sum -c" ...
We have heretofore used GnuPG to generate those. It was convenient, because
we knew that it would be on the RM's machine, since the RM would need it to
generate PGP sigs.
> if there is *any* app that can automate the verification of these sigs, that
> should be documented somewhere.
I've committed a change to release_commands.pl so that in the future, RMs will
use Perl instead of GnuPG to generate checksums.
The commands are somewhat lengthy, but they produce digests that md5sum and
shasum can chew.
perl -MDigest -e '$d = Digest->new("MD5"); open $fh, "<apache-lucy-incubating-0.2.2.tar.gz" or die; $d->addfile($fh); print $d->hexdigest; print " apache-lucy-incubating-0.2.2.tar.gz\n"' > apache-lucy-incubating-0.2.2.tar.gz.md5
perl -MDigest -e '$d = Digest->new("SHA-512"); open $fh, "<apache-lucy-incubating-0.2.2.tar.gz" or die; $d->addfile($fh); print $d->hexdigest; print " apache-lucy-incubating-0.2.2.tar.gz\n"' > apache-lucy-incubating-0.2.2.tar.gz.sha
I've also updated the Wiki page to include instructions on how to verify with
md5sum/shasum when available, falling back to eyeballing if necessary.
Marvin Humphrey
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Nov 02, 2011 at 08:51:46PM -0700, Nathan Kurz wrote:
> On Wed, Nov 2, 2011 at 7:52 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> > Here's the line in question:
> >
> > fprintf(stderr, "Can't malloc %" U64P " bytes.\n", (uint64_t)count);
> >
> > Thanks for pointing these warnings out, Hoss. I would like to silence them,
> > but it's hard to do that portably -- for instance, we can't cast to "long long
> > int" because it's not there on all systems.
>
> I do believe that we should compile warning free, but I'm not sure I'm
> understanding the issue here. Hoss's error is on GCC, we're
> targetting C99, and you already have U64P defined as a macro?
Our dialect is the intersection of C99 and C++, which gets us nice things
like mixed declarations and code and double-slash comments, but does not
guarantee the availablility of "%zu".
> Wouldn't "%zu" work fine without the cast? I think it's standard C99 at
> this point, and not just a GCC extension. But if you've got a macro anyway,
> it should be fine to use. Historically, the reason to avoid it was support
> under Windows, where you would have to use "%Iu" (that's a capital 'i', not
> a lower case 'L').
>
> http://msdn.microsoft.com/en-us/library/tcxf1dw6(v=VS.100).aspx
>
> Or am I missing another layer of complexity?
"%zu" is indeed C99.
OK, this isn't so hard to solve after all. We can just have Charmonizer
define a macro which defines the size_t print format in a way which both works
for MSVC (in C++ mode) and which doesn't make GCC squeal.
Marvin Humphrey
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Nathan Kurz <na...@verse.com>.
On Wed, Nov 2, 2011 at 7:52 PM, Marvin Humphrey <ma...@rectangular.com> wrote:
> Here's the line in question:
>
> fprintf(stderr, "Can't malloc %" U64P " bytes.\n", (uint64_t)count);
>
> Thanks for pointing these warnings out, Hoss. I would like to silence them,
> but it's hard to do that portably -- for instance, we can't cast to "long long
> int" because it's not there on all systems.
I do believe that we should compile warning free, but I'm not sure I'm
understanding the issue here. Hoss's error is on GCC, we're
targetting C99, and you already have U64P defined as a macro?
Wouldn't "%zu" work fine without the cast? I think it's standard C99
at this point, and not just a GCC extension. But if you've got a
macro anyway, it should be fine to use. Historically, the reason to
avoid it was support under Windows, where you would have to use "%Iu"
(that's a capital 'i', not a lower case 'L').
http://msdn.microsoft.com/en-us/library/tcxf1dw6(v=VS.100).aspx
Or am I missing another layer of complexity?
--nate
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Joe Schaefer <jo...@yahoo.com>.
D00d relax, warnings aren't errors unless you
want them to be. Gcc is wonderfully inconsistent
between versions and has always been that way
(assuming that's the culprit here).
I don't support writing around compiler warnings,
especially not from gcc, unless the compiler is
actually generating the wrong result as a consequence.
>________________________________
>From: Marvin Humphrey <ma...@rectangular.com>
>To: lucy-dev@incubator.apache.org
>Cc: peter@peknet.com
>Sent: Wednesday, November 2, 2011 10:52 PM
>Subject: Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
>
>On Tue, Nov 01, 2011 at 10:15:09AM -0700, Chris Hostetter wrote:
>> 3) A few misc warnings popped up during C compilation...
>
>Grr. These are annoying.
>
>> /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c:259: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’
>
>The compiler is crying wolf.
>
>It's not important to distinguish between a signed 64-bit integer type named
>"long long int" and another signed 64-bit integer type named "int64_t" when
>passing arguments to *printf. The compiler ought to be smart enough to figure
>out that those are equivalent.
>
>> /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:28: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘size_t’
>
>Here's the line in question:
>
> fprintf(stderr, "Can't malloc %" U64P " bytes.\n", (uint64_t)count);
>
>The variable "count" is indeed a "size_t". However, it is specifically being
>cast to a uint64_t so that fprintf will get a 64-bit integer to go with that
>64-bit format string specifier regardless of whether size_t is 32 bits or
>64 bits.
>
>Thanks for pointing these warnings out, Hoss. I would like to silence them,
>but it's hard to do that portably -- for instance, we can't cast to "long long
>int" because it's not there on all systems.
>
>For the second case, we could theoretically create a temporary uint64_t
>variable and stop the compiler from complaining about size_t. But I'm almost
>positive the compiler would then whine about a uint64_t not being the "long
>long unsigned int" it wants to see paired with "%llu".
>
>Marvin Humphrey
>
>
>
>
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Nov 01, 2011 at 10:15:09AM -0700, Chris Hostetter wrote:
> 3) A few misc warnings popped up during C compilation...
Grr. These are annoying.
> /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c:259: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’
The compiler is crying wolf.
It's not important to distinguish between a signed 64-bit integer type named
"long long int" and another signed 64-bit integer type named "int64_t" when
passing arguments to *printf. The compiler ought to be smart enough to figure
out that those are equivalent.
> /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:28: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘size_t’
Here's the line in question:
fprintf(stderr, "Can't malloc %" U64P " bytes.\n", (uint64_t)count);
The variable "count" is indeed a "size_t". However, it is specifically being
cast to a uint64_t so that fprintf will get a 64-bit integer to go with that
64-bit format string specifier regardless of whether size_t is 32 bits or
64 bits.
Thanks for pointing these warnings out, Hoss. I would like to silence them,
but it's hard to do that portably -- for instance, we can't cast to "long long
int" because it's not there on all systems.
For the second case, we could theoretically create a temporary uint64_t
variable and stop the compiler from complaining about size_t. But I'm almost
positive the compiler would then whine about a uint64_t not being the "long
long unsigned int" it wants to see paired with "%llu".
Marvin Humphrey
Re: [lucy-dev] Module::Build sneakily configuring configure_requires
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 7, 2011, at 9:52 AM, David E. Wheeler wrote:
>> trunk and 0.2
>
> Done and uploaded to PAUSE. Should appear on a CPAN mirror near you shortly.
A few notes on the release:
• `./Build disttest` does not work. Seems that the dist target has been overridden to pre-compile stuff. Ideally, that work should be moved to another Build target and made a dependency of both the `dist` and `disttest` targets.
• Once I uploaded to PAUSE, I found that I did not have co-maint of Lucy::Test::TestCharmonizer. The release manager needs to have permission to release *all* classes in the distribution, or else the whole distribution will be marked as unofficial. Furthermore, if there are new classes in a release, the releaser will get ownership of those new modules. These will need to be transferred to all other release managers via PAUSE.
Marvin gave me permission to Lucy::Test::TestCharmonizer after upload, so CPAN should re-index it and make it an official release in the next day or so. So I think we're good for this release. But I recommend that `./Build disttest` be fixed, and that the number of class changes between releases be kept to a minimum. Private package namespaces can be hidden from the indexer by declaring them on two lines. The DBI does this, for example, in DBI.pm:
{ package # hide from PAUSE
DBD::Switch::dr;
# ...
}
Best,
David
Re: [lucy-dev] Module::Build sneakily configuring configure_requires
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 3, 2011, at 10:04 AM, Peter Karman wrote:
>> Great. Is there a particular branch I should commit the change to?
>>
>
> trunk and 0.2
Done and uploaded to PAUSE. Should appear on a CPAN mirror near you shortly.
Best,
David
Re: [lucy-dev] Module::Build sneakily configuring configure_requires
Posted by Peter Karman <pe...@peknet.com>.
David E. Wheeler wrote on 11/3/11 12:03 PM:
> On Nov 3, 2011, at 10:02 AM, Peter Karman wrote:
>
>>> Is it too late to make one of these changes? Has 0.2.2 been tagged and
>>> packaged up, yet?
>>
>> the VOTE thread is on the official release .tar.gz file. The CPAN version can
>> deviate from that official release at your discretion.
>
> Great. Is there a particular branch I should commit the change to?
>
trunk and 0.2
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] Module::Build sneakily configuring configure_requires
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 3, 2011, at 10:02 AM, Peter Karman wrote:
>> Is it too late to make one of these changes? Has 0.2.2 been tagged and
>> packaged up, yet?
>
> the VOTE thread is on the official release .tar.gz file. The CPAN version can
> deviate from that official release at your discretion.
Great. Is there a particular branch I should commit the change to?
D
Re: [lucy-dev] Module::Build sneakily configuring configure_requires
Posted by Peter Karman <pe...@peknet.com>.
David E. Wheeler wrote on 11/3/11 11:54 AM:
> Well, I'll have to add that to the Build.PL in order to prevent Module::Build
> from inserting the latest version of itself. Or we can add
> `auto_configure_requires => 0`.
>
> Is it too late to make one of these changes? Has 0.2.2 been tagged and
> packaged up, yet?
the VOTE thread is on the official release .tar.gz file. The CPAN version can
deviate from that official release at your discretion.
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: [lucy-dev] Module::Build sneakily configuring configure_requires
Posted by "David E. Wheeler" <da...@kineticode.com>.
On Nov 2, 2011, at 8:19 PM, Marvin Humphrey wrote:
> Version 0.36, eh?
>
> We currently list Module::Build in Build.PL under build_requires:
>
> build_requires => {
> 'Module::Build' => 0.280801,
>
> Version 0.280801 is the version that shipped with Perl 5.10.0, when
> Module::Build was added to the Perl core. We don't want to require M::B
> version 0.36 -- that's silly and unnecessary.
>
> But maybe it's OK for M::B to add itself like that under configure_requires
> because versions prior to 0.36 ignored configure_requires? I'm speculating…
It was added in 0.2808_01. Module::Build just inserts its current version if you don't specify it.
> David Wheeler has agreed to perform the CPAN release for Lucy 0.2.2. David,
> can you please make sure that M::B doesn't force its minimum required version
> to 0.36 when you run ./Build dist?
>
> And then probably adding this line to Build.PL would be OK for both trunk and
> our 0.2 branch (assuming that the 0.2 branch has a life beyond 0.2.2, which
> may not be the case.)
>
> configure_requires => { 'Module::Build' => 0.280801 }
Well, I'll have to add that to the Build.PL in order to prevent Module::Build from inserting the latest version of itself. Or we can add `auto_configure_requires => 0`.
Is it too late to make one of these changes? Has 0.2.2 been tagged and packaged up, yet?
Best,
David
[lucy-dev] Module::Build sneakily configuring configure_requires
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Nov 01, 2011 at 10:15:09AM -0700, Chris Hostetter wrote:
> 2) "./Build dist" warned that "Module::Build" was not listed as a pre-req,
> so it was being added automaticly...
>
> --BEGIN--
> Creating META.yml
> Module::Build was not found in configure_requires! Adding it now
> automatically as: configure_requires => { 'Module::Build' => 0.36 }
> --END--
Version 0.36, eh?
We currently list Module::Build in Build.PL under build_requires:
build_requires => {
'Module::Build' => 0.280801,
Version 0.280801 is the version that shipped with Perl 5.10.0, when
Module::Build was added to the Perl core. We don't want to require M::B
version 0.36 -- that's silly and unnecessary.
But maybe it's OK for M::B to add itself like that under configure_requires
because versions prior to 0.36 ignored configure_requires? I'm speculating...
David Wheeler has agreed to perform the CPAN release for Lucy 0.2.2. David,
can you please make sure that M::B doesn't force its minimum required version
to 0.36 when you run ./Build dist?
And then probably adding this line to Build.PL would be OK for both trunk and
our 0.2 branch (assuming that the 0.2 branch has a life beyond 0.2.2, which
may not be the case.)
configure_requires => { 'Module::Build' => 0.280801 }
Marvin Humphrey
[lucy-dev] Parse::RecDescent 1.96.0 vs. 1.94
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Tue, Nov 01, 2011 at 10:15:09AM -0700, Chris Hostetter wrote:
> 1) During both invokations of "perl Build.PL" I got the following
> warning about needing a version of Parse::RecDescent that i already
> had...
>
> --BEGIN--
> Checking prerequisites...
> build_requires:
> ! Parse::RecDescent (1.96.0) is installed, but we need version >= 1.94
>
> ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions
> of the modules indicated above before proceeding with this installation
> --END--
Remember how I made a big fuss over naming Lucy's initial release "0.1.0" and
not "0.1"? Parse::RecDescent has just illustrated why you really, really don't
want to mix X.Y and X.Y.Z version numbers for your CPAN distro.
In Perl, the X.Y.Z version number 1.96.0 numifies as the floating point value
1.096000. 1.096000 is less than 1.94. :P
There's nothing we can do about this. It's a problem with Parse::RecDescent.
Mercifully, the problem will go away once we get to Lucy 0.3.0, since
Parse::RecDescent is no longer a Lucy dependency on trunk.
Marvin Humphrey
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Chris Hostetter <ho...@fucit.org>.
: Release candidate 1 for Apache Lucy (incubating) version 0.2.2 can
: be found at:
:
: http://people.apache.org/~karpet/apache-lucy-incubating-0.2.2-rc1/
...
: [ ] +1 Release RC 1 as Apache Lucy (incubating) version 0.2.2.
+1
* SHA checks out
* MD5 checks out
* ASC checks out
* LICENSE, NOTICE, README, CHANGES, and INSTALL all look good
* perl bindings build and tests pass
...so all in all it looks good to go to me.
### Some comments on oddities noticed that should not block release but
definitely considered for the future...
0) (as noted on the wiki) the SHA and MD5 sig formats don't match any
format i've ever seen before -- making them impossible to check in an
automated fasion using things like "md5sum -c" or "sha512sum -c" ... if
there is *any* app that can automate the verification of these sigs, that
should be documented somewhere.
1) During both invokations of "perl Build.PL" I got the following
warning about needing a version of Parse::RecDescent that i already
had...
--BEGIN--
Checking prerequisites...
build_requires:
! Parse::RecDescent (1.96.0) is installed, but we need version >= 1.94
ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions
of the modules indicated above before proceeding with this installation
--END--
2) "./Build dist" warned that "Module::Build" was not listed as a pre-req,
so it was being added automaticly...
--BEGIN--
Creating META.yml
Module::Build was not found in configure_requires! Adding it now
automatically as: configure_requires => { 'Module::Build' => 0.36 }
--END--
3) A few misc warnings popped up during C compilation...
--BEGIN--
cc -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2 -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core -Iautogen -Ixs -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/modules/analysis/snowstem/source/include -I/usr/lib/perl/5.10/CORE -fPIC -std=gnu99 -D_GNU_SOURCE -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -o /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.o /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c: In function ‘lucy_CB_vcatf’:
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c:259: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Object/CharBuf.c:281: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘uint64_t’
...
cc -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2 -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core -Iautogen -Ixs -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/modules/analysis/snowstem/source/include -I/usr/lib/perl/5.10/CORE -fPIC -std=gnu99 -D_GNU_SOURCE -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -o /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.o /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c: In function ‘lucy_Memory_wrapped_malloc’:
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:28: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘size_t’
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c: In function ‘lucy_Memory_wrapped_calloc’:
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:39: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘size_t’
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:39: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 4 has type ‘size_t’
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c: In function ‘lucy_Memory_wrapped_realloc’:
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Util/Memory.c:49: warning: format ‘%llu’ expects type ‘long long unsigned int’, but argument 3 has type ‘size_t’
...
cc -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2 -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core -Iautogen -Ixs -I/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/modules/analysis/snowstem/source/include -I/usr/lib/perl/5.10/CORE -fPIC -std=gnu99 -D_GNU_SOURCE -c -D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g -o /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Index/SkipStepper.o /home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Index/SkipStepper.c
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Index/SkipStepper.c: In function ‘lucy_SkipStepper_to_string’:
/home/hossman/tmp/lucy-rc/apache-lucy-incubating-0.2.2/perl/Lucy-0.2.2/core/Lucy/Index/SkipStepper.c:55: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64_t’
--END--
-Hoss
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Wed, Oct 19, 2011 at 10:42:36PM -0500, Peter Karman wrote:
> http://people.apache.org/~karpet/apache-lucy-incubating-0.2.2-rc1/
Tested on OS X 10.6 with Perl 5.12.2, plus my ActivePerl, Strawberry Perl and
Cygwin installs -- all pass.
Tarball contents identical to the tag.
Sums and sigs check out.
Looks good to me!
+1
Marvin Humphrey
marvin@smokey:~/Desktop/apache-lucy-incubating-0.2.2-rc1 $ gpg --verify apache-lucy-incubating-0.2.2.tar.gz.asc
gpg: Signature made Wed Oct 19 20:37:37 2011 PDT using RSA key ID 4A7DB092
gpg: Good signature from "Peter Karman (CODE SIGNING KEY) <ka...@apache.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 52CF C03E D308 A026 33B2 4258 2625 1987 4A7D B092
marvin@smokey:~/Desktop/apache-lucy-incubating-0.2.2-rc1 $ gpg --print-md MD5 apache-lucy-incubating-0.2.2.tar.gz
apache-lucy-incubating-0.2.2.tar.gz: 7C 58 BA 5F A2 F7 29 B7 DF B2 60 6C 1B 82
C6 04
marvin@smokey:~/Desktop/apache-lucy-incubating-0.2.2-rc1 $ cat apache-lucy-incubating-0.2.2.tar.gz.md5
apache-lucy-incubating-0.2.2.tar.gz: 7C 58 BA 5F A2 F7 29 B7 DF B2 60 6C 1B 82
C6 04
marvin@smokey:~/Desktop/apache-lucy-incubating-0.2.2-rc1 $ gpg --print-md SHA512 apache-lucy-incubating-0.2.2.tar.gz
apache-lucy-incubating-0.2.2.tar.gz: 54D6AB4A AC7EFB65 DF44C5E9 5C684935
48631A35 6D9CB9E8 8C53862A 01DD15FE
520D54D4 A9C1A848 D4F52212 CB53EBC2
A9850DAB 5AABA783 DB1E0CDB 2B4DF206
marvin@smokey:~/Desktop/apache-lucy-incubating-0.2.2-rc1 $ cat apache-lucy-incubating-0.2.2.tar.gz.sha
apache-lucy-incubating-0.2.2.tar.gz: 54D6AB4A AC7EFB65 DF44C5E9 5C684935
48631A35 6D9CB9E8 8C53862A 01DD15FE
520D54D4 A9C1A848 D4F52212 CB53EBC2
A9850DAB 5AABA783 DB1E0CDB 2B4DF206
marvin@smokey:~/Desktop/apache-lucy-incubating-0.2.2-rc1 $
[lucy-dev] Re: [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
Posted by Peter Karman <pe...@peknet.com>.
Peter Karman wrote on 10/19/11 10:42 PM:
> [X] +1 Release RC 1 as Apache Lucy (incubating) version 0.2.2.
> [ ] +0
> [ ] -1 Do not release RC 1 as Apache Lucy (incubating) version 0.2.2 because...
Here's my +1. All tests passed on OS X 10.6.8 and CentOS 5.6, both with Perl 5.8.9.
--
Peter Karman . http://peknet.com/ . peter@peknet.com