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

[John Arbash Meinel]

Robert Collins wrote:

> 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.
Who is using CFLAGS directly? Reading rules.mk it states:
#       CFLAGS          _additional_ flags for the C compiler (e.g. "-O")
#                       default: -g.  This may be set from the command line
#                       but should not be set in a Makefile that includes
#                       rules.mk
#       EXTRA_CFLAGS    _additional_ flags for the C compiler.  This may be
#                       set in a Makefile that includes rules.mk.

I generally have to give EXTRA_CFLAGS on Mac, so that it can find stuff
like libneon (which is in /sw/lib /sw/include if installed by Fink, or
/opt/local/lib /opt/local/include if using darwinports).

> > 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.
The only thing that concerns me is that the way he builds tla is:

$(objroot)/libneon/libtool ... -o tla ...

Which means he uses *libneon's* libtool to build tla. Which works fine,
but what happens as you add expat, gpgme, etc all which might have been
built with libtool. Is the "built" version of libtool always the same,
independent of the source that it was built from?

I have both a libgpgme-pth, libgpgme-pthread, and libgpgme. I assume the
plain one is still pth.

I noticed that there is a "gpgme-config" script installed. So instead of
libtool you use:
gpgme-config --thread=pth --libs
gpgme-config --thread=pth --cflags

So probably cfg__gpgme_library should actually be cfg__gpgme_config
which can be used as an executable, and then passed approprate arguments.

> > 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.
Have you ever used valgrind? http://www.valgrind.org/
It is basically an x86 emulator which runs your program, and keeps track
of what memory has been allocated, what has been read without being
written, etc.

Be aware that tla tends to have a few memory leaks all over the place,
so it might take a while to track them all down. :) I was running it in
the past on my tla--mem-leaks-b branch. Which I don't think got merged.

> > (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 ?
That would be my recommendation. Since you are trying to match the path,
you probably just want a plain match.

> > 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
Well, actually, I have gpg installed a couple of times. :( The problem
is that on the Mac you can have both Fink or Darwinports. Fink uses
apt-get, darwinports uses the BSD port system.
Anyway, I started with Fink, as it has a nice graphical package manager,
and it was the one my friend told me about. When I wanted to install
gpg-agent, though, I found that Fink didn't have it, but darwinports
did. And the Fink gpg doesn't work properly with the darwinports gpg-agent.
I'm pretty sure that I have universally switched over to darwinport's gpg.
But gpgme is also installed by using darwinports, so I would assume that
if it was path sensitive, it would have been installed correctly. (I
just do "sudo port install gpgme")

I realize you probably don't need the full description, but it *might*
help someone in the future who is trying to configure gpg + gpg-agent +
gpgme on Mac.

My /usr/local/bin/gpg points to my darwinports /opt/local/bin/gpg. I
tried adding /usr/bin/gpg -> /opt/local/bin/gpg but that didn't work.

When I tried to look through the binary library for a path or something,
I didn't find anything other than perhaps a bare gpg.
I went ahead and uninstalled the Fink gnupg, and still no love.

Do you know any way to find out what path gpgme is looking at? The best
I can find is that it is looking for /opt/local/bin which would be correct.

John
=:->

signature.asc
Description: OpenPGP digital signature