Midori is a lightweight web browser based on webkit (gtk port). Midori is written on pure C with gtk toolkit. This ebuild has some new use-flags: 'idn' -- for international domain name support (via libidn) 'unique' -- for support single instance via libunique 'doc' -- for generation api-docs 'html' -- for generating html user documentation (help file), requires docutils There is conditional structure with inherit in this ebuild, so release and live(git) ebuilds differ only in KEYWORD variable. Early this ebuild was in bug #266402 , but that bug was closed.
Created attachment 199708 [details] git ebuild for midori
Created attachment 199709 [details] ebuild for midori-0.1.8
Thanks for submitting your enhanced ebuilds, assigning to midori maintainer.
assigning to new maintainer. -I personally would keep the 9999 stuff outside of the normal ebuild - too much clutter. -Don't need to reinvent the wheel with PATCHES handling. That is already done in base.eclass or the new xfconf.eclass (which uses base itself)
(In reply to comment #4) > -I personally would keep the 9999 stuff outside of the normal ebuild - too much > clutter. I think in this instance that's good. > -Don't need to reinvent the wheel with PATCHES handling. That is already done > in base.eclass or the new xfconf.eclass (which uses base itself) Okey. I'll look what I can do with it.
Created attachment 200307 [details] ebuild for midori-0.1.9 * version bump * some minor fixes (depends etc.) - dropped patches
That still has the conditional PV-ugliness, please kill that off.
Created attachment 200377 [details] ebuild for midori-0.1.9 Nevertheless i think that conditional structure is nice... but if you want... - conditional structure with PV is dropped
Created attachment 200379 [details] git ebuild for midori synced git ebuild
Created attachment 200386 [details, diff] midori-0.1.9.ebuild.diff For ease of review, here is a diff between your ebuild and mine. Please note, you are changing SRC_URI to a location that does *not* have a 0.1.9 distfile at all: http://goodies.xfce.org/releases/midori/ I feel your gnome USE-flag is obfuscating the real dependency on libsoup, XFCE users without gnome might still want to drag that in. You're taking that ability away from them. Also, you're dropping a FreeBSD keyword. Do you need that multilib inherit? Does it fix a QA warning or directory naming issue? If so, which? Perhaps "doc" should enable both sets of documentation. I expect a "of *course* I want HTML support in my browser!" gut reaction to USE="html" (we have traditionally used USE="doc" for this). Since your src_unpack is the default, you don't need to supply it. Just let the default remain in place. The --disable-docs that is later overridden with use_enable looks strange to me, could you elaborate on how that works?
Created attachment 200387 [details] midori-0.1.9.ebuild (with xfconf.eclass) (In reply to comment #8) > Created an attachment (id=200377) [edit] > ebuild for midori-0.1.9 > > Nevertheless i think that conditional structure is nice... but if you want... > > - conditional structure with PV is dropped > Attached ebuild utilizes xfconf.eclass moreso. This is a direct conversion and does not take into account any suggestions made by comment #10. I am leaving this for review to the maintainer, since I don't even use midori and do not wish to maintain it ;)
Created attachment 200397 [details, diff] midori-0.1.9.ebuild.diff (In reply to comment #10) > Created an attachment (id=200386) [edit] > midori-0.1.9.ebuild.diff > > For ease of review, here is a diff between your ebuild and mine. This is other diff with some changes. > Please note, you are changing SRC_URI to a location that does *not* have a > 0.1.9 distfile at all: > http://goodies.xfce.org/releases/midori/ fxd. i usually use git version myself. > I feel your gnome USE-flag is obfuscating the real dependency on libsoup, XFCE > users without gnome might still want to drag that in. You're taking that > ability away from them. Dependency on libsoup is hard from 0.1.2 version (AFAIK). And if libsoup is built with 'gnome' use-flag (de facto this means libproxy support) midori can manage proxy settings through libproxy. This use flag requires libsoup[gnome] which pulls libproxy that pulls gvfs and many gnome libs... > Also, you're dropping a FreeBSD keyword. fxd > Do you need that multilib inherit? > Does it fix a QA warning or directory naming issue? If so, which? It is needed because it contains get_libdir function. AFAIK, waf cannot automatically detect libdir on multilib systems. > Perhaps "doc" should enable both sets of documentation. I expect a "of *course* > I want HTML support in my browser!" gut reaction to USE="html" (we have > traditionally used USE="doc" for this). I don't think so. api-docs are needed only for developers, in turn user-docs (F1-help, that is one html file) are needed for almost all user, especially for beginners. But some advanced users don't want to install docutils which is required to generate user-docs which aren't needed for them. So we need two flags for it. I have chose 'html' because: >grep :html /usr/portage/profiles/use.* ... >/usr/portage/profiles/use.local.desc:dev-libs/fcgi:html - Install HTML documentation ... >/usr/portage/profiles/use.local.desc:dev-python/pylint:html - Install HTML documenation ... >/usr/portage/profiles/use.local.desc:net-misc/hylafax:html - Adds HTML documentation >/usr/portage/profiles/use.local.desc:sys-kernel/linux-docs:html - Install HTML documenation If you can propound another second use-flag, propond, please. > Since your src_unpack is the default, you don't need to supply it. Just let the > default remain in place. This was an artifact :) . fxd > The --disable-docs that is later overridden with use_enable looks strange to > me, could you elaborate on how that works? midori's install script has three parameters for docs: {--enable-,--disable}{docs,userdocs,apidocs} -- the first is for installing {AUTHORS ChangeLog INSTALL TODO} plain-text files which are usually putted in tarballs, the second is for html file which is showed on F1 key press, the third is for api-docs for developers (requres gtk-doc). There are two use_enables for docs: for use-flag 'doc' and apidocs parameter, and for use-flag html and userdocs. So use_enable doesn't override --disable-docs and AUTHORS etc. files aren't installed by script because those files should be installed by dodoc command to proper directory.
Created attachment 200398 [details, diff] midori-9999.ebuild.diff 9999 diff
Created attachment 200399 [details, diff] midori-0.1.9.ebuild.diff the same, but with xfconf eclass
Created attachment 200400 [details, diff] midori-9999.ebuild.diff the same
(In reply to comment #15) > Created an attachment (id=200400) [edit] > midori-9999.ebuild.diff I need more time to think do we need this...
Created attachment 200722 [details] midori-0.1.9-r1.ebuild Okay, best amalgation of my ebuild, Jan's suggestions and Jeremy's update that I could come up with. The patch that you both reference... please attach it.
Created attachment 200783 [details] patch, that makes docdir version-specific (In reply to comment #17) > Created an attachment (id=200722) [edit] > midori-0.1.9-r1.ebuild > > Okay, best amalgation of my ebuild, Jan's suggestions and Jeremy's update that > I could come up with. :) >The patch that you both reference... please attach it. Ok. This is it. But this patch is version-dependent and I mean that sed commands is better... With sed you must only rename ebuild for build new version, and with patch you need edit/remake patch.
(In reply to comment #17) > Created an attachment (id=200722) [edit] > midori-0.1.9-r1.ebuild Are you sure that pkgconfig is needed?
Created attachment 200791 [details] ebuild for midori 0.1.9 with sed command I belive that ebuild with sed command instead of docdir patch is more easy to maintain.
Created attachment 200793 [details] git ebuild for midori with sed command synced git ebuild
(In reply to comment #19) > Are you sure that pkgconfig is needed? Show me that it is *not* required for this particular "waf" build system (which still seems to have versioned dependencies). I'm open to dropping this dependency, but not by virtue of leaving it out of the ebuild and waiting for bugs.
(In reply to comment #22) > (In reply to comment #19) > > Are you sure that pkgconfig is needed? > > Show me that it is *not* required for this particular "waf" build system (which > still seems to have versioned dependencies). I'm open to dropping this > dependency, but not by virtue of leaving it out of the ebuild and waiting for > bugs. > hmm... really: user@localhost /home/docs/user/src/midori $ grep -r pkg-config . ./.waf-1.5.3-575529c232c0559c3efb0adb3d077447/wafadmin/Tools/config_c.py: kw['path']='pkg-config --errors-to-stdout --print-errors' ./.waf-1.5.3-575529c232c0559c3efb0adb3d077447/wafadmin/Tools/config_c.py: kw['msg']='Checking for pkg-config version >= %s'%kw['atleast_pkgconfig_version'] ./.waf-1.5.3-575529c232c0559c3efb0adb3d077447/wafadmin/Tools/qt4.py: pkgconfig=env['pkg-config']or'PKG_CONFIG_PATH=%s:%s/pkgconfig:/usr/lib/qt4/lib/pkgconfig:/opt/qt4/lib/pkgconfig:/usr/lib/qt4/lib:/opt/qt4/lib pkg-config --silence-errors'%(qtlibs,qtlibs) ./.waf-1.5.3-575529c232c0559c3efb0adb3d077447/wafadmin/Tools/gnome.py: conf.env['DB2OMF']=Utils.cmd_output("/usr/bin/pkg-config --variable db2omf gnome-doc-utils",silent=1).strip()
(In reply to comment #18) > > Ok. This is it. But this patch is version-dependent and I mean that sed > commands is better... With sed you must only rename ebuild for build new > version, and with patch you need edit/remake patch. > Thanks for attaching it, I simply forgot. The reason is simple. With Gentoo, our goal is to not have any sed or patches, they should all be sent upstream. So, if the patch a) doesn't get sent upstream, or b) upstream rejects it, then yes..a sed command is easier and won't require messing with the patch for every bump. Hope that makes sense. :)
Created attachment 201723 [details] git ebuild for midori with sed command *fixed EGIT_REPO_URI
Created attachment 203199 [details] git ebuild for midori EGIT_REPO_URI :)
This should apply to the just-released Midori-0.1.10 that came out on the 11th. Stuff looks good. I'd especially like to see the libunique dependency made *optional* ASAP, as upstream says it is indeed optional. Just check the homepage. It really isn't necessary to run; it's just one more thing to download and compile. Actually, 0.1.10 looks much more exciting than 0.1.9 since the latest version introduces something like AdBlock+, so no need for Firefox any longer! Just renaming this ebuild to the latest version works nicely. :)
Go for it nightmorph, feel free to take maintainership. I've switched back to Firefox.
(In reply to comment #28) > Go for it nightmorph, feel free to take maintainership. I've switched back to > Firefox. I don't have commit access to gentoo-x86. Besides, I thought jokey was the maintainer? I see him on lots of other midori/webkit-gtk bugs. Maybe he'd be up for it, or possibly the Xfce guys.
-0.1.10 is in the tree with said enhancements (few additions, deletions from posted ebuilds here) -Removed Tony from metadata, per comment #28. xfce team will take care of this. -revamped -9999 ebuild with 0.1.10 improvements. -won't fix 0.1.9, moving on with new versions only. All done, thanks.
