[gentoo-dev] am I ready to step into Gentoo?
hi all, it's since about 6 years I am using (loving) Gentoo! I wish I could be a developer, but I have no idea where do I fit well, and which are the g.o needs. looking at the bugtracker you can find random enhancements submitted by myself [1], recently: #220162 (source navigator NG3), #219519 (blambot-fonts), #219324 (dev-tcltk/gnocl), #190225 (sys-process/daemon), #185788 (keyfuzz)... also #173347 a proposal of making a setpci init script [2] my computer-related hobbies (or I should say time-killers!) are Tcl (scripting language) and Pure-Data (multimedia dataflow environment). I regularly use Pd to create audio/video apps, and Tcl for everything else that doesn't fit Pd, I've also developed a Tcl-Pd loader, that allows to code externals for Pd in Tcl. see my Pd page at [3]. perhaps that's the category I should belong to...(?) I keep occasional contact with Tcl developers, so I could bring some love to the Tcl/Tk Gentoo herd (yes, I am a Tcl/Tk fan, as you can see on my wikipage at [4]) I've also set up an overlay (pd-overlay, [5]) and used to develop together with ColdWind (actually a Gentoo dev) ebuilds for EVERY pd external! today I just bought a dark Gentoo t-shirt from CafePress to support Gentoo foundation, and to spread the Gentoo word here and there ;) about my life: I work part-time in a big telecommunications company as a system engineer / sysadmin, my specific task at the moment is to develop/package linux platforms for Data Warehouse systems (running on Oracle :S) and Business Intelligence platforms. I'll get a Computer Science Engineering degree soon... if I have to devote some time to Gentoo, surely I'll do it during the work hours, since Linux is the 99.99% of my work! so what's going to be my next step into Gentoo? perhaps finding a mentor? ColdWind would you...? any one else? [1] http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailreporter1=1&emailtype1=substring&email1=xaero%40inwind.it&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= [2] http://bugs.gentoo.org/show_bug.cgi?id=173347 [3] http://puredata.info/Members/federico [4] http://wiki.tcl.tk/FF [5] http://pd-overlay.sourceforge.net/ best regards, Federico Ferri -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
Joe Peterson ha scritto: It was mentioned that "comments are to be ignored", but you point out a perfect and very fundamental example of where this is not true: #!/usr/bin/env bash Putting another line close to this one with: #EAPI=42 or #!EAPI=42 if you like (conforms more to the shell script specifier), is not too muchh of a stretch. The so-called shebang; very good in my opinion! Works very well for true shell scripts. why it can't work for ebuilds? First, I think of two alternatives: 1) the interpreter is the EAPI (with /usr/bin/ebuild being EAPI=0) this will be the first line of a EAPI=0 ebuild: #!/usr/bin/ebuild this will be a EAPI=paludis ebuild: #!/usr/bin/ebuild-paludis apparently it's the same mechanism the shell uses to execute a shell script, except for the fact that: * ebuild is not an executable file * an external program is used to determine the EAPI (i.e.: extract the shebang) 2) fixed interpreter name, use arguments for switching EAPIs this is another option, wich carries itself a GREAT power of leaving an open door when in the future will happen something similar to what we have now, where switching the EAPI (or replace EAPI with something else) is critical and breaks compatibility. example - EAPI=0: #!/usr/bin/ebuild ... another eapi: #!/usr/bin/ebuild -eapi paludis This allows virtually unlimited cases similar to this; for example when switching to , another switch will be used: #!/usr/bin/ebuild -eapi foo -fluffy bar Advantages of both solutions: * easy to parse * doesn't break compatibility What it does not address: * doesn't break compatibility In fact, it should break compatibility. again I can think of two solutions: 1) change the ebuild extension to a different value, once and (hopefully) forever, e.g. from .ebuild to .xbuild, and leave the minimal set of .ebuild-s for the upgrade path 2) use two repositories: the legacy one, needed for the upgrade path, and the shyny-new-repository with the new ebuilds format best regards, Federico Ferri -- #include main(){printf("%x",4275974592);} -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d-(--) a- C++$ UL+++$ L+++$ E--- W++@ w--@ PE PGP+ R- tv-- DI++>+++ D++ h+ --END GEEK CODE BLOCK-- signature.asc Description: OpenPGP digital signature
[gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, today I hit this annoyance, because my laptop hung in the middle of an 'emerge -e @world' (checking that my world set compiles with gcc-4.3... stopped at ~ 300 of 700 :S ) I was looking for an entry in /var/db/pkg// that could have told me the compiler used to build the package, but couldn't find any. indeed it would be a fairly useful feature to have, both for testing purposes, and for user's everyday maintenance. please criticize this with anything constructive you can think of. thanks - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk9v14ACgkQV/B5axfzrPucugCfRN51KpJZ/HYCYA3v/Z2lAhaf 8eUAniZONnbWtN4f5CblJzaxEMbFWI3m =4l7H -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Petteri Räty wrote: > Federico Ferri wrote: >> Hello, >> today I hit this annoyance, because my laptop hung in the middle of an >> 'emerge -e @world' (checking that my world set compiles with >> gcc-4.3... stopped at ~ 300 of 700 :S ) >> > > Consider using emerge --keep-going next time. > >> I was looking for an entry in /var/db/pkg// that could have >> told me the compiler used to build the package, but couldn't find any. >> indeed it would be a fairly useful feature to have, both for testing >> purposes, and for user's everyday maintenance. >> > > But the idea isn't that bad imfo. Maybe save the output of emerge --info > in general and it could be easily made available for bug filing. If it > was a while since you emerged the package your emerge --info could now > be different from the merge time and now for example reflect your use flags. nice point! I didn't see the whole potential of my proposal :-D - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk+11kACgkQV/B5axfzrPvq4QCgvs5zVMieQADGfdq8DcJZSNzK +3QAoKmH/TzzJ/9ZmqgWrXK5C9jINsI3 =/qv2 -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gordon Malm wrote: > Should be able to find which gcc was used by checking LDPATH in the > environment.bz2. I believe it is about the only gcc version > information recorded in /var/db/pkg/// though. > $ find /var/db/pkg -name environment.bz2 | wc - -l 747 $ find /var/db/pkg -name environment.bz2 -exec bzgrep -q LDPATH '{}' ';' -print | wc -l 11 sorry, that appears to be of little help - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk+7uUACgkQV/B5axfzrPsaJwCdFVpGO3fYAMcyhRTN2QdRuZkH 2CsAniO7oZCxZSC6lt/j/+PRmrgyCyuI =5mFz -END PGP SIGNATURE-
Re: [gentoo-dev] Proposal: add a compiler-version entry to pkg db
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: > On 01:44 Tue 09 Dec , Federico Ferri wrote: >> today I hit this annoyance, because my laptop hung in the middle >> of an 'emerge -e @world' (checking that my world set compiles >> with gcc-4.3... stopped at ~ 300 of 700 :S ) >> >> I was looking for an entry in /var/db/pkg// that could >> have told me the compiler used to build the package, but couldn't >> find any. indeed it would be a fairly useful feature to have, >> both for testing purposes, and for user's everyday maintenance. >> >> please criticize this with anything constructive you can think >> of. > > As I mentioned on IRC, I think this isn't a very general use case > (given the existence of --resume, --keep-going, etc.) so code to > accomplish it the point was not resuming my emerge because the laptop hung. was more like: tracking which compiler built which package or vice-versa > would be better put into a custom portage bashrc than into portage > proper. yes, that makes sense. it could be an external tool, like revdep-rebuild is, which queries compiler by pkg, and eventually rebuilds packages (not) matching a certain compiler. but to accomplish this, an information about the compiler (in the pkg record) should be there. something like /var/db/pkg///COMPILER - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk+8qQACgkQV/B5axfzrPs9BwCbBmbU3HVY0i6bqljlx3yZqICk nT8AoJpgTbcNc/UOirCrPRw3zTOlxI5G =uWSJ -END PGP SIGNATURE-
Re: [gentoo-dev] Handling Launchpad SRC_URI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Josh Saddler wrote: > Right now, there's no canonical (heh) way of handling SRC_URI for > projects that have their files at launchpad.net. We need a standard way > of handling Launchpad SRC_URIs, similar to what we do with > mirror://sourceforge/ SRC_URIs. > > 1. Some packages use the launchpadlibrarian.net download redirect, which > results in a non-helpful server-generated number: > > (gnome-catalog) > SRC_URI="http://launchpadlibrarian.net/11326737/${PN}_${PV}.orig.tar.gz > > 2. Some hack up interesting MY_P stuff: > > (gnome-do-plugins) > MY_PN="do-plugins" > PVC=$(get_version_component_range 1-2) > PVC2=$(get_version_component_range 1-3) > SRC_URI="https://launchpad.net/${MY_PN}/${PVC}/${PVC2}/+download/${P}.tar.gz"; > > (avant-window-navigator-extras) > MY_P="awn-extras-applets-${PV}" > SRC_URI="https://launchpad.net/awn-extras/${PV%.*}/${PV}/+download/${MY_P}.tar.gz"; > > The AWN-extras ebuild is the closest to the "right" way of doing it, I > think. > > So can we agree on a standard way of treating Launchpad SRC_URIs and get > the handler support into Portage? > 3. (seq24-0.9.0) SRC_URI="http://edge.launchpad.net/seq24/trunk/${PV}/+download/${P}.tar.bz2"; just another example of different SRC_URI - -- FF -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl8s0oACgkQV/B5axfzrPssBACffhjl4xMsQSGL8Ez6ngdlkH43 56MAoI9YIesKOrNMg5lYuJyR5xpKUVXP =wLnZ -END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nirbheek Chauhan wrote: > ${PORTDIR}/tags/games/puzzles/ksudoku -> ../../../kde-base/ksudoku > ${PORTDIR}/tags/games/puzzles/sudoku/ksudoku -> ../../../../kde-base/ksudoku > ${PORTDIR}/tags/dying/amarok -> ../media-sound/amarok - -- I like the tag idea. I don't like tag as described above. I feel having tags organized in hierarchical way is inappropriate. that just makes another organization of packages in categories. tags <-> packages is a many-to-many relation. btw, if the DESCRIPTION field is well written, it functions as a tag. e.g.: $ eix -c -S dockapp -S net [N] x11-plugins/allin1 (--): All in one monitoring dockapp: RAM, CPU, Net, Power, df, seti [N] x11-plugins/wmifinfo (0.09): a dockapp for monitoring network interfaces. [N] x11-plugins/wminet (3.0.0): dockapp for monitoring internet connections to and from your computer. [N] x11-plugins/wmitime (0.3): Overglorified clock dockapp w/time, date, and internet time [N] x11-plugins/wmnd (0.4.11-r1): WindowMaker Network Devices (dockapp) [N] x11-plugins/wmnetload (1.3-r2): Network interface monitor dockapp [N] x11-plugins/wmwifi (0.6): wireless network interface monitor dockapp Found 7 matches. although DESCRIPTION doesn't contain "obvious" tags. perhaps it's worth the addition of a TAGS field (?) that has to be searched just like DESCRIPTION just my 2E-2 Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmPHZIACgkQV/B5axfzrPu9ewCgr2XRqbTy9XycR5g0KeFWtOnV ou8An2WKDEeIsPioWHn/lVEtPrHF4QNg =GvLh -END PGP SIGNATURE-
Re: [gentoo-dev] Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nirbheek Chauhan wrote: >> I like the tag idea. I don't like tag as described above. I feel >> having tags organized in hierarchical way is inappropriate. that >> just makes another organization of packages in categories. > > KDE and OLPC are looking towards hierarchical tags as the future of > content management. People don't really use folders, they use > tags: > > "Holidays" > "2008" > "Switzerland" "Open Source" > "Gentoo" > > "portage" > the above looks exactly like folders (unless you elaborate on that) I don't know what KDE or OLPC are thinking. when I tag my stuff I'd probably have: photo001.jpg {2008,holidays,nature,switzerland} photo002.jpg {2008,holidays,fun,switzerland,zurich} photo158.jpg {2009,computer,me,misc} (the order of tags here is alphabetical) > tags <-> packages is a many-to-many relation. >> >> Aren't tags _made_ to be many-to-many? > > ie, symlinking can allow that kind of relationship can you show an example (of many-2-many relation, with symlinks)? Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmPJHsACgkQV/B5axfzrPtbpACfcq8qpQdkneWplS8H3XgEiry1 1qUAoKZcMUGDyro8nHwrSvNwflm0nyGn =PV0+ -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Category tags on packages (was: new categories:)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ryan Hill wrote: > > I've always thought it would be cool to have user-created tag > clouds, del.icio.us-style, on packages.g.o. I expect this would be > a hell of a lot of work to set up however. initially, packages could be automatically tagges, based on the following criteria: - - category - - common* words found in $DESCRIPTION - - common* words found in metadata.xml: if any - - extend the above with description found on the net plus: - - a hidden tag to indicate that tags were assigned automatically, to be removed whenever the pkg tags are "reviewed" by a human += 2E-2 Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmPXfEACgkQV/B5axfzrPu46wCdFaTMWf4LSGCRHJJFB0xh0Vio yYwAn0siZ5oIaec3H2PfDEc6q/t02b6D =1Pjf -END PGP SIGNATURE-
[gentoo-dev] Tcl/Tk multi-slot testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've done some work on providing multi-slot Tcl and Tk packages. you can find it on my overlay [1] this work consists basiaclly of: 1) modifying tcl/tk ebuilds for install stuff with - --prefix=/usr/tcl/${SLOT} and merging all the ebuilds code into the tcltk eclass 2) provide a tcltk eselect module for switching the active tcltk version pro: this would allow less painful unmasking and stabilizing of tcl/tk packages, so users can have a tcl runtime of the 21st century =)) tcltk apps that are less "vital" (i.e. have not "ported" to newer runtimes) could still live on a system using the tcltk switcher potential issues: this could become troublesome if there is a tcl extension installed, and is needed both for tcl 8.5 and tcl 8.6. it should be reinstalled after each 'eselect tcltk set ...' btw, on a different topic: the number of bugs on tcltk (8.5) has lowered a bit. maybe it's time to unmask it and have package maintainers fix the outdated apps? [1] http://overlays.gentoo.org/dev/mescalinum * uninstall previous versions of tcl/tk if you are testing this, as slotmoves are not possible for overlays -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm6oUgACgkQV/B5axfzrPvBWACffga+Jv3492sFXpojSChujoR4 /j8An1SNh/Ruwt3JMG7JWHfwCKj/2mJc =5Q1Q -END PGP SIGNATURE-
Re: [gentoo-dev] Tcl/Tk multi-slot testing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Peter Volkov wrote: > В Птн, 13/03/2009 в 19:09 +0100, Federico Ferri пишет: >> btw, on a different topic: the number of bugs on tcltk (8.5) has >> lowered a bit. maybe it's time to unmask it and have package >> maintainers fix the outdated apps? > > A number of packages depend on itcl which does not builds with 8.5. > unfortunately itcl didn't seen a release since long time ago (but development happens in CVS) few weeks ago, Itcl/Itk 4.0_beta3 were released (requires Tcl 8.6, which is in beta1) you can find those fresh pkgs in my tcl-8.6 overlay (layman -a tcl-8.6) > It is maintained by tcl/tk herd. What's your stance on this > package? Same question about otcl, but less packages (the only > net-analyzer/nam?) depend on it. I'm sorry, I tried but didn't succeed to fix otcl :-( I could report the issue upstream, and let things flow - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm9bNUACgkQV/B5axfzrPu1EACbB52ul7RKLFFkfzNT3yQuBVAT /CcAnR7oNqakXvgeham2afm3U8WV/5If =shj/ -END PGP SIGNATURE-
Re: [gentoo-dev] Xorg 1.5.3 is going stable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rémi Cardona wrote: > Hi all, > > This is just a quick announcement to let everyone know that Xorg > 1.5.3 and pretty much all X libraries and apps which have been > sitting in ~arch for months/years are finally going to go stable, > replacing our old, rusty and busted 1.3 X server. > > Arch Teams have received the final package list just this afternoon. > > The Upgrade Guide is located at > http://www.gentoo.org/proj/en/desktop/x/x11/xorg-server-1.5-upgrade-guide.xml > > perhaps you made a typo did you meant INPUT_DEVICES="evdev" instead of INPUT_DRIVER="evdev", isn't it? bye - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknRLIIACgkQV/B5axfzrPvrgwCeJkfiypY9cO/i/LTTDh0Bjxjj cqcAn0DWEUIK9ftCstJFDZMr3NlA/NKH =6qxR -END PGP SIGNATURE-
Re: [gentoo-dev] net-www category
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: > Is the following description for the category metadata O.K.? > More translations are welcome. > > en: The www-plugins category contains plugins for Web browsers. > de: Die Kategorie www-plugins enthält Plugins für Webbrowser. > it: La categoria www-plugins contiene plugins per i browser web. - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknfcXoACgkQV/B5axfzrPvXgACgorfAM7KkdwN4rG9Y5TG7S9qR ZOwAnRx8Q5WrfxPvEOoFRIt0crkQCGvu =UzKf -END PGP SIGNATURE-
[gentoo-dev] =dev-lang/{tcl,tk}-8.5* unmask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It's been long time since tcl-8.5 is sitting in tree p.masked. a number of bugs have been fixed in the past (last bugs I've fixed this evening: itcl-3.3, tix, tclpython; one I can't fix is otcl - moreover, it's damn obsolete (last commit 2 years ago)) the remaining bugs in the tracker [1] are mostly applications (not tcltk's herd) with (mostly) no rdeps. I think it's now safe for {tcl,tk}-8.5 to enter the testing branch. I'll end my job in Anritsu on 30th April, so I'll have more time for Gentoo project =) ...and for supporting this task. if there are no objections, I'll unmask tcl/tk 8.5* (I've just bumped the package to 8.5.7) by the next week. [1] http://bugs.gentoo.org/show_bug.cgi?id=173467 - [Tracker] dev-lang/{tcl,tk}-8.5 incompatible packages Best regards, Federico Ferri (mescalinum) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkno74AACgkQV/B5axfzrPt7agCfal4MSsx0sgT62Nbx4U98BAU7 RAAAoLxnkB/riD8DKyeafSn5uZeUjTD8 =oakn -END PGP SIGNATURE-
[gentoo-dev] Last rites: net-analyzer/ns and net-analyzer/nam
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 # Federico Ferri (26 May 2008) # Deprecated cause depending on unmaintained dev-tcltk/otcl. # Everything being moved to 'abandonware' overlay. # Possible replacement: net-misc/gns3 (sunrise overlay) # Going for removal in ~30 days if no one objects. # removal bug #271305 net-analyzer/ns net-analyzer/nam # Federico Ferri (26 May 2008) # Unmaintained upstream. # Going for removal in ~30 days. # removal bug #271307 dev-tcltk/otcl dev-tcltk/tclcl -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkob8bEACgkQV/B5axfzrPvnFQCeId9Sg1yOsOPzqJjfAJZpWPBO hTkAnj8d5lpl/TvXMSF3KjxVXNyswKvA =tlPp -END PGP SIGNATURE-
Re: [gentoo-dev] New app-eselect category?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Philipp Riegger wrote: > Hello world! > > On Tue, 2009-05-26 at 16:24 +0200, Tiziano Müller wrote: >> Am Dienstag, den 26.05.2009, 09:04 +0200 schrieb Ulrich Mueller: >>> As of today, app-admin contains 179 packages. We could move the >>> 27 eselect-* packages to a new app-eselect category (eselect >>> itself would stay in app-admin). >>> >>> Opinions? >> Yes in general. Maybe think about what happens when the Universal >> Select Tool gets released/used. Possible alternative: app-select? >> > > How will that tool be called? Maybe uselect? > > Another alternative: app-xselect. > seems like here two-level categories are a limitation. if three-level categories were available, I'd say app-admin-xselect. since the last two levels make more sense, compared to the 1+3, if you believe the app-admin category is too crowded, why not just make a new category admin-XYZ, thus adding the missing third level? - -- Federico Ferri (mescalinum) > Philipp > > > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocAeQACgkQV/B5axfzrPv12gCeO8tVVCvJcqb0OK4qsFBxELe3 VuoAoKub0H7s1u0yvPR9n4DSNeKmN+rE =dovF -END PGP SIGNATURE-
Re: [gentoo-dev] New app-eselect category?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 AllenJB wrote: > Fabian Groffen wrote: >> On 26-05-2009 09:04:46 +0200, Ulrich Mueller wrote: >>> As of today, app-admin contains 179 packages. We could move the >>> 27 eselect-* packages to a new app-eselect category (eselect >>> itself would stay in app-admin). >>> >>> Opinions? >> >> I hate package moves, so is it really *really* necessary? >> >> > I have to agree. app-admin is hardly among the largest categories. > Perhaps we should consider splitting up the 400 odd packages in > kde-base (kde-graphics, kde-admin, kde-games, etc) =P > > As for app-admin-eselect, I'd favor tags over increasing the > category levels, tho I'm not the three-levels-category was an example. the realistic approach I proposed is splitting app-admin in many two-level categories: + admin-eselect + admin-sysconf + admin-www + admin-apache ... as it usually has been done in such cases. - -- Federico Ferri (mescalinum) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkocHNoACgkQV/B5axfzrPsCzgCeJZknEWRV1o2SjPpPc9HJ0k1u bUoAnRygFK/mRPfAguutyUmZWssnPyXh =hZFu -END PGP SIGNATURE-
Re: [gentoo-dev] Re: GLEP 55 Version 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ulrich Mueller wrote: >> On Sun, 07 Jun 2009, Steven J Long wrote: > >> I'd just like to know what the implications would be for users if we >> kept the .ebuild extension, and a new PMS were rolled out stating >> that the mangler were allowed to find the EAPI without sourcing (and >> giving the restrictions) once portage 2.2 was stable, or the ability >> to handle this backported to 2.1.6, and issued in a release? > > Even if we do only a one-time change of the file extension, can we > ever get rid of the old extension? unfortunately, no. > Or are we then stuck with two > extensions in the tree until the end of time? > Let's assume for the moment that we change from ".ebuild" to ".eb". better put this new ebuild type in a new tree; such a massive change to the tree its not recommended. > Then we obviously cannot change all ebuilds in the tree to ".eb", > otherwise old Portage versions would see an empty tree and there would > be no upgrade path. leaving actual ".ebuild"s as they are now (good healthy state :)) and making new development of ".eb" ebuilds happen in a new tree (I said new tree, but it could be any way that hides those new ebuild to OLD package managers) would help. only newer versions of package managers are required to support this, that is they will look for .eb (in new or current tree, not sure what's best) and then for .ebuilds, and ideally this should be transparent to old package managers and allow an upgrade path. - -- mescali...@g.o -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkortVIACgkQV/B5axfzrPsTiACeJCJb3F8Up/+CjHIwC3Slhn/6 yZgAoLcJgNn2d3W/JeZPkK85arUPW9vV =fR4T -END PGP SIGNATURE-
Re: [gentoo-dev] Policy regarding enabling IUSE defaults application in ebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Maciej Mrozowski wrote: > Hi > > I'd like to raise your attention on problem of in my opinion overusing IUSE > defaults in various packages. > Currently there seems to be no policy whatsoever at least advising when it's > appropriate to add + and when not, so it's just up to developer's > taste. > While it usually doesn't do any particular harm (but I guess security and > prefix/alt team won't agree on this) - insanely enabling everything by default > is not the best idea in my opinion. > Of course we need an example. Let's have a look at latest stable media- > video/mplayer-1.0_rc2_p20090322 ebuild: > > IUSE="3dnow 3dnowext +a52 +aac aalib +alsa altivec +amrnb +amrwb arts +ass > bidi bindist bl +cddb +cdio cdparanoia -cpudetection -custom-cflags > -custom-cpuopts debug dga +dirac directfb doc +dts +dv dvb +dvd +dvdnav dxr3 > +enca +encode esd +faac +faad fbcon ftp gif ggi -gtk +iconv ipv6 jack > joystick jpeg kernel_linux ladspa libcaca lirc +live lzo mad md5sum +mmx > mmxext mng +mp2 +mp3 musepack nas +nemesi +network openal +opengl oss png pnm > pulseaudio pvr +quicktime radio +rar +real +rtc -samba > +schroedinger sdl +speex sse sse2 ssse3 svga teletext tga +theora +tremor > +truetype +unicode v4l v4l2 vdpau vidix +vorbis -win32codecs +X +x264 xanim > xinerama +xscreensaver +xv +xvid xvmc zoran" moreover, there are certain USE flags that do not make sense in IUSE="+". for example alsa: if I use alsa, I want alsa globally enable in /etc/make.conf if I not use it (e.g. not in my profile) why should I explicitly put - -alsa in $USE? this may lead to an explosion of - flags in $USE. probably this example falls back into the "flag which pulls dependencies" case, but it is one more argument. configure scripts already have default values for the configure switches, and ebuilds should try to follow the defaults by putting + where needed, but with some exceptions (maybe on a flag-by-flag basis, or -more generally- by use-case, like you just wrote) - -- mescali...@g.o -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoz2rMACgkQV/B5axfzrPs1dACeKIfPZ6XMRlD4Nf6L5s9WyCw5 uukAoKVmF2OMSykUhKwQ7aR5vR4j/+Nz =LuUh -END PGP SIGNATURE-
Re: [gentoo-dev] 2.6.22 stable plans
William L. Thomson Jr. ha scritto: This is for the very short term. I don't want to maintain a driver for hardware I don't own and never intend on purchasing. Well seems most AMD machines are likely to ship with ATI chipsets these days. For sure most lappies :) Interesting side note. Beryl/Xgl works on my laptop, ATI Xpress200m. cool... would you like to write a pair of lines describing the process, software (ebuilds) versions used, tips and quirks? cause I tried many time but always failes someway, so that I started to think ati-drivers for X200M are bork :S -- 0xff -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] RFC: new gnustep eclasses
Bernard Cafarelli ha scritto: Hello all, hi that's a cool project you are working on! I wish I could contribute actively in the future Feedback, comments, suggestions, other ideas are welcome! right now I found a problem (I wonder if it happens on others too) about gnustep-back-art-0.12.0. unfortunately I don't figure how to fix it, so I opened a bug at http://bugs.gentoo.org/show_bug.cgi?id=188044 I wish someone could help. I'll ask to gnustep guys as soon as possible too -- #include main(){printf("%x",4275974592);} -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI) [2]
Ciaran McCreesh ha scritto: > On Thu, 27 Dec 2007 18:03:27 + > Roy Marples <[EMAIL PROTECTED]> wrote: > >> Using your analogy you should then recognise that there is a strong >> dislike for pink and should seek a new colour that allows the building >> of said extensions. >> > > And what colour would that be? We've already ruled out purple, brown > and yellow, and no-one has yet found any other colour of paint. > sorry if this has already suggested. my idea is to use shebang; the advantage in using shebang is that file doesn't need to be sourced or parsed by complex algorithms in order to extract the necessary information. an example: #!/usr/bin/ebuild eapi=1 # Copyright 1999-2007 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # $Header: $ DESCRIPTION="My EAPI-1 ebuild" HOMEPAGE="http://www.gentoo.org/"; SRC_URI="" LICENSE="GPL-2" ... shebang's synopsis would look something like: #! [key=value] [key=value] [...] pros: 1) it's standard. shell scripts use it. why ebuilds shouldn't? 2) it's easy to parse: eval `head -n1 $ebuild | cut -d\ -f2-`; echo $eapi 3) in the future, for any other situation analogous to this, you could add another key=value to the ebuild's shebang 4) easily checked by repoman cons: ? just my two Eurocents. since now you can bite me ;-) -- #include main(){printf("%x",4275974592);} -- [EMAIL PROTECTED] mailing list
[gentoo-dev] portage and conflict resolutions!? (really is about =cat/pkg-${VER}* dependencies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 {{sorry if you receive this message twice. I've got smtp problems and I had to switch smtp, so please reply to THIS message only}} there are pieces of software that consist of multiple packages (either by upstream decision, or by a Gentoo dev that splits a package) and have the additional restriction that every component must have the exact same version (or in some case the exact major version). examples are Qt, and SynCE (I'll take the latter as example, as it is my area of competence). SynCE requires the same major version of other synce packages to work. so, inside synce ebuilds I do this: synce_PV=$(get_version_component_range 1-2) DEPEND=" ... =app-pda/synce-libsynce-${synce_PV}* ... " I introduced this in synce 0.13 series, without thinking to what would be happened (today) when a user (me) would have tried to upgrade from synce 0.13 to synce 0.14 (in my overlay now) portage can't resolve the conflict by itself, because, as it tries to touch one of dependencies (upgrading 0.13 => 0.14), the currently installed synce meta ebuild 0.13 [which depends on =0.13* deps too] won't allow that (that is: block everything that is not 0.13*) as a consequence, the multiple-packages-per-slot error is shown when upgrading packages [1]. after exchanging a few words with some devs on IRC, I understand no solution actually exists for this. :-( but still, that ebuild snippet is a formally legal directive (?) what I want to state is that the user has to have installed all synce of the same major version (0.13.*) to properly work I can see also why portage is failing: when (trying to) upgrading the first package, the whole package set enters into a *transient* state, which is not valid for normal usage (that is: one 0.14 lib, and all other 0.13 libs), but still has to be valid in order for portage being able to upgrade correctly all the packages, because when portage will end [successfully!], the system will be again in a valid state. what I am going to propose here is a resolution strategy for this (although this whole thing simply tells me that portage misses some knowledge about the problem, like for example that dependencies should be enforced only at transaction boundaries, or simply that we have a class of dependencies that is irrelevant while system is in transient state) but, without trying to introduce overcomplicated solutions, as an user, I could solve the initial problem very easily: resolution strategy for it is to unmerge the old synce-0.13 packages, then the user will be able to install 0.14 packages. so, if the user can do it, why can't portage handle it? (so that even a not-so-smart user could painlessly get out of this mess) many devs pointed out how Qt works, that is, only depends on >=other-qt-library-${PV}, but that IMHO is an incomplete dep specification (read: a workaround). before I revert my changes to synce packages, are there any will to change portage behavior in the near future to support and fix this? [1]# emerge -auvDN world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] app-pda/synce-libsynce-0.14 [0.13] USE="hal" 364 kB [0=>1] [ebuild U ] app-pda/synce-librapi2-0.14 [0.13.1] 483 kB [0=>1] [ebuild U ] app-pda/synce-librra-0.14 [0.13] 414 kB [0=>1] [ebuild U ] app-pda/synce-sync-engine-0.14 [0.13] 158 kB [0=>1] [ebuild U ] app-pda/synce-hal-0.14 [0.13] 314 kB [0=>1] [ebuild U ] app-pda/synce-kpm-0.14 [0.13] 90 kB [0=>1] [ebuild U ] app-pda/synce-trayicon-0.14 [0.13] USE="-debug" 381 kB [0=>1] [ebuild U ] app-pda/synce-gvfs-0.3 [0.2.1] USE="-debug" 1,950 kB [0=>1] [ebuild U ] app-pda/synce-0.14 [0.13] USE="gnome hal -kde -serial" 0 kB [0=>1] Total: 9 packages (9 upgrades), Size of downloads: 4,151 kB Portage tree and overlays: [0] /usr/portage [1] /usr/local/portage/synce !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: app-pda/synce-librapi2:0 ('ebuild', '/', 'app-pda/synce-librapi2-0.14', 'merge') pulled in by =app-pda/synce-librapi2-0.14* required by ('ebuild', '/', 'app-pda/synce-librra-0.14', 'merge') =app-pda/synce-librapi2-0.14* required by ('ebuild', '/', 'app-pda/synce-hal-0.14', 'merge') =app-pda/synce-librapi2-0.14* required by ('ebuild', '/', 'app-pda/synce-gvfs-0.3', 'merge') (and 1 more) ('installed', '/', 'app-pda/synce-librapi2-0.13.1', 'nomerge') pulled in by =app-pda/synce-librapi2-0.13* required by ('installed', '/', 'app-pda/synce-gnomevfs-0.13', 'nomerge') app-pda/synce-libsynce:0 ('ebuild', '/', 'app-pda/synce-libsynce-0.14', 'merge') pulled in by =app-pda/synce-libsynce-0.14* required by ('ebuild', '/', 'app-pda/synce-gvfs-0.3', 'merge') =app-pda/synce-libsynce-0.14* required by ('ebuild', '/', 'app-pda/synce-hal-0.14', 'merge') =app-pda/synce-libsynce-0.14* required by ('ebuild',
Re: [gentoo-dev] portage and conflict resolutions!? (really is about =cat/pkg-${VER}* dependencies)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Zac Medico wrote: > >> what I am going to propose here is a resolution strategy for this >> (although this whole thing simply tells me that portage misses some >> knowledge about the problem, like for example that dependencies should >> be enforced only at transaction boundaries, or simply that we have a >> class of dependencies that is irrelevant while system is in transient >> state) >> >> but, without trying to introduce overcomplicated solutions, as an >> user, I could solve the initial problem very easily: >> resolution strategy for it is to unmerge the old synce-0.13 packages, >> then the user will be able to install 0.14 packages. > > As said above, the problem is in the synce-gnomevfs-0.13 > dependencies, and there's nothing portage can do to change that. > ok, after discussion on IRC came out that the SynCE 0.14 suite didn't include a synce-gnomevfs-0.14 package (so it has implicitly needed to be uninstalled the old 0.13 version). unfortunately portage doesn't handle this situation automatically. I had to add a !app-pda/synce-gnomevfs dep to synce-0.14. this will be never handled automatically by portage unfortunately, because synce-gnomevfs has no reverse-depend on anything (my fault!), so a user generally puts into the world set. the user will see a blocker when upgrading, but that's little pain. cheers - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp5/sIACgkQV/B5axfzrPsIvgCfUFlEIwfZRsFxsMIKwrCzxwUQ rAcAnAsj9ej5d4n14LqjL7/tvLAwAv7z =hOZH -END PGP SIGNATURE-
[gentoo-dev] work on Tcl-8.5 tracker - call for maintainers, reporters... or treecleaners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tracker URL: https://bugs.gentoo.org/show_bug.cgi?id=173467 work for the tcl-8.5 tracker is reaching its end. there are few bugs still blocking the trackers. for every bug there is a solution (that is, for obsolete software, removal is a solution!) so, please, reporters and maintainers, do your job! I'll proceed with last rites as next action. summary of open bugs: media-tv/nxtvepg-2.7.7 fails with tcl-8.5.1 http://bugs.gentoo.org/show_bug.cgi?id=212682 status: version 2.8.0 works, waiting for maintainer sci-electronics/xcircuit doesn't run with tcl/tk 8.5 http://bugs.gentoo.org/show_bug.cgi?id=213852 status: fixed ebuild has been provided, waiting for maintainer x11-terms/clusterssh-3.22 doesn't work with tk-8.5 http://bugs.gentoo.org/show_bug.cgi?id=246950 status: version 3.26 works, waiting for maintainer dev-db/pgaccess-0.99.0.20040219 failed to start http://bugs.gentoo.org/show_bug.cgi?id=247210 status: unmaintained. remove? wait for maintainer net-dialup/isdn4k-utils-3.11_pre20071003: tcl dependency required? http://bugs.gentoo.org/show_bug.cgi?id=249311 status: invalid? wait for reply from reporter net-irc/quirc-0.9.84 doesn't emerge with tcl/tk 8.5 http://bugs.gentoo.org/show_bug.cgi?id=249468 status: fix provided. waiting for maintainer - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp9i/gACgkQV/B5axfzrPtCBQCgkzfAbalGVgtbUcVmPCT0Zu9A R84AoKFglh+jaR8KOq6ZvM0CB1umeeeN =tgq6 -END PGP SIGNATURE-
DONE! Re: [gentoo-dev] work on Tcl-8.5 tracker - call for maintainers, reporters... or treecleaners
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Status Update > media-tv/nxtvepg-2.7.7 fails with tcl-8.5.1 > http://bugs.gentoo.org/show_bug.cgi?id=212682 status: version 2.8.0 > works, waiting for maintainer > > sci-electronics/xcircuit doesn't run with tcl/tk 8.5 > http://bugs.gentoo.org/show_bug.cgi?id=213852 status: fixed ebuild > has been provided, waiting for maintainer > > x11-terms/clusterssh-3.22 doesn't work with tk-8.5 > http://bugs.gentoo.org/show_bug.cgi?id=246950 status: version 3.26 > works, waiting for maintainer thanks Samuli Suominen for those > > dev-db/pgaccess-0.99.0.20040219 failed to start > http://bugs.gentoo.org/show_bug.cgi?id=247210 status: unmaintained. > remove? wait for maintainer I just fixed this > > net-dialup/isdn4k-utils-3.11_pre20071003: tcl dependency required? > http://bugs.gentoo.org/show_bug.cgi?id=249311 status: invalid? wait > for reply from reporter thanks again Samuli for sorting it out :) > > net-irc/quirc-0.9.84 doesn't emerge with tcl/tk 8.5 > http://bugs.gentoo.org/show_bug.cgi?id=249468 status: fix provided. > waiting for maintainer > let's wait for the removal next action: tcl/tk 8.5 stable :-) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp+PvgACgkQV/B5axfzrPv9ZACdHzIU/J2oL4ImZSsZS38aErQb d1UAoIlKTHDGImvDT52RwoZY6aJUl4sM =dcnZ -END PGP SIGNATURE-
[gentoo-dev] new global USE flag: dssi
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, I think dssi could be a global USE flag # euse -i dssi global use flags (searching: dssi) no matching entries found local use flags (searching: dssi) [+ C ] dssi (dev-java/gnu-classpath): Enable the DSSI midi synthesizer provider [+ C ] dssi (media-sound/qtractor): Enable support for DSSI Soft Synth Interface [+ C ] dssi (media-sound/rosegarden): Enable support for DSSI Soft Synth Interface the description for it should be something similar to ladspa (dssi is a plugin architecture like ladspa) # euse -i ladspa global use flags (searching: ladspa) [+ C ] ladspa - Enables the ability to support ladspa plugins anyone? - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp+6FsACgkQV/B5axfzrPt4dwCfY7w2iijRTQSxl0eqQfAS4Qfe swMAnRK9BgRRjx2BhyNWftHIcGleVgl/ =sT2W -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] QA last rites for media-libs/libzzub and reverse dependencies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I posted updated ebuilds for aldrin and armstrong (formerly libzzub). will sound keep maintaining it? Diego E. 'Flameeyes' Pettenò wrote: > # Diego E. Pettenò (8 Aug 2009) # on behalf > of QA Team # +# libzzub: fails to build (bug #247149), lacking > maintainer. +# others: need libzzub +# Removal on 2009-10-08 > +media-libs/libzzub +media-sound/aldrin +dev-python/pyzzub + > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp+/+kACgkQV/B5axfzrPvwYgCdEEkcG4cdk84/MyD47IAHJFRj 51oAnRQw/aLM3wfcGfCbdoZX8wsxroLX =jXGj -END PGP SIGNATURE-
Re: [gentoo-dev] Multimedia overlay
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben de Groot wrote: > We would like to invite anyone interested in developing and maintaining > ebuilds related to multimedia in the wider sense: video, sound, tv, > graphics and fonts. If you have any live ebuilds or otherwise bleeding > edge packages, you can move them to the overlay for testing and shared > maintenance. note that for sound-related packages there exists pro-audio overlay - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqAx3sACgkQV/B5axfzrPt0NQCfUGCrSkdRzldaAjhujsxoua6C wuoAoLWpX7Le62LOeANJLEYvJ9jDWSef =OEzv -END PGP SIGNATURE-
Re: [gentoo-dev] Stats test server running, please check it out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pipping wrote: > Hello again! > > > I have set up a test server of the current stats code. If you have > a minute to check it out that would rock. I'm very interested in > overall feedback and bug reports. 1st: you could make an ebuild for it ;) 2nd: how to improve the output: you could make every data an hyperlink: that would help understand better the contents example: Archs: hyperlink arch name to wikipedia perhaps CFLAGS can link the flag name to GCC user guide relevant section, or to http://en.gentoo-wiki.com/wiki/CFLAGS# same for other flags and MAKEOPTS FEATURES can link feature to make.conf man page: http://linuxreviews.org/man/make.conf/ (unfortunately this man page is rendered with no anchors over variable/features, so you could do better ^__^ USE flags can link to http://gentoo-portage.com/Search?search=&use= (now appears down) System profiles: can link to profiles in cvs Package atoms can link to packages.g.o or to gentoo-portage.com those percentages are just funny: 33 (275.0 %)58 (483.3 %) 25 (208.3 %) Total 12 (100.0 %) [[ yeah, total is 100%, sometimes ]] kde 3 (25.0 %) others 554 (4616.67 %) Total 1066 (8883.33 %) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqAzOkACgkQV/B5axfzrPu9YwCfekbUmNJ0LfJ1PxqgAcCuFiD8 STYAn1xjdrMNmWusEV+EZlHPrL5Hr8gH =ZcgR -END PGP SIGNATURE-
Re: [gentoo-dev] Stats test server running, please check it out
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sebastian Pipping wrote: > Federico Ferri wrote: >> FEATURES >> can link feature to make.conf man page: >> http://linuxreviews.org/man/make.conf/ (unfortunately this man page is >> rendered with no anchors over variable/features, so you could do >> better ^__^ > > the output of neither > > # man2html -r make.conf.5 > make.conf.5.html > > nor > > # groff -man -Thtml make.conf.5 > make.conf.5.html > > make me really happy > > do you know any alternative coming with more anchors and external CSS > support? # nope for css, but you could do something like this: # imagine you have the feature list in a file # (I don't know how to extract it automatically, but perhaps someone does) $ cat featurelist assume-digests buildpkg buildsyspkg ... userpriv usersandbox usersync webrsync-gpg $ bzcat /usr/share/man/man5/make.conf.5.bz2 | man2html -r > make.html # basically now you have to match featurename # and add a anchor tag to it: $ eval `echo sed; cat featurelist | sed 's,^\(.*\),-e '\''s:\1:\1:'\'','; echo make.html` > make_anchors.html this will give you anchor to features, e.g. make_anchor.html#feature_buildpkg a bit tricky the sed - could be easier, but this version is fast because it builds a giant sed expression instead of calling sed n times. - -- Federico Ferri -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqBqKwACgkQV/B5axfzrPsegwCdFo95i26IF9+jeUSLntVI4nhS msgAnRw4I4D1MwPUf1yBY8gJh3PHtX9S =cx8u -END PGP SIGNATURE-