Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
View Bug Activity | Format For Printing | XML | Clone This Bug
Hi, hugin is an easy to use cross-platform GUI for Panorama Tools. This ebuild depends on panorama-tools-2.6.ebuild, previously submitted.
Created an attachment (id=29582) [edit] media-gfx/hugin-0.4_pre.ebuild
Created an attachment (id=29583) [edit] media-gfx7hugin-200402081721.ebuild
Also created ebuild for snapshots
both ebuild works, i checked them for syntax errors, looks fine. emerges fine. however, i suggest using the snapshot ebuild, as the 0.4pre one comes with some nasty warnings during compile. else it looks good.
This ebuild would be a welcome addition to portage. I built from the snapshot ebuild without problems.
Doesn't belong in java, media guys take care of this
I locally tested hugin a bit in the past, thanks for the ebuild, why now it needs the java wrappers from panotools btw?
Well, the java wrappers are needed by hugin to actually do the hard work. AFAIK Hugin hasn't got an interface to the plain lib provided by media-libs/panotools.
Please note that if you emerged wxGTK with USE=unicode, the executable parts of hugin don't seem to compile. Also note that the posted ebuilds do not fail even if those parts of the compile process fail. Some sample output if you try ACCEPT_KEYWORDS=~x86 emerge USE=unicode wxGTK hugin : ---- Compiling huginApp.cpp (C++) g++ -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -I. -I./include -Wall -O2 -I. -I../include -Wall -O2 -I/usr/lib/wx/include/gtk2u-2.4 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I../ -c -o .obj/huginApp.o huginApp.cpp ar r ../lib/libvigra_ext.a .obj/LoweSIFT.o .obj/PointMatching.o ar: creating ../lib/libvigra_ext.a ranlib ../lib/libvigra_ext.a make[2]: Leaving directory `/var/tmp/portage/hugin-200402081721/work/hugin/src/vigra_ext' Descending directory Panorama to do "make lib" make[2]: Entering directory `/var/tmp/portage/hugin-200402081721/work/hugin/src/Panorama' ---- Compiling Panorama.cpp (C++) g++ -march=athlon-xp -O2 -pipe -frename-registers -fomit-frame-pointer -I. -I./include -Wall -O2 -I. -I../include -Wall -O2 -I../ -c -o .obj/Panorama.o Panorama.cpp huginApp.cpp: In member function `virtual bool huginApp::OnInit()': huginApp.cpp:63: error: conversion from `const char[6]' to `const wxString' is ambiguous /usr/include/wx/string.h:306: error: candidates are: wxString::wxString(wchar_t, unsigned int) <near match> /usr/include/wx/string.h:284: error: wxString::wxString(int) <near match> huginApp.cpp:100: error: conversion from `const char[12]' to `const wxString' is ambiguous [ ... many lines of errors ... ] ImageCache.cpp: In member function `const vigra::BImage& ImageCache::getPyramidImage(const std::string&, int)': ImageCache.cpp:268: error: no matching function for call to `wxString::Format( const char[40], const char*, int&)' /usr/include/wx/string.h:738: error: candidates are: static wxString wxString::Format(const wxChar*, ...) make[2]: *** [.obj/ImageCache.o] Error 1
Hugin isn't mature enough, btw I'd like to see the unnecessary deps on java front-ends removed before committing it
cool. ;-) please put it into portage ASAP. would be also nice to have all the plugins in.
btw: latest version is: http://hugin.sourceforge.net/snapshots/hugin_2004_07_03-17_50.tgz
Created an attachment (id=37597) [edit] testcase on hugin compile Used the bug 48268 panorama-tools ebuild, which merged nicely, also the panotools bug 53487 ebuild which also merged nicely. This one however had a new version which did not merge nicely... :/
Created an attachment (id=38181) [edit] Patch for hugin to make it compile when the system uses Unicode I finally got hugin compiling and working on my system by modifying the configure script and makefiles to force the use of the non-Unicode GTK and wxWidgets library versions. My first attempt at fixing the problem was by actually modifying hugin to use Unicode properly, but after spending about 16 hours working on this, I was still having problems getting it to work. So the Really Right Way to make things work would be to fix hugin to use unicode, but it will take a lot of work. Also, I have an ebuild I've been using BUT it's from a CVS snapshot I made myself a couple days ago, so I don't have a SRC_URI to put in the ebuild. Maybe we should get the hugin folks to make a more recent snapshot?
Created an attachment (id=38182) [edit] Hugin ebuild for the latest CVS code, using my Unicode fix patch This is my ebuild for hugin. It uses my Unicode patch which forces compilation with non-Unicode library versions. There are two problems that I could use help on: 1. There is no recent CVS snapshot available from the hugin site, so I had to check out and make my own. So right now this ebuild won't work unless you manually put my tarball in your distfiles dir. 2. The hugin makefiles are retarded and don't abort or even exit with an error code when a component fails to compile or build. Right now I have the ebuild at least checking to see if the important executables are built as a basic success indicator.
Colin, I'd like to try your version, but where can I get your tarball? :)
I can only enter into the group of people that want to have this application into Portage as soon as possible. This is one of the white spots in the Portage map...
Created an attachment (id=46678) [edit] ebuild for 0.4 using the Oct 15 sources This is ebuild installs the the Oct 15,2004 sources. It requires the splash-configure_ac.patch attachment, (placed in the files subdir), which fixes the splash screen configure problem. Does not include the previous unicode patches.
Created an attachment (id=46679) [edit] splash-configure_ac.patch This patch fixes the splash configure problem in the Oct 15,2004 srcs. Please place in the files subdir.
how did you manage to get wxrc?
Created an attachment (id=46897) [edit] hugin-0.4-wx_gtk.m4.patch for wx gtk detection wxrc is provided by default by wxGTK-2.5.3. However, the version of GTK (at least with GTK2) used in building this version of wxGTK is not detected by the 2004_10_25 hugin. This patch brings m4/ax_check_wx_gtk.m4 up to revision 1.5 from hugin cvs, and fixes the problem.
Created an attachment (id=46898) [edit] hugin-0.4.ebuild for Oct 15 sources Thanks to everyone for assembling this package. Here is a suggested ebuild including the wxGTK-2.5.3 gtk version detection, and other modifications that I needed to get hugin to build. (I haven't really tested running the program yet though.) fftw3 is not detected so using fftw2. xrcdir and xrcdatadir need to be explicitly specified for einstall as the Makefiles do not calculate these from datadir. Other changes are mentioning the SIFT licence, blackdown-jdk seems to work OK so using virtual/jdk, rebuilding configure after patching so that configure is not run twice, and there doesn't seem much point in dodoc'ing the windows files.
Karl's ebuild worked for me. I'm not sure that java is used at all, so we may be able to remove that dependency.
Small correction which should be made to the ebuild. The message about emerging enblend should be put in the postinst, not in the package description. Also, the package description is way to long. Also please remove the unecessary commented lines and remove obsoleted attachments from this bug.
fftw is now in sci-libs not dev-libs
Created an attachment (id=47340) [edit] r1 of hugin ebuild Please note: fftw moved from from dev-libs to sci-libs, and this ebuild supports this. You *need* a recent sync, a la Jan 1, 2005. * Changed fftw from dev-libs to sci-libs * Removes commented code. * Shortened description. * einfo at end for enblend and autopano-sift.
There are so many attachments on this bug I don't know what is going on. There should be at most 4 attachments here which are non-obsolete. 3 patches: unicode, splash, and wx_gtk, as well as 1 ebuild. I see 9 ebuilds here. Obsolete attachments can still be viewed, don't worry about it so much.
Where do I get the ebuild panotools-cvs? Is there a separate bug for this? I only have panotools...
The only appropriate files at the moment are: splash patch. wx_gtk patch 0.4-r1 ebuild. A developer that has write permission for this bug should obsolete the rest (not me). Note that unicode has been fixed in the source since the October 15 sources. The panotools-cvs can be found here: Download: http://dev.gentoo.org/~lu_zero/overlay/panotools-cvs.tar.bz2 mv <download dir>/panotools-cvs.tar.bz2 /usr/local/portage tar xjvf panotools-cvs.tar.bz2 ebuild usr/local/portage/media-gfx/panotools-cvs/panotools-cvs-20041220.ebuild digest ACCEPT_KEYWORDS=
The only appropriate files at the moment are: splash patch. wx_gtk patch 0.4-r1 ebuild. A developer that has write permission for this bug should obsolete the rest (not me). Note that unicode has been fixed in the source since the October 15 sources. The panotools-cvs can be found here: Download: http://dev.gentoo.org/~lu_zero/overlay/panotools-cvs.tar.bz2 mv <download dir>/panotools-cvs.tar.bz2 /usr/local/portage tar xjvf panotools-cvs.tar.bz2 ebuild usr/local/portage/media-gfx/panotools-cvs/panotools-cvs-20041220.ebuild digest ACCEPT_KEYWORDS=~x86 emerge =media-gfx/panotools-cvs Please see this thread: http://forums.gentoo.org/viewtopic.php?t=251842&highlight=autopano The panotools bugzilla is messed up, as I see three different/duplicate bugs. 24922 enh P2 x86 graphics@gentoo.org NEW Request an ebuild for Panoramic Tools applications by Hel... 48268 enh P2 All graphics@gentoo.org NEW panorama-tools-2.6.ebuild (New Package) 53487 maj P2 All lu_zero@gentoo.org ASSI panotools-2.6 ebuild should depend on jdk and properly se...
FYI, I was able to compile hugin with media-libs/panotools instead of panotools-cvs as dependency. Is -cvs really needed?
All I know is, panotools is in portage and there is a hard mask on panotools due to this reason: # <lu_zero@gentoo.org> (26 Nov 2004) # Masking since the ebuild is broken and the package is going to have a # radical change. # So I went with panotools-cvs which seddes provided here, and in another bugzilla bug (not sure which one). I agree with seddes, it appears there are 3 bugs for the same thing, which is not a good thing.
I believe that the ebuild called "hugin-0.4.ebuild for Oct 15 sources" should also be obsoleted, and r1 should be used instead. Small notes: HOMEPAGE= should be put back in I think panotools-cvs dependancy should be in media-libs not media-gfx
I get the following error while trying to build hugin-0.4-r1.build g++ -DHAVE_CONFIG_H -I. -I../../src/include -I../../src/foreign -march=athlon-xp -O3 -pipe -fomit-frame-pointer -m3dnow -msse -mfpmath=sse -mmmx -MT PanoToolsInterface.lo -MD -MP -MF .deps/PanoToolsInterface.Tpo -c PanoToolsInterface.cpp -o PanoToolsInterface.o In file included from ../../src/include/PT/PTOptimise.h:33, from PanoToolsInterface.cpp:34: ../../src/include/PT/ImageGraph.h:36:40: boost/graph/graph_traits.hpp: No such file or directory ../../src/include/PT/ImageGraph.h:37:42: boost/graph/adjacency_list.hpp: No such file or directory ../../src/include/PT/ImageGraph.h:38:38: boost/graph/properties.hpp: No such file or directory In file included from ../../src/include/PT/PTOptimise.h:33, from PanoToolsInterface.cpp:34: ../../src/include/PT/ImageGraph.h:47: error: syntax error before `::' token ../../src/include/PT/ImageGraph.h:55: error: type specifier omitted for parameter `CPGraph' ../../src/include/PT/ImageGraph.h:55: error: parse error before `&' token ../../src/include/PT/ImageGraph.h:59: error: syntax error before `::' token ../../src/include/PT/ImageGraph.h:69: error: syntax error before `::' token ../../src/include/PT/ImageGraph.h:78: error: type specifier omitted for parameter `OverlapGraph' ../../src/include/PT/ImageGraph.h:78: error: parse error before `&' token In file included from PanoToolsInterface.cpp:34: ../../src/include/PT/PTOptimise.h:35:48: boost/graph/breadth_first_search.hpp: No such file or directory In file included from PanoToolsInterface.cpp:34: ../../src/include/PT/PTOptimise.h:66: error: `boost' is not a class or namespace ../../src/include/PT/PTOptimise.h:67: error: `default_bfs_visitor' is not a class or namespace ../../src/include/PT/PTOptimise.h:67: error: invalid base-class specification ../../src/include/PT/PTOptimise.h: In member function `void PTools::OptimiseVisitor::discover_vertex(Vertex, const Graph&)': ../../src/include/PT/PTOptimise.h:92: error: `boost' is not a class or namespace ../../src/include/PT/PTOptimise.h:92: error: no class template named ` graph_traits' in `boost' ../../src/include/PT/PTOptimise.h:92: error: `adjacency_iterator' is not a class or namespace ../../src/include/PT/PTOptimise.h:92: error: ISO C++ forbids declaration of `ai ' with no type ../../src/include/PT/PTOptimise.h:93: error: `boost' is not a class or namespace ../../src/include/PT/PTOptimise.h:93: error: no class template named ` graph_traits' in `boost' ../../src/include/PT/PTOptimise.h:93: error: `adjacency_iterator' is not a class or namespace ../../src/include/PT/PTOptimise.h:93: error: ISO C++ forbids declaration of ` ai_end' with no type ../../src/include/PT/PTOptimise.h:98: error: parse error before `;' token ../../src/include/PT/PTOptimise.h: At global scope: ../../src/include/PT/PTOptimise.h:115: error: parse error at end of saved function text if /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H "-I." -I../../src/include -I../../src/foreign -march=athlon-xp -O3 -pipe -fomit-frame-pointer -m3dnow -msse -mfpmath=sse -mmmx -MT SpaceTransform.lo -MD -MP -MF ".deps/SpaceTransform.Tpo" \ -c -o SpaceTransform.lo `test -f 'SpaceTransform.cpp' || echo './'`SpaceTransform.cpp; \ then mv -f ".deps/SpaceTransform.Tpo" ".deps/SpaceTransform.Plo"; \ else rm -f ".deps/SpaceTransform.Tpo"; exit 1; \ fi make[2]: *** [PanoToolsInterface.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... g++ -DHAVE_CONFIG_H -I. -I../../src/include -I../../src/foreign -march=athlon-xp -O3 -pipe -fomit-frame-pointer -m3dnow -msse -mfpmath=sse -mmmx -MT SpaceTransform.lo -MD -MP -MF .deps/SpaceTransform.Tpo -c SpaceTransform.cpp -o SpaceTransform.o make[2]: Leaving directory `/tmp/portage/hugin-0.4-r1/work/hugin-0.4/src/Panorama' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/portage/hugin-0.4-r1/work/hugin-0.4/src' make: *** [all-recursive] Error 1
looks like you don't have boost installed
Yes, that's right, boost wasn't detected. re-emerging fixed it.
Created an attachment (id=47529) [edit] hugin-0.4-r1.ebuild updated Updated dependancies, removed src_compile (unecessary, since portage will do econf and emake by default), added HOMEPAGE
Please obsolete the "r1 of hugin ebuild" attachment from 2005-01-01
Was able to start up hugin using the ebuild I just submitted. Please test on many systems to make sure it works. Actually doing the panorama stitching is another task, but something which I will do another day, after I understand it better, perhaps after reading the tutorial at hugin.sf.net
I tried stitching two photographs with hugin using the most recent ebuild and it worked well. I stitched it using PTStitcher as well as "nona" (which I'm pretty sure is provided by hugin) and they both worked fine.
Created an attachment (id=47594) [edit] hugin-0.4-r1.ebuild updated Removed hard dependancy on panorama-tools-nonfree for now. Users should just use nona instead of PTStitcher. Provided message informing users of panorama-tools-nonfree/PTStitcher as alternative to nona.
Hi guys, I'm using hugin myself though not yet by using ebuild but my compiling myself. It works just fine with all the dependencies installed. I'm going to deinstall it and try the ebuilds this weekend. This is certainly something that had been missing in Portage! :-) I'm looking forward to having it in Portage on an ordinary basis! Thanks to all people working on this!
Every time I test is is too unstable or has too many issues (eg: depending on wxGTK) for being in portage, that's why I told time ago that I'd put it when there is a stable release, in the mean time there is plenty of work adding the required and released deps.
The latest hugin looks good. I'd be comfortable putting it in with ~x86 and I think any bugs that come in would be manageable. But like you said, the priority should be getting the deps in, and hopefully by that time there may be a 0.4 non-beta release of hugin.
Created an attachment (id=48071) [edit] hugin-0.4-r1.ebuild updated to use wxwidgets eclass By default hugin tries to run wx-config but this symlink is explicitly removed in wxGTK-2.5.3.ebuild. The wx-config file therefore needs to be explicitly specified on the configure command. This ebuild follows the example of wxpython-2.5.3.1.ebuild in using the wxwidgets eclass to determine which file to use for wx-config. Also >=x11-libs/gtk+-2.0.3 is only necessary if using gtk2.
Admin, please obsolete this attachment: r1 of hugin ebuild text/plain 2005-01-01 16:46 PST
I got the following error message and therefore modified the ebuild: ----- checking command to parse /usr/bin/i686-pc-linux-gnu-nm -B output from i686-pc-linux-gnu-gcc object... ok checking for objdir... .libs checking for i686-pc-linux-gnu-ar... i686-pc-linux-gnu-ar checking for i686-pc-linux-gnu-ranlib... i686-pc-linux-gnu-ranlib checking for i686-pc-linux-gnu-strip... (cached) i686-pc-linux-gnu-strip checking for correct ltmain.sh version... no *** Gentoo sanity check failed! *** *** libtool.m4 and ltmain.sh have a version mismatch! *** *** (libtool.m4 = 1.5.10, ltmain.sh = 1.5.6) *** Please run: libtoolize --copy --force if appropriate, please contact the maintainer of this package (or your distribution) for help. -----
Created an attachment (id=48599) [edit] hugin-0.4-r1.ebuild updated
Just to confirm, resync and recompile of latest ebuild worked fine for me.
Latest ebuild worked fine for me. And hugin works well. It took a bit more effort to get going and a few more CPU cycles but it works better than Canon Utilities PhotoStitch Version 3.1.14.34 (which doesn't seem to handle roll) and hugin doesn't require a reboot (into MS OS) to use the software.
Searched google found these: http://www.email-lists.org/pipermail/ptx/2005-January/003010.html http://www.email-lists.org/pipermail/ptx/2005-January/003011.html The second one has a fix and it does work... but it still breaks on me. I do have gcc 3.4.3, so that might be the problem.
Followed that thread further... It does seem like an amd64 problem. I got the cvs version and am trying it out. I had to delete a few lines from a tranlation file, but it seems to work. I guess just update the ebuild to use a newer cvs...
For AMD64 you have to do the following (maybe anyone could add a patch - I'm a newbie :( ) Download --> hugin_2004_10_15_11_20.tgz extract it and change the file hugin-0.4/src/include/vigra_ext/PointMatching.c:163 result.push_back(vigra::make_triple(dist1, it1 - feat1.begin(), best)); with result.push_back(vigra::make_triple(dist1, (int)(it1 -feat1.begin()), best));
Too early... hugin starts well, but adding an image ends with an "segmentation fault" on AMD64 :(...
I got some problem compiling 0.4-r1 on my gentoo system, using gcc 3.4.3 on pentium-m laptop. So, i modified the euild to 0.5_beta2 and now it worked! econf line is probably wrong... but worked for me :)
Created an attachment (id=51824) [edit] i only changed something... never made any ebuild...
Hmm, it seems that http://sourceforge.net/project/showfiles.php?group_id=77506 isn't linked from their http://hugin.sf.net site, so I didn't know there was such a recent beta. Great stuff miolinux.
miolinux, can you confirm that the 2 patches are no longer necessary?
If patches are no longer necessary, someone please obsolete the patches and obsolete "hugin-0.4-r1.ebuild updated" attachment. Thank you.
no, patches listed here for version 0.4-r1 are not needed anymore since 0.5_beta2 package includes them. i'm not an ebuild expert and someone should check why i needed to change the econf line from: - econf --with-wx-config="${WX_CONFIG}" || die "configure failed" to: + econf --with-wx-config="${WX_CONFIG}" --with-unicode|| die "configure failed" there must be another way to include "--with-unicode" but i haven't got time to read ebuild-how-to docs.
libtoolize should stay in src_unpack conditional unicode check should be `use_with unicode`
Created an attachment (id=51958) [edit] hugin-0.5_beta2.ebuild Please obsolete the older 0.5_beta2 ebuild
I think we can obsolete splash-configure_ac.patch as well
I would recommend that "hugin-0.4-r1.ebuild updated" and the patches go into portage with ~x86. Once 0.5_beta2 is tested a bit, it can go in too.
Just a quick to note the 0.5_beta2 ebuild works for me (modified it because libpano12 is still called panotools and unmasked wxGTK 2.5.x). I didn't emerge autopano-sift (#75192) because I don't have mono on my system (yet). The Preferences dialog for hugin seems to indicate there is a "autopanog"? Is it a bug that I don't have that or are we only supporting autopano-sift?
Colin, I've been pushing for a name change to libpano12. Use the ebuild at Bug #76476. So far it is 2-1 for changing the name to libpano12. If we have your vote that would be 3-1. ;-) It's a small detail, but I stand by my opinion that for new users it is very confusing, as Helmut's nonfree java stuff is called panotools as well. I also like lib packages to start with "lib." And BTW, the panotools ebuild in CVS might be the same as the libpano12 ebuild at Bug #76476 I'm not sure. But anyways, every hugin ebuild I'll submit will have the libpano12 dependancy, not panotools. Install mono, it's easy. Be ware of the nptl issue. mono + nptl USE flag requires gcc 3.4.x Disable the nptl USE flag for mono and use gcc 3.3.x or upgrade to gcc 3.4.x. gcc is slotted I think, so it's not biggie to try it out. libpano-sift works like a charm. autopanog is autopano-sift. I believe in the most recently submitted autopano-sift ebuild, the name of the script which loads autopano-sift is now called autopanog (used to be autopano-sift). See Bug #75192: "I changed the gui to be run with autopanog instead of autopano-sift because I thought it was more consistent with the man page." I don't agree or disagree with this decision.
I suggest that either hugin depends on autopano-sift or, if thats too heavy a dependency then at least einfo a message telling users they might want to emerge autopano-sift. Thanks for your help David (mono building overnight tonight on gcc-3.3!). Hugin and friends are a really amazing set of software: it'll be a big boost to Gentoo to get these included in the tree (and a boost to the Free Software movement in general as these programs become more popular).
Created an attachment (id=52087) [edit] hugin-0.5_beta2.ebuild Colin, the einfo message about autopano-sift was there, but in src_install which is probably why it got missed. Now it is in pkg_postinst
If really necessary I could came up with a sift modelled after the C# one but written in a less demanding language (C++, python, perl, ruby?)
mono-1.0.6 and mono-1.0.5-r4 don't need gcc-3.4 any more. (See dev-dotnet/mono/ChangeLog.) When I used a special USE=-ntpl for mono-1.0.5-r3, lt-mono would often hang. I don't know if it still happens but turn ntpl on if you have that problem. (Looking forward to trying out hugin-0.5_beta2 when I get a chance.)
mono built fine on my gcc-3.3 system. The pipeline of Hugins -> autopano-sift -> enblend works great for me! I don't feel there is need for anyone to recode autopano (if a system is used to using big images like this it can probably build mono without complaint! :)
Luca, what do you mean by demanding? Are you referring to building? or runtime? I had some trouble with 0.5_beta2 and gcc 3.4.x. Ended up rebuilding a few packages (I think wxGTK was the one that really needed rebuilding) and then rebuilding hugin. Loads up fine now, haven't tried making a panorama with 0.5_beta2 yet though.
There are people that could enjoy a java free and mono free system, so, if there is somebody asking for it, I could spend some time trying at least to figure out to avoid java bindings in libpano12 (I'll move it asap) or to rewrite autopano-sift in another language that doesn't need a rVM. I have to thank you again for the help you are giving us in order to have a decent panoramic tool suite in gentoo.
Luca, I suggest we just talk to upstream, and ask them to provide an option to ./configure which disables or enables java bindings. If they are completely 100% unwilling, then a patch could be made, and then submitted upstream.
hugin is useful even without autopano-sift so I don't think hugin should depend on autopano-sift. autopano-sift is VERY useful though and so we should make it easy to run from hugin. At bug #75192, Peter Johanson said "As much as possible, *.exe should avoid going into /usr/bin." Is this a gentoo policy? hugin-0.5_beta2 by default tries to run autopanog.exe. If we don't like the .exe suffixes then a sed -i 's/"autopanog.exe"/"autopanog"/' src/include/hugin/config_defaults.h in src_unpack would make things consistent. Has anyone looked at panosifter and sift_keypoints that come with hugin? It does look like they have been superseded by autopano-sift. I don't think rewriting autopano-sift is a priority, but I'd check these tools out before doing another rewrite. (The java dependency on libpano12 does seem unnecessary and some people may like to have this removed.) Also: aclocal/automake/autoconf should no longer be necessary now that m4 files are not being patched. make install DESTDIR=${D} || die seems to work with 0.5-beta2 so this would get rid of the ugly xrcdir/xrcdatadir stuff I put in.
(From update of attachment 46897 [edit]) Already included in hugin-0.5_beta2
Created an attachment (id=52306) [edit] hugin-0.5_beta2.ebuild simplified Few simplifications, and removal of autoconf/automake step
Created an attachment (id=52432) [edit] hugin-0.5_beta2.ebuild Added the debug USE flag functionality. There have been reports of segfaults on the hugin mailing list. If you get one, use the debug USE flag and re-build.
Created an attachment (id=52435) [edit] hugin-0.5_beta2.ebuild Changes discussed in Comment #74. If you have a $HOME/.hugin you won't notice the new default autopano executable name unless you remove this file. Also removed unused eutils and used PV to calculate MY_P.
Karl (per comment #74), This forums thread somewhat addresses your .exe question: http://forums.gentoo.org/viewtopic-t-295927-view-next.html
Thanks for the link, seddes. So putting *.exe in /usr/bin is like clubbing a baby seal. Can't say I really understand the similarity but I don't want to do that.
Created an attachment (id=52821) [edit] hugin-0.5_beta2.ebuild 1: Work around a bug in hugin where -g -DDEBUG compile flags are added when --disable-debug is provided configure. 2: Make nona the default stitcher as Gentoo will probably not provide PTStitcher (see Bug #48268). For 1, the problem is really in configure.ac which adds the flags irrespective of the value of enableval, but it is easy enough to modify the ebuild so as not to supply --disable-debug when the debug use flag is not set.
I'll have a look on it, thanks for the help
re: comment *81: I just told upstream about the --disable-debug not working. Doug Wilkins has fixed it in CVS so it should be fixed in the next release and we can just use `use_enable debug`
Created an attachment (id=52970) [edit] hugin-0.5_beta3.ebuild
Ruben, you did not use the most recent ebuild when creating the version bump. If you added some extra in the ebuild, please incorporate it into the most recent ebuild and then attach.
2005-03-07 14:33 dwilkins42 * configure.ac: Fix --disable-debug error This was fixed, so we can use `use_enable debug` now Other changes in the new beta are: -Added support for ignoring some images during optimisation and stitching. Added support for crop (not supported during stitching yet) -fixed bug when reading exif data of rotated images. (image data rotated, portrait orientation, but exif sensor size is usually still in landscape format) -Fixed "yaw optimisation enabled bug". I wonder why the compilers didn't detect that I was using different enums in the switch and case statements.. -If images are in a new directory, use new directory for loading all images -revert "fix" for yaw optimisatin problem.. shouldn't code straight after getting up. I suspect a build problem is responsible for that bug :( -fixed optimize anchor yaw when vertial OR horizontal point is selected.
Created an attachment (id=52997) [edit] hugin-0.5_beta4.ebuild same as beta3, but compiles with gcc 3.4
Created an attachment (id=53383) [edit] hugin-0.5_beta4.ebuild The change I made in Comment #81 to make nona the default stitcher doesn't work. This change corrects that.
emerged quite well. one issue: I do not see any images or menus with images. when I add an image nothing happens. When I drag and drop the status bar lets me know that it is importing the image, but once that is done, the gui does not change to list the images I added. The only way I can see anything is if I open up the preview window. Any thoughts wise ones? I have tried with gtk and gtk2.
greg, so you're dragging-and-dropping? Why don't try clicking on add images... Either way, give us exact detail of what you are doing step-by-step so we can try out the same steps. Look for error messages in the console. emerge with the DEBUG USE flag enabled, and send reports. Maybe create a new bug though, because this bug report is getting a bit long.
If you re-read my bug, I did try to "Add image" but nothing happens at all. Will try the debug route...
Debug on. After I close the tooltip I click on "Add Individual Images" and see: TRACE 15:13:17.408844 (MainFrame.cpp:608) OnAddImages(): INFO 15:13:18.265292 (MainFrame.cpp:631) OnAddImages(): Image extention: all (hugin:30359): Gtk-CRITICAL **: gtk_file_folder_unix_get_info: assertion `strcmp (dirname, folder_unix->filename) == 0' failed I select the images, say "Open" and get: INFO 15:13:31.717397 (MainFrame.cpp:663) OnAddImages(): img_ext: 3 TRACE 15:13:31.717547 (MainFrame.cpp:672) OnAddImages(): Perhaps a gtk problem? I have gtk+-2.6.4. What other info can I provide? i686-pc-linux-gnu-3.4.3-20050110 Screenshot here: http://ricelab.plbr.cornell.edu/images/hugin_no-images.jpg
So I am trying the 0.4-r1 ebuild now and notice that I do not have fftw. Should that be a required ebuild for 0.5? Anyway, 0.4r1 bombs out on: In file included from ../../src/include/PT/PanoToolsInterface.h:38, from ../../src/include/panoinc.h:81, from ../../src/include/hugin/MyProgressDialog.h:27, from MyProgressDialog.cpp:30: /usr/include/pano12/panorama.h:69:71: windows.h: No such file or directory In file included from ../../src/include/PT/PanoToolsInterface.h:38, from ../../src/include/panoinc.h:81, from ImageCache.cpp:29: /usr/include/pano12/panorama.h:69:71: windows.h: No such file or directory make[4]: *** [MyProgressDialog.lo] Error 1
Works great here on my amd64 box thanks! (as well as enblend and autopano-sift :) ).
The ebuild should have ~amd64 added to the key words. I have been running beta 3 how for several weeks on my amd64 system.
As noted in Comment #87 the hugin-0.5_beta4 ebuild is really for hugin 0.5 beta 3 and as such it should have been named hugin-0.5_beta3-r1.ebuild. Now that beta 4 has been released this will be confusing. So it should be renamed and an ebuild for the real beta 4 needs to be created.
Initially, I tried emerging hugin-0.4-r1. During the compiling, I got the following error: make[5]: Entering directory `/var/tmp/portage/hugin-0.4-r1/work/hugin-0.4/src/hugin/xrc' wxrc -g -o about.xrs about.xrc make[5]: wxrc: Command not found make[5]: *** [about.xrs] Error 127 I have wxrc-2.6, so I created a soft link to it, and tried again. # ln -s /usr/bin/wxrc-2.6 /usr/bin/wxrc This time, it got further, but stopped at a different point (I'm afraid I didn't write this error down). Using the latest ebuild, hugin-0.5_beta4, I had no problems! Thanks a lot, guys!
Created an attachment (id=58776) [edit] patch for hugin-0.5_beta4.ebuild to use wxGTK 2.6 This is just a quick hack which worked for me.
The path in hugin-0.5_beta5.tar.bz2 has changed. You need this (in addition to the wxGTK 2.6 patch) to get past ./configure: 9,10c9 < MY_P="${PN}-${PV/_/-}" < SRC_URI="mirror://sourceforge/hugin/${MY_P}.tar.bz2" --- > SRC_URI="mirror://sourceforge/hugin/${PN}-${PV/_/-}.tar.bz2" 24c23 < S=${WORKDIR}/${MY_P} --- > S=${WORKDIR}/${PN}-0.5 However, make won't proceed, saying it has no rule to make several files under the m4 directory. To me it looks like there are some files missing in the tarball. I tried using the m4 files from beta4, but to no avail. Is anyone more familiar with configure and/or m4?
