libexif-devel — This is the place where your questions about libexif will be answered.

[Libexif-devel] Re: docs

[Arnaud L. <as...@la...>]

Le Fri, Apr 18, 2003 at 02:23:09AM -0400, Bob Lockie a =E9crit:
> I saw an old post for a RFE asking for documentation.
> Is there still need for some documentation?
> I couldn't find any. :-)

There is. If you want to write any, you're damn welcome !

	Arnaud.
--=20
BOFH excuse:
HTTPD Error 666 : BOFH was here

[Libexif-devel] docs

[Bob L. <bjl...@lo...>]

I saw an old post for a RFE asking for documentation.
Is there still need for some documentation?
I couldn't find any. :-)


-- 
----------------------------------------
Sent from Mozilla and GNU/Linux.
Powered by an AMD processor.

Re: [Libexif-devel] libexif, metacam, and TIFFs

[Jason V. P. <jv...@la...>]

Lutz M=FCller wrote:
>=20
> Not tried yet. This is your chance to contribute :-)

I assure you, you don't want me cutting code. :-)  I graduated from unive=
rsity=20
in '95, and that was the last time I did any hacking.

I actually contacted the metacam author.  He said he's way too busy to he=
lp,=20
but that anyone is free to rob from his code.  I dunno how easy it'd be t=
o=20
recode all of his C++ stuff into C, though...

jas
--=20
Jason Van Patten
AOL IM: Jason VP

Re: [Libexif-devel] libexif, metacam, and TIFFs

[Lutz <lu...@us...>]

On Fri, 2003-03-14 at 16:26, Jason Van Patten wrote:
> Have you guys considered sending him an invitation to join the development 
> crew?  It looks like he might be able to add a bit of functionality to libexif 
> as far as TIFFs are concerned.

Not tried yet. This is your chance to contribute :-)

-- 
Lutz Müller <lu...@us...>

[Libexif-devel] libexif, metacam, and TIFFs

[Jason V. P. <jv...@la...>]

Lutz and co -

I recently stumbled on Daniel Stephens' home page describing his "metacam" 
application.  It's a CLI-based app that reads and displays EXIF information, 
much like the exif and jhead CLI tools do.  However, it's A)self contained, 
and B)supports TIFFs. :-)  I've tested it on TIFFs from two different cameras, 
and it works beautifully.

Have you guys considered sending him an invitation to join the development 
crew?  It looks like he might be able to add a bit of functionality to libexif 
as far as TIFFs are concerned.

Check here: http://www.cheeseplant.org/~daniel/pages/metacam.html

jas
-- 
Jason Van Patten
AOL IM: Jason VP

[Libexif-devel] Re: assorted patches (mostly rpm build related)

[Arnaud L. <as...@la...>]

Le Fri, Jan 03, 2003 at 04:33:33PM +0100, Daniel Resare a écrit:
> libexif-0.5.8 as distributed from sf.net does not include the header
> file libexif/exif-note.h (as it was broken out into libmnote) that is
> needed by exif-0.5.tar.gz also distributed from sf.net

Ok, I see. Just released everything, and now all the last
versions should work right.

> IMHO the release of libexif-0.5.8.tar.gz should have been
> delayed until exif was updated to match the new library, and
> libmnote was ready for release.

You're right. I just released:

libexif 0.5.9
libexif-gtk 0.3.3
libmnote 0.5.6
exif 0.6
gexif 0.5

Everything is based on the couple libexif/libmnote.

> your compile will fail as there is an empty directory named
> /cvsroot/exif/exif/exif, accidentally also the name of the
> binary that is to be created.

Ok, I see now.

> 2) Checkout with the -P option after 'co'

[x] Stick on this.

> 4) Log in to the cvs server and remove /cvsroot/libexif/exif/exif/exif

We don't have our hands on the cvsroot :/ I note to add this to
the things to do when we'll have something really important to
ask the SF admins.

Thanks,
	Arnaud.
PS: could you test the last releases ?

Re: [Libexif-devel] Re: assorted patches (mostly rpm build related)

[Lutz <lu...@us...>]

On Fri, 2003-01-03 at 15:10, Arnaud Launay wrote:
> Commited. BTW, I also added a fix, IFD was written IDF :)

Thank you, Arnaud. 

> > - my version of automake (automake-1.6.3-3) seems to have a 'make
> > distcheck' implementation that gets confused by the empty
> > CONFIG_CLEAN_FILES (then it doesn't remove libexif.spec on distclean).
> > Removing the parameter from Makefile.am entirely fixes the problem
> 
> Commited, too. This should be checked a little further -- Uli, Lutz ?

As long as it compiles, I am ok with it. I am no automake expert.

Lutz

Re: [Libexif-devel] Detailed API documentation on libexif? Perl Port?

[Lutz <lu...@us...>]

On Tue, 2003-01-07 at 10:14, Msc...@ao... wrote:
> However, I couldn't find any documentation on your API on your site,
> do you have any pointers? Would be great if you could point me to the
> appropriate location, thanks!

We are waiting for someone to write some docs :-) The only documentation
we've got so far is the EXIF specification itself and the header files.
Also, the test programs are usually very enlightening for people wanting
to write their own programs using libexif.

Lutz
-- 
Lutz Müller <lu...@us...>

[Libexif-devel] Detailed API documentation on libexif? Perl Port?

[<Msc...@ao...>]

Hi libexif guys,

do you know if there's a Perl port (XS wrapper on top of the C-API) of your 
libexif library available somewhere? Doesn't seem like it, so I decided to 
write one myself. However, I couldn't find any documentation on your API on 
your site, do you have any pointers? Would be great if you could point me to 
the appropriate location, thanks!

--- Mike

Mike Schilli
log...@pe...
http://log4perl.sourceforge.net
http://perlmeister.com

Re: [Libexif-devel] Re: assorted patches (mostly rpm build related)

[Daniel R. <no...@me...>]

On Fri, 2003-01-03 at 15:10, Arnaud Launay wrote:
> Hello,
> 
> Le Wed, Jan 01, 2003 at 09:13:43PM +0100, Daniel Resare a écrit:
> > Since the latest released versions doesn't compile i decided to
> > try out HEAD cvs and to my great joy it worked out nicely.
> 
> This is disturbing. What's wrong with released versions ? We need
> to know...
> 

libexif-0.5.8 as distributed from sf.net does not include the header
file libexif/exif-note.h (as it was broken out into libmnote) that is
needed by exif-0.5.tar.gz also distributed from sf.net

IMHO the release of libexif-0.5.8.tar.gz should have been delayed until
exif was updated to match the new library, and libmnote was ready for
release.

> > A few details:
> > - the exif/exif directory in cvs should really be removed
> > manually so that new users doesn't get confused when they
> > forget to check out with -P
> 
> I don't get that. Could you be more specific ?
> 

In cvs you don't remove directory but instead there is a convention that
empty directories should be treated like they weren't there. To achieve
that 'cvs update' and 'cvs checkout' has the -P flag, that removes all
empty directories in the working tree.

If you check out the exif package from cvs and skip using the -P flag,
your compile will fail as there is an empty directory named
/cvsroot/exif/exif/exif, accidentally also the name of the binary that
is to be created.

So when i run "cvs -z3
-d:pserver:ano...@cv...:/cvsroot/libexif co exif" (cut
and paste from sf.net project page)

and then "./autogen.sh; ./configure; make" the build fails with the
message:

rm: cannot remove `exif': Is a directory
make[2]: *** [exif] Error 1
make[2]: Leaving directory `/home/noa/slask/exif/exif'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/noa/slask/exif'
make: *** [all] Error 2

There are some solutions to this problem:

1) run 'rm -rf exif/exif' before make
2) Checkout with the -P option after 'co'
3) Use an alternate build directory
4) Log in to the cvs server and remove /cvsroot/libexif/exif/exif/exif

> > - typo in exif.1 (see attachment 0)
> 
> Commited. BTW, I also added a fix, IFD was written IDF :)

oops. That a quite high typo percentage (two chars wrong out of four
added) *smile*

> 
> > gettextize edits configure.in and Makefile.am when it is called
> > through ./autogen.sh. I see the point in having intl/ symlinked
> > in from the current version, but the changing of the mentioned
> > files above makes sending in patches against cvs difficult, so
> > I think that those changes should be applied to cvs HEAD.
> 
> No. We support gettextize from 0.10.40 to the latest ones, and
> unfortunately they don't act the same way, one modifies the files
> under every circumstances, another one doesn't, and sometimes
> rerunning gettextize just adds the files twice (!). So the
> current solution is the best, as we don't depend on a specific
> version of gettext. That way, everybody could use the cvs.
> 

Oki, if the current solution is well thought out then we should use it.
Having the added lines in Makefile.am and configure.in is only a minor
annoyance anyway.

cheers!
/noa

[Libexif-devel] Re: assorted patches (mostly rpm build related)

[Arnaud L. <as...@la...>]

Hello,

Le Wed, Jan 01, 2003 at 09:13:43PM +0100, Daniel Resare a écrit:
> Since the latest released versions doesn't compile i decided to
> try out HEAD cvs and to my great joy it worked out nicely.

This is disturbing. What's wrong with released versions ? We need
to know...

> A few details:
> - the exif/exif directory in cvs should really be removed
> manually so that new users doesn't get confused when they
> forget to check out with -P

I don't get that. Could you be more specific ?

> - typo in exif.1 (see attachment 0)

Commited. BTW, I also added a fix, IFD was written IDF :)

> - i wrote a .spec file for exif (see attachment 1). Just add exif.spec
> to AC_OUTPUT in configure.in and to EXTRA_DIST in Makefile.am

Done.

> - patched libexif.spec to not hardcode the library version number,
> header names and include libexif.so (attachment 2)

Commited.

> - my version of automake (automake-1.6.3-3) seems to have a 'make
> distcheck' implementation that gets confused by the empty
> CONFIG_CLEAN_FILES (then it doesn't remove libexif.spec on distclean).
> Removing the parameter from Makefile.am entirely fixes the problem

Commited, too. This should be checked a little further -- Uli, Lutz ?

> - patched also libmnote specfile (attahcment 3)

Ok.

> gettextize edits configure.in and Makefile.am when it is called
> through ./autogen.sh. I see the point in having intl/ symlinked
> in from the current version, but the changing of the mentioned
> files above makes sending in patches against cvs difficult, so
> I think that those changes should be applied to cvs HEAD.

No. We support gettextize from 0.10.40 to the latest ones, and
unfortunately they don't act the same way, one modifies the files
under every circumstances, another one doesn't, and sometimes
rerunning gettextize just adds the files twice (!). So the
current solution is the best, as we don't depend on a specific
version of gettext. That way, everybody could use the cvs.

	Arnaud.

[Libexif-devel] assorted patches (mostly rpm build related)

[Daniel R. <no...@me...>]

Hello fellows

As I might use libexif in the not so distant future I wanted to check it
out. Since the latest released versions doesn't compile i decided to try
out HEAD cvs and to my great joy it worked out nicely.

A few details:

- the exif/exif directory in cvs should really be removed manually so
that new users doesn't get confused when they forget to check out with
-P

- typo in exif.1 (see attachment 0)

- i wrote a .spec file for exif (see attachment 1). Just add exif.spec
to AC_OUTPUT in configure.in and to EXTRA_DIST in Makefile.am

- patched libexif.spec to not hardcode the library version number,
header names and include libexif.so (attachment 2)

- my version of automake (automake-1.6.3-3) seems to have a 'make
distcheck' implementation that gets confused by the empty
CONFIG_CLEAN_FILES (then it doesn't remove libexif.spec on distclean).
Removing the parameter from Makefile.am entirely fixes the problem

- patched also libmnote specfile (attahcment 3)

One issue that I don't see an obvious solution to is the fact that
gettextize edits configure.in and Makefile.am when it is called through
./autogen.sh. I see the point in having intl/ symlinked in from the
current version, but the changing of the mentioned files above makes
sending in patches against cvs difficult, so I think that those changes
should be applied to cvs HEAD.


That's all for now.
/noa

Re: [Libexif-devel] Re: release of libmnote

[Hans U. N. <gp...@n-...>]

Arnaud Launay <as...@la...> writes:

> Well, it would be sufficient if I would not create a new
> package... I can't create libmnote as simple dev, and it seems
> uli is in holidays, I can't find him on irc :)

Not holidays.

I was in bed. Vomiting.

But I'm back now.

> If you may just create a new package called, say, hmmm, for
> example, and using some random letters, hmm, libmnote ? :)

Done.

And don't use the QRS if you intend to upload more than one file for a
release (a .tar.bz2 and a .tar.gz qualify for "more than one").

Gru=DF,

Uli

[Libexif-devel] Re: release of libmnote

[Arnaud L. <as...@la...>]

Le Mon, Dec 30, 2002 at 08:18:11PM +0100, Lutz Müller a écrit:
> > > > Would it be possible to make a release of libmnote ?
> > > Sure. Do you have enough privileges to do so?
> > No, I don't think so.
> Project role        [Developer                     ] 
> Project Admin       [ ]                              
> Release Technician  [*]
> This is the current state. If that isn't enough, I'll promote
> you to project admin.

Well, it would be sufficient if I would not create a new
package... I can't create libmnote as simple dev, and it seems
uli is in holidays, I can't find him on irc :)

> > this is the task of project managers, like you.
> I'd say it differently: This is the task of someone who knows
> how to do a release (i.e. tag CVS) and has the time to do it.

If you may just create a new package called, say, hmmm, for
example, and using some random letters, hmm, libmnote ? :)

Well, then I may act, no need for more perms (I don't like having
too much).

	Arnaud.

Re: [Libexif-devel] Re: release of libmnote

[Lutz <lu...@us...>]

On Mon, 2002-12-30 at 18:18, Arnaud Launay wrote:
> Le Mon, Dec 30, 2002 at 05:47:36PM +0100, Lutz Müller a écrit:
> > > Would it be possible to make a release of libmnote ?
> > Sure. Do you have enough privileges to do so?
> 
> No, I don't think so.

Project role        [Developer                     ] 
Project Admin       [ ]                              
Release Technician  [*]

This is the current state. If that isn't enough, I'll promote you to
project admin.

> this is the task of project managers, like you.

I'd say it differently: This is the task of someone who knows how to do
a release (i.e. tag CVS) and has the time to do it.


Lutz
-- 
Lutz Müller <lu...@us...>

[Libexif-devel] Re: release of libmnote

[Arnaud L. <as...@la...>]

Le Mon, Dec 30, 2002 at 05:47:36PM +0100, Lutz Müller a écrit:
> > Would it be possible to make a release of libmnote ?
> Sure. Do you have enough privileges to do so?

No, I don't think so. Uli will correct me if I'm wrong, but
"simple" developers don't have enough perms to make releases,
this is the task of project managers, like you. Hey, you must be
of use for something ;-)

(btw, if you do a release, please tag the cvs, I looked at
libexif recently and you forgot to tag for the 0.5.8)

	Arnaud.

Re: [Libexif-devel] release of libmnote

[Lutz <lu...@us...>]

On Mon, 2002-12-30 at 08:43, Arnaud Launay wrote:
> Would it be possible to make a release of libmnote ?

Sure. Do you have enough privileges to do so?

Lutz
-- 
Lutz Müller <lu...@us...>

[Libexif-devel] release of libmnote

[Arnaud L. <as...@la...>]

Hello people,

Would it be possible to make a release of libmnote ? It seems to
be stable at this point, and I need a release as a dependency to
exif for distributions packages...

	Arnaud.

[Libexif-devel] Re: compile help?

[Arnaud L. <as...@la...>]

Le Fri, Dec 13, 2002 at 01:37:10PM -0800, Don Campbell a écrit:
> >-Wpointer-arith -Werror -c gtk-exif-browser.c  -fPIC -DPIC -o 
                   ^^^^^^^

This is the problem.

> >cc1: changing search order for system directory "/usr/local/include"
> >cc1:   as it has already been specified as a non-system directory

And this is the cause: you're using gcc3.

> Can someone help me figure out how to compile this package?

Either use cvs (it has been corrected by me in rev 1.13 on
configure.in, dated 2002/09/13), or either wait a new release --
but not so many things have changed, so we may wait a few time
before rolling out a new release.

Another way would be to modify "configure" before running it, and
deleting every bit of "Werror" in it... Try this on a clean dir:
sed -e 's/ -Werror//g' configure.in >configure.in.new; mv configure.in.new configure.in

And then retry.

	Arnaud.
(xpost and fu2)

Re: [Libexif-devel] libexif release?!

[Hans U. N. <gp...@n-...>]

Lutz M=FCller <lu...@us...> writes:

> On Mon, 2002-11-18 at 03:20, Hans Ulrich Niedermann wrote:

>> If nobody speaks up against a release within the next few days, I'll
>> do a release on monday/thursday evening or so.
>
> Should I remove the MakerNote stuff (now in libmnote) before or after
> the release?

After.

Then we can do a joint release of the leaner libexif and libmnote.=20

I'm just waiting for feedback from Christophe about the i18n file name
issue, then I'm going to release.

Gru=DF,

Uli
(whose mind is starting to race around in circles about release this,
release that, ... :-)

[Libexif-devel] Re: [gphoto-devel] libexif request

[Hans U. N. <gp...@n-...>]

Hans Ulrich Niedermann <gp...@n-...> writes:

> GETTEXT_PACKAGE=3D'${PACKAGE}${LIBEXIF_CURRENT}'
> AC_SUBST(GETTEXT_PACKAGE)
>
> But should this be:
>
> GETTEXT_PACKAGE=3D'${PACKAGE}'"$(expr ${LIBEXIF_CURRENT} + ${LIBEXIF_REVI=
SION})"
> AC_SUBST(GETTEXT_PACKAGE)
>
> Or even more version details? Simply ${PACKAGE}-${VERSION}?

Christophe?

Is current libexif CVS OK? Or the RC1 tarball I put up on
http://n-dimensional.de/releases/ ?

Gru=DF,

Uli

[Libexif-devel] Re: libexif release?!

[Arnaud L. <as...@la...>]

Le Mon, Nov 18, 2002 at 08:51:34AM +0100, Lutz Müller a écrit:
> > I can't see any reason why we should *not* release libexif (just
> > libexif, nothing else) in the state it is now.
> > If nobody speaks up against a release within the next few days, I'll
> > do a release on monday/thursday evening or so.
> Should I remove the MakerNote stuff (now in libmnote) before or
> after the release?

As of now, it compiles and works with libmnote, but may be buggy,
I did not test it extensively. If it's not buggy and does not
impact core functionality, I would vote for leaving it and do a
libmnote release, too.

	Arnaud.

Re: [Libexif-devel] libexif release?!

[Lutz <lu...@us...>]

On Mon, 2002-11-18 at 03:20, Hans Ulrich Niedermann wrote:
> I can't see any reason why we should *not* release libexif (just
> libexif, nothing else) in the state it is now.
> 
> If nobody speaks up against a release within the next few days, I'll
> do a release on monday/thursday evening or so.

Should I remove the MakerNote stuff (now in libmnote) before or after
the release?

Lutz
-- 
Lutz Müller <lu...@us...>

[Libexif-devel] libexif release?!

[Hans U. N. <gp...@n-...>]

Hi,

I can't see any reason why we should *not* release libexif (just
libexif, nothing else) in the state it is now.

If nobody speaks up against a release within the next few days, I'll
do a release on monday/thursday evening or so.

Gru=DF,

Uli

[Libexif-devel] Re: [gphoto-devel] libexif request

[Hans U. N. <gp...@n-...>]

Reply-To: lib...@li...

christophe barbe <chr...@ca...> writes:

> Current libexif install the following file:
>=20
>    /usr/share/locale/de/LC_MESSAGES/libexif.mo
>=20
> This is problematic because you can't install simultaneously two
> different releases of libexif on a given system.
>=20
> It would be better to put the major somewhere in the path. For example:
>=20
>    /usr/share/locale/de/LC_MESSAGES/libexif$(major).mo

This depends on what kinds of different releases we want to support
installed into the same directory hierarchy. Is the major number a
good criterion for that?

It shouldn't be a packager's job, that is sure.

> I don't know if this i18n file is useful. If it is perhaps we could do
> an effort to get it translated in other languages.

I don't know either. I run everything in LANG=3DC here :-)

Gru=DF,

Uli