Hello, I attach the file libcwd-0.99.28.ebuild , libcwd is a usefull lib to help while debugging applications. more information are available at http://libcwd.sourceforge.net Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 10086 [details] libcwd-0.99.28.ebuild is the ebuild for libcwd a usefull C++ debugging lib
sorry I did a mistake while entering the bug, I should use libcwd-0.99-28.ebuild( New Package ) instead of a full description. I'm not very familiar with bugzilla, so I'm still looking on how to edit it. also note , that I find the ebuild submission sytem kinda slower.is there a way to speed up things ?
ok .. sorry it took so long to get around, can you please fix a couple things in the ebuild and resubmit it? 1. add IUSE="" 2. don't use SUB=... , that is not needed, S=${WORKDIR}/${P} should work fine 3. the SRC_URI should use the mirror://sourceforge construct, you can take a look at some of the other ebuilds like net-im/gaim 4. you can replace ./configure ... with econf like : src_compile() { econf || die make || die "make failed" } 5. are there any readme and other docs that can be installed using "dodoc" ?
Created attachment 13275 [details] up to date libcwd -0.99.28 ebuild.
I fixed the ebuild,this should be ok now, exept for the dodoc thing. there is a nice documentation, but there are a lot of files,and some subdirs , I don t know well how I could use dodoc to install it and to create the necessary subdirs. I'm looking in others ebuilds on how to do that.
Created attachment 13278 [details] Ebuild for libcwd 0.99.28 I added the documentation installation , using dodoc.
Created attachment 13279 [details] Ebuild for libcwd 0.99.28
ok .. we're nearly there. a couple more things to fix up. the docs stuff is good, but you don't have to use dodoc for all the documentation files. it is easier if you use something like cp -rf ${S}/documentation/{somedirectories} ${D}/usr/share/doc/${PF} also, the LICENSE isn't valid. it should be GPL-2 or GPL-1. finally, i just checked the libcwd website and they seem to have a new version. does this work with 0.99.29?
Created attachment 13674 [details] ebuild for libcwd-0.99.28 I removed the dodoc part ( I found it ugly too, but I trought I had to use dodoc ). the license was wrong , it's now set to QPL. this ebuild works for the new version,this one wasn t out when I made it.as soon as it as been accepted,I'll bump to the next version.
should I do something more ?
sorry this has been sitting on my queue for a while, but i don't have the time to put this into portage. bug-wranglers, you'd like to assign it to someone more appropriate? its seems to be actively maintained since the last update was just in june 2004
The actual version is libcwd-0.99.39 since 8 Oct 2004
its been sitting on my buglist and i haven't got time to maintain this :(
Created attachment 89948 [details] libcwd-0.99.44.ebuild Ok then, ebuild is in the gentoo-sunrise overlay, you can also get it at http://gentoo-sunrise.org/svn/sunrise/dev-cpp/libcwd
Version 1.0.0 is out and adds proper support for amd64. Bumping the current ebuild from the sunrise overlay worked fine. Regards, Elias P.
The current ebuild in sunrise(0.99.47) fails in pkg_install due to 'emake ... install' jobs stomping on each other. The simple fix is to just do 'emake -j1 ... install' - tested and working fine here.
Created attachment 174435 [details, diff] gcc-4.3.patch Needs following patch for gcc-4.3. Error: elfxx.cc:708: error: explicit template specialization cannot have a storage class elfxx.cc:727: error: explicit template specialization cannot have a storage class make[2]: *** [libcwd_la-elfxx.lo] Error 1 Explanation: http://gcc.gnu.org/gcc-4.3/porting_to.html Shall I fix this in sunrise?
Last upstream release 4 years ago, version in sunrise from 2008 and doesn't work: x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I./include -I./include -DCWDEBUG -g -O2 -march=nocona -mno-sse3 -pipe -c type_info.cc -fPIC -DPIC -o .libs/libcwd_la-type_info.o x86_64-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I./include -I./include -DCWDEBUG -g -O2 -march=nocona -mno-sse3 -pipe -c function.cc -fPIC -DPIC -o .libs/libcwd_la-function.o In file included from demangle3.cc:112:0: ./include/demangle.h:465:35: error: redeclaration of 'void __gnu_cxx::demangler::session<Allocator>::add_substitution(int, __gnu_cxx::demangler::substitution_nt, int)' may not have default arguments [-fpermissive] int number_of_prefixes = 0) ^ In file included from demangle3.cc:112:0: ./include/demangle.h:1739:53: error: redeclaration of 'void __gnu_cxx::demangler::qualifier_list<Allocator>::decode_qualifiers(__gnu_cxx::demangler::qualifier_list<Allocator>::string_type&, __gnu_cxx::demangler::qualifier_list<Allocator>::string_type&, bool) const' may not have default arguments [-fpermissive] bool member_function_pointer_qualifiers = false) const ^ Makefile:581: recipe for target 'libcwd_la-demangle3.lo' failed make[2]: *** [libcwd_la-demangle3.lo] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/var/tmp/portage/dev-cpp/libcwd-0.99.47/work/libcwd-0.99.47' Makefile:769: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/dev-cpp/libcwd-0.99.47/work/libcwd-0.99.47' Makefile:376: recipe for target 'all' failed make: *** [all] Error 2 emake failed
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
Is there still any interest in having this added to Gentoo? There have been more versions published upstream since 0.99.44 but the last one, 1.0.6, came out in September 2016. In the event of there being no interest, we shall close this ticket in 30 days from now.
