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
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
