Re: [Gnu-arch-users] Bazaar 1.3 preview

[Robert Collins]

On Wed, 2005-03-30 at 14:19 -0600, John Arbash Meinel wrote:
> Robert Collins wrote:
> 
> >Baz 1.3 is shaping up for release now. There hasn't been much noise
> >during this cycle - we've been head down and tail up hacking on the
> >ArchiveRegistration and SigningRules draft specifications put up on the
> >wiki last month.
> >
> >
> 
> I downloaded the latest as of today, and tried to build on Mac OSX.
> There were a few issues.
> 
> First, it didn't detect that gpgme was missing, but would fail to build
> without it.
> 
> When trying to "make test" I had to add a line in several Makefiles for
> EXTRA_CFLAGS = -I$(srcroot) -I $(srcroot)/baz -I$(objroot) -I$(objroot)/baz

Thats usually package-framework bug with folk doing 'make test
CFLAGS=blah' :[ -- it uses CFLAGS directly, which means that 
make CFLAGS=blah
will fail, but
CFLAGS=blah make
should work. I haven't had the time to go and give it a private CFLAGS
to use.

> I probably didn't need to add all the includes, but I did need most of them.
> 
> It didn't realize that I still needed the -lintl and -lpth flags. (I
> think -lintl is for libneon and -lpth is for libgpgme, but I'm not sure)

I've noted this down. High on my todo is to merge the libtool simulation
from Toms branch. -lpth would be for libgpgme if it was built with that
on your platform, yes.

> During TESTING: Archive Registration
> For tests 38-43, I got warnings of:
> *** malloc[10984]: error for object 0x60c6a0: Double free

Oh, thats very interesting. I'll hunt that down asap.

> (The exact address varied a little bit).
> 
> Test 156 just plain failed.
> 
> 
> Also, in the past I have used a build directory of "+build" because that
> is *really* what it should be. '=' implies that the directory is part of
> the source, and it is only historical reasons why the dir stayed
> '=build'. Anyway, there are some tests that regex compare the current
> working directory with the contents of a file. However, if the current
> working directory has a "+" in it, the regex interprets it, rather than
> considering it a plain string. This probably isn't the best way of
> testing for an exact path, since it breaks if there are any regex
> characters in the path.

garh. We're just lucky to have avoided that. Perhaps we need a non-regex
file_match too ?

> Appended is the output for Test 156 if you think you can figure out the
> error:
> It seems to be "Failed to verify signature data: error: 117440662
> (Invalid crypto engine)"

I'll bet you that either you don't have gpg installed, or libgpgme was
built without gpg support/incorrect. Given that you got  signed
checksums, its probably libgpgme not having gpg support correctly
installed & configured. That error comes from gpgme_op_verify ();

One thing about gpgme is that it depends on a specific path to gpg - is
it possible that gpgme has the wrong path ?

Rob

signature.asc
Description: This is a digitally signed message part