[gentoo-dev] Application server deployment eclass?
Okay, so if I have a servlet to deploy to an application container such as tomcat, is there an eclass that I can use to inherit from? Obviously the webapp eclass helps for straight apache-like deployments, but it's not going to help much when deploying to tomcat. I looked in /usr/portage/ebuild, but nothing jumped out at me... So how do I get my war file deployed? Am I left to external tools such as ant to manage that for me? How does such an entity fit within the portage world? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Application server deployment eclass?
Dave Nebinger wrote: > Okay, so if I have a servlet to deploy to an application container such as > tomcat, is there an eclass that I can use to inherit from? I don't think so. > > Obviously the webapp eclass helps for straight apache-like deployments, but > it's not going to help much when deploying to tomcat. > Well maybe the webapp setup can be configured or added the support for tomcat too. It is just a matter of paths I think. > > I looked in /usr/portage/ebuild, but nothing jumped out at me... > I don't think we have any servlets packaged in the tree at the moment. > > So how do I get my war file deployed? Am I left to external tools such as > ant > to manage that for me? > ant is a helper tool for building java software from sources, hopefully no-one uses it for package management. I think at the moment people just do the management manually, but you need to ask people who actually use tomcat in production. > > How does such an entity fit within the portage world? > If we start packaging servlets, then we of course need a setup for that, but it is not something the java team is actively looking into. Feel free to do your own development and we can then integrate it to the official tree if we find it a valuable addition. Regards, Petteri Räty signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: grub reiser4
On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > The grub maintainer's stance was that reiser 4 support would not be > included in grub until it was included in gentoo-sources, not any kernel > in portage. The grub maintainer has been AWOL for the last 9 months or > so however, so i guess it's now up to the base-system herd. I was under > the impression that feature-adding patches should be sent upstream. > > I still think it's retarded to have a reiser 4 boot partition, but > whatever stirs your pot. ;P It makes sense if you're actually using reiser4 for everything else. Why bloat your kernel with an extra FS just for /boot? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Application server deployment eclass?
On Sun, Oct 02, 2005 at 03:07:23AM -0400, Dave Nebinger wrote: > So how do I get my war file deployed? Am I left to external tools such as ant > to manage that for me? > > How does such an entity fit within the portage world? Each J2EE server has its own method for deploying j2ee archives. I don't think it is easy to create one that supports them all (WebSphere, WebLogic, Oracle's, TomCat/JBoss, ...). And anyway, the idea behind such archives is that the deployment itself is tweaked to the environment itself - there is no way for a "default works for all" deployment method afaik. I personally use a Java tool that uses the JMX possibilities of the J2EE server (if it supports it) to deploy tools, but this is targetted on a personal environment and mainly used to 1. provide a sort-of default method for deploying archives on the environment (which uses a single brand of J2EE servers anyway) 2. automate the upgrading of archives to a new version Wkr, Sven Vermeulen -- Gentoo Foundation Trustee | http://foundation.gentoo.org Gentoo Documentation Project Lead | http://www.gentoo.org/proj/en/gdp Gentoo Council Member The Gentoo Project <<< http://www.gentoo.org >>> pgp3zvrS6Ghx5.pgp Description: PGP signature
Re: [gentoo-dev] Re: grub reiser4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Bainbridge wrote: > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > >>The grub maintainer's stance was that reiser 4 support would not be >>included in grub until it was included in gentoo-sources, not any kernel >>in portage. The grub maintainer has been AWOL for the last 9 months or >>so however, so i guess it's now up to the base-system herd. I was under >>the impression that feature-adding patches should be sent upstream. >> >>I still think it's retarded to have a reiser 4 boot partition, but >>whatever stirs your pot. ;P > > > It makes sense if you're actually using reiser4 for everything else. > Why bloat your kernel with an extra FS just for /boot? > Because most people want a tried and true fs on /boot, because if that tanks your system doesn't boot. I'm not trying to bash reiser here, I still use ext2 on /boot even if xfs is my main fs of choice for this reason. Alec Warner (antarus) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ0AE8WzglR5RwbyYAQK8qg//ZkvUesz1inYyajZmR5f0AaghEa77cT+m bzZquMF9ttZj81lyqY9dgMvMVCa6+xVU+ZYx7Z76sbDeNeAmn5gQ3vW4KksHulVB pv7SH49hgzKA/ThTjSZsDeVbSVfnAjnElC17keXOp3i7AzPN2QoefqsaheW+L9mg f9Pb63Lz73e49Ahj9YmERJ37HZY28xPIWorlqlL+XkpOhymcofgU9o5iC6qrz+vi ht9cs7E4zNjU1JdNQ8ydsfz6z6Qd/YAu3M+zsd8ENOzO/0iIHFTI3l6Xss3ZfH0b bH4OdLni6qch/dWzoz2WqUo+JQgRYvwnDbE0wtr5kVSkhkmwRG9JFTY5zxzqtbTd MP/QGdx+j79muwVtI4Dl6h4GjnZtRlVmgSjFnNxMwFarITIoqJEtoFgP+mPXxEhe pPC9UwpphOujwMf8K9A6+a54KmGgH+SKKCcDMkiAFNje3HdvKcZTaDeXMzLODMBa iAyfewvzUIZG59AH0uN00sfwQ0lWiISA5p8ILVuoHFsajobv+nvUiWDBq2xZr0NU geHBJ6LsUjHbBSGFiMpWnP49uZCHv2PCbBxhHGIGY007fC1lVoiidah51iLZ3rid 3aU+KCuuXDj3IX4n2uG2HRJZHp8sRLUaCdOWR6oH4+EkRIcF5eCuYTSqN6H1Edrv v1YbLXiDjS4= =DXSo -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: grub reiser4
On 02/10/05, Alec Warner <[EMAIL PROTECTED]> wrote: > Chris Bainbridge wrote: > > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > >>I still think it's retarded to have a reiser 4 boot partition, but > >>whatever stirs your pot. ;P > > > > It makes sense if you're actually using reiser4 for everything else. > > Why bloat your kernel with an extra FS just for /boot? > > Because most people want a tried and true fs on /boot, because if that > tanks your system doesn't boot. I'm not trying to bash reiser here, I > still use ext2 on /boot even if xfs is my main fs of choice for this reason. Being able to boot a kernel isn't much use without a root fs. If I can't boot, I have a livecd sitting on my desk. I guess if I had a ramdisk on /boot with a shell and some recovery tools then I might care, but I don't. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] The end of dev-java/wx4j in official
Here is the package.mask entry explaining the situation: # Petteri Räty <[EMAIL PROTECTED]> (02 Oct 2005) # Upstream is dead and does not compile against the latest swig. # There are no packages using the library and there are better # alternatives. Will be moved to java experimental if no-one steps up. So if no-one steps up, I will be moving the package to our experimental java tree after a month. Regards, Petteri Räty (Betelgeuse) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: grub reiser4
On 10/2/05, Chris Bainbridge <[EMAIL PROTECTED]> wrote: > On 02/10/05, Alec Warner <[EMAIL PROTECTED]> wrote: > > Chris Bainbridge wrote: > > > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > > >>I still think it's retarded to have a reiser 4 boot partition, but > > >>whatever stirs your pot. ;P > > > > > > It makes sense if you're actually using reiser4 for everything else. > > > Why bloat your kernel with an extra FS just for /boot? In addition, why bloat your fs by having a journaled filesystem for essentially static files? > > > > Because most people want a tried and true fs on /boot, because if that > > tanks your system doesn't boot. I'm not trying to bash reiser here, I > > still use ext2 on /boot even if xfs is my main fs of choice for this reason. > > Being able to boot a kernel isn't much use without a root fs. If I > can't boot, I have a livecd sitting on my desk. I guess if I had a > ramdisk on /boot with a shell and some recovery tools then I might > care, but I don't. > > -- > gentoo-dev@gentoo.org mailing list > > -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Interactive emerge
Hi, I would just like some clarification if at all possible.
Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran
into some interactivity. I was under the impression that emerge was
supposed to be completely autonomous, and any user interaction should
take place in ebuild ... config.
Apparantly one of us is {in,}correct, but I cannot find any
documentation although I'm fairly sure I have read it..
Opinions?
Dan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Interactive emerge
On Sun, 2 Oct 2005 13:21:58 -0400 Dan Meltzer <[EMAIL PROTECTED]> wrote: | Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran | into some interactivity. I was under the impression that emerge was | supposed to be completely autonomous, and any user interaction should | take place in ebuild ... config. emerge is non-interactive. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpARbx2OtslB.pgp Description: PGP signature
Re: [gentoo-dev] Re: grub reiser4
On 02/10/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: > On 10/2/05, Chris Bainbridge <[EMAIL PROTECTED]> wrote: > > On 02/10/05, Alec Warner <[EMAIL PROTECTED]> wrote: > > > Chris Bainbridge wrote: > > > > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: > > > >>I still think it's retarded to have a reiser 4 boot partition, but > > > >>whatever stirs your pot. ;P > > > > > > > > It makes sense if you're actually using reiser4 for everything else. > > > > Why bloat your kernel with an extra FS just for /boot? > In addition, why bloat your fs by having a journaled filesystem for > essentially static files? Because it's easier to have a single fs for / than have multiple partitions, and try to isolate all of the things that are "essentially static" and move them over to unjournalled file systems. Journalling operations on /boot are responsible for filling a very, very small percentage of my hard disk. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Interactive emerge
On Sun, Oct 02, 2005 at 06:41:47PM +0100, Ciaran McCreesh wrote: | On Sun, 2 Oct 2005 13:21:58 -0400 Dan Meltzer | <[EMAIL PROTECTED]> wrote: | | Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran | | into some interactivity. I was under the impression that emerge was | | supposed to be completely autonomous, and any user interaction should | | take place in ebuild ... config. | | emerge is non-interactive. Also when FEATURES="test" ? In such case the mod_php and php packages are broken. They ask you to save, reject or send the result of the tests if I'm not mistaken Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgphbi18gG9bL.pgp Description: PGP signature
Re: [gentoo-dev] Interactive emerge
This is what I have found thanks to research of friendly people! http://article.gmane.org/gmane.linux.gentoo.devel/29810 (pkg_config only interactive) and, somewhere in dev manual it does say test can be interactive also.. not sure about that though On 10/2/05, Fernando J. Pereda <[EMAIL PROTECTED]> wrote: > On Sun, Oct 02, 2005 at 06:41:47PM +0100, Ciaran McCreesh wrote: > | On Sun, 2 Oct 2005 13:21:58 -0400 Dan Meltzer > | <[EMAIL PROTECTED]> wrote: > | | Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I ran > | | into some interactivity. I was under the impression that emerge was > | | supposed to be completely autonomous, and any user interaction should > | | take place in ebuild ... config. > | > | emerge is non-interactive. > > Also when FEATURES="test" ? In such case the mod_php and php packages > are broken. They ask you to save, reject or send the result of the > tests if I'm not mistaken > > Cheers, > Ferdy > > -- > Fernando J. Pereda Garcimartín > Gentoo Developer (Alpha,net-mail) > 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 > > > -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Interactive emerge
On Sun, Oct 02, 2005 at 07:50:53PM +0200, Fernando J. Pereda wrote: > Also when FEATURES="test" ? In such case the mod_php and php packages > are broken. They ask you to save, reject or send the result of the > tests if I'm not mistaken Even if they succeed? The point of test is to get some additional confidence that the package actually works. It doesn't mean you want to be bothered for nothing. Maurice. -- Maurice van der Pot Gentoo Linux Developer [EMAIL PROTECTED] http://www.gentoo.org Creator of BiteMe! [EMAIL PROTECTED] http://www.kfk4ever.com pgpH7uqtOnGSy.pgp Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Sun, 2 Oct 2005 19:50:53 +0200 "Fernando J. Pereda" <[EMAIL PROTECTED]> wrote: | On Sun, Oct 02, 2005 at 06:41:47PM +0100, Ciaran McCreesh wrote: | | On Sun, 2 Oct 2005 13:21:58 -0400 Dan Meltzer | | <[EMAIL PROTECTED]> wrote: | | | Recently, while testing bugzilla-2.18.4 for x86 (bug # 107796) I | | | ran into some interactivity. I was under the impression that | | | emerge was supposed to be completely autonomous, and any user | | | interaction should take place in ebuild ... config. | | | | emerge is non-interactive. | | Also when FEATURES="test" ? In such case the mod_php and php packages | are broken. They ask you to save, reject or send the result of the | tests if I'm not mistaken Yup. There're quite a few broken test packages in the tree. Another common problem is calling wget from inside test. Mostly this comes from src_test being a fairly recent feature... When some of the ebuilds in question were written it didn't exist. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpq8wHGW6GMP.pgp Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Sun, Oct 02, 2005 at 08:01:08PM +0200, Maurice van der Pot wrote: | On Sun, Oct 02, 2005 at 07:50:53PM +0200, Fernando J. Pereda wrote: | > Also when FEATURES="test" ? In such case the mod_php and php packages | > are broken. They ask you to save, reject or send the result of the | > tests if I'm not mistaken | | Even if they succeed? The point of test is to get some additional | confidence that the package actually works. It doesn't mean you want to | be bothered for nothing. I can't remember if they failed or not, but if the test failed then the ebuild should just die, no? I just don't feel like recompiling it again :) Cheers, Ferdy -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgps6uXTr9eyc.pgp Description: PGP signature
Re: [gentoo-dev] Interactive emerge
On Sun, Oct 02, 2005 at 07:02:02PM +0100, Ciaran McCreesh wrote: | | Also when FEATURES="test" ? In such case the mod_php and php packages | | are broken. They ask you to save, reject or send the result of the | | tests if I'm not mistaken | | Yup. There're quite a few broken test packages in the tree. Another | common problem is calling wget from inside test. Mostly this comes from | src_test being a fairly recent feature... When some of the ebuilds in | question were written it didn't exist. Ok, thanks for the clarification. -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgp5MrmL4AoAH.pgp Description: PGP signature
Re[2]: [gentoo-dev] Interactive emerge
2.10.2005, 20:13:52, Fernando J. Pereda wrote: > On Sun, Oct 02, 2005 at 08:01:08PM +0200, Maurice van der Pot wrote: > | On Sun, Oct 02, 2005 at 07:50:53PM +0200, Fernando J. Pereda wrote: | >> Also when FEATURES="test" ? In such case the mod_php and php packages | >> are broken. They ask you to save, reject or send the result of the | >> tests if I'm not mistaken > | > | Even if they succeed? The point of test is to get some additional > | confidence that the package actually works. It doesn't mean you want to > | be bothered for nothing. > I can't remember if they failed or not, but if the test failed then the > ebuild should just die, no? > I just don't feel like recompiling it again :) > Cheers, > Ferdy No, the ebuild does not die, there are things known to be broken in those tests. About 10-15 tests always fail, IIRC. Otherwise, it's Bug 59337. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) pgp367NYmDQ9x.pgp Description: PGP signature
[gentoo-dev] lights on internals
The ready to cut ebuild at the bottom print it's environment (variable
and functions) to a bunch of files into /var/tmp/fakebuild/.
May be useful for who want to have a look at "what" and "when" is
avaible during the various emerge phases (but not limited to).
usage:
# env -i \
PORTDIR_OVERLAY=/the/path/ \
fakebuild_progr=100 \
ebuild fakebuild-1.ebuild digest
# env -i \
fakebuild_progr=200 \
PORTDIR_OVERLAY=/the/path/ \
emerge --buildpkgonly =fakebuild-1
hint: try also the following:
- remove the egrep, sort after "typeset" to have also the sorce code of
the functions
- remove "{pkg,src}*" functions (after the previous step) to have a
look at the predefined functions.
--- app-misc/fakebuild --
# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
DESCRIPTION="fake ebuild to test environment"
HOMEPAGE="http://dev.gentoo.org/~vivo/";
SRC_URI=""
LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~x86"
print_env() {
local fakebuild_output_dir="/var/tmp/fakebuild"
mkdir -p "${fakebuild_output_dir}" || die
[[ -z "${fakebuild_progr}" ]] && fakebuild_progr=100
fakebuild_progr=$(( $fakebuild_progr +1 ))
export fakebuild_progr
local fakebuild_ext="${1}.${fakebuild_progr}"
# not sorting, break multiline vars
einfo "${fakebuild_output_dir}/env_${fakebuild_ext}"
env \
&> "${fakebuild_output_dir}/env_${fakebuild_ext}"
# Remove egrep and sort to see the source of every fx
einfo "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
typeset \
| egrep '^\b.* \(\)' \
| sort \
&> "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
}
print_env "global_scope"
pkg_setup(){ print_env "pkg_setup" ; }
src_unpack() { print_env "src_unpack" ; }
src_compile() { print_env "src_compile" ; }
src_test() { print_env "src_test" ; }
src_install() { print_env "src_install" ; }
pkg_preinst() { print_env "pkg_preinst" ; }
pkg_postinst() { print_env "pkg_postinst" ; }
--- app-misc/fakebuild --
--
___ __ _ ___ ___
/ ___/_ \_ \/ \ / / ___/ ___/ _ / ___/ _ \ /_ \
/ __/ _/__ / \ \/ / /__/ _/_ _\ \/ /__/ / / / / _/
/_/ /_/\_\/_/_/_/ \__/\___///___ \___/\/ / /\_\o
Simultaneous breaking of databases and backups since '90s.
World wide since 2005.0
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: grub reiser4
Chris Bainbridge posted <[EMAIL PROTECTED]>, excerpted below, on Sun, 02 Oct 2005 17:43:04 +: > On 02/10/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: >> On 10/2/05, Chris Bainbridge <[EMAIL PROTECTED]> wrote: >> > On 02/10/05, Alec Warner <[EMAIL PROTECTED]> wrote: >> > > Chris Bainbridge wrote: >> > > > On 02/10/05, R Hill <[EMAIL PROTECTED]> wrote: >> > > >>I still think it's retarded to have a reiser 4 boot partition, but >> > > >>whatever stirs your pot. ;P >> > > > >> > > > It makes sense if you're actually using reiser4 for everything >> > > > else. Why bloat your kernel with an extra FS just for /boot? >> In addition, why bloat your fs by having a journaled filesystem for >> essentially static files? > > Because it's easier to have a single fs for / than have multiple > partitions, and try to isolate all of the things that are "essentially > static" and move them over to unjournalled file systems. Journalling > operations on /boot are responsible for filling a very, very small > percentage of my hard disk. I'm doing this with reiserfs (3) ATM. 100% reiserfs system, fat and ext2 as kernel modules that I load only in the rare event I'm going to access a floppy. I have 20 partitions, including /boot and some others that are normally static, and /tmp and my portage tree and source partitions that are temporary or redownloadable so they really don't need journalled. However, the disk is some 250 GB, out of which well over 100 GB remains entirely unformatted at this point, so journal space isn't an issue, and it's simply less bother keeping everything on reiserfs, even on partitions where the default journal is a rather large portion of the entire partition, than otherwise. Note that reiser4 is "wandering journal". As I understand it, it doesn't set up a dedicated journal space, but rather, journals on the fly, by rewriting a file then cascading the metadata entries up the (duplicated) tree branch until it reaches the root entry, at which point the commit goes final as the old metadata tree branch is discarded and the new one takes effect. This isn't journalling, but rather, atomic metadata entry. Thus, there *IS* no journal per se, simply half finished commits that haven't gotten all the way up the tree to the root entry yet. The change is either fully committed or not committed at all, so unless the crash occurs at the exact moment the root entry itself is being updated (and I believe there's a special case for it, accounting for that very possibility), there's simply nothing to journal. Half-written commits that didn't fully cascade all the way to the top will simply be pruned in the event of recovery. The system is fully atomic, no journal necessary. Thus (unless I've misunderstood what I've read of reiser4), journal space isn't an issue with reiser4. It's an atomic transaction system, rather than a journal. That's also one of the reasons why copy method affects access time. Untar a tarball not created on reiser4 onto a reiser4 system, and those files won't be laid out for optimum access efficiency. That was one of the points Hans made in some of the benchmarking attempts. I don't quite understand the implications here, but apparently, taking the newly expanded files, copying (not moving) them elsewhere on the reiser4 system, deleting the old copy, then copying them back (if necessary), will reoptimize the layout into reiser4-access-optimized. Alternatively, running the repacker reoptimizes the entire fs, as well. Obviously, I've been following reiser4 with some interest, altho I've stuck with reiser3 to this point. (reiser4 has been unstable on amd64, I've been told.) That may change in the next few months, however, as I'll probably get a new disk (I've lots of space left, but this one has some badblocks due to overheating during an A/C malfunction) and am considering taking the opportunity to transfer to reiser4. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Ebuild limits?
Well, I've been plugging along happily on constructing an ebuild for zimbra. But because of a) their built-in hardwiring and b) ant-based build/install system, my ebuild is starting to get pretty big and complex. In order to keep my own thought patterns straight, I've isolated a lot of the code in src_compile and src_install to a number of different functions. But as the size of the ebuild continues to grow, I'm now starting to ask myself if, as it is currently going, the ebuild might not be accepted. So I guess I need to know: a) are there limits to the size and/or complexity of the ebuilds that are accepted into portage? b) If there are and I end up going beyond them, is there a recommended methodology for relocating some of the functionality? I mean, can I put code into scripts in the files directory and freely execute from there? Just wondering... Dave -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuild limits?
On Sun, 02 Oct 2005 19:58:19 -0400 Dave Nebinger <[EMAIL PROTECTED]> wrote: | a) are there limits to the size and/or complexity of the ebuilds that | are accepted into portage? Well... * Whoever ends up maintaining said ebuild must understand it. * Too much complexity is often a sign that you're doing something wrong. * Too much complexity often suggests that an eclass is needed. * Too much complexity often suggests that upstream's build system is annoyingly broken. | b) If there are and I end up going beyond them, is there a | recommended methodology for relocating some of the functionality? I | mean, can I put code into scripts in the files directory and freely | execute from there? eclass. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpCaeu85dDHa.pgp Description: PGP signature
Re: [gentoo-dev] Ebuild limits?
On Sunday 02 October 2005 08:08 pm, Ciaran McCreesh wrote: > On Sun, 02 Oct 2005 19:58:19 -0400 Dave Nebinger <[EMAIL PROTECTED]> > > wrote: > | a) are there limits to the size and/or complexity of the ebuilds that > | are accepted into portage? > > Well... > > * Too much complexity is often a sign that you're doing something > wrong. Well that's always the possiblity ;-) > * Too much complexity often suggests that upstream's build system is > annoyingly broken. This is it. Zimbra, if you're not aware of it yet, is another one of those LAMP-like distributions with a twist. Instead of Apache, it's based upon Tomcat, and their distribution includes a ton of other stuff (i.e. postfix, mysql, jdk, etc.) that gentoo's already got. So how I'm approaching it is a little twisted, but the basic steps are: 1. unpack zimbra's distribution. 2. apply patches to get their initial build to live within the sandbox rather than /opt/zimbra (like they expect). 3. apply patches to their iniitialization scripts to have the configuration scripts they would normally build in /opt/zimbra in the sandbox, then run said scripts. 4. Combine info from those configs, known values at build time, and values from existing (installed) configs, swing back through the code base applying patches and sed scripts to make the code conform to the local system. 5. build the distribution war files in the sandbox. 6. for installation, re-distribute the files from their scatter-brained distribution to use a more FHS and/or Gentoo friendly approach. Step 4 is necessary because they store a lot of default values (inappropriate values for an existing package installation) within their ldap (populated from an ldif) as well as hard-coding in the source files (for values they choose not to go to ldap to retrieve). This is further complicated because there are shell scripts, java source files, and configuration files to make passes through to fix things up. So yeah, things are pretty complicated due to the upstream build system expectations. The good news is that the ebuild is full of embedded comments ;-) All in all, though, this has been a great ebuilding educational experience. Such a large distrib to boil down into it's component parts, coordinating unpacking vs compiling vs installing, etc. I'm pretty much exposing myself to all the knooks and crannies of portage ;-) > | b) If there are and I end up going beyond them, is there a > | recommended methodology for relocating some of the functionality? I > | mean, can I put code into scripts in the files directory and freely > | execute from there? > > eclass. Cool, eclass it is, but a few more questions arise out of this direction: 1. Can I use /usr/local/portage/eclass for development/testing? 2. Do I create a single eclass, i.e. zimbra.eclass, to represent an eclass for a specific package or do I generate multiple eclasses based upon functionality? For example, I've got a gres function, a /var/db/pkg query system, etc. 3. Do eclasses get submitted on the same bug report as the ebuild submission, or do they get a bug report of their own? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuild limits?
On Sun, 02 Oct 2005 20:48:27 -0400 Dave Nebinger <[EMAIL PROTECTED]> wrote: | So yeah, things are pretty complicated due to the upstream build | system expectations. I suggest hitting upstream with a cluebat until they make a proper build system. | 1. Can I use /usr/local/portage/eclass for development/testing? Portage is kinda broken with eclasses in overlay... It'll work, so long as you remember to touch all affected ebuilds every time you change the eclass. | 2. Do I create a single eclass, i.e. zimbra.eclass, to represent an | eclass for a specific package or do I generate multiple eclasses | based upon functionality? Well... If it's really an eclass for a whole package, it may not be worth packaging the thing at all. | a /var/db/pkg query system, Yick! Bad bad bad idea. | 3. Do eclasses get submitted on the same bug report as the ebuild | submission, or do they get a bug report of their own? All in one bug's usually easier. -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpTzLowWrmPd.pgp Description: PGP signature
Re: [gentoo-dev] Ebuild limits?
On Sunday 02 October 2005 09:28 pm, Ciaran McCreesh wrote: > On Sun, 02 Oct 2005 20:48:27 -0400 Dave Nebinger <[EMAIL PROTECTED]> > > wrote: > | So yeah, things are pretty complicated due to the upstream build > | system expectations. > > I suggest hitting upstream with a cluebat until they make a proper > build system. Their build system suits their purpose - distribute a LAMP-like system for the foundation of their web application. I'm sure it will keep them from getting distracted from questions like 'zimbra works for postfix 2.2 but breaks for 2.2.3'; they provide it all and to use it you're normally stuck with their 3rd party binaries at the version/patch level they give you. So no matter how hard or how long I was going to hit them with the cluebat, they're not going to bend. Their distribution is structured as follows: /opt/zimbra /opt/zimbra/bin /opt/zimbra/conf ... /opt/zimbra/postfix /opt/zimbra/postfix/bin /opt/zimbra/postfix/etc ... /opt/zimbra/tomcat /opt/zimbra/tomcat/bin /opt/zimbra/tomcat/conf ... Yada yada yada. The alterations to get it to fit under a regular distribution make the resulting ebuild pretty large. All for the goal of extracting two web applications and some configuration info. Go figure. > | 2. Do I create a single eclass, i.e. zimbra.eclass, to represent an > | eclass for a specific package or do I generate multiple eclasses > | based upon functionality? > > Well... If it's really an eclass for a whole package, it may not be > worth packaging the thing at all. That's the rub. Create eclass(es) to make a single ebuild less complex, or skip the eclasses and have a larger ebuild. > | a /var/db/pkg query system, > > Yick! Bad bad bad idea. Yeah, I know. But how else do you answer the question "Hey, Portage, where did you really install that my.cnf file?" Obviously the system admin is free to move the my.cnf file or even use a different file/path altogether. But at least it would give me a starting value to use at compile time... -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] aging ebuilds with unstable keywords
Hi,
This is an automatically created email message.
http://gentoo.tamperd.net/stable has just been updated with 12916 ebuilds.
The page shows results from a number of tests that are run against the ebuilds.
The tests are:
* if a version has been masked for 30 days or more.
* if an arch was in KEYWORDS in an older ebuild, but not in the newer ones.
* if SRC_URI contains hosts specified in thirdpartymirrors.
* if ebuild uses patch instead of epatch.
* if ebuild sets S to ${WORKDIR}/${P}.
* if ebuild redefines P, PV, PN or PF.
* if ebuild doesn't inherit eutils when it uses functions from eutils.
* if ebuild doesn't inherit flag-o-matic when it uses functions from
flag-o-matic.
* if ebuild has $HOMEPAGE in SRC_URI (cosmetic).
* if ebuild has $PN in SRC_URI (cosmetic).
* if ebuild forces -fPIC flag to CFLAGS.
* if ebuild has deprecated WANT_AUTO(CONF|MAKE)_?_?.
* if ebuild uses is-flag -fPIC, should be changed to has_fpic.
* if ebuild appends $RDEPEND or $DEPEND to $RDEPEND or $DEPEND to $DEPEND.
* if ebuild has arch keyword(s) in iuse.
* if ebuild overrides MAKEOPTS.
* if ebuild has automake, autoconf or libtool in RDEPEND.
* if ebuild exists in ChangeLog.
* if ebuild installs COPYING and/or INSTALL into doc.
The database is updated once a day and this email is sent once a week.
Questions and comments may be directed to [EMAIL PROTECTED]
Script has been running for 227 minutes.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] grub reiser4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Frysinger wrote: | On Thursday 29 September 2005 02:10 pm, Chris Bainbridge wrote: | |>I was wondering if there's any chance of having the reiser4 patch for |>grub (or even the whole grub-reiser4 distfile) added to the ebuild. |>There are various bugs where people have posted patches for 0.96x |>ebuilds which were never added and the bugs have been WONTFIXed or |>left dangling. I've been using grub+reiser4 for about 9 months now |>with no problems. The last reason I heard it wouldn't be added was |>that no kernels in portage support it; I believe that's not true |>anymore, at least mm-sources has reiser4. | | | i'll ask a few devs how they feel about it before i commit it | -mike I'd prefer if the patch was left out for amd64 users, or included via a use flag. reiser4 isn't yet stable or proven on amd64. - -- === Mike Doty [EMAIL PROTECTED] Gentoo/AMD64 Strategic Lead PGP Key: 0xA797C7A7 Gentoo Developer Relations ~ ===GPG Fingerprint=== ~ 0094 7F06 913E 78D6 F1BB 06BA D0AD D125 A797 C7A7 === -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDQKwe0K3RJaeXx6cRAj01AKCKpJfVT5FM1bJFgbu4jpgXbuiErwCeI8hk cb7WM663LziKx0ME95oqWr0= =zfvZ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuild limits?
On Sun, 02 Oct 2005 21:50:07 -0400 Dave Nebinger <[EMAIL PROTECTED]> wrote: | Their build system suits their purpose - distribute a LAMP-like | system for the foundation of their web application. I'm sure it will | keep them from getting distracted from questions like 'zimbra works | for postfix 2.2 but breaks for 2.2.3'; they provide it all and to use | it you're normally stuck with their 3rd party binaries at the | version/patch level they give you. Hrm. Does this really need an ebuild? Wouldn't it be better to use the associated portage-provided packages? Also, how do you intend to handle security updates? | > | a /var/db/pkg query system, | > | > Yick! Bad bad bad idea. | | Yeah, I know. But how else do you answer the question "Hey, Portage, | where did you really install that my.cnf file?" | | Obviously the system admin is free to move the my.cnf file or even | use a different file/path altogether. But at least it would give me | a starting value to use at compile time... I'm starting to think you really shouldn't be ebuilding this lot at all... -- Ciaran McCreesh : Gentoo Developer (Vim, Shell tools, Fluxbox, Cron) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm pgpaSamJsN5PS.pgp Description: PGP signature
Re: [gentoo-dev] Ebuild limits?
On Monday 03 October 2005 12:47 am, Ciaran McCreesh wrote: > On Sun, 02 Oct 2005 21:50:07 -0400 Dave Nebinger <[EMAIL PROTECTED]> > > wrote: > | Their build system suits their purpose - distribute a LAMP-like > | system for the foundation of their web application. I'm sure it will > | keep them from getting distracted from questions like 'zimbra works > | for postfix 2.2 but breaks for 2.2.3'; they provide it all and to use > | it you're normally stuck with their 3rd party binaries at the > | version/patch level they give you. > > Hrm. Does this really need an ebuild? I think so. As a stand-alone package it has a number of dependencies that need to be managed, something Portage handles quite well. Also, I'm finding that at it's core, portage handles the reorganization of a distribution quite nicely. Being able to automagically handle the java dependencies using java-pkg is a godsend. Itematically choosing the individual files from the distribution build and retargeting them to /usr/share/webapp with a one-line command... The advantages appear to outweigh the costs. > Wouldn't it be better to use the > associated portage-provided packages? That's the goal - strip out the parts from their distribution that have exiting components already within the portage tree (and already installed on my system). Boils down to a couple of wars for the most part, plus scripts, things like that. > Also, how do you intend to handle > security updates? For the most part I'd leave that to Portage for the 3rd party components. I'm expecting that once I get the initial ebuild figured out, when they release a new distribution I'll just have to re-diff & re-patch if the current patches stop working. > | > | a /var/db/pkg query system, > | > > | > Yick! Bad bad bad idea. > | > | Yeah, I know. But how else do you answer the question "Hey, Portage, > | where did you really install that my.cnf file?" > | > | Obviously the system admin is free to move the my.cnf file or even > | use a different file/path altogether. But at least it would give me > | a starting value to use at compile time... > > I'm starting to think you really shouldn't be ebuilding this lot at > all... I understand your doubts, and trust me I have them to. But the way I see it I have two basic choices: 1. use their distribution. This discards all of the advantages that portage provides (i.e. updates to the foundation software). Also means that for each component in their system that is already on mine, I need to shut mine down/unmerge them so the system will rely upon theirs. Will really mess up things like openldap and mysql dependent projects as their distribution doesn't provide the full development stuff portage would need to handle builds. 2. create an ebuild to merge only the necessary components into my system, taking advantage of the fact that I already have working components installed. It would seem to me that #2 is the appropriate gentoo-way... I started working on this because I was initially looking for a good web mail package to use on my gentoo box (I'm starting a new contract where I won't have pop3/imap access to my email from the job site). Scope soon creeped to become a good collaboration suite to use on my gentoo box (because I'd have calendars, address books, etc. scattered across many different sources). While I was checking out the options that were already in portage I was also checking online for other possiblilities. The recent posting to slashdot on the very subject caught my eye, and when I went through the flash demo at http://www.zimbra.com I was really impressed with everything I saw. But to get it up and running I soon discovered I'd have to make one of the choices from above. Eventually some 1,000 year old geezer might say "He chose poorly," but who knows - it might work and might catch on. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] lights on internals
On Sun, Oct 02, 2005 at 11:07:13PM +0200, Francesco R wrote:
> The ready to cut ebuild at the bottom print it's environment (variable
> and functions) to a bunch of files into /var/tmp/fakebuild/.
> May be useful for who want to have a look at "what" and "when" is
> avaible during the various emerge phases (but not limited to).
> print_env() {
> local fakebuild_output_dir="/var/tmp/fakebuild"
> mkdir -p "${fakebuild_output_dir}" || die
>
> [[ -z "${fakebuild_progr}" ]] && fakebuild_progr=100
> fakebuild_progr=$(( $fakebuild_progr +1 ))
> export fakebuild_progr
>
> local fakebuild_ext="${1}.${fakebuild_progr}"
>
> # not sorting, break multiline vars
> einfo "${fakebuild_output_dir}/env_${fakebuild_ext}"
> env \
> &> "${fakebuild_output_dir}/env_${fakebuild_ext}"
>
> # Remove egrep and sort to see the source of every fx
> einfo "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
> typeset \
> | egrep '^\b.* \(\)' \
> | sort \
> &> "${fakebuild_output_dir}/fxlist_${fakebuild_ext}"
> }
This won't work as you expect. Env is a binary, it only gets
the exported env.
Elaborate on the "what and when" bit also, since the env that's dumped
to ebuild.sh varies depending on a lot of things.
~harring
pgprbcwHzA0vE.pgp
Description: PGP signature
[gentoo-dev] user/group manipultaion feedback request.
Ladies & Gentlemen,
Some of you may know me from lurking on #gentoo-dev or moderating
#gentoo or any of another handful of channels that I'm in. Anyway, I'm
trying to become a developer and to learn the Gentoo way. I have been
assigned an old bug to try and resolve, Bug #5113, "New adduser and
deluser features request". In pursuit of that end I have decided to
start from scratch and write a single wrapper script for the useradd,
userdel, groupadd, and groupdel scripts to ensure that file locking is
properly handled on all archs. That said, everything else except
writing to /etc/{passwd,group,shadow,gshadow} will be handled by this
script.
Chris White read and commented on this email prior to its being sent
and thinks that I should have a working code base first. I disagree and
think that these decisions will effect the design of the script and may
necessitate and re-write; that is what I'm trying to avoid. I have
already written a few hundred lines of code for some of the branch
features like scanning the /etc/{passwd,group,shadow,gshadow} files for
data, searching for files/processes, reading/writing the defaults file,
etc., enough to get a grasp of most of the problems but I want to figure
out the main hierarchy before I go too much further.
I intended to add all of the functionality that exists right now into
the new script. It will read values from /etc/login.defs and have its
own config file for extensions/additions to the current way of doing
things. The script will also add functionality on top of that like the
ability to delete a user's home directory when that user is deleted. I
know that is handled now but the ability to archive that user's home
directory prior to deletion is not. And the ability to hunt down the
user's mailspool and aliases, crontab and sudoers entries, running
processes and files outside of their home is not. If everything works
out as planned this script can be used as a user/administrator's sole
interface into the /etc/{passwd,group,shadow,gshadow} files and can even
be expanded into an eclass for ebuilds that need to create users/groups.
I would like some input in the name of the program, its features,
calling convention, and its config file options. I was thinking of
calling it id-manage with three basic modes of operation. User to
manipulate users. Group to manipulate groups. And default to manipulate
the config file's entries.
id-manage user [add|del|show] [additional-options]
id-manage group [add|del|show] [additional-options]
id-manage default [set|get] []
I would like the script to be able to be called with the least amount
of cruft as possible. It is my opinion that having a program a category
and a mode is easier to remember than one of four program names. It is
also my belief that sane defaults should be provided and that they be
able to be overridden by the administrator. I am interested on any
feedback that I can get regarding the calling convention of the program
here. For instance, "id-manage add user" was eliminated because
defaults can't be added. Nothing is set in stone here although I have
made some decisions that are going to require some pretty strong
arguments to get me to change my mind. I'm open to debate and the last
thing that I want to do is write something that I feel is great and not
have it adopted because I overlooked some Gentooism or failed to
consider someone else's point of view. This is your chance to speak up.
Also, I need to know exactly what is and is not allowed in certain
places. For instance: user names, they can be alpha-numeric but they
have to start with a letter don't they (shadow v4.03)? Also, user names
with capitals have been banned since most MTAs are case-insensitive and
that can cause confusion. What else is there to consider?
I'm not new to programming so all of this is within my skill set so
don't be afraid to ask for features. However, this is going to take a
couple of weeks to write entirely in bash so that it is both portable
and can be used on the most minimal of systems. (Also, although I'm not
thinking of other distributions right now I don't want to do anything
that will preclude its use on them). I have seen a request for
something like "superadduser user-name group-name" to add a user to a
group. This won't work with my design but "manage-id user add user-name
to group-name" might. I'm interested in design discussion here but I
don't want to do things just because it is the way that something else
does them.
The last issue is the config file. I have a boatload of ideas here but
I don't want to cloud anyone else's ideas with mine. Can you just give
me ideas that you would like to see here. As an example:
# If enabled then it will find a uid/gid that is new
# if id min/max was 1000/5000 and ids 1000-1050 have been assigned
# but ids 1022-1025 have been deleted, normally the next id assigned
# would b
