2.3.0 is out since about 1 week, with support for MY new mp3 player ;)
Created attachment 103763 [details] personnal attempt at ebuild Basically the same as libgphoto-2.2.1-r1, with 2 patch removed (since they were integrated upstream), and with the building of api docx through gtk-doc removed (it failed, plus on upstream's BTS they seem to say they want to ditch gtk-doc for doxygen). I put a couple of line to run doxygen, I'm not 100% sure about them though
Additional, copying over gphoto2-2.2.0.ebuild to gphoto2-2.3.0.ebuild while changing the version requirement on libgphoto2 to 2.3.0 seems to work.
Created attachment 103810 [details, diff] backported fixes to udev-rules as already applied to 2.2.1-r1 ebuild This patch results in the same behaviour as approached with the patch already applied to 2.2.1-r1-ebuild. It results in udev-rules working with 103 (more exactly >=0.98) and also finally working code to match PTP-USB-Class-type. (See Bug #153471).
1. The resulting print-camera-list should then be called print-camera-list udev-rules-0.98 mode 660 group plugdev But the mode is also subject for discussion. 2. This perhaps makes the script /etc/hotplug/usb/usbcam redundant. 3. As udev is default perhaps depend to sys-apps/hotplug can disappear (or be use-flag based).
what about libgphoto2-2.1.2-norpm.patch its not attached but is still in the ebuild.
Created attachment 105068 [details] media-libs/libgphoto2-2.3.1.ebuild For the time being I removed the epatch line because you said they were integrated upstream and I am assuming that is why you did not attach them to this bug. epatch ${FILESDIR}/${PN}-2.1.2-norpm.patch
Created attachment 105069 [details, diff] libgphoto2-2.3.1-backported-udev-fixes.diff
> For the time being I removed the epatch line because you said they were > integrated upstream and I am assuming that is why you did not attach them to > this bug. > > epatch ${FILESDIR}/${PN}-2.1.2-norpm.patch > No, the 2 patch that I said were integrated upstream were the ones mentionned in those lines (in the 2.2.1-r1 ebuild) epatch ${FILESDIR}/${PN}-2.2.0-includes.patch epatch ${FILESDIR}/libgphoto-2.2.1-new-dbus-api.patch The norpm patch still makes sense. I didn't attached it because it's already in the files directory in portage and works as is.
Created attachment 105348 [details, diff] libgphoto2-2.1.2-norpm.patch
Created attachment 105349 [details] libgphoto2-2.3.1.ebuild re-added the norpm patch.
(In reply to comment #10) > Created an attachment (id=105349) [edit] > libgphoto2-2.3.1.ebuild > > re-added the norpm patch. > Ebuild is alright for the most part, but as I was telling metalgod IUSE_CAMERA needs to expand to IUSE. confcache is dead and not supported so that could be removed from the list. Other then those two I would go ahead and recommend it for addition.
> Other then those two I would go ahead and recommend it > for addition. > I'd add that the behaviour of the doc is useflag needs reviewing. I changed it from the 2.2.1-r1 ebuild, where it was running gtk-doc, and I made it run doxygen instead (according to some comments on upstream bts, gtk-doc is no longer maintained). But I have the impression that the generated documentation doesn't get installed, although some html pages do end up in /usr/share/doc/libgphoto, regardless of the doc use flag ... so I'm a bit lost and shouldn't be trusted to know what I'm doing.
I tried to make my camera work... without much success... But I've created a new version of the ebuild, please review and merge your required modification to this base. Since it did not work for me, all I can suggest an ebuild cleanup.
Created attachment 106716 [details] alt-libgphoto2-2.3.1.ebuild
Created attachment 106718 [details, diff] alt-libgphoto2-2.3.1-package.patch
(In reply to comment #13) > Since it did not work for me, all I can suggest an ebuild cleanup. > Thank you, but ... 1. The ebuild fails to compile with the doc use flag. The origin of the problem is described in upstream's BTS : http://sourceforge.net/tracker/index.php?func=detail&aid=1487240&group_id=8874&atid=108874 and the last comment says "gtk-doc is being phased out in favour of doxygen, so this problem will go away without being actually fixed." I don't know whether the transition phase is over and doxygen can be used or there is no usable documentation to build at the moment and the doc use flag should simply be removed 2. I see you didn't include the "norpm" patch. I /believe/ (as in "in reality I don't know" :) ) that it is needed to avoid building the rpm on gentoo systems where rpm is installed (which probably exists somewhere as rpm is in portage). I'll try and ask upstream about the doc question...
(In reply to comment #16) > > I'll try and ask upstream about the doc question... > Well I didn't have to ask, I found the answer in gphoto-user list archive : http://sourceforge.net/mailarchive/message.php?msg_id=35442887 Straight from the dev's mouth : " In your build directory: $cd doc $doxygen Doxyfile The HTML documentation will be in doxygen-output/libgphoto2-api.html (relative to that directory you are in) Doxygen is a software available in most distributions. " So I got it almost right in my first ebuild, but it lacked the installation part... I'm not sure, which of the dodoc dodir or dowhatever calls should be used ?
(In reply to comment #16) > 1. The ebuild fails to compile with the doc use flag. > The origin of the problem is described in upstream's BTS : True. if use doc doxygen should be depended. > 2. I see you didn't include the "norpm" patch. I /believe/ (as in "in reality I have... Just differently... More correctly in automake. And regarding doc, if you contact upstream, please tell them that they have a bug in --disable-docs which actually enables it... They should fix the if statement in the m4m, m4 *_doc*.m4
Created attachment 106755 [details] alt-libgphoto2-2.3.1.ebuild
Created attachment 106756 [details, diff] alt-libgphoto2-2.3.1-package.patch udev works now.
Created attachment 106760 [details] libgphoto2-2.3.1.ebuild, with correct doc behaviour Ok, i finally got it : the documentation is build automatically if the configure script detects doxygen. The solution implemented in this ebuild is to "doc-use-depend" on doxygen, and in src_install, to delete the documentation if it was generated although we didn't want it. A little bonus is that as we don't use the gtk-doc apidoc anymore, the "emake -j1" restriction goes away. The not so nice thing is that if doxygen is present on a system, USE=-doc will make the ebuild build the documentation and then destroy it. I've tried to see if we could avoid that but it seems difficult... It seems it needs a little configure patching, and then launching econf with a envvar like GENTOO_BUILD_DOC, or maybe a big configure patch (eeek! :( ).
Created attachment 106761 [details] libgphoto2-2.3.1.ebuild, with correct doc behaviour Oops
Created attachment 106762 [details] alt-libgphoto2-2.3.1.ebuild Group fixup
(In reply to comment #21) > Ok, i finally got it : the documentation is build automatically if the > configure script detects doxygen. Already done in alt ebuild. Can you please try to merge into the alt one? I don't thing we need so many patches, and it seems to work, although it has some internal error with my camera.
Created attachment 106792 [details] alt-libgphoto2-2.3.1.ebuild OK, here it is. A litte patch is worth a thousand words of explanations : --- libgphoto2-2.3.1.ebuild.orig 2007-01-13 12:47:35.000000000 +0100 +++ libgphoto2-2.3.1.ebuild 2007-01-13 12:55:25.000000000 +0100 @@ -89,18 +89,17 @@ --with-html-dir=/usr/share/doc/${PF}/html \ --with-hotplug-doc-dir=/usr/share/doc/${PF}/hotplug \ $(use_enable nls) \ - $(use_enable doc docs) \ ${myconf} || die "econf failed" - # documentation breaks with -j1 - emake -j1 || die "make failed" + emake || die "make failed" } src_install() { emake DESTDIR=${D} install || die "install failed" - # fixup autoconf bug - if ! use doc; then + # The doc is automatically generated if doxygen is found, + # so we remove it if we don't want it + if [[ -d "${D}/usr/share/doc/${PF}/apidocs.html" ]] && ! use doc; then rm -fr "${D}/usr/share/doc/${PF}/apidocs.html" fi
attach the bug please, do not use the comment field to post a patch.
patch i mean... Not bug. /me goes to bed.
(In reply to comment #27) > patch i mean... Not bug. > Well, I attached the full ebuild to the bug, i just posted the patch in the description to make it easier to see what I changed. Good night :)
Created attachment 106799 [details] alt-libgphoto2-2.3.1.ebuild alonbl, I don't think you intended this line : sed -e 's:=plugdev:=plugdev:' -i packaging/linux-hotplug/usbcam.group I turned it back to : sed -e 's:=camera:=plugdev:' -i packaging/linux-hotplug/usbcam.group
Created attachment 106818 [details] alt-libgphoto2-2.3.1.ebuild Thanks! Left the use during configure, so when upstream will fix their code the rm -fr will not be needed.
Kalidarn: Can you please check if the alt* works for you? We can focus on improving one branch.
(In reply to comment #30) > Left the use during configure, so when upstream will fix their code the rm -fr > will not be needed. > I understand your point, but --enable-doc makes the build fail for me, everytime. So it should be at least commented out for now. It's because currently, --enable-docs makes it launch gtk-doc, but libgphoto2's gtk-doc documentation is broken. So it should be at least commented out. (see the URL i provided in comment #16) Furthermore, as I understand it, upstream is happy with just autodetecting doxygen and building the doc if it's found, so the --enable-docs option might never be fixed, or maybe it will be simply removed.
Created attachment 106825 [details] alt-libgphoto2-2.3.1.ebuild I see your point. I also removed the previous include patch... I don't see it required. Can you please confirm that it works for you? I am working blind here... :) Well... After something will work, I will work with upstream to: 1. Add --enable-rpm to configure. 2. Fix --enable-docs so that --disable-docs will work. 3. Fix udev stuff. 4. Fix package make file.
Created attachment 106851 [details, diff] libgphoto2-2.3.1-package.patch OK... We don't need the include fixups as-well.
Oh... And forgot to say that it works for me! I had to use the ptp2 driver, which is generic ptp. So I guess we have a working ebuild with minimal patches.
(In reply to comment #35) > Oh... And forgot to say that it works for me! Good :) Your latest ebuild+patches builds fine for me too. I have some problems accessing my "iRiver T20 FM" audio player (regardless of the latest changes to the ebuild), but its support in gphoto2 is quite new so i guess its not a regression or a general malfunction.
Created attachment 106919 [details] libgphoto2-2.3.1.ebuild Some cleanups, and warning for users that upstream will not support them if they do not install all cameras.
Alastair: Please review and see if you can get this into portage.
(In reply to comment #37) > Created an attachment (id=106919) [edit] > libgphoto2-2.3.1.ebuild > > Some cleanups, and warning for users that upstream will not support them if > they do not install all cameras. > Not a native english speaker, but shouldn't "Upstream will not support you if you not compile all camera drivers first" be : "Upstream will not support you if you don't compile all camera drivers first" Ah, striving for perfection ... :)
please change it to .tar.bz2 the developer supports these packages, all other related packages are .tar.bz2 (as in gtkam and gphoto2)
Created attachment 107013 [details] media-libs/libgphoto2-2.3.1 BZ2 version.
Created attachment 107014 [details] media-libs/libgphoto2-2.3.1 BZ2 version.
Comment on attachment 107013 [details] media-libs/libgphoto2-2.3.1 gah double post.....
Created attachment 107035 [details] libgphoto2-2.3.1.ebuild You forgot the "don't"... :)
for the record, I think I had problems getting kipi-plugins to work with this version of libgphoto. Does anyone have libgphoto2-2.3 and any version of kipi-plugins from portage working?
kamera also does not work with this version.... :( But at least it works via the command-line :)
Created attachment 107462 [details] libgphoto2-2.3.1.ebuild In this ebuild I have added support for USE-EXPAND (#139884). I also rebuilt the list of cameras according to subdirectories of "camlibs/" (on libgphoto2 sources), this is the command that I used: on camlibs/ echo -e 'IUSE_CAMERAS="'$(find . -maxdepth 1 -mindepth 1 -type d -printf "cameras_%f ")'"' >> /path/ebuild It works on my system.
Created attachment 107475 [details] libgphoto2-2.3.1.ebuild Thanks, some modifications. Next time, please submit patch for a specific modification. Please check.
Created attachment 108059 [details] libgphoto2-2.3.1.ebuild With help of upstream. I removed the usb hotplug stuff... It works with udev only now. Also no patch is actually required now! So I am happy... :) Just remember if you test this, you should add CAMERAS into: /usr/portage/profiles/base/make.defaults::USE_EXPAND
Fixed, please CC me if you open new bug regarding this change.
