This is another ebuild for midori-0.1.5. It supports 'idn' & 'unique' use flags, use 'soup' has been removed because now midori require libsoup hard (not optional). webkit-gtk-0_p42000 has been replaced with net-libs/webkit-gtk-1.1.1 Reproducible: Always
Created attachment 188595 [details] ebuild for midori-0.1.5
I think we need webkit-gtk-1.1.5 in the tree then too alongside the SVN ones or replacing them. Due to that personally interested too (would do the webkit-gtk bits if had more time, maybe I shall take that time over the weekend). Then the SVN builds, if any, would be webkit-gtk-1.1.5_p200904nn, etc for proper ordering
(In reply to comment #2) it will be nice :)
Created attachment 189563 [details] ebuild for midori-0.1.6 + Version bump + Use-flag 'doc' for api-doc building has been added * Documentation path fixed (/usr/share/doc/midori -> /usr/share/doc/midori-0.1.6) * Some minor changes
Created attachment 189567 [details] ebuild for midori-0.1.6 + depend on dev-python/docutils for building user help
Created attachment 189580 [details, diff] reverse trash menu order This patch reverses trash menu order to proper: the latest closed tab is on top.
Created attachment 189581 [details] ebuild for midori-0.1.6 Ebuild with trash order patch
Created attachment 189583 [details] git ebuild for midori Live git ebuild, like previous
Created attachment 189612 [details] git ebuild for midori cosmetic fix
Created attachment 189939 [details] ebuild for midori-0.1.6 * fix path for user-doc ( /usr/share/doc/${P} -> /usr/share/doc/${PF} )
Created attachment 189940 [details] git ebuild for midori
Created attachment 191794 [details] ebuild for midori-0.1.6 *Now version and git ebuilds have the same structure. *PATCHES variable with list of patches. !Take care about version-specific patches. They'll not be applied after ebuild renaming, but...
Created attachment 191796 [details] git ebuild for midori just renamed git ebuild (and without patches instead of release ebuild)
0.1.7 version bump and some minor fixes
Created attachment 192960 [details] ebuild for midori-0.1.7
Created attachment 192962 [details, diff] reverse trash menu order
Created attachment 192963 [details] git ebuild for midori
Created attachment 193174 [details] ebuild for midori-0.1.7 *fix KEYWORDS
Created attachment 193177 [details] fit ebuild for midori
The DEPEND-string looks completely wrong... libsoup, webkit-gtk, libxml2, gtk+, idn, gettext, sqlite and libunique are definitly also RDEPENDs :) (I doubt, that the midori-build links them staticly :P)
(In reply to comment #20) > The DEPEND-string looks completely wrong... > > libsoup, webkit-gtk, libxml2, gtk+, idn, gettext, sqlite and libunique are > definitly also RDEPENDs :) (I doubt, that the midori-build links them staticly > :P) > Of course :) . But configure script checks if they're installed and fails if not...
Then add them to both ;). The problem with them only being in DEPEND is, that an "emerge --depclean --with-bdeps=n" will remove them ;)
Created attachment 194758 [details] git ebuild for midori Is this right?
Created attachment 194759 [details] ebuild for midori-0.1.7
*** Bug 276257 has been marked as a duplicate of this bug. ***
I tested the midori-0.1.7-r1 ebuild, and it works fine, however, there are two things I must note: 1. Why is "dev-python/docutils" a mandatory dependency? For that matter, why is the config option "userdocs" forced to being selected? I need no docs, and by editing the ebuild I could save myself from installing an additional package for documentation I don't want. 2. Should there be a way to strip MAKE_OPTS from unsupported flags? At first I got an error because "./waf build" does not understand the -s switch (MAKE_OPTS="-j3 -s").
I know, I'm impatient... but is there anything we can help test to get this moving? and/or is this in any of the o.g.o overlays? it seems we have a working (albeit maybe not optimal) ebuild... if not I'll go mess around in my own overlay but that's probably not very helpful beyond my few boxes :)
Created attachment 197559 [details] updated midori 0.1.7 ebuild this works for me, and makes optional the docutils dependancy (possibly it should be a seperate userdocs use flag, if you like...)
just uploaded a very slightly modified ebuild - puts the userdocs under the doc use flag, maybe that's poor judgement on my part but seemed sane to me. Also I dropped passing makeopts to waf - that might be contentious I guess, but as it doesn't support or silently drop all make opts and it can cause failures it seems safer to me...
(In reply to comment #26) > I tested the midori-0.1.7-r1 ebuild, and it works fine, however, there are two > things I must note: > > 1. Why is "dev-python/docutils" a mandatory dependency? For that matter, why is > the config option "userdocs" forced to being selected? I need no docs, and by > editing the ebuild I could save myself from installing an additional package > for documentation I don't want. There's policy to install readme and 'f1'-help files by default. Use-flag 'doc' is for api documentation and other developer docs. There are no standard flags to ommit installing of readme and others... (i.e. all xfce helps are installed by default). About docutils: maybe we need separate use-flag, but i mean that geeks may make theirs own gentoo without docutils and userdocs, and with blackjack and hookers :) > 2. Should there be a way to strip MAKE_OPTS from unsupported flags? At first I > got an error because "./waf build" does not understand the -s switch > (MAKE_OPTS="-j3 -s"). It's simplier to drop it. Makeops are not necessary for this package.
(In reply to comment #27) > I know, I'm impatient... but is there anything we can help test to get this > moving? and/or is this in any of the o.g.o overlays? it seems we have a > working (albeit maybe not optimal) ebuild... maybe... > if not I'll go mess around in my own overlay but that's probably not very > helpful beyond my few boxes :) u can share portage tree with local overlay on network with nfs :)
(In reply to comment #28) u must not change version number if there is no code/patches has been updated. userdocs must not be under 'doc' flag. i will upload ebuild with dropped makeopts soon.
(In reply to comment #32) > u must not change version number if there is no code/patches has been updated. > userdocs must not be under 'doc' flag. i will upload ebuild with dropped > makeopts soon. > Sure I kinda expected the 'doc' flag to not be ideal, but I think it needs to be optional via USE flag as many don't like pulling in arguably superfluous packages. Glad you agree re: dropping the makeopts.
(In reply to comment #33) > (In reply to comment #32) > > userdocs must not be under 'doc' flag. i will upload ebuild with dropped > Sure I kinda expected the 'doc' flag to not be ideal, but I think it needs to > be optional via USE flag as many don't like pulling in arguably superfluous > packages. > ls -lh /usr/share/doc/midori-9999/user/ > total 16K > -rw-r--r-- 1 root root 14K 2009-07-12 19:21 midori.html > emerge -s docutils > ... > * dev-python/docutils > Latest version available: 0.5 > Latest version installed: 0.5 > ... > Size of files: 1,246 kB > ... Userdocs is one 13kB html file. Weight docutils'sources is about one MB. Where is a trouble? Why so many clamor about them? Helps and mans are very usable for beginners and must be installed by default. Nevertheless there are some possible solutions: You can sharpen ebuild so as to install really *all* docs with 'dodoc' command and use RESTRICT="doc" (docutils will be installed). Or we can decide to hide userdocs under use flag (under which??? maybe maintainers know?) Or we can ask upstream to include generated in release tarballs (ask kalikana if you want :) ). Together with the first it will allow not to install docutils and docs.
Created attachment 198121 [details] ebuild for midori-0.1.7 * dropped makeopts
Created attachment 198123 [details] git ebuild for midori
(In reply to comment #28) > Created an attachment (id=197559) [edit] > updated midori 0.1.7 ebuild Please obsolete your attachment.
(In reply to comment #34) > > ls -lh /usr/share/doc/midori-9999/user/ > > total 16K > > -rw-r--r-- 1 root root 14K 2009-07-12 19:21 midori.html > > > emerge -s docutils > > ... > > * dev-python/docutils > > Latest version available: 0.5 > > Latest version installed: 0.5 > > ... > > Size of files: 1,246 kB > > ... > > Userdocs is one 13kB html file. Weight docutils'sources is about one MB. Where > is a trouble? Why so many clamor about them? Helps and mans are very usable for > beginners and must be installed by default. Hmm... > emerge -s midori * www-client/midori Latest version available: 0.1.7-r1 Latest version installed: 0.1.7-r1 Size of files: 452 kB Do I really have to install something that weighs twice the browser for some documentation I don't want? ;P It seems a viable solution is to use a local use flag that is enabled by default ("userdoc"?). I do not contend that user documentation must be installed by default, but not giving users the choice to skip it in the ebuild goes against my favourite feature of ebuilds, the ability to choose what components get built in...
(In reply to comment #38) > (In reply to comment #34) > Do I really have to install something that weighs twice the browser for some > documentation I don't want? ;P You have not. You always can do something with it youself :) > It seems a viable solution is to use a local use flag that is enabled by > default ("userdoc"?). I do not contend that user documentation must be > installed by default, but not giving users the choice to skip it in the ebuild > goes against my favourite feature of ebuilds, the ability to choose what > components get built in... Okey. I decide to do so. It will be 'html' use-flag (what will think lamers^Wbeginners about this flag for browser?.. :-)) )
Created attachment 198419 [details] git ebuild for midori + 'html' use-flag for user html documentation.
Created attachment 198420 [details] ebuild for midori-0.1.7
Created attachment 198422 [details] ebuild for midori-0.1.7 trivial fix
Created attachment 198423 [details] git ebuild for midori
Created attachment 198686 [details] ebuild for midori-0.1.8 New minor release. - Old 'reverse trash menu order' patch doesn't work.
I'm sorry to say that modifying the inherit & KEYWORD lines in this fashion would trash the metadata cache. As such, it can not be allowed in the portage tree. This also makes it hard for me to cherry-pick your improvements. As such, I will consider this a version bump request and resolve the bug as fixed. When you have specific ebuild improvements to suggest, please do so in a new bug. +*midori-0.1.8 (27 Jul 2009) + + 27 Jul 2009; <chainsaw@gentoo.org> +midori-0.1.8.ebuild, metadata.xml: + Version bump, as requested by Jan Aniŝĉuk in bug #266402. Taking + maintainership together with the XFCE herd, approved by Jokey on IRC.
(In reply to comment #45) > I'm sorry to say that modifying the inherit & KEYWORD lines in this fashion > would trash the metadata cache. As such, it can not be allowed in the portage > tree. This also makes it hard for me to cherry-pick your improvements. > As such, I will consider this a version bump request and resolve the bug as > fixed. When you have specific ebuild improvements to suggest, please do so in a > new bug. Hmm... And what about, for example, sys-kernel/genkernel ebuilds? They have the same stucture with inherit.
I think it might actually be fine, due to $PV probably being available while generating the metadata (it's gotten from the filename of the ebuild). http://devmanual.gentoo.org/ebuild-writing/using-eclasses/index.html#the-inherit-function and http://devmanual.gentoo.org/general-concepts/portage-cache/index.html confirm that it's fine.
Anyways, lets take this to a new bug then please for clean improvements as requested by Tony. Please CC me as well there
(In reply to comment #48) > Anyways, lets take this to a new bug then please for clean improvements as > requested by Tony. Please CC me as well there > moved to bug #279768
