[gentoo-dev] PORTAGE_NICENESS is not so nice...
So I set PORTAGE_NICENESS to 19 in /etc/make.conf on my primary gentoo desktop so I could do emerges in the background and still use my box... Well tonight I emerged boost... The system maxed out and ran that way for an hour without looking like it was going to complete anytime soon. Which wouldn't have been so bad if the system wasn't pegged to the point of being totally unresponsive under X. I eventually killed it and system load dropped back to normal. Commented out the PORTAGE_NICENESS value and emerged boost again. This time the system pegged again, but the whole process was finished in 10 minutes. So I'm starting to question how useful PORTAGE_NICENESS actually is... If the system is pegged under niceness 19 and 0, but 0 completes in 10 minutes, why would PORTAGE_NICENESS benefit me in any way? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
i still dont see how this addresses the nocxx / USE=-* noFOO is used because FOO is on by default, and noFOO turns it off. AutoUSE is the same way, package bar is included in the buildplan and to have sane defaults, certain flags are turned on. that was a great explanation however irrelevant it may have been i guess we will have to make 'nocxx' a special case as we strip all other 'no*' USE flags from portage Sorry, guys, but isn't that what -FOO is supposed to be for? If we already have support for -FOO, why then do we need a noFOO also? Or is there some distinction I'm missing here? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
there is nothing hard about USE=-* cxx but while most here want to say 'fuck the users' (and i'm inclined to agree), i'd rather not field those bugs/questions/etc... The average gentoo newbie is not going to know anything about -* in /etc/make.conf. Mostly it's folks that have been around for a system build or two before they start adding the -* at the beginning of their USE flags. I may be wrong but I don't believe the gentoo install doco even mentions -* as part of USE flag setup. So basically if only 'experienced', yet misguided, folks are using '-*', then the only bugs to come up from this would be ABKB bugs, leaving them with egg on their face for messing with '-*' in the first place. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] ${PORTDIR}/profiles/package.use
On Thursday 20 October 2005 11:09 pm, Dave Nebinger wrote: So basically if only 'experienced', yet misguided, folks are using '-*', then the only bugs to come up from this would be ABKB bugs, leaving them with egg on their face for messing with '-*' in the first place. Before anyone asks, ABKB is help-desk lingo for A**hole Behind Key Board. I always preferred that to the id10t error (idiot). Dave -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] New category for xmingw cross compile toolchain
Just a few opinions from the outside looking in... On Thursday 13 October 2005 12:25 pm, Stefan Jones wrote: I am just wondering about people's option about making a new category, called something like dev-xmingw or similar. Wouldn't set a precident for dev-gcc, dev-icc, dev-[enter alternate toolchain here]? The other option is to make an external non-official tree that people could use as an overlay. Personally I don't like that idea either. To me, external overlays are 'tainted' because they are not blessed enough to be part of the default gentoo tree. I therefore don't trust them and don't use them. Obviously that means I don't get the latest cutting edge stuff, but to have a stable gentoo environment I'm willing to make that sacrafice. Relegating these mingw stuff to an external overlay would carry the same 'taint' with it. And the fact that external non-official overlays are not really given much representation in the doco, most users looking for something like this would not have any idea that the external overlay existed and they could get the packages they're looking for from there. Like I said, just comments from an outsider... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Tomcat 5.5 in portage
On Wednesday 12 October 2005 01:36 pm, Petteri Räty wrote: The java herd is heavily understaffed. So how does one get involved? I'm a professional Java developer and a gentoo enthusiast. I'd love to participate and it would seem my skills would be a good fit here, especially since you have the need... -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Just another portage enhancement idea...
This is probably the fifth time at least that I've been bitten by this...
Portage is great in that it manages compiles for a bulk of applications
(including dependencies) in one fell swoop.
Yesterday I emerged gnome - that was it, just gnome, and it took care of the
whole thing soup to nuts. Wahoo, and kudos to all of you who put in the
work.
But here's my issue... In emerging one of the 101 packages missing on my
system for gnome, a little blurb flew buy that should have caught my
attention, a message posted in the pkg_postinst() message indicating what I
should do now that my installation has completed.
That's well and good, but as it was one of only 101 other packages, that
message quickly gets lost in the shuffle.
So here's the enhancement: have portage collect all of these kinds of messages
and display them after all of the emerging has completed.
So here's my proposed enhancement: Before the call to pkg_postinst(), set a
flag that causes einfo/ewarn/etc. to tee the output generated by the ebuild
to /var/log/portage_postinst.log (or something configurable in make.conf,
whatever). Preface the first generated line with the ${P} so we know what
it's related to. After the pkg_postinst() method completes, clear the flag
and other emerges can carry on as they need to.
Had this kind of thing been in place, after emerging 101 packages I could go
to the postinst log and see everything that I had to do, including the little
blurb that I had missed before.
Yes, I know folks are going to say that you can enable portage logging and
look for messages that need to be taken care of. But I just emerged 101 new
packages, have many emerge -ud worlds, etc. resulting in almost 2000 files
out there in /var/log/portage. Talk about the needle in the haystack,
there's not even some specific keywords I could grep on to hit on the
relevant information.
Understandably I don't know what you all will say about this. It seems like a
great idea to me, and wouldn't appear to come with all the political issues
that the 'extending the ebuild meta data' or some other issues that have come
up recently.
But I'll leave it to the rest of you to decide...
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Python setuptools/eggs
I've been working on an eclass for these but its not ready. I was hoping it'd be as easy as the Ruby gems eclass, because they are similar, but eggs don't play nicely in a sandbox yet. But aren't eggs a bit against the Gentoo philosophy? I mean there are some eggs that contain precompiled C-extensions. Shouldn't it still be source builds that just somehow work with setuptools? I may be a bit of-base, but since I don't know much about the ruby gems, I'm wondering how close of a situation this is with the perl cpan modules? They're integrated to operate using the distribution process of both cpan and portage... Just a suggestion. Like I said, I could be way off-base... -- gentoo-dev@gentoo.org mailing list
[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
[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 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 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
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
[gentoo-dev] Question about java builds and the sandbox...
Okay, hopefully this works as I expect, but... If I have an ant build.xml file that creates and populates an /opt/dnebing directory but runs as part of an ebuild, will it actually create the /opt/dnebing directory or is it made as part of the image in /var/tmp/portage/dnebing/image directory? I'm hoping it is the latter, but if not I guess I'd need to strip installation stuff from the build.xml file and put the appropriate commands in the ebuild script. Can someone shed a little light on this for me? Thanks! -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Project, GLEP, or skip it?
Chris, Thanks for your comments, and I'll work on the BO issue ;-) How comprehensive is this? Is this something like a cPanel/Plesk clone or is it simpler than that? The XAMPP distribution, at http://www.apachefriends.org/en/xampp-linux.html, is comprehensive as it coordinates the installation of apache, mysql, perl, and php as a connected system. All of the various configuration files are structured so that all of the pieces interact with each other, a step that we would otherwise need to do as manual processes. The included web application, the primary piece that would be grabbed from the project, modified, and included in GAMPP, includes a number of pages which display all of the functional components installed as part of XAMPP, such as the image building and PDF building components and links to the installed web apps that are part of XAMPP (webalizer, phpMyAdmin, and phpSQLiteAdmin). So I guess GAMPP for the most part would act like kde-meta in that it pulls all of the disparate pieces together into a single deployment package. It then adds the web app that can be used to test the final installation. To quote the XAMPP site: XAMPP is an easy to install Apache distribution containing MySQL, PHP and Perl. XAMPP is really very easy to install and to use - just download, extract and start. The goals of GAMPP would be similar yet apply to the gentoo world and conform to the gentoo way of handling the installations. -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Project, GLEP, or skip it?
Basically, it only controls the components that it installs, it doesn't do anything like package upgrades/user additions (outside of mysql users)/etc. Right. Just some config file tweaks to the various separate packages so they know about each other, but nothing the package itself installs outside of the web application. My ultimate goals is to generate ebuilds for eGroupWare and/or zimbra (I want a groupware solution for my home system and I like the look and feel/features that these offer). The GAMPP thing would just provide the foundation for those... -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] Project, GLEP, or skip it?
Dave Nebinger wrote: | My ultimate goals is to generate ebuilds for eGroupWare and/or zimbra (I | want a groupware solution for my home system and I like the look and | feel/features that these offer). Um, egroupware is already in portage. Thanks for spoiling my fun ;-) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] How to create SRC_URI from messed-up URL?
Hey, folks. I'm trying to write an ebuild, not my first, but definitely something that is relatively new to me. Anyways, I've got the following URL that pulls down the source package: http://www.fpdf.org/en/dl.php?v=153?f=tgz The file that gets downloaded is fpdf153.tgz. Well, that messed up dl.php?... stuff results in the file /usr/portage/distfiles/dl.php?v=153?f=tgz rather than the fpdf153.tgz that I need it to be called. So how do I 'trick' portage into downloading the file from the given link to the fpdf153.tgz file I want to have? Or am I stuck with the fetch restriction and have the end-user download the file manually? TIA, Dave -- gentoo-dev@gentoo.org mailing list
