You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Chris Hostetter <ho...@fucit.org> on 2011/11/01 18:15:09 UTC
Re: [lucy-dev] [VOTE] Apache Lucy (incubating) 0.2.2 RC 1
: 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
[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