Ebuild for semantik Reproducible: Couldn't Reproduce Steps to Reproduce:
Created attachment 125016 [details] Ebuild for semantik 0.4.5
Created attachment 125267 [details] working version of ebuild
Created attachment 125436 [details] semantik-0.4.6.ebuild
I got you ebuild and tried to fix that sandbox issue. The waf build system has options for prefix and destdir, but it doesn't work without problem. I always get that error: --- * installing waf as /usr/share/semantik/templates/waf Could not install the file /usr/share/semantik/templates/waf --- While other files get correctly installed with --destdir=${D}. It seems that waf is the culprit.
Created attachment 128953 [details] Ebuild for semantik-0.5.1f This ebuild works for me (x86). Very simple, since it doesn't inherit distutils.
Ebuild for semantik-0.5.1f does work for me too on x86.
Created attachment 129118 [details] Ebuild for semantik-0.5.1f Addad the ~amd64 keyword and works on my amd64 too.
Created attachment 129206 [details] semantik-0.5.2.ebuild
Created attachment 129305 [details] semantik-0.5.3.ebuild New ebuild.
Created attachment 131165 [details] semantik-0.5.4.ebuild Return to kde-apps.org disturl.
Created attachment 133409 [details] kde-misc/semantik/semantik-0.5.8.ebuild
(In reply to comment #11) > Created an attachment (id=133409) [edit] > kde-misc/semantik/semantik-0.5.8.ebuild > It is working fine on x86 !
(In reply to comment #12) > (In reply to comment #11) > > Created an attachment (id=133409) [edit] > > kde-misc/semantik/semantik-0.5.8.ebuild > > > > It is working fine on x86 ! > Works fine on both x86 and amd64 for me Note that the next release 0.68 requires Qt4.4 which is still hard masked.
Created attachment 174792 [details] semantik-0.6.8.ebuild - version bump - using kde4-base eclass - slotted to 4.1 - removed dependency on swig (didn't found it on the website) - removed unnecessary variables from the ebuild Configures, compiles and runs fine here on amd64.
0.6.9 is out. Also, could this be slowly added to the official tree or at least an overlay?
(In reply to comment #15) > 0.6.9 is out. Also, could this be slowly added to the official tree or at least > an overlay? I cannot answer since I'm not a gentoo dev. I just want to point out that : - 0.6.9 was buggy (a file collision problem prevented semantik from being installed by emerge, without extra commands in src_install()). This problem was reported upstream and is now solved in 0.7.0. - the ebuild for 0.6.8 works for 0.7.0 (just have to rename it).
Created attachment 177338 [details] kde-misc/semantik/semantik-0.7.0.ebuild
works fine on ~ppc.
Since Qt4 is in Portage already available as atomic ebuilds, I'd be necessary to add support for their users as well in the ebuild. E.g. (example taken from the SMPlayer ebuild) DEPEND="|| ( x11-libs/qt-gui:4 =x11-libs/qt-4.3* )"
I just asked Thomas Nagy (the developer of Semantik) about its real dependancies and here's his list: Run-time: * qtcore * qtgui * qtxml * python * python-xml Compilation: * ocaml * python-dev * g++ * gcc * kdelibs-devel I suppose the '*-devel' packages are used in other distributions and in Gentoo they're just called '*'. ;)
Also 0.7.1 is out.
Created attachment 187027 [details] semantik-0.7.1.ebuild In response to comments #20 and #21 I attach semantik-0.7.1.ebuild. It fails with a sandbox violation, but I could merge it with FEATURES="-sandbox" Step by step, I get the sandbox violation when doing the ebuild /path/to/semantik-0.7.1.ebuild qmerge part: -------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE "/var/log/sandbox/sandbox-11039.log" VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: open_wr S: deny P: /etc/ld.so.cache~ A: /etc/ld.so.cache~ R: /etc/ld.so.cache~ C: /sbin/ldconfig --------------------------------------------------------------------------------
(this is an automated message based on filtering criteria that matched this bug) 'EBUILD' is in the KEYWORDS which should mean that there is a ebuild attached to this bug. This bug is assigned to maintainer-wanted which means that it is not in the main tree. Heuristics show that no Gentoo developer has commented on your ebuild. Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
(In reply to comment #22) > It fails with a sandbox violation, but I could merge it with > FEATURES="-sandbox" What's weird is that your 0.7.1 ebuild worked just fine using Paludis, but now that I'm back on Portage, I get the same error as you do. Also, today TNagy just released 0.7.2 with some minor bugfixes since 0.7.1.
Thanks Matija, This works with --> FEATURES="-sandbox" Also semantik-0.7.2 installed succesfully by copying semantik-0.7.1.ebuild to semantik-0.7.2.ebuild and emerging it.
Hi all Thanks for all the work with semantik done so far. I was not really too happy about just emerging with USE='-sandbox' and tried to tweak the ebuild to work around the issue of calling ldconfig. My current result is far from complete and I'm running out of time I can spend on this right now. What it does: a) it let's you build w/o '-sandbox' by patching the call to ldconfig. I'm not sure if we'd need to write a file into /etc/env.d instead by using doenvd (similar to e.g. augustus-2.1.ebuild) b) It runs into a with potential security picked up by scanelf relating to DT_RPATH and DT_RUNPATH each being set to '-Wl:/usr/lib/qt4 in the two binaries libnablah.so and semantik. I have not been able to quickly resolve this. I have successfully used the installed program semantik and created some mindmaps and exported to nearly all export paths. However the scanelf issue should be resolved. Maybe somebody can pick this up. HTH, regards Urs
Created attachment 191003 [details] Diff to semantik-0.7.1 patch to build 0.7.2 using sandbox has issues with scanelf and DT_R(UN)PATH='-Wl:/usr/lib/qt4' relies on wscript_ldconfig.patch
Created attachment 191005 [details] wscript_ldconfig.patch to let wscript not run ldconfig (prevent sandbox violation)
Latest available version 0.7.3
Created attachment 205264 [details] kde-misc/semantik/semantik-0.7.3.ebuild
Created attachment 205265 [details, diff] files/semantik-0.7.3-wscript_ldconfig.patch
Is there any chance of seing this ebuild soon in Sunrise or even the official tree?
I've made a few changes to the ebuild to make it work and to clean up some of the dependancies clutter.
Created attachment 220369 [details] Cleaned up, working ebuild I took the alredy existing 0.7.3 ebuild, cleaned it up a bit and made it work (again).
Works for me on amd64 for kde 4.4 How to get it in the tree?
(In reply to comment #35) > Works for me on amd64 for kde 4.4 Same here on KDE 4.3 (AMD64 stable) > How to get it in the tree? Someone from the Gentoo devs has to upload it to the official CVS. So basically we wait until someone checks if it's good enough. Or better yet, until the arch testers test it on their arches and if all looks well and the quality is met, upload it to the official CVS. The moment that happens, we users get access to it on the next sync.
Altho it is nice app, it uses waf, and i dont think anyone from kde team wants that thing again in the tree :] Might be REALLY good idea to convince upstream to switch to cmake/autotools.
I've tested 0.7.3 ebuild attached here, and I can see 2 problems stopping the inclusion to Portage. First one, doesn't respect LDFLAGS: * QA Notice: Files built without respecting LDFLAGS have been detected * Please include the following list of files in your report: * /usr/lib64/libnablah.so Second one, insecure runtime path: scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='-Wl:/usr/lib64/qt4' in /var/tmp/portage/kde-misc/semantik-0.7.3/image/usr/bin/semantik scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='-Wl:/usr/lib64/qt4' in /var/tmp/portage/kde-misc/semantik-0.7.3/image/usr/bin/semantik scanelf: rpath_security_checks(): Maybe? sec problem with DT_RPATH='-Wl:/usr/lib64/qt4' in /var/tmp/portage/kde-misc/semantik-0.7.3/image/usr/lib64/libnablah.so scanelf: rpath_security_checks(): Maybe? sec problem with DT_RUNPATH='-Wl:/usr/lib64/qt4' in /var/tmp/portage/kde-misc/semantik-0.7.3/image/usr/lib64/libnablah.so
(In reply to comment #37) > Altho it is nice app, it uses waf, and i dont think anyone from kde team wants > that thing again in the tree :] I understand the problem. But the package/ebuild packs WAF with it — which is also not the nicest thing, I know — so there's no need for a dependancy and it doesn't leave it on the system after the emerge finishes. > Might be REALLY good idea to convince upstream to switch to cmake/autotools. This might be a problem, since the same author wrote WAF as well (since he was not happy with autotools/cmake/...) :\ It would be worth a shot though. BTW, the URL is: http://freehackers.org/~tnagy/semantik.html
(In reply to comment #38) > I've tested 0.7.3 ebuild attached here, and I can see 2 problems stopping the > inclusion to Portage. Thanks for the report. I'm pretty new to ebuilds and suck at coding, so it'll take me quite a while to figure out what those two problems are and how to solve them, but I'll take a look at it — there is no excuse to having foo ebuilds in portage! :]
Created attachment 257452 [details] ebuild with more cleanups Current state of the ebuild. However it will not go anywhere unless the security and qa warnings are fixed, and that takes some analyzing.
In the main portage tree now, enjoy!
