Re: [gentoo-dev] looking for mentor
I may not have interpreted your message correctly. If I inferred something from it that you didn't intend to convey, please clarify. Developing the Portage software itself is an entirely different process than creating an ebuild: unless you're planning to contribute enhancement code to Gentoolkit or Portage, they're just a set of tools for package development and management. In order to create an ebuild, you need to know what package you /want/ to bring into the tree. Randomly submitting ebuilds that will shortly thereafter be without a home is only a recipe for neglected packages. I'm aware of the fact that building portage related software is different from creating ebuilds. I'm interested in the openoffice ebuilds, as well as scheme and some lisp related ebuilds. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal: sys-pam category
Ned Ludd wrote: On Sun, 2005-06-05 at 16:22 +0200, Diego 'Flameeyes' Pettenò wrote: Currently pam stuff (implementations, modules) are organized in the worst way I ever seen. Most of them are in sys-libs, some of them in app-admin, other in app-crypt, pam_smb in net-misc and so on. I think we should reorganize them and have a sys-pam category with implementations (Linux-PAM and OpenPAM) and the modules needed. Such a change would require a lot of work and we can't count on epkgmove I think, but if someone is going to help me or at least tell me how to do such a change without breaking everything (always if such a change is accepted, obv.).. Comments? Diego: This is not directed at you solely but expresses my general feelings on the topic of ever moving packages. I think they are fine where they are. Moving stuff around is a waste of time. Makes things more complex. Makes more work on everybody. Invalidates binary package trees. It places stress on rsync servers. It makes people have to rewrite rsync_exclude files. Makes it harder for scripts that interact with portage. And in the end really gains us next to nothing. Please stop moving stuff around for cosmetic reasons. I see far to many threads about changing stuff. No real valuable work ever gets done. Stuff simply just gets shifted around somebody can think of a new way to categorize existing data. I do agree with you but some package just have completely wrong place within portage, such package placements migh confuse the user. To give an example: mzscheme was placed in dev-lisp while portage had a dev-scheme directory. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Proposal: sys-pam category
Nathan L. Adams wrote: Then why is their a browsable Categories link on the packages site? http://packages.gentoo.org/categories/ Very good question , .. I don't agree with Ned. Organizing the packages logically makes things less confusing for the end-user and developers alike and doesn't qualify as a cosmetic reason. It *is* valuable work, IMHO. I often use simple unix tools like ls grep etc .. to search for things in my portage tree I find that this goes alot quicker then using the user utilities , so I guess your right those need more attention then the tree structure. That's not to say that the user tools shouldn't be improved where possible, of course. I don't think anyone would argue with that. Nathan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] looking for mentor
Hello guys, I've been using gentoo for 2 years now and I'm really found of this distrobution , never touched an other distro since then. Lately I've been creating some small probably meaningless ebuilds for several packages like tinyscheme and adding some bug reports etc .. I'm also looking into gentoolkit , already had some contact about that with karltk. Now as you can see I'm getting involved and somewhere in the holy gentoo developers handbook I read that a new developer should have mentor .. Short info about me: I'm 20 years old, live in Belgium meanly Brussels, still a college student. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] looking for mentor
Mike Frysinger wrote you can join #gentoo-dev and we dont mind giving voice to people who are interested in joining development ... I'm there most of the time my nick is eniac. the first step to becoming a dev really is to figure out *what* you want to work on ... after that it's pretty easy to locate the sub group of devs to integrate yourself with I'm interested in portage and gentoolkits , that includes mainting and creating ebuilds. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bashrc mini HOWTO
Chris White wrote:
Hi guys,
Well, I was working on my bashrc one day and thought, gee, would be
nice for other people to know what the heck is going on too!. Well, I
decided to go ahead and do that :P. So, here we go, a mini bashrc HOWTO
(note this only works on the latest stable of portage. You go grab cvs head
and try this, you can kiss yer but goodbye! :D).
HOW DOES IT WORK
if [ -f ${PORTAGE_BASHRC} ]; then
source ${PORTAGE_BASHRC}
This little code in ebuild.sh pretty much sums it up. Basically, when
ebuild.sh is run with various ebuild stages (unpack, compile, postinst, etc..
etc.. etc.), it sources the bashrc file (located in /etc/portage/bashrc),
giving it the exact same environment as ebuild.sh has. So, your bashrc file
pretty much ends up like a mini ebuild. Now that we've explained that, let's
get down and dirty.
LET'S USE IT
case $* in
# stay really quiet here.
depend) : ;;
*)
[ $* = compile ] package-pre-compile
[ $* = postinst ] package-post-install
;;
esac
Here's some sample code for my small bashrc file. This is something I pulled
from solar's bashrc and adjusted it a bit. $* is all parameters passed to
the program. This means the ebuild stage in this particular case. So
package-pre-compile is run when the compile stage is hit, and
package-post-install is run when the postinst stage is hit. Here, depend is
silenced, as ebuilds get depend'ed a LOT, things get kind of noisy. Now that
we know what stages we can run stuff at, let's see what we can do with
environmental variables.
ENVIRONMENTAL VARIABLES
Well, first off portage is kind of restrictive. That said, anything you need
to pull from /usr/bin you're probably going to have to add it to PATH:
package-post-install() {
PATH=$PATH:/usr/sbin:/usr/bin:/bin:/sbin
As such. If you have program not found errors, chances are you didn't do
this. So now, what about FEATURES. That's right, you can actually use
FEATURES as well to cook up some nice stuff. In my case, I had portage update
the whatis database when it's done installing. This is nice because I'm
horribly lazy and wouldn't have the guts to do it manually/add a cron job.
Here we go:
if has whatis ${FEATURES} test -x
/usr/sbin/makewhatis ; then
echo *** whatis enabled. Updating the whatis
database...
# update the whatis database
`makewhatis -u`
fi
}
Alright so, remember how I said that bashrc is a mini-ebuild? Note how you
can use the same has command that ebuilds can. This is because we're being
sourced from ebuild.sh, and therefore have all its functions. What does that
mean? That means you get this:
addread
addwrite
adddeny
addpredict
esyslog
use
usev
useq
has
hasv
hasq
has_version
portageq
best_version
use_with
use_enable
diefunc
check_KV
keepdir
unpack
strip_duplicate_slashes
all the stuff described in man 5 ebuild (too lazy to list here)
killparent
remove_path_entry
do_newdepend
inherit (yes.. you can inherit eclasses.. weird ain't it...)
debug-print-function
debug-print-section
And you also notice FEATURES. It can even do all the nifty portage variables
too (default and in /etc/make.conf). So that's it, with this nice little
touch you can do cool customizations to the portage process, without messing
with portage code ;).
Chris White
I gave this a quick look, and aren't you talking about bash scripts in
general rather then .bashrc files using /etc/portage/bashrc as reference
for this document.
Also I can't see the real use , that's why I started reading then
quickly scanned through it .. and now I'm writting this email ..
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bashrc mini HOWTO
Alec Warner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jonas Geiregat wrote: snip ChrisWhite I gave this a quick look, and aren't you talking about bash scripts in general rather then .bashrc files using /etc/portage/bashrc as reference for this document. Also I can't see the real use , that's why I started reading then quickly scanned through it .. and now I'm writting this email .. normal bash scripts aren't sourced by portage when ebuilds are being processed. Only PORTAGE_BASHRC ( current /etc/portage/bashrc ) is sourced. Thus you can do cool stuff like print debug info, over-ride default functions, and otherwise other fun stuff that normally would be a complete PITA, especially if you don't know portage internals well. No such file on my system, is that the reason why I should use the cvs version of portage, so the new version will source /etc/portage/bashrc when it comes out of cvs ? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQpT+LmzglR5RwbyYAQKXWQ/+KjdNLnZlokuD2rKPXwgsYRzeLpmZtMs5 Qm7k+gakIuO9tMlbnYFUm5vaZxif+IaPDWeMRSpshOWA94G7kTx22bytMc7axu5J xlIrVjajHip96nHrGYNklETUEtbt9tm+1nLYpoLAjfejXby2QnTd8+GANaZ1Lqwz SzgJA6IYNXtIk6Xu6mZE0V+Fpizmflvii+UueviwH9+UzKR6SKrYjZmBTU5NAjGv uy4kcTMNkl3LZMKu5P9yKV3NYOX0YABrgxpfhtbgZJsBC4a2a3Y8XLymmKcTeMUS AIP1o6V/h+dWfU9H5PuQsYvBsmfMK06thWTAZF411FFZLXk+HhKo9De0nQvkaM9H P+P5UwXgEdlJLk7k2oq1eE09klDRegzZGEVs6mcxk9b6qQ9d8ub/8IUB1Fv68PwI 62lngdKNw7BND1IRwBuyNXD1JOoUHYZuSO1CHyraneij5NunSiwqwLl8sbqsXmqJ riuvaIuWPce37CS3Pmg55eh42aW8ikHpjusDMmSAGh8ffsdW6ogHi4sHwBMMDpEf c2/ybSZU5cK13csDaPPcaadhNZWPXFOs1pLphOfCoe+3ia0W2cjQruI1jdL2CG2y nO7NYLmUZ50xELvawmEPXKu76O6qbV0JB2J2SKFgAExV+GXFSGdpPoZiLyLWnSMF 6r8juJ5CpeE= =W3Pe -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] problem with first ebuild
Hi,
I've presented this problem already to 2 developers, both of them where
unable to help me.
I hope I can find a solution on this list.
I've created my first ebuild, I've included the ebuild script the patch
and the output of the emerge tinyscheme command.
The problem is with the install -g root -o root -m 755 scheme etc ..
command, it seems to run fine but at the end nothing is installed
If I patch the source myself and run make make
DESTDIR=/home/jonas/bin install; everything works fine ...
I find it a really odd problem..
Regards Jonas
# Copyright 2000-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
inherit eutils
DESCRIPTION=Lightweight scheme interpreter
HOMEPAGE=http://tinyscheme.sourceforge.net;
SRC_URI=http://tinyscheme.sourceforge.net/tinyscheme-1.35.tar.gz;
LICENSE=BSD
SLOT=0
KEYWORDS=~ppc
IUSE=
DEPEND=
RDEPEND=
src_unpack() {
unpack ${A} || die
cd ${S}
epatch ${FILESDIR}/${P}-make-install.patch
}
src_compile() {
emake || die
}
src_install() {
echo ${D}
make DESTDIR=${D} install || die
}
Calculating dependencies ...done!
emerge (1 of 1) dev-scheme/tinyscheme-1.35 to /
md5 files ;-) tinyscheme-1.35.ebuild
md5 files ;-) files/digest-tinyscheme-1.35
md5 files ;-) files/tinyscheme-1.35-make-install.patch
md5 src_uri ;-) tinyscheme-1.35.tar.gz
Unpacking source...
Unpacking tinyscheme-1.35.tar.gz to /var/tmp/portage/tinyscheme-1.35/work
* Applying tinyscheme-1.35-make-install.patch ...
[ ok ]
Source unpacked.
gcc -fpic -I. -c -g -Wno-char-subscripts -O -DSUN_DL=1 -DUSE_DL=1 -DUSE_MATH=0
-DUSE_ASCII_NAMES=0 scheme.c
gcc -fpic -I. -c -g -Wno-char-subscripts -O -DSUN_DL=1 -DUSE_DL=1 -DUSE_MATH=0
-DUSE_ASCII_NAMES=0 dynload.c
dynload.c:24:1: warning: SUN_DL redefined
command line:11:1: warning: this is the location of the previous definition
gcc -shared -o libtinyscheme.so scheme.o dynload.o -ldl
ar crs libtinyscheme.a scheme.o dynload.o
gcc -fpic -o scheme -g -Wno-char-subscripts -O scheme.o dynload.o -ldl
Test phase [not enabled]: dev-scheme/tinyscheme-1.35
Install tinyscheme-1.35 into /var/tmp/portage/tinyscheme-1.35/image/
category dev-scheme
/var/tmp/portage/tinyscheme-1.35/image/
install -o root -g root -m 755 scheme
/var/tmp/portage/tinyscheme-1.35/image//bin
man:
prepallstrip:
strip: powerpc-unknown-linux-gnu-strip --strip-unneeded
strip: powerpc-unknown-linux-gnu-strip --strip-unneeded
bin
Completed installing tinyscheme-1.35 into
/var/tmp/portage/tinyscheme-1.35/image/
Merging dev-scheme/tinyscheme-1.35 to /
!!! /bin
/bin
Safely unmerging already-installed instance...
--- makefile.b 2003-01-07 20:01:04.0 +0100
+++ makefile2005-05-24 17:00:36.773034840 +0200
@@ -28,6 +28,7 @@
OUT = -o $@
RM= -rm -f
AR= ar crs
+DESTDIR=/usr
# Linux
LD = gcc
@@ -82,3 +83,6 @@
tags: TAGS
TAGS: $(TAGS_SRCS)
etags $(TAGS_SRCS)
+
+install:
+ install -o root -g root -m 755 scheme$(EXE_EXIT) $(DESTDIR)/bin
Re: [gentoo-dev] Maintaining an ebuild
Fredrik Tolf wrote: Hi List! This is probably a FAQ, but I really couldn't find the answer. I've STFW'd, RTFM'd and RTFDeveloper's Handbook, but I still have no answer. The thing is, I've got a li'l program of mine that I'd like to have in portage. I've written an ebuild and all (which works with PORTDIR_OVERLAY), but I have no idea if I can maintain it myself in portage (and, in that case, how I would acquire the permission for that) or if I have to ask someone on the inside to do it for me (and, in that case, who I should ask). Flame me all you want, but please point out where it says at the same time. ;-) Fredrik Tolf Not really a FAQ but you can find the answer here : http://www.gentoo.org/doc/en/ebuild-submit.xml -- gentoo-dev@gentoo.org mailing list
