Attached is gphoto2-2.1.1.tar.gz containing: libusb-0.1.7, libgphoto2-2.1.1, gphoto2-2.1.1, and gtkam-0.1.10. Also new ebuilds for libexif-0.5.8 and libexif-gtk-0.3.2 which are used with a new "exif" USE clause. The exif ebuilds are updates from bug #6558 now that gphoto2 compiles with exif correctly. I know PHP can also be compiled against exif. I put the libexif under media-libs.
Created attachment 6446 [details] gphoto2-2.1.1
Deps: gtkam->gphoto2,libexif(opt),libexif-gtk(opt) gphoto2->libgphoto2, libexif(opt) libgphoto2->libusb,libexif(opt)
*** Bug 12111 has been marked as a duplicate of this bug. ***
*** Bug 12558 has been marked as a duplicate of this bug. ***
Can someone place this into CVS portage please? A libexif has already been put in so just compare and leave the best one. Also Bug #12559 is a duplicate of this bug.
*** Bug 12559 has been marked as a duplicate of this bug. ***
I just added separated ebuilds for libexif, libexif-gtk and libmnote, all using the last version -- look at 13435 and blocked. BTW, only gtkam depends on gtk, so assigning this to the gnome team is maybe not so right.
Assigning this to seemant exif is not a valid useflag (grep exif -i /usr/portage/profiles/use.desc ) and so far we have a whopping 2 packages that could have it optional, theese two. I'm more inclined to make theese static deps if that should be the case, in order to avoid useflag cruft
libexif and libmnote exist in the tree, using them as static is not really interesting. Better to put them as mandatory deps if you want to avoid the exif flag.
php can also use exif. Saw a couple of people in forums manually compiling it in. But it will probably mainly used for photo apps. Exif is not a requirement and I couldn't even get it to compile with gphoto2 before 2.1.1. Would like to keep it optional but it doesn't have to be in the main use.desc unless it comes more popular. Someone might want to let the php ebuild people know though.
gthumb can use exif optional too btw
I think this bug is out of date and assigned to the wrong people as well. The new PHP ebuilds coming soon will have exif, so that is done from my side.
Really, this isn't a -gnome- package and I'm still unable to test this package properly. Do we have anyone who feels like taking up the maintainership?
<shameless begging mode>if someone donates me a camera, i'll do it ;)</mode>
I made them, so I can help any way possible. The exif ebuilds are old and new ones are already in portage. I just wanted to use a similar exif USE statement if the PHP people were going to do it too.
libusb 0.1.7, gphoto2 2.1.1 and libgphoto2 2.1.1 already exist in portage. Only gtkam 0.1.10 isn't uptodate, an ebuild exist for 0.1.9. I'd propose closing this one, and creating a new one just for gtkam.
But the ones currently in portage do not support exif where these do.
since various things can support exif (PHP, gthumb, gphotos, maybe media-gfx/exiftags?) I propose a proper exif tag. I do use EXIF support myself for my digital camera. However I don't use gphoto2, I just put my CF memory card in a proper reader and download faster. use.desc: "exif - Adds support for handling EXIF data" I use EXIF with jhead (ebuild coming soon) and gutted MiG to power my photo gallery (http://photo.orbis-terrarum.net/). I'm posting the proposal to -dev and -core.
Ok, the end results are as follows. Since EXIF is an extension of JPEG The 'jpeg' flag is now to be used to denote both jpeg support and exif support. I've changed my new php stuff accordingly. Is this bug now resolved?
would be correct, if its all over the place in the tree, which I havent checked yet. mark as resolved when you feel satisfied with your solution.
*** Bug 12560 has been marked as a duplicate of this bug. ***
OK. Back from vacation. So the consensus is to key the EXIF off the jpeg USE? Do I need to redo the ebuilds and re-submit and also should we close this bug and submit them in a new bug #?
i've added a new revision of gphoto2 and libgphoto2 that has the "jpeg" USE flag that enables exif support.
