[gentoo-dev] Re: VDB access
Hi, Ciaran McCreesh <[EMAIL PROTECTED]>: > The following things access VDB by hand: > * gnome2-utils.eclass. Will be fixed once a portage with proper > env saving goes stable, which isn't too far off. Bug 155993. > > * net-misc/l7-filter. This can be fixed as soon as portage with proper > env saving goes stable. > > * kde.eclass, for slot_rebuild. This seems like it's a really dumb > hack to cater for users who don't know how to use revdep-rebuild > (there seems to be a lot of that going around, making elog worthless, > but that's a different issue...), and should probably just be removed. > > * pcmcia.eclass. Supposedly deprecated. Bug 140289. Are there open bugs for it? Or is anyone aware of and working on it? > * Modify built_with_use so that it calls native_built_with_use if such > a function exists, and falls back to its own implementation otherwise. > > * Allow package managers that implement native_built_with_use to > sandbox off vdb completely, and ban all ebuild access to vdb. Sounds reasonable as far as I can see. > This will let package managers use a format other than VDB. A well > designed replacement can shave a minute off cold cache command times. How much gain can be expected? And what package managers will allow native_built_with_use? V-Li -- Christian Faulhammer, Gentoo Lisp project http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode http://www.faulhammer.org/> signature.asc Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-db/qdbm: ChangeLog qdbm-1.8.77.ebuild
On Mon, 4 Feb 2008 23:05:18 -0800 Donnie Berkholz <[EMAIL PROTECTED]> wrote: > What happens if the make process changes directories? In a different process? It's pretty unlikely make will ever become a shell builtin... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-text/hyperestraier: ChangeLog hyperestraier-1.4.13.ebuild
On 17:28 Mon 04 Feb , Akinori Hattori (hattya) wrote:
> 1.1 app-text/hyperestraier/hyperestraier-1.4.13.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/hyperestraier/hyperestraier-1.4.13.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/app-text/hyperestraier/hyperestraier-1.4.13.ebuild?rev=1.1&content-type=text/plain
> for u in java ruby; do
> if ! use ${u}; then
> continue
> fi
>
> for d in ${u}native ${u}pure; do
> cd ${d}
> econf || die
> emake || die
> cd -
Same question as qdbm for the directory changing..
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in dev-db/qdbm: ChangeLog qdbm-1.8.77.ebuild
On 17:16 Mon 04 Feb , Akinori Hattori (hattya) wrote:
> 1.1 dev-db/qdbm/qdbm-1.8.77.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-db/qdbm/qdbm-1.8.77.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/dev-db/qdbm/qdbm-1.8.77.ebuild?rev=1.1&content-type=text/plain
> src_compile() {
>
> econf \
> $(use_enable debug) \
> $(use_enable zlib) \
> --enable-pthread \
> --enable-iconv \
> || die
> emake || die
>
> local u
>
> for u in java perl ruby; do
> if ! use ${u}; then
> continue
> fi
>
> cd ${u}
> econf || die
> emake || die
> cd -
> done
>
> }
What happens if the make process changes directories? Does `cd -` still
work as expected, or should you use pushd/popd instead?
Same point for src_test() and src_install().
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in net-irc/kvirc: ChangeLog kvirc-3.2.6_pre20080204.ebuild
On 14:11 Mon 04 Feb , Dawid Weglinski (cla) wrote:
> 1.1 net-irc/kvirc/kvirc-3.2.6_pre20080204.ebuild
>
> file :
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/kvirc/kvirc-3.2.6_pre20080204.ebuild?rev=1.1&view=markup
> plain:
> http://sources.gentoo.org/viewcvs.py/gentoo-x86/net-irc/kvirc/kvirc-3.2.6_pre20080204.ebuild?rev=1.1&content-type=text/plain
> src_unpack() {
> unpack ${A}
> cd "${S}"
> ./autogen.sh
> epatch "${FILESDIR}"/${PN}-svn-kdedir-fix.patch
> epatch "${FILESDIR}"/${PN}-gendoc.patch
> }
Any particular reason to not use eautoreconf?
Thanks,
Donnie
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: I want to steal your tools
On Mon, 04 Feb 2008 21:21:14 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Also very good, thanks. Instead of sourcing, we can instead use > > $ portageq envvar PORTDIR Or simply `portageq portdir'... > $ portageq portdir_overlay I remember reading you wanted a program that did the job *fast*. Calling portageq takes around 2 (VIA EPIA M1) to 3 (HP Visualize C3650) or more seconds to return on (some|older) systems. Kind regards, JeR -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: I want to steal your tools
Heath N. Caldwell wrote:
On 2008-02-04 14:51, Ryan Hill wrote:
Can someone provide a tool that given a package name simply prints the
category or cat/pkg, or if ambiguous, prints the multiple cat/pkgs or
returns an error code? I don't care what it's written in as long as it's
relatively quick. I'm sick of depending on udept (which is an incredible
tool but a lot heavy for a simple shell script) just to get a simple
category.
What about something like this:
--
#!/bin/bash
source /etc/make.globals
source /etc/make.conf
for i in ${PORTDIR} ${PORTDIR_OVERLAY}; do
(cd $i; a=(*/$1); [ -e ${a[0]} ] && ls -1 -d */$1)
done | sort | uniq
--
It's really fast, at least.
Also very good, thanks. Instead of sourcing, we can instead use
$ portageq envvar PORTDIR
$ portageq portdir_overlay
How do paludis and pkgcore make this info available?
--
fonts,by design, by neglect
gcc-porting, for a fact or just for effect
wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: I want to steal your tools
On 2008-02-04 14:51, Ryan Hill wrote:
> Can someone provide a tool that given a package name simply prints the
> category or cat/pkg, or if ambiguous, prints the multiple cat/pkgs or
> returns an error code? I don't care what it's written in as long as it's
> relatively quick. I'm sick of depending on udept (which is an incredible
> tool but a lot heavy for a simple shell script) just to get a simple
> category.
What about something like this:
--
#!/bin/bash
source /etc/make.globals
source /etc/make.conf
for i in ${PORTDIR} ${PORTDIR_OVERLAY}; do
(cd $i; a=(*/$1); [ -e ${a[0]} ] && ls -1 -d */$1)
done | sort | uniq
--
It's really fast, at least.
--
Heath Caldwell - [EMAIL PROTECTED]
Operating Systems Analyst - California State Polytechnic University, Pomona
pgpMH8rxILWSX.pgp
Description: PGP signature
[gentoo-dev] VDB access
The following things access VDB by hand: * gnome2-utils.eclass. Will be fixed once a portage with proper env saving goes stable, which isn't too far off. Bug 155993. * net-misc/l7-filter. This can be fixed as soon as portage with proper env saving goes stable. * kde.eclass, for slot_rebuild. This seems like it's a really dumb hack to cater for users who don't know how to use revdep-rebuild (there seems to be a lot of that going around, making elog worthless, but that's a different issue...), and should probably just be removed. * pcmcia.eclass. Supposedly deprecated. Bug 140289. * eutils.eclass. For built_with_use. Of these, only the last appears to be of any use. So how about the following? * Modify built_with_use so that it calls native_built_with_use if such a function exists, and falls back to its own implementation otherwise. * Allow package managers that implement native_built_with_use to sandbox off vdb completely, and ban all ebuild access to vdb. This will let package managers use a format other than VDB. A well designed replacement can shave a minute off cold cache command times. -- Ciaran McCreesh -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] RFC: Ruby project
I've gone and created Ruby project. It is living under the prog_lang project. In accordance with GLEP 39, I'm sending this out as an RFC. Initially, it will be just the Ruby herd. As we get things together, we hope to add an overlay, documentation, mailing list, and so on. I will be serving as the first project lead. It can be seen at: http://www.gentoo.org/proj/en/prog_lang/ruby/ -- Josh Nichols Gentoo/Ruby Developer -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Retiring
On 21:18 Mon 04 Feb , Kevin F. Quinn wrote: > I'm finally giving in to reality and retiring as a Gentoo Dev. I've > been effectively inactive since March last year and lack of time > means that isn't going to change any time soon. I'll still be using > Gentoo of course, so I'll still stick my nose in on bugzilla now and > again :) Feel free to keep trying to get hardened X working perfectly. =) Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: I want to steal your tools
Thomas de Grenier de Latour wrote:
On 2008/02/04, Ryan Hill <[EMAIL PROTECTED]> wrote:
Can someone provide a tool that given a package name simply prints
the category or cat/pkg, or if ambiguous, prints the multiple
cat/pkgs or returns an error code? I don't care what it's written in
as long as it's relatively quick.
As long as you're only interrested in stuffs from the Portage tree,
and not overlays, and you have portage-utils installed along with its
post-sync hook, you can use one of this function:
find_cat1() {
qsearch -CsN "^${1}$"
}
find_cat2() {
sed -n "\\|/${1}/|s:/[^/]*\$::p" "${PORTDIR}"/.ebuild.x \
| uniq
}
Note that find_cat1() is case-insensitive, probably not what you want.
And without portage-utils' ebuilds cache, this works too:
find_cat3() {
pushd "${PORTDIR}" >/dev/null
ls -1d $(sed "s:\$:/${1}:" profiles/categories) 2>/dev/null
popd >/dev/null
}
Here are some benchs (real time, with 1 run from cold I/O cache, and
then 100 runs also from cold I/O cache, with "fuse" as argument):
* find_cat1:
- 0m0.972s
- 0m25.967s
(No real advantage... that's not the primary target of this applet.)
* find_cat2:
- 0m0.237s
- 0m3.746s
(Acceptable in both cases.)
* find_cat3:
- 0m2.319s
- 0m2.607s
(Really slow on first run, but really fast once the tree as been
walked. May be a good choice in some contexts.)
Perfect! I'll tinker with these and see what I come up with.
Thanks.
--
fonts,by design, by neglect
gcc-porting, for a fact or just for effect
wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Re: I want to steal your tools
On 2008/02/04, Ryan Hill <[EMAIL PROTECTED]> wrote:
>
> Can someone provide a tool that given a package name simply prints
> the category or cat/pkg, or if ambiguous, prints the multiple
> cat/pkgs or returns an error code? I don't care what it's written in
> as long as it's relatively quick.
As long as you're only interrested in stuffs from the Portage tree,
and not overlays, and you have portage-utils installed along with its
post-sync hook, you can use one of this function:
find_cat1() {
qsearch -CsN "^${1}$"
}
find_cat2() {
sed -n "\\|/${1}/|s:/[^/]*\$::p" "${PORTDIR}"/.ebuild.x \
| uniq
}
Note that find_cat1() is case-insensitive, probably not what you want.
And without portage-utils' ebuilds cache, this works too:
find_cat3() {
pushd "${PORTDIR}" >/dev/null
ls -1d $(sed "s:\$:/${1}:" profiles/categories) 2>/dev/null
popd >/dev/null
}
Here are some benchs (real time, with 1 run from cold I/O cache, and
then 100 runs also from cold I/O cache, with "fuse" as argument):
* find_cat1:
- 0m0.972s
- 0m25.967s
(No real advantage... that's not the primary target of this applet.)
* find_cat2:
- 0m0.237s
- 0m3.746s
(Acceptable in both cases.)
* find_cat3:
- 0m2.319s
- 0m2.607s
(Really slow on first run, but really fast once the tree as been
walked. May be a good choice in some contexts.)
--
TGL.
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gentoo-commit messages for SVN
On Mon, Feb 04, 2008 at 02:38:57PM +0100, Ioannis Aslanidis wrote: > For now, the KDE repository is not being used and its purpose is more > internal to the herd, so I'd opt out for it. Both kde and pybugz taken out now. I locked them to RO as well since you say that they aren't being used either anymore. -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpPkIJNrUHMs.pgp Description: PGP signature
[gentoo-dev] Re: I want to steal your tools
Ciaran McCreesh wrote: On Mon, 04 Feb 2008 15:59:26 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: I want something that anybody can use in their scripts without having to install paludis What's the difference between installing Paludis and installing Perl in order to use a tool? Ha. Nice edit. What I actually said was: I want something that anybody can use in their scripts without having to install paludis, or eix, or udept, or etc. Well, perl is already installed on my and everyone else's system. Paludis was one example, but I would like it to work without having to install anything extra at all. Otherwise I'd continue to use udept. So, do you have such a solution or did you just pop up because someone said Paludis? -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: I want to steal your tools
Ciaran McCreesh wrote: On Mon, 04 Feb 2008 15:59:26 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: I want something that anybody can use in their scripts without having to install paludis What's the difference between installing Paludis and installing Perl in order to use a tool? About 10 minutes (YMMV) Mon Nov 19 22:26:38 2007 >>> dev-lang/perl-5.8.8-r4 merge time: 6 minutes and 10 seconds. Wed Nov 7 12:46:01 2007 >>> sys-apps/paludis-0.24.6 merge time: 16 minutes and 25 seconds. -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: I want to steal your tools
On Mon, 04 Feb 2008 15:59:26 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > I want something that anybody can use in their scripts without having > to install paludis What's the difference between installing Paludis and installing Perl in order to use a tool? -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: I want to steal your tools
Ryan Hill wrote: Can someone provide a tool that given a package name simply prints the category or cat/pkg, or if ambiguous, prints the multiple cat/pkgs or returns an error code? I don't care what it's written in as long as it's relatively quick. I'm sick of depending on udept (which is an incredible tool but a lot heavy for a simple shell script) just to get a simple category. After getting a couple suggestions, I guess I forgot some requirements. a) package-manager agnostic b) using only tools in the system set + maybe gentoolkit and portage-utils I want something that anybody can use in their scripts without having to install paludis, or eix, or udept, or etc. Bonus points for actually integrating this feature into gentoolkit or portage-utils. ;) -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-admin/ctcs, net-libs/libhttpd-persistent, net-ftp/gtkfxp, dev-libs/tinyq
# Raúl Porcel (04 Feb 2008) # Masked for removal in 60 days. That is, 04 Apr 2008 # For treecleaners, # doesn't compile, last release in 2002, # bug #152044 dev-libs/tinyq # Various bugs, upstream dead, gtk-1, last release 2003 # bug 205481 net-ftp/gtkfxp # Last release 2003, unfixable, doesn't compile # bug #193415 app-admin/ctcs # Doesn't compile, useless, bug #152493 net-libs/libhttpd-persistent -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Retiring
Hi all I'm finally giving in to reality and retiring as a Gentoo Dev. I've been effectively inactive since March last year and lack of time means that isn't going to change any time soon. I'll still be using Gentoo of course, so I'll still stick my nose in on bugzilla now and again :) There's not much out there that depends on me; packages that have my name against them as maintainer are: app-admin/eselect-oodict app-text/hunspell app-text/info2html sys-apps/qtparted and app-dicts/myspell-* There's useful work to be done on the myspell dictionaries (which are used by hunspell). Currently various applications install their own copies of dictionaries in various places - something that is just wasteful and lazy. I'd always intended to finish an eselect module for managing myspell dictionaries; got some work done but never finished it off. eselect-oodict was a quick version for dealing with OOo.org dictionaries (which uses myspell dictionaries) and you can find my attempts at a more generic eselect-myspell on bugzilla. Doing that needs co-operation from the relevant applications (particularly the mozilla application set). qtparted is controversial and may not be worth holding on to; see bugzilla for details. Lastly, just to say I've learned a lot from my involvement with Gentoo over the time I was active and it has been very worthwhile for me; hopefully I've managed to contribute at least something back to compensate! All the best, Kev. signature.asc Description: PGP signature
[gentoo-dev] Re: I want to steal your tools
Alec Warner wrote: * Tool being a tool useful for gentoo development, dealing with profiles, ebuilds, configs, etc. Tool does not include your penis or other genitellia. defeature: http://dev.gentoo.org/~dirtyepic/bin/defeature [requires app-portage/udept] disables FEATURES per-package, most common usage being defeature test coreutils mklastrites: http://dev.gentoo.org/~dirtyepic/bin/mklastrites how i do the last rites mails. was also an exercise in learning awk so don't make too much fun of me. http://dev.gentoo.org/~dirtyepic/bin/cp2overlay yet another portage -> overlay copier [also requires app-portage/udept] Can someone provide a tool that given a package name simply prints the category or cat/pkg, or if ambiguous, prints the multiple cat/pkgs or returns an error code? I don't care what it's written in as long as it's relatively quick. I'm sick of depending on udept (which is an incredible tool but a lot heavy for a simple shell script) just to get a simple category. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwindows @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new portage categories
Donnie Berkholz wrote: On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: Thinking about it again I would say tags and categories just fulfill different purposes. Tags can not replace categories but might be a useful extension to categories for the tasks I described, not more not less. They are not better or worse, just different:) Why don't you think they can replace categories? For example: # eix -e fuse * app-emulation/fuse Description: Free Unix Spectrum Emulator by Philip Kendall * dev-java/fuse [1] Description: Fuse is a lightweight resource injection library specifically designed for GUI programming. * sys-fs/fuse Description: An interface for filesystems implemented in userspace. Also imagine all those packages sorted into subdirs just by first character of the name (because having them all in one huge dir would be murder), yuck :) -- Vlastimil Babka (Caster) Gentoo/Java signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] new portage categories
On 2/4/08, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: > > Thinking about it again I would say tags and categories just fulfill > > different purposes. Tags can not replace categories but might be a > > useful extension to categories for the tasks I described, not more not > > less. They are not better or worse, just different:) > > Why don't you think they can replace categories? Quick answer: Because there are packages with the same name in different categories. How would tags deal with that? Long answer: Well maybe there is a way. But I think that it would probably take a long time to make such a change. Technically tags could probably replace categories but then their would be no definite "full" name for that package anymore. Someone calls it foo/app and someone bar/app, and since there is also fuu/app which is a different application but with the same name, nobody would no for sure about package is being taked about without checking if his beloved foo/app is the same as bar/app the other guy is talking about. Also how do you sort the packages in the tree? all in one directory?! every package in the directories of each tag it belongs to using hardlinks? -- Jonas -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new portage categories
On 20:11 Mon 04 Feb , Jonas Bernoulli wrote: > Thinking about it again I would say tags and categories just fulfill > different purposes. Tags can not replace categories but might be a > useful extension to categories for the tasks I described, not more not > less. They are not better or worse, just different:) Why don't you think they can replace categories? Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new portage categories
On 2/4/08, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > Sounds like what you really want are tags, not categories ... Yes and no. tags would definitely be better than subcategories. But for some packages a new category would probably still make sense like app-scm ( http://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg27404.html). > You could play with adding them into metadata.xml and patching some > existing search tools to search for them. Added to my TODO list. Extending existing search tool would only be a first step however. The ability to exclude/include packages from the tree would also be a useful feature (and that doesn't seam to fit the design of the tools I have used). > I'm all for the idea of tags, > and I think it's a better approach than categories. Thinking about it again I would say tags and categories just fulfill different purposes. Tags can not replace categories but might be a useful extension to categories for the tasks I described, not more not less. They are not better or worse, just different:) -- Jonas -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] new portage categories
On 18:35 Mon 04 Feb , Jonas Bernoulli wrote: > So I ask you: why are there no such categories? Of course I can > imagine a few reasons myself for not having more categories: > > (1) a category must in general include n packages > (2) more categories are evil, once we start creating new once there is no end > (3) moving packages in the tree is bad, things break > (4) who does all the work > (5) subcategories would be better, but to implement this... > > > Please point me to any discussions on this subject. Keep in mind I am > not demanding new categories, I am not even asking for them to be > created. I simply would like to know why there aren't more. And if you > developers are also interested in more categories I would love to make > some suggestions and help with looking through the tree to see which > packages would have to be moved. > > Reasons why more categories might be usefull: Sounds like what you really want are tags, not categories ... You could play with adding them into metadata.xml and patching some existing search tools to search for them. I'm all for the idea of tags, and I think it's a better approach than categories. Thanks, Donnie -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] new portage categories
Hello Recently I started to exclude parts of the portage tree for various reasons. One of them is that I play with the thought of creating my own minidistro/livecd based on Gentoo. So keep in mind that I don't think that it is in general useful to trim the portage tree to the extend that I have. One of the obvious things one might start out with is to exclude kde when one prefers gnome or vice versa. I extended this to exclude packages within on category that fulfill the same purpose. E.g. I use app-admin/metalog so it doesn't make much sense to include all the other loggers. Since the decision for metalog at the time was not substantiated at the time a also made a note basically saying "is metalog really the best? these are the alternatives". Once I have the time I might include the other loggers again and evaluate them. But to make the list of loggers I basically had to read through the descriptions of all packages in app-admin to sort out all loggers (I could have searched but I wanted to make sure I don't miss anything). Since I have not done this for loggers only this was/is a lot of work and I therefor asked myself why are there no categories like app-log or app-cron. So I ask you: why are there no such categories? Of course I can imagine a few reasons myself for not having more categories: (1) a category must in general include n packages (2) more categories are evil, once we start creating new once there is no end (3) moving packages in the tree is bad, things break (4) who does all the work (5) subcategories would be better, but to implement this... Please point me to any discussions on this subject. Keep in mind I am not demanding new categories, I am not even asking for them to be created. I simply would like to know why there aren't more. And if you developers are also interested in more categories I would love to make some suggestions and help with looking through the tree to see which packages would have to be moved. Reasons why more categories might be usefull: (1) Easier to find new packages One great benefit of going through the tree to exclude packages was for me that I came across many great packages I did not know about. The likeliness of this would be increased e.g. for the category app-admin, if I did not have to read the DESCRIPTION of ~8 loggers even though I already have selected one and currently am not at all interested in evaluating the alternatives. In addition there are ~14 logfile analysers of some sort in app-admin ~4 logfile rotators ~2 other log related packages. And some more can probably be found in app-misc, x11-apps and x11-misc. So all in all at least ~30 packages that have to do with logging, why not create app-log? (2) Easier to find alternatives to a package Need a logger? See what is in app-log! (3) Makes it less likely that similar packages end up in different categories Just an example app-admin/pwcrypt DESCRIPTION="An improved version of cli-crypt (encrypts data sent to it from the cli) but cli-crypt is in app-crypt" By the way why is there app-crypt but not app-log? There are other things I noticed when weeding through the tree. E.g. some DESCRIPTIONs start with a capitalized letter others don't. Some end with a period, others don't. Some for now apparent reason start with "foo is an application to do bar" instead of "do bar". I understand that it is not very interesting for any developer to fix such minor errors, and I am not asking anyone to do something about it. But I would like to know if there is any change that new categories are created if I or others collect lists of packages that could be moved to new categories. And yes I understand that the work doesn't end here and would possibly also help finding packages whose dependencies would have to be modified. For me also this is not exactly fun. But since I do this kind of work for my own personal benefit at the moment I might as well do it in a way that benefits others as well. -- Jonas -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Last rites: www-apps/gallery-1*
Hi Benedikt, Benedikt Böhm <[EMAIL PROTECTED]> writes: > +# Benedikt Böhm <[EMAIL PROTECTED]> (03 Feb 2008) > +# Masked for removal in 30 days wrt #208584 > +# Does not use webapp/depend.apache eclass correctly I'll fix this ASAP (probably tomorrow) > +# Obsoleted by =www-apps/gallery-2* > +=www-apps/gallery-1* Why do you call the gallery-1* branch obsoleted? It still gets releases and security audits. In contrast to gallery-2* it does not require a MySQL db which might be a plus for some people and I don't see a reason to remove the package from the tree. If you don't object I'll remove the mask once I fixed the dependecy issue. Cheers, Gunnar -- Gunnar WrobelGentoo Developer __C_o_n_t_a_c_t__ Mail: [EMAIL PROTECTED] WWW: http://www.gunnarwrobel.de IRC: #gentoo-web at freenode.org _ -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gentoo-commit messages for SVN
For now, the KDE repository is not being used and its purpose is more internal to the herd, so I'd opt out for it. On Feb 4, 2008 2:33 PM, Santiago M. Mola <[EMAIL PROTECTED]> wrote: > On Feb 4, 2008 12:54 PM, Robin H. Johnson <[EMAIL PROTECTED]> wrote: > > > > Included: > > pybugz > > > > If you think a repo is on the wrong side, please respond here! > > > > This is no longer in use and can be even removed. > > It's now an external project, hosted on http://code.google.com/p/pybugz/ > > -- > Santiago M. Mola > Jabber ID: [EMAIL PROTECTED] > -- > gentoo-dev@lists.gentoo.org mailing list > > -- Ioannis Aslanidis 0xB9B11F4E -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] gentoo-commit messages for SVN
On Feb 4, 2008 12:54 PM, Robin H. Johnson <[EMAIL PROTECTED]> wrote: > > Included: > pybugz > > If you think a repo is on the wrong side, please respond here! > This is no longer in use and can be even removed. It's now an external project, hosted on http://code.google.com/p/pybugz/ -- Santiago M. Mola Jabber ID: [EMAIL PROTECTED] -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] gentoo-commit messages for SVN
Thanks to antarus stepping up and doing a bit of script development, the gentoo-commits list now has SVN mails in addition to the existing CVS mails. Git mails should follow soon. The SVN mails have the same set of X-VCS headers for you to use to procmail our what you are interested in. Here's which repos are or aren't included in the mails. Included: - apache autoepatch baselayout catalyst devmanual dietlibc eselect genkernel gentoo-alt gentoo-bashcomp gentoo-dev-summary gentoo-news gentoo-perl gentoo-python gentoo-syntax gentoo-vdr gentoolkit gli glsr hardened hwdata kde keychain linux-patches livecd-tools overlays path-sandbox php planet portage pybugz releng sandbox scire votify vps Excluded: - adopt-a-dev bugday gentoo-infra kbase These contain private content. If you think a repo is on the wrong side, please respond here! -- Robin Hugh Johnson Gentoo Linux Developer & Infra Guy E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgp2vUgYkzRNa.pgp Description: PGP signature
