[gentoo-dev] Re: Re: RFC: New build types
Rémi Cardona wrote: Steve Long a écrit : First and foremost to give an environment wherein people can write their installation scripts using the language they are most comfortable with. If bash is not easy or straightforward enough for what you are trying to achieve, then I'd say the package is broken (ie, hand-made configure script, odd makefiles and whatnot). Better fix the package rather than rewriting ebuilds, make the world a better place. Heh, I'm fine with BASH believe it or not ;p nor do I have that much interest in the other scripting languages. I really just think it would make porting stuff to Gentoo a lot simpler for people who don't know Cbut do know their language of choice. Secondly efficiency; in the case of a pbuild it could be run from within the PM; for something like a jbuild it would use the native tools and existing libraries like ANT. For hbuild it would tie into Cabal. While these may be used already, we go from PM - BASH - LangX. I'm just saying give the _option_ to leave out the BASH bit when you have mature tools in langX. Care to back that up with any sort of figure or number? Is bash really the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash. But then again, I don't have any numbers to back that up either... I don't have figures, but my understanding is that one of the major factors in pkgcore's speed (which *is* impressive, even if the UI isn't quite there yet) is that it doesn't reload bash for every phase. (The whole ebuild daemon or ebd thing.) Honestly, maybe it could be a fun project, but I'm hardly convinced it would bring any sort of real advantage to the tree. In fact, having ebuilds in many languages would probably wreak havoc more than anything else. I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. It's something I'd imagine would be used only for packages developed in the relevant overlay, since that's where the people who know the language develop stuff (and they'd be the ones maintaining their version.) However, they'd need to know that, once they've signed off on it, the central tree will support it without further code changes. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Doug Goldstein wrote: All, This is a formal notice to everyone that OpenRC will be hitting the Gentoo tree sooner rather then later. I would like to see *ALL* arch teams give the current code a whirl on their systems, which is available via the layman module openrc. I would also like to give the docs team a chance to weigh in here and work with me on a migration guide as well as any necessary updates. The installation handbooks won't be changed until openrc baselayout-2 are stabilized and shipped with the stage3 tarballs. The same goes for our existing documentation. Until the new baselayout openrc are stabilized, made the default, *and* the old stuff is marked deprecated, don't expect it to show up in our other documents alongside baselayout-1 content. The last thing I want is to fork our documentation code samples, and duplicate everything with if you're on baselayout2 and/or openrc, do this instead instructions. That type of thing is a maintenance and usability headache. It's all or nothing. There can be only one! I'll be working on the migration guide with Cardoe (and possibly Roy, if we can tag-team him into submission). As much of a pain as migration will be, we'll definitely need a howto. Fun, fun. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: RFC: New build types
On Thu, Mar 20, 2008 at 06:51:13AM +, Steve Long wrote:
Rémi Cardona wrote:
Steve Long a écrit :
First and foremost to give an environment wherein people can write their
installation scripts using the language they are most comfortable with.
If bash is not easy or straightforward enough for what you are trying
to achieve, then I'd say the package is broken (ie, hand-made configure
script, odd makefiles and whatnot). Better fix the package rather than
rewriting ebuilds, make the world a better place.
Heh, I'm fine with BASH believe it or not ;p nor do I have that much
interest in the other scripting languages. I really just think it would
make porting stuff to Gentoo a lot simpler for people who don't know Cbut
do know their language of choice.
Secondly efficiency; in the case of a pbuild it could be run from within
the PM; for something like a jbuild it would use the native tools and
existing libraries like ANT. For hbuild it would tie into Cabal. While
these may be used already, we go from PM - BASH - LangX. I'm just
saying give the _option_ to leave out the BASH bit when you have mature
tools in langX.
Care to back that up with any sort of figure or number? Is bash really
the bottleneck? For 90% of the tree's ebuilds, I would _gcc_ is the
bottleneck. Then I'd bet a big lump on libtool. Not portage, not bash.
But then again, I don't have any numbers to back that up either...
I don't have figures, but my understanding is that one of the major factors
in pkgcore's speed (which *is* impressive, even if the UI isn't quite there
yet) is that it doesn't reload bash for every phase. (The whole
ebuild daemon or ebd thing.)
From a speed standpoint, EBD is only relevant if we're talking about
metadata regeneration-
http://gentooexperimental.org/~ferringb/blog/archives/2005-03.html#e2005-03-05T16_59_39.txt
Generally speaking, if you're sourcing to get metadata (regardless of
the underlying format), you're already screwed- cache exists for a
reason and is massively faster to rely on. Pkgcore's speed comes
about from careful design + a massive amount of JIT, EBD is faster
then the alternatives but that's *only* relevant for metadata
regeneration.
Finally, bear in mind we're talking about build phase here- even if
the pkg is just a straight unpack/copy, the bottleneck there isn't
going to be the bash bits for setting up the env, it's going to be the
unpack, copy, multiple QA checks that do repeated find's across ${D},
multiple file invocations for same file, etc. Seriously- profile a
merge sometime, even on non-compilations the large time slices are
never bash.
~brian
pgpXWz5ckvRsg.pgp
Description: PGP signature
[gentoo-dev] Re: bzr.eclass into Portage
Jorge Manuel B. S. Vicetto [EMAIL PROTECTED]: Petteri Räty wrote: Christian Faulhammer kirjoitti: in the Emacs overlay we imported the bzr.eclass from the xeffects overlay. In the near future Emacs development will switch from CVS to Bazaar and thus we need the new eclass in Portage to still provide our live ebuilds from app-editors/emacs-cvs. Question is now, who wrote it? Look at the SCM history in xeffects? Better yet, look at the desktop-effects overlay[1] and check the history of the eclass[2]. I could not find the xeffects overlay...ok, Jorge you seem to be the author. So is it ready to import to Portage? V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://www.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Remaining PMS todo list etc
On Wed, 19 Mar 2008 18:32:41 -0600 Ryan Hill [EMAIL PROTECTED] wrote: * 174335: Some ebuild use FEATURES. Can we get them to stop doing that, or do we have to force package managers to emulate it? We seriously need a PM-independent way of saying run the testsuite, run the testsuite with user privledges, and run the testsuite with root privledges if you can, otherwise forget it. Also required is the ability to make test failures non-fatal on a per-package basis, though this probably has nothing to do with the PMS. Sounds like you need to write your own src_test for these situations. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Remaining PMS todo list etc
Hi,
Ciaran McCreesh [EMAIL PROTECTED]:
On Wed, 19 Mar 2008 18:32:41 -0600
Ryan Hill [EMAIL PROTECTED] wrote:
* 174335: Some ebuild use FEATURES. Can we get them to stop doing
that, or do we have to force package managers to emulate it?
We seriously need a PM-independent way of saying run the
testsuite, run the testsuite with user privledges, and run the
testsuite with root privledges if you can, otherwise forget it.
Also required is the ability to make test failures non-fatal on a
per-package basis, though this probably has nothing to do with the
PMS.
Sounds like you need to write your own src_test for these situations.
if has userpriv ${FEATURES} ! has usersandbox ${FEATURES};then
make check-local || die test suite failed
else
ewarn Activate FEATURES=userpriv and deactivate \
FEATURES=usersandbox to run testsuite.
fi
^ That's mlocate, mysql also tests for FEATURES.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode
URL:http://www.faulhammer.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] Re: Remaining PMS todo list etc
On Thu, 20 Mar 2008 08:52:40 +0100
Christian Faulhammer [EMAIL PROTECTED] wrote:
if has userpriv ${FEATURES} ! has usersandbox ${FEATURES};then
make check-local || die test suite failed
else
ewarn Activate FEATURES=userpriv and deactivate \
FEATURES=usersandbox to run testsuite.
fi
^ That's mlocate, mysql also tests for FEATURES.
Yeah, and that's a strong case for why we don't want FEATURES used in
ebuilds -- the ebuild is copying package manager internal logic that
has changed in the past and may well change in the future.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
[gentoo-dev] Re: [RFC] Major changes to the Gnome2 Eclasses
Rémi Cardona wrote:
Now, basically, if the portage metadata or QA people could tell me a way
to figure *all* the ebuilds that inherit gnome2 *and* have a
pkg_preinst() function somewhere (either in the ebuild or in an eclass
somewhere) I'd really appreciate it, as I really don't want to read
through thousands of ebuilds to figure it out.
PORTDIR=$(portageq envvar PORTDIR)
# Get eclasses which export pkg_preinst()
preEclass=($(qgrep -EeCl 'EXPORT_FUNCTIONS.*pkg_preinst'))
# We don't want the eclass/ prefix
preEclass=([EMAIL PROTECTED]/#eclass\/})
# or the .eclass suffix
preEclass=([EMAIL PROTECTED]/%.eclass})
# make a regex for an ebuild with a pkg_preinst, or inheriting one
# of the eclasses
IFS='|'
search=^[[:space:]]*(pkg_preinst\(\)|inherit .*(${preEclass[*]}))
unset IFS
# find matching ebuilds
while read ebuild; do grep -El $search $PORTDIR/$ebuild
done (qgrep -Cel 'inherit .*gnome2')
# just the packages (would need to count dirs in PORTDIR and amend awk
# accordingly to use the env var)
while read ebuild; do grep -El $search /usr/portage/$ebuild
done (qgrep -Cel 'inherit .*gnome2') | \
awk -F/ '!s[$4/$5]++ { print $4/$5 }'
If you wanted to do something with the files, you'd use:
grep -Eq $search $PORTDIR/$ebuild files+=($PORTDIR/$ebuild)
in the loop, and then access the [EMAIL PROTECTED] array after. You can't do
that with a pipe, see http://wooledge.org/mywiki/BashFAQ/024
--
gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Re: RFC: New build types
Steve Long kirjoitti: I don't see how it would wreak more havoc than a novice using, eg ANT from Java which s/he is comfortable with, and then further having to learn BASH peculiarities when things don't fit with the eclass. But yeah, the fun is what attracts me to the idea more than anything. Java needs to be compiled and ant is meant to be started from the command line. Of course you can invoke the main method from Java but what's the point? Developers have to be able to review ebuilds and having all those different languages would make the job harder and I don't really see benefits. If you need something bit more complex done in an ebuild, you can always use something like inline python. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
On Thursday 20 March 2008 06:59:24 Josh Saddler wrote: I'll be working on the migration guide with Cardoe (and possibly Roy, if we can tag-team him into submission). As much of a pain as migration will be, we'll definitely need a howto. Fun, fun. I already provide documentation with commands in example config files and man pages that cover nearly every aspect on OpenRC and all it's commands. The nice thing about not being a Gentoo dev means I don't feel the urge to write a migration how to. However, here's a really good primer. 1) Install OpenRC 2) Review all updated files in /etc/conf.d/ and /etc/rc.conf [1] [2] 3) If using a volume such as LVM, you'll find an appropriate init script in /etc/init.d that you need to add to the boot runlevel. 4) Carry on as normal [3] Thanks Roy [1] The case of variable names has been changed from UPPER to lower. This is for a few reasons (removes confusion vs environment vars, looks nicer). However, *existing* UPPER case vars should still work. [2] Paludis users will need to ensure that the init scripts checkfs and checkroot are removed. I don't care whose bug this is, but neither side wants to fix it. [3] A reboot is currently needed as for some reason state data isn't migrated from baselayout-1. This is probably due to OpenRC being split from baselayout and the code is pretty much the same here. Maybe some plucky Gentoo ebuild dev can step up and fix it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [RFC] net-libs/xulrunner-1.9 slotting or not?
FYI this will be finally slotted. Turns out it couldn't be slotted because a patch we used that simulated xulrunner-1.8 pkgconfig files. But since 99% of the stuff that depends on xulrunner-1.8 won't work with xulrunner-1.9, those packages should be fixed by upstream, and they should look for the correct pkgconfig files. Sorry about the mess :) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
Roy Marples wrote: On Thursday 20 March 2008 06:59:24 Josh Saddler wrote: I'll be working on the migration guide with Cardoe (and possibly Roy, if we can tag-team him into submission). As much of a pain as migration will be, we'll definitely need a howto. Fun, fun. I already provide documentation with commands in example config files and man pages that cover nearly every aspect on OpenRC and all it's commands. The nice thing about not being a Gentoo dev means I don't feel the urge to write a migration how to. However, here's a really good primer. 1) Install OpenRC 2) Review all updated files in /etc/conf.d/ and /etc/rc.conf [1] [2] 3) If using a volume such as LVM, you'll find an appropriate init script in /etc/init.d that you need to add to the boot runlevel. 4) Carry on as normal [3] Thanks Roy [1] The case of variable names has been changed from UPPER to lower. This is for a few reasons (removes confusion vs environment vars, looks nicer). However, *existing* UPPER case vars should still work. [2] Paludis users will need to ensure that the init scripts checkfs and checkroot are removed. I don't care whose bug this is, but neither side wants to fix it. [3] A reboot is currently needed as for some reason state data isn't migrated from baselayout-1. This is probably due to OpenRC being split from baselayout and the code is pretty much the same here. Maybe some plucky Gentoo ebuild dev can step up and fix it. You missed the whole /etc/modules.autoload.d/* - /etc/conf.d/modules but I already discussed that with Josh for the guide. ;) -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] OpenRC baselayout-2 meets Gentoo
2008/3/20, Doug Goldstein [EMAIL PROTECTED]: Roy Marples wrote: On Thursday 20 March 2008 06:59:24 Josh Saddler wrote: I'll be working on the migration guide with Cardoe (and possibly Roy, if we can tag-team him into submission). As much of a pain as migration will be, we'll definitely need a howto. Fun, fun. I already provide documentation with commands in example config files and man pages that cover nearly every aspect on OpenRC and all it's commands. The nice thing about not being a Gentoo dev means I don't feel the urge to write a migration how to. However, here's a really good primer. 1) Install OpenRC 2) Review all updated files in /etc/conf.d/ and /etc/rc.conf [1] [2] 3) If using a volume such as LVM, you'll find an appropriate init script in /etc/init.d that you need to add to the boot runlevel. 4) Carry on as normal [3] Thanks Roy [1] The case of variable names has been changed from UPPER to lower. This is for a few reasons (removes confusion vs environment vars, looks nicer). However, *existing* UPPER case vars should still work. [2] Paludis users will need to ensure that the init scripts checkfs and checkroot are removed. I don't care whose bug this is, but neither side wants to fix it. [3] A reboot is currently needed as for some reason state data isn't migrated from baselayout-1. This is probably due to OpenRC being split from baselayout and the code is pretty much the same here. Maybe some plucky Gentoo ebuild dev can step up and fix it. You missed the whole /etc/modules.autoload.d/* - /etc/conf.d/modules but I already discussed that with Josh for the guide. ;) -- gentoo-dev@lists.gentoo.org mailing list Maybe the XSESSION variable disappearing from /etc/rc.conf and the changed settings in /etc/conf.d/clock are worth consideration too! Regards, Daniel -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-core] OpenRC baselayout-2 meets Gentoo
On Thursday 20 March 2008, Doug Goldstein wrote: That being said, I will be the primary point of contact on the transition to OpenRC appearing in ~arch (along with it's associated baselayout-2.0.0 ebuild). Any and all grievances, concerns, suggestions and comments can and should be routed to me via the associated Bugzilla entries or e-mail. everything should be handled via [EMAIL PROTECTED] like normal. direct assignment to individuals wrongly cuts herds out of the loop as to whats going on. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: Remaining PMS todo list etc
Marius Mauch wrote: On Wed, 19 Mar 2008 18:32:41 -0600 Ryan Hill [EMAIL PROTECTED] wrote: We seriously need a PM-independent way of saying run the testsuite, run the testsuite with user privledges, and run the testsuite with root privledges if you can, otherwise forget it. Also required is the ability to make test failures non-fatal on a per-package basis, though this probably has nothing to do with the PMS. How about just checking EUID == 0 in src_test and skip the tests (with a ewarn message) if it doesn't match your needs? I thought I remembered someone raising a stink about checking permissions being a race condition because the condition can change between the checking and performing the action. Maybe that was only about write permissions... If checking EUID is an acceptable method, it should be relatively simple to write an eclass to handle the common cases and have ebuilds use that instead of checking $FEATURES (which i do think is a bug). -- fonts, gcc-porting, by design, by neglect mips, treecleaner,for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: OpenPGP digital signature
[gentoo-dev] webmin maintainership
I've taken over maintainership of webmin, usermin, and already assigned the bugs to me. Thanks to armin76 for recent security bumps. That's all. Steve -- gentoo-dev@lists.gentoo.org mailing list
