[gentoo-dev] links between anoncvs.g.o and sources.g.o

2008-12-20 Thread Jonas Bernoulli

May I suggest that you add links so that anoncvs.g.o and sources.g.o
link to one another. Users might find one of those pages and think
that's all there is to it. However both of the pages contain
information not available on the other. anoncvs.g.o mentions git and
rsync, and sources.g.o allow viewing repo contents using your browser.

-- Jonas

Re: [gentoo-dev] Re: bzr.eclass into Portage

2008-10-05 Thread Jonas Bernoulli
Here is a patch that adds support for shared repositories. Since bzr
is still a bit slow this is quite useful when using multiple branches.

For example I have modified the live emacs(-cvs) ebuild to use the bzr
mirror of emacs instead of cvs. I also have my own emacs branches, and
sometimes want to install from one of these and at other times from
trunk. Without support for shared repositories this would require the
standalone branches to be manually moved out of the way everytime I
want to switch branches. (Or worse the complete tree to be checked out
from scratch every time I switch branches.)

Please consider these changes


--- /usr/local/portage/layman/emacs/eclass/bzr.eclass   2008-10-05
22:40:18.0 +0200
+++ /usr/portage/eclass/bzr.eclass  2008-10-05 10:22:12.0 +0200
@@ -9,6 +9,7 @@
 # The bzr.eclass provides support for apps using the bazaar DSCM
(distributed source control management system).
 # The eclass was originally derived from the git eclass.
+# Shared repository support added by Jonas Bernoulli [EMAIL PROTECTED].
 # Note: Just set EBZR_REPO_URI to the url of the branch and the src_unpack
 # this eclass provides will put an export of the branch in ${WORKDIR}/${PN}.
@@ -22,13 +23,23 @@
 DESCRIPTION=Based on the ${EBZR} eclass


 # The dir to store the bzr sources.

+# Whether to use a shared repository (see bzr help repositories).
+# The bzr command to initialize the shared repository.
+EBZR_INIT_REPO_CMD=bzr init-repo
 # The bzr command to fetch the sources.
@@ -54,9 +65,24 @@
 # The bzr command to list revision number of the branch.
 EBZR_REVNO_CMD=bzr revno

+# Options passed to the init-repo commands.
+# Options passed to the fetch commands in additon to EBZR_OPTIONS.
+# Options passed to the update commands in additon to EBZR_OPTIONS.
-# The options passed to the fetch and update commands.
+# The common options passed to the fetch and update commands.

@@ -72,7 +98,7 @@
 #  - lp://
 # @CODE
-# Note: lp = https://launchpad.net
+# Note: lp = http://launchpad.net

@@ -93,21 +119,26 @@
 # The branch to fetch in bzr_fetch().
-# default: trunk

 # Revision to get, if not latest (see http://bazaar-vcs.org/BzrRevisionSpec)

-# The dir to store the source for the package, relative to EBZR_STORE_DIR.
+# The dir name of the local shared repository (if any).
 # default: ${PN}
+# The dir name of the local branch.
+# default: ${EBZR_BRANCH} when using a shared repository or ${PN} otherwise

 # @FUNCTION: bzr_fetch
@@ -143,37 +174,64 @@

cd -P ${EBZR_STORE_DIR} || die ${EBZR}: can't chdir to 

addwrite ${EBZR_STORE_DIR}
-   addwrite ${EBZR_BRANCH_DIR}

+   if [[ -n ${EBZR_SHARED_REPO} ]]; then
+   # using shared repository
+   addwrite ${EBZR_REPO_DIR}
+   else
+   # using stand-alone branch
+   fi
+   addwrite ${EBZR_BRANCH_DIR}

-   local repository
+   local branch

-   if [[ ${EBZR_REPO_URI} == */* ]]; then
-   repository=${EBZR_REPO_URI}${EBZR_BRANCH}
+   if [[ -n ${EBZR_BRANCH} ]] ; then
+   branch=${EBZR_REPO_URI}/${EBZR_BRANCH}

Re: [gentoo-portage-dev] please explain use of hooks

2008-03-02 Thread Jonas Bernoulli
On Sat, Mar 1, 2008 at 7:38 PM, Zac Medico [EMAIL PROTECTED] wrote:

  When portage is installed with USE=doc enabled, you'll find that
  there is a small Ebuild Phase Hooks section in the first chapter
  of the html documentation.

thx. I never bothered looking there as I have always assumed that
would just install the handbook.

I have seen rather complex uses of hooks, that's why I thought it
would be harder to get started.

On Sun, Mar 2, 2008 at 2:27 AM, Alec Warner [EMAIL PROTECTED] wrote:

  Do not attribute to malice what can easily be attributed to laziness ;)

yes sorry about that. Though I was not really all that lazy just made
a really bad assumption.

And if not the handbook this should really go into the portage manpage.


If  needed, this  file can  be  used to  set up  a
special  environment for  ebuilds,  different from
the standard root  environment.  The syntax is the
same as for any other bash script.
+ One thing you can do here is define phase hooks.
+ A phase hook function name begins with a pre_ or post_ prefix to
indicate that it will be called before or after one of the ebuild
phases. The prefix is followed by the name of the ebuild function that
the hook will be associated with. + For example, a hook named
pre_src_compile will be called before src_compile, and a hook named
post_src_compile will be called after src_compile.

postsync.d should also be documented there.

All in all now that I have looked at the documentation installed with
portage I think it is obsolete. Not in the sense that it is outdated
but everything in it is documented elsewhere already or should be
moved there.

II. Package Formats -  2. Ebuild - Ebuild Phases is already in the
developer handbook and

III. Quality Assurance - 3. QA Notices should be moved to the
developer handbook

If some developers an the list agree with me and welcome me to do so
then I could file a bug(s) for those changes.

gentoo-portage-dev@lists.gentoo.org mailing list

[gentoo-portage-dev] please explain use of hooks

2008-03-01 Thread Jonas Bernoulli

I was aware that the alternative package managers provide hooks for
some time now, but only found out recently that portage also has this
feature. Unfortunately I was not able to find any documentation about
it. I found some information related to hooks in portage on this list
and elsewhere but all of those sources assumed that the reader already
knows the basics.

So what I am looking for is a tutorial along the lines howto write
you first portage hook function. Of course a more in-depth
description would also be welcome. If something like this already
exists I apologize for not searching enough, and kindly ask you to
point you to the location.

The earlies post about hooks on this list seam to be from 2005, so I
was a bit surprised I could not find any documentation about them. In
my opinion this should be documented in the handbook. I can only
assume that either no one found the time to write it or that hooks are
intentionally not documented to prevent users from messing things up
and then filling untraceable bug reports. So if later were the case I
would still be very thankful if you could answer me in private, even
though I think this should be documented in public.

gentoo-portage-dev@lists.gentoo.org mailing list

Re: R: [gentoo-portage-dev] manual uninstall

2008-02-14 Thread Jonas Bernoulli
On 2/14/08, Lanza Fabrizio [EMAIL PROTECTED] wrote:
  I cannot issue a direct emerge command because catalyst does not support

If the stage supports it you can use N/fsscript. Or if you want to
unmerge the package at the beginning of the loop you could modify
gentoo-portage-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] new portage categories

2008-02-04 Thread Jonas Bernoulli
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 ( 

 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

[gentoo-dev] new portage categories

2008-02-04 Thread Jonas Bernoulli

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

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

Re: [gentoo-dev] new portage categories

2008-02-04 Thread Jonas Bernoulli
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