[gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers
Luca Barbato wrote: Carsten Lohrke wrote: On Sunday 03 September 2006 16:36, Stefan Schweizer wrote: I am not adding stuff. I am fixing existing packages. And I am taking responsibility. How wonderful this sort of maintenance is you can read here: https://bugs.gentoo.org/show_bug.cgi?id=146626 Am I the only one who has a problem with this? Genstef PLEASE always contact the related herd before adding stuff. I am part of the kde herd, thanks. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On 9/7/06, Carsten Lohrke [EMAIL PROTECTED] wrote: How wonderful this sort of maintenance is you can read here: https://bugs.gentoo.org/show_bug.cgi?id=146626 Am I the only one who has a problem with this? No. And I'm sure I'm not the only one who has a problem with your comment in that bug either. Bugzilla isn't there for flaming other devs. There was a time when we used to suspend devs for doing that. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Am Donnerstag, 7. September 2006 11:11 schrieb Stuart Herbert: On 9/7/06, Carsten Lohrke [EMAIL PROTECTED] wrote: How wonderful this sort of maintenance is you can read here: https://bugs.gentoo.org/show_bug.cgi?id=146626 Am I the only one who has a problem with this? No. And I'm sure I'm not the only one who has a problem with your comment in that bug either. Bugzilla isn't there for flaming other devs. There was a time when we used to suspend devs for doing that. Sadly we don't suspend developers for extended history of QA violations. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thu, Sep 07, 2006 at 12:17:27PM +0200, Danny van Dyk wrote: Am Donnerstag, 7. September 2006 11:11 schrieb Stuart Herbert: On 9/7/06, Carsten Lohrke [EMAIL PROTECTED] wrote: How wonderful this sort of maintenance is you can read here: https://bugs.gentoo.org/show_bug.cgi?id=146626 Am I the only one who has a problem with this? No. And I'm sure I'm not the only one who has a problem with your comment in that bug either. Bugzilla isn't there for flaming other devs. There was a time when we used to suspend devs for doing that. Sadly we don't suspend developers for extended history of QA violations. Not true, unfortunately these problems seem to very rarely get communicated to devrel... -- Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Alec Warner wrote: If you can't work it out, you talk to your project lead. If THEY can't work it out, you talk to the ombudsman, and so forth. Everyone knows the policy and yet no one follows it. I don't want to see this thread continue; you know what you have to do.[1] [1] http://www.gentoo.org/proj/en/devrel/policy.xml Don't even have to go that way. It's far simpler: (quoting the devrel policy you linked to:) Issues not necessarily related to personal conflict, such as intentional or repeated policy breaches, malicious or abrasive behavior to users or developers, or similar developer-specific behavioral problems should be brought directly to Developer Relations via [EMAIL PROTECTED] These should be dealt with on a case-by-case basis by Developer Relations and may require disciplinary action. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Brian Harring wrote: On Wed, Sep 06, 2006 at 10:37:21PM -0400, Stephen P. Becker wrote: Carsten Lohrke wrote: On Sunday 03 September 2006 16:36, Stefan Schweizer wrote: I am not adding stuff. I am fixing existing packages. And I am taking responsibility. How wonderful this sort of maintenance is you can read here: https://bugs.gentoo.org/show_bug.cgi?id=146626 Am I the only one who has a problem with this? I find this not at all surprising considering that one of his recent mentees failed so many of the ebuild quiz questions so badly as to be outright denied (which is not at all the recruit's fault). In any case, if you don't appreciate Stefan taking responsibility for stuff which he has no business touching in the first place, you have every right to tell him to piss off. Maybe I'm just a moron (well, likely I am), but why are you two posting this shit on the dev ml? Conflict for a change, fine, carlo go revert it. Crazy notion, but it's a one minute revert, yes it's not your mess but it is your package and _your_ users, leaving your users hanging because you're trying to make genstef clean something up screws the users over. So what is wrong with making people accountable for stuff which *they* broke? The proper forum for crap like this is via taking it up with QA/devrel. Screaming about a change on the ml doesn't accomplish anything more then making you look like a jack ass trying to publically embarass someone you're pissed at; at least carlo has a reason, stephen you're just being an asshole. Yes, I am, because it pisses me off when people outright break things because they had no clue what they were doing. Furthermore, he did break mips with that change, so that makes it my business to whip out the cluestick. My previous email was intended to show that he doesn't seem to have any idea what he was doing. Further, Stephen shouldn't even know about a candidates failing, let alone go stating it on a public ml. Really nice one there; someone tries to help, deemed not yet skilled enough to have access to the tree, and you're bringing it up as a way to take potshots at genstef. Note that I have no idea who this person is, and that I also stated it is not their fault at all. Pretty much anybody is capable of learning the skills required to have access to the tree. Failing the ebuild quiz is a reflection on the mentor, which was my point. Further, you're taking a potshot at a dev candidate who via going through the process was at least *trying* to contribute, even if they didn't pass the quiz. No, I'm not, see above. I encourage this candidate to keep contributing, and to ask questions of anybody who can help. Carlo, go talk to devrel, stephen, go do your monthly mips stabling. Meanwhile spare us the idiocy, and do something productive. That's a funny statement, coming from you. Screaming on a ml won't solve the conflict, just makes the screamer look childish. That's an even funnier statement, coming from you. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thursday 07 September 2006 04:09, Carsten Lohrke wrote:
How wonderful this sort of maintenance is you can read here:
I'll try to overlook the reverted changes in kdelibs for bug fixes, the
improper ${ROOT} injected in my changes where it wasn't supposed to be, the
broken opengl on kdelibs checks that appeared last month, unhelpful comments
when trying to achieve something from the users, a bug lingering for an year
and a half because my solution wasn't good enough, and that was the solution
that now kde 3.5.4 implements, decisions against the interest and request of
all the users and developers, QA bugs opened without checking facts, GWN
articles sent without notes on [EMAIL PROTECTED] alias for what I can see ...
No, I'm not referring to Stefan. He's human and he did mistakes, but if
someone would be allowed to put them in public, that would be his lead (that
in this case is Caleb, not you), or the QA team.
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpwZ010qa0PD.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers
On Thursday 07 September 2006 07:58, Stefan Schweizer wrote: I am part of the kde herd, thanks. To my knowledge you have never asked to join the KDE team, nor did I see you helping tracking down KDE bug reports ever. Just adding yourself doesn't work. Carsten pgp7tjbj1KWLV.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Stephen P. Becker wrote: Brian Harring wrote: The proper forum for crap like this is via taking it up with QA/devrel. Screaming about a change on the ml doesn't accomplish anything more then making you look like a jack ass trying to publically embarass someone you're pissed at; at least carlo has a reason, stephen you're just being an asshole. Yes, I am, because it pisses me off when people outright break things because they had no clue what they were doing. Furthermore, he did break mips with that change, so that makes it my business to whip out the cluestick. My previous email was intended to show that he doesn't seem to have any idea what he was doing. I wonder how exactly genstef broke mips, 'cos mind you, he just reverted to what the ebuild was doing before Bug 114161 was fixed by hard-disabling of hspell [1]. Since mips doesn't have hspell keyworded, it wasn't affected by that bug before it's been fixed and it wasn't affected after the bug has been reintroduced now [2] (Additionally there shouldn't be any problem now except for one called automagic dependencies since the blocker for incompatible versions was there). [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/kde-base/kdelibs/kdelibs-3.5.0.ebuild?hideattic=0r1=1.4r2=1.5 [2] http://sources.gentoo.org/viewcvs.py/gentoo-x86/kde-base/kdelibs/kdelibs-3.5.4-r1.ebuild?r1=1.3r2=1.4 So, how exactly is this public bitching useful? -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thursday 07 September 2006 13:25, Diego 'Flameeyes' Pettenò wrote:
I'll try to overlook the reverted changes in kdelibs for bug fixes, the
improper ${ROOT} injected in my changes where it wasn't supposed to be, the
broken opengl on kdelibs checks that appeared last month, unhelpful
comments when trying to achieve something from the users, a bug lingering
for an year and a half because my solution wasn't good enough, and that was
the solution that now kde 3.5.4 implements, decisions against the interest
and request of all the users and developers, QA bugs opened without
checking facts, GWN articles sent without notes on [EMAIL PROTECTED] alias
for what I
can see ...
I do make mistakes too, yes. That I did revert your changes was a problem with
a local script - still - my mistake. No idea what you're referring to with
your unhelpful comments stanza as well as the bug lingering around. There
are a lot of bugs lingering around and I do not have a todo list tracking
them in a specific time frame. QA bug_s_? Regarding the GWN, you should have
gotten the email, in which I pointed out that it's time to remove KDE 3.4
from the tree.
Carsten
pgpiZ8MyhPkOO.pgp
Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thursday 07 September 2006 13:48, Jakub Moc wrote: I wonder how exactly genstef broke mips, 'cos mind you, he just reverted to what the ebuild was doing before Bug 114161 was fixed by hard-disabling of hspell [1]. Since mips doesn't have hspell keyworded, it wasn't affected by that bug before it's been fixed and it wasn't affected after the bug has been reintroduced now [2] (Additionally there shouldn't be any problem now except for one called automagic dependencies since the blocker for incompatible versions was there). You're right. It was very early in the morning, I saw the dependency not matching architectures, but wasn't aware that blocker dependencies are not taken into account with regards to tree breakage. So: Dear Stefan, I was wrong, you didn't break the tree. Please excuse that I did accuse you doing this. I regret not having verfied my position, before i filed the bug. Furthermore I'd like to add that, as blubb put it in an private email, my intention wasn't to put you down, but to shed light on the issue - apparently making myself a fool. One question remains: Is it needed/correct that Portage doesn't take blockers for architecture breakages into account? Such a line/prefix is easily changed and when someone - whatever the bad reason is - uses cvs commit, a real tree breakage is the cause. Carsten pgpLpkRTXiwfL.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Carsten Lohrke wrote: One question remains: Is it needed/correct that Portage doesn't take blockers for architecture breakages into account? Such a line/prefix is easily changed and when someone - whatever the bad reason is - uses cvs commit, a real tree breakage is the cause. The behaviour is correct. The depstring in question was !app-text/hunspell-1.0, which means that you can't have hunspell-1.0 and kdelibs installed on a system at the same time. Reason for this could e.g. be file collisions that got fixed in hunspell-1.0. If the depstring was !app-text/hunspell-1.0 app-text/hunspell, (same as =app-text/hunspell-1.0, just retarded) repoman would complain loudly. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Paid support
On Wed, 2006-09-06 at 23:50 -0400, Curtis Napier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: MD5 I'm in support of having a list of devs who want to do paid support. Anything that helps people eat is OK in my book. ;) On the other hand, I think we need to have the foundation run this past our lawyer(s) and make sure we have our i's dotted and out t's crossed. I would hate for something good like this to cause us problems down the road. Umm... The Foundation has zero to do with a contract between two third parties. Let me give you an example. I am currently doing paid Gentoo work for a company, who will remain nameless. I filled out paperwork with the company. My being a member of the Gentoo Foundation, a Trustee, or anything else, has exactly zero bearing on my being contracted, as an individual, to a company. I know christel is consulting with an accountant about adpot-a-dev, maybe she can throw this in as well? Do we have to do some special law-abiding dance to have sponsors listed on the site? What about advertisers? What Christel is researching is the tax law related to individuals receiving gifts. It has no bearing on the Foundation itself. Let's look at this another way. We have advertisers that sell Gentoo servers and Gentoo-based services. How exactly is this any different? Is it because they're developers? How does that matter? In the end, the contract is entirely between two third-party entities, the developer, and whomever contracts him. It isn't like the Foundation is offering services. It isn't. The individual developers are offering services. The Foundation is not any of our employer. We are not bound by any legal contract to the Foundation, and it has no ties to us. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Simon Stelling wrote: Carsten Lohrke wrote: One question remains: Is it needed/correct that Portage doesn't take blockers for architecture breakages into account? Such a line/prefix is easily changed and when someone - whatever the bad reason is - uses cvs commit, a real tree breakage is the cause. The behaviour is correct. The depstring in question was !app-text/hunspell-1.0, which means that you can't have hunspell-1.0 and kdelibs installed on a system at the same time. Reason for this could e.g. be file collisions that got fixed in hunspell-1.0. If the depstring was !app-text/hunspell-1.0 app-text/hunspell, (same as =app-text/hunspell-1.0, just retarded) repoman would complain loudly. Well, now the ebuild is broken even worse, since the blocker is gone [1] and hspell is still not disabled, so it will go kaboom when someone installs the stable version. [1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/kde-base/kdelibs/kdelibs-3.5.4-r1.ebuild?r1=1.4r2=1.5 carlo, you might want to revert it properly, instead of reverting only half of the previous commit you've been complaining about here. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Jakub Moc wrote: carlo, you might want to revert it properly, instead of reverting only half of the previous commit you've been complaining about here. Could you please take such stuff where it belongs next time? (To the bug, that is.) There's really no need to point out such things on -dev, because this is not a hey everybody, look, $dev did something stupid! list. It doesn't matter whether $dev is genstef or carlo or anybody else. The bitching ain't gonna stop if you just give back. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thu, 07 Sep 2006 16:42:11 +0200 Simon Stelling [EMAIL PROTECTED] wrote: Carsten Lohrke wrote: One question remains: Is it needed/correct that Portage doesn't take blockers for architecture breakages into account? Such a line/prefix is easily changed and when someone - whatever the bad reason is - uses cvs commit, a real tree breakage is the cause. The behaviour is correct. The depstring in question was !app-text/hunspell-1.0, which means that you can't have hunspell-1.0 and kdelibs installed on a system at the same time. Reason for this could e.g. be file collisions that got fixed in hunspell-1.0. If the depstring was !app-text/hunspell-1.0 app-text/hunspell, (same as =app-text/hunspell-1.0, just retarded) repoman would complain loudly. 1,$ s/hunspell/hspell/g :) To follow up in the use of a blocker - obviously blocking something like kdelibs, a core part of a major package suite, against a utility like hspell is less than ideal (to put it politely). This was not the case before - kdelibs and hspell could happily be installed on the same system, just kdelibs wouldn't make use of hspell. Adding the blocker unnecessarily restricts the system, and was the wrong thing to do. One point that illustrates this clearly, is that if kdelibs is blocked by hspell, a corollary is that hspell should block kdelibs. However since hspell wasn't blocking kdelibs, you would fail to install kdelibs until hspell was unmerged. Unmerging hspell would allow kdelibs to merge, then you could happily install hspell again and end up with a confused dep tree. Also, to my understanding, having configure automagically build support for hspell if it's available on the system is not the way we're supposed to handle such dependencies. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
What have we learnt now, Jakub? Keep it in the bug report. ;) Carsten pgpxG13G6keIP.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Carsten Lohrke wrote: On Thursday 07 September 2006 16:42, Simon Stelling wrote: !app-text/hunspell-1.0, which means that you can't have hunspell-1.0 and kdelibs installed on a system at the same time. This is clear to me. My point was, if there's a specific need to allow to not to break arch keywording this way. I'd find it more foolproof and consistent, if repoman would catch this and Portage would warn. Warn about what exactly? About blocker that $arch doesn't have even keyworded? I fail too see why this would be useful. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
[gentoo-dev] New git.eclass (Take #2)
Hi guys,
We are planning to add git.eclass as presented in bug #132383 (as
attachment 96300). I also attach it here in case someone wants to
comment parts of it.
Please raise your concerns if you have any.
- ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
# Copyright 1999-2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvs/overlay/eclass/git.eclass,v 1.7 2006/09/07 18:01:14 ferdy
Exp $
## --- #
# subversion.eclass author: Akinori Hattori [EMAIL PROTECTED]
# modified for git by Donnie Berkholz [EMAIL PROTECTED]
# improved by Fernando J. Pereda [EMAIL PROTECTED]
#
# The git eclass is written to fetch the software sources from
# git repositories like the subversion eclass.
#
#
# Description:
# If you use this eclass, the ${S} is ${WORKDIR}/${P}.
# It is necessary to define the EGIT_REPO_URI variable at least.
#
## --- #
inherit eutils
EGIT=git.eclass
EXPORT_FUNCTIONS src_unpack
HOMEPAGE=http://git.or.cz/;
DESCRIPTION=Based on the ${ECLASS} eclass
## -- add git in DEPEND
#
DEPEND==dev-util/git-1.4.0
## -- EGIT_STORE_DIR: git sources store directory
#
EGIT_STORE_DIR=${PORTAGE_ACTUAL_DISTDIR-${DISTDIR}}/git-src
## -- EGIT_FETCH_CMD: git clone command
#
EGIT_FETCH_CMD=git clone --bare
## -- EGIT_UPDATE_CMD: git fetch command
#
EGIT_UPDATE_CMD=git fetch -f -u
## -- EGIT_DIFFSTAT_CMD: Command to get diffstat output
#
EGIT_DIFFSTAT_CMD=git diff --stat
## -- EGIT_OPTIONS:
#
# the options passed to clone and fetch
#
: ${EGIT_OPTIONS:=}
## -- EGIT_REPO_URI: repository uri
#
# e.g. http://foo, git://bar
#
# supported protocols:
# http://
# https://
# git://
# git+ssh://
# rsync://
# ssh://
#
: ${EGIT_REPO_URI:=}
## -- EGIT_PROJECT: project name of your ebuild
#
# git eclass will check out the git repository like:
#
# ${EGIT_STORE_DIR}/${EGIT_PROJECT}/${EGIT_REPO_URI##*/}
#
# so if you define EGIT_REPO_URI as http://git.collab.net/repo/git or
# http://git.collab.net/repo/git. and PN is subversion-git.
# it will check out like:
#
# ${EGIT_STORE_DIR}/subversion
#
# default: ${PN/-git}.
#
: ${EGIT_PROJECT:=${PN/-git}}
## -- EGIT_BOOTSTRAP:
#
# bootstrap script or command like autogen.sh or etc..
#
: ${EGIT_BOOTSTRAP:=}
## -- EGIT_PATCHES:
#
# git eclass can apply pathces in git_bootstrap().
# you can use regexp in this valiable like *.diff or *.patch or etc.
# NOTE: this patches will apply before eval EGIT_BOOTSTRAP.
#
# the process of applying the patch is:
# 1. just epatch it, if the patch exists in the path.
# 2. scan it under FILESDIR and epatch it, if the patch exists in FILESDIR.
# 3. die.
#
: ${EGIT_PATCHES:=}
## -- EGIT_BRANCH:
#
# git eclass can fetch any branch in git_fetch().
# Defaults to 'master'
#
: ${EGIT_BRANCH:=master}
## -- EGIT_TREE:
#
# git eclass can checkout any tree.
# Defaults to EGIT_BRANCH.
#
: ${EGIT_TREE:=${EGIT_BRANCH}}
## - EGIT_REPACK:
#
# git eclass will repack objects to save disk space. However this can take a
# long time with VERY big repositories. If this is your case set:
# EGIT_REPACK=false
#
: ${EGIT_REPACK:=false}
## - EGIT_PRUNE:
#
# git eclass can prune the local clone. This is useful if upstream rewinds and
# rebases branches too often. If you don't want this to happen, set:
# EGIT_PRUNE=false
#
: ${EGIT_PRUNE:=false}
## -- git_fetch() - #
git_fetch() {
local EGIT_CLONE_DIR
# EGIT_REPO_URI is empty.
[[ -z ${EGIT_REPO_URI} ]] die ${EGIT}: EGIT_REPO_URI is empty.
# check for the protocol.
case ${EGIT_REPO_URI%%:*} in
git*|http|https|rsync|ssh)
;;
*)
die ${EGIT}: fetch from ${EGIT_REPO_URI%:*} is not
yet implemented.
;;
esac
if [[ ! -d ${EGIT_STORE_DIR} ]] ; then
debug-print ${FUNCNAME}: initial clone. creating git directory
addwrite /
mkdir -p ${EGIT_STORE_DIR} \
|| die ${EGIT}: can't mkdir ${EGIT_STORE_DIR}.
chmod -f o+rw ${EGIT_STORE_DIR} \
|| die ${EGIT}: can't chmod ${EGIT_STORE_DIR}.
export SANDBOX_WRITE=${SANDBOX_WRITE%%:/}
fi
cd -P ${EGIT_STORE_DIR} || die ${EGIT}: can't chdir to
${EGIT_STORE_DIR}
EGIT_STORE_DIR=${PWD}
# every time
addwrite ${EGIT_STORE_DIR}
[[ -z ${EGIT_REPO_URI##*/} ]] EGIT_REPO_URI=${EGIT_REPO_URI%/}
EGIT_CLONE_DIR=${EGIT_PROJECT}
debug-print ${FUNCNAME}: EGIT_OPTIONS = \${EGIT_OPTIONS}\
export GIT_DIR=${EGIT_CLONE_DIR}
if [[ ! -d ${EGIT_CLONE_DIR} ]] ; then
# first
[gentoo-dev] Re: [gentoo-core] Why you use Gentoo
On Thursday 07 September 2006 20:31, Chris White wrote: So, wondering why people use Gentoo. penis envy -mike pgpD0ckVyufBA.pgp Description: PGP signature
Re: [gentoo-dev] Why you use Gentoo
[user] I started using gentoo on dec. 2003. This was my first big step after one year SuSE Linux. I was very delight when I saw, that I was able to build my own system (I always wanted it) with my own requirements and in the way I wanted it to be built. I was very happy when I didn't saw the rcX.d hell and using rc-update instead was very easy and confortable. I quickly noted that Gentoo was easier to configure thougth you don't use something graphical and I use gentoo since then, because I didn't find anything better for me in the last 3 years :) Pablo Pablo Yánez Trujillo http://klingsor.informatik.uni-freiburg.de/ Chris White wrote: So, wondering why people use Gentoo. Put [dev] or something if you're an actual gentoo dev and [user] if you're a user. Doesn't need to be fancy, you can put community or something if that's all you want. All responses off list please. Thanks. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Why you use Gentoo
So, wondering why people use Gentoo. Put [dev] or something if you're an actual gentoo dev and [user] if you're a user. Doesn't need to be fancy, you can put community or something if that's all you want. All responses off list please. Thanks. -- Chris White Gentoo Developer A+ | MCSE Mobile: 999-999- Fax: 999-999- Skype: 999-999- Sattelite Phone: 999-999- Home Phone: 999-999- pgp2uijSCzrP7.pgp Description: PGP signature
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Zac Medico wrote:
If we implement the repo-level profile, it can have a
bashrc (much like profile.bashrc) that acts as a repo-level ebuild template
(like install-helpers.eclass). Actually, the repo-level profile already
exists
in the form of files such as ${PORTDIR}/profiles/{package.mask,arch.list},
though it doesn't yet have support for a bashrc (ebuild template).
Well, this is a nice idea, but not applicable to this problem. I had a
chat with Brian some days back, and the conclusion was that factoring
out the helper functions is basically an EAPI change. If we handle it
transparently, as in either using PORTAGE_AUTOLOAD_ECLASS or the
repo-level profile, we move parts of the EAPI out into the tree, which
is a bad idea because we are unable to support multiple versions. As the
EAPI needed for the ebuild is unknown when sourcing
install-helpers.eclass, we're actually forced into using that one and
only version, which is quite limiting.
So, the correct way to do it is to define an EAPI=1 that does no longer
include these helper functions and make the eclasses/ebuilds that use it
inherit the eclass manually. However, this will need to run through -dev
and I'm afraid the ebuild devs wouldn't like it at all :-/
--
Kind Regards,
Simon Stelling
Gentoo/AMD64 developer
--
gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: repo-level profile, we move parts of the EAPI out into the tree, which is a bad idea because we are unable to support multiple versions. As the EAPI needed for the ebuild is unknown when sourcing install-helpers.eclass, we're actually forced into using that one and only version, which is quite limiting. Well, if the metadata generation step is viewed as being separate from the rest, and the helpers aren't needed during that step, then it's possible to get the EAPI from the ebuild without the helpers being in the environment. Once the EAPI is known, the package manager can use that to determine what else (if anthing) needs to be added to the environment. Then you'd only need a way to tell the package manager which EAPI levels the functions in your install-helpers.eclass (or whatever) apply to. So, the correct way to do it is to define an EAPI=1 that does no longer include these helper functions and make the eclasses/ebuilds that use it inherit the eclass manually. However, this will need to run through -dev and I'm afraid the ebuild devs wouldn't like it at all :-/ They won't like it because it's expected that EAPI will provide the necessary information. Why should they have to inherit some special eclass if it's already implied by the EAPI that they've specified? Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAEl+/ejvha5XGaMRAhlSAKCjL1CJ5TZT1c+K6qcDMUIVIPMSLACfQ7M2 Whd0XSwhfbvUFPRdjjRyOXs= =dRI7 -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
On Thu, Sep 07, 2006 at 09:32:04AM -0700, Zac Medico wrote: Simon Stelling wrote: repo-level profile, we move parts of the EAPI out into the tree, which is a bad idea because we are unable to support multiple versions. As the EAPI needed for the ebuild is unknown when sourcing install-helpers.eclass, we're actually forced into using that one and only version, which is quite limiting. Well, if the metadata generation step is viewed as being separate from the rest, and the helpers aren't needed during that step, then it's possible to get the EAPI from the ebuild without the helpers being in the environment. Once the EAPI is known, the package manager can use that to determine what else (if anthing) needs to be added to the environment. Then you'd only need a way to tell the package manager which EAPI levels the functions in your install-helpers.eclass (or whatever) apply to. So, the correct way to do it is to define an EAPI=1 that does no longer include these helper functions and make the eclasses/ebuilds that use it inherit the eclass manually. However, this will need to run through -dev and I'm afraid the ebuild devs wouldn't like it at all :-/ They won't like it because it's expected that EAPI will provide the necessary information. Why should they have to inherit some special eclass if it's already implied by the EAPI that they've specified? Blubb left out the real kicker. Make this change, and it means that all overlays that can function as standalone, must bundle the eapi helpers themselves. This is ignoring the potential fun of an overlay that redefines an eapi locked function. Understand initial intention of wanting to make the scripts usable by all pkg managers (pushed this myself shortly after I became a portage dev), but the A) requirement of trying to keep helper functionality exactly in sync per tree, B) fragmentation this implicitly enables isn't good. ~harring pgpnCDHRvNPUM.pgp Description: PGP signature
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Zac Medico wrote: Well, if the metadata generation step is viewed as being separate from the rest, and the helpers aren't needed during that step, then it's possible to get the EAPI from the ebuild without the helpers being in the environment. Once the EAPI is known, the package manager can use that to determine what else (if anthing) needs to be added to the environment. Then you'd only need a way to tell the package manager which EAPI levels the functions in your install-helpers.eclass (or whatever) apply to. That is a workaround, but it makes a pretty hard link between the package manager and the functions, which is exactly what I am trying to cut through with the patch. Sure, it'd be a workaround, but just keeping them in the portage package until EAPI=1 is reached is one too... So, the correct way to do it is to define an EAPI=1 that does no longer include these helper functions and make the eclasses/ebuilds that use it inherit the eclass manually. However, this will need to run through -dev and I'm afraid the ebuild devs wouldn't like it at all :-/ They won't like it because it's expected that EAPI will provide the necessary information. Why should they have to inherit some special eclass if it's already implied by the EAPI that they've specified? It wouldn't be implied anymore. The install-helpers.eclass would actually be like every other eclass, like eutils fex. Actually, the reason they won't like it for will more likely be that it requires adding another eclass to the inherit line for ~15'000 ebuilds. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
Brian Harring wrote: Make this change, and it means that all overlays that can function as standalone, must bundle the eapi helpers themselves. Not true. I don't have to add eutils.eclass to my overlay to use epatch. Same goes for install-helpers.eclass. Standalone-repos will have that problem, but there is none yet to my knowledge. Sure, the problem persists for future repos, but it's not so much of a deal to copy an eclass once. Also, as it stands today, portage IS connected to gentoo-x86 through exactly these helpers. Upon the needs of the portage tree the functions in portage are changed, and this is simply not correct. This is ignoring the potential fun of an overlay that redefines an eapi locked function. eclasses in overlays that also exist in the tree are fun anyway. If people are messing with eutils, we tell them that it is entirely their responsibility if something breaks. Same goes for install-helpers.eclass. That being said, this problem already exists today: A custom eclass could simply define a function 'dosbin' and ebuild.sh would use that one. While it's a possible cause for breakage, it's not an argument against the move. A) requirement of trying to keep helper functionality exactly in sync per tree, If the helpers were a part of the EAPI those trees would have to verify that the EAPI portage provides matches their needs. Whether you sync against portage or the portage tree is not a big difference. B) fragmentation this implicitly enables isn't good. I agree here. -- Kind Regards, Simon Stelling Gentoo/AMD64 developer -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
On Thu, Sep 07, 2006 at 07:11:01PM +0200, Simon Stelling wrote: Brian Harring wrote: Make this change, and it means that all overlays that can function as standalone, must bundle the eapi helpers themselves. Standalone-repos will have that problem, but there is none yet to my knowledge. Sure, the problem persists for future repos, but it's not so much of a deal to copy an eclass once. Err... that's rather whacky. You're suggesting that a fix in an eapi class must be copied into *every* standalone repo; lets pretend for a moment that glep19 actually got somewhere, and subtree generation is possible. We'll pretend that a 1k admins use it to filter down to lamp/mailserver/whatever, point is, they generated their own stand alone. See where the we'll just copy it around starts to break down and go mildly apeshit? Also, as it stands today, portage IS connected to gentoo-x86 through exactly these helpers. Not really. Yes, portage knows the names of a few pkgs, but those pkgs are defined in the tree; in that respect, it's actually semi-sanely designed. Point there is that portage can be ran against a foreign tree without needing gentoo-x86; frankly, claiming otherwise is a bit daft and requires real world examples of where it breaks down. Upon the needs of the portage tree the functions in portage are changed, and this is simply not correct. This assertion doesn't make any sense; clarify please. This is ignoring the potential fun of an overlay that redefines an eapi locked function. eclasses in overlays that also exist in the tree are fun anyway. If people are messing with eutils, we tell them that it is entirely their responsibility if something breaks. Same goes for install-helpers.eclass. That being said, this problem already exists today: A custom eclass could simply define a function 'dosbin' and ebuild.sh would use that one. While it's a possible cause for breakage, it's not an argument against the move. There's a real difference however for the dosbin example; the eclass can wrap the functionality, not flat out replacing it. If it's a func, you're boned trying to get at the original, non-wrapped dosbin. Move it into the tree, and you enable people to accidentally cause mayhem on a repository wide scale via tinkering with bundled bits of the eapi format; folks can do it now, but this makes it *far* easier. A) requirement of trying to keep helper functionality exactly in sync per tree, If the helpers were a part of the EAPI those trees would have to verify that the EAPI portage provides matches their needs. The assertion there was that you would be stuck copying eclasses across all repos that exist; thus not addressing that assertion (should have been clearer, pardon). Thing I think you're missing here is that the ebuild format is not bound to gentoo-x86, nor is portage; thus trying to move intrinsic bits of the format into gentoo-x86 goes pretty hardcore against the goal of ever trying to sanely support N standalone repos due to the fact each repo now can now carry it's own potential offshoot of the eapi spec. ~harring pgpUQjEKtSjJO.pgp Description: PGP signature
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: Brian Harring wrote: B) fragmentation this implicitly enables isn't good. I agree here. Fragmentation is always a potential with free and open software. People can fork if they want or collaborate if they want. The choice is theirs. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAFgo/ejvha5XGaMRApacAKDKrMaNpx3sxtXA+Tk89W2pswEhUwCgwAdc vIDB7wnr8CYjzbtPJkYSLxc= =udnD -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
On Thu, Sep 07, 2006 at 10:22:38AM -0700, Zac Medico wrote: Simon Stelling wrote: Zac Medico wrote: Well, if the metadata generation step is viewed as being separate from the rest, and the helpers aren't needed during that step, then it's possible to get the EAPI from the ebuild without the helpers being in the environment. Once the EAPI is known, the package manager can use that to determine what else (if anthing) needs to be added to the environment. Then you'd only need a way to tell the package manager which EAPI levels the functions in your install-helpers.eclass (or whatever) apply to. That is a workaround, but it makes a pretty hard link between the package manager and the functions, which is exactly what I am trying to cut through with the patch. Sure, it'd be a workaround, but just keeping them in the portage package until EAPI=1 is reached is one too... It's not intended as a workaround and it shouldn't create a hard link between the package manager and the functions. The idea is that the tree should provide the necessary information for the package manager (portage or not) to determine how it should setup the environment for a given EAPI. The file containing the functions from install-helpers.eclass would have to be labeled in some way such that any package manager would know that those functions are required when EAPI=0 (and possible other EAPI levels). Just so we're clear... if gentoo-x86 wants to define their own base template all ebuilds in that repo use, that's fine. That's a different beast from moving the format definition into the tree though. Kind of curious if either of you have thought through the implications of moving this functionality into the tree for the vdb and binpkgs also (short version, even with ebds env handling its not going to be pretty for backwards compatibility). So, the correct way to do it is to define an EAPI=1 that does no longer include these helper functions and make the eclasses/ebuilds that use it inherit the eclass manually. However, this will need to run through -dev and I'm afraid the ebuild devs wouldn't like it at all :-/ They won't like it because it's expected that EAPI will provide the necessary information. Why should they have to inherit some special eclass if it's already implied by the EAPI that they've specified? It wouldn't be implied anymore. The install-helpers.eclass would actually be like every other eclass, like eutils fex. Fine, but the EAPI can still be used to imply that some other functions may or may not be available. Not really. Via moving parts of the format into gentoo-x86 it's implciitly setting it up such that whatever tree portage is working against now defines EAPI. Sounds whacky, but think it through; instead of trying to verify that 3 package managers are EAPI compliant, it's now dependant on the environment the tree defines, as such the tree can redefine the env without bumping the EAPI. Yes that's stupid to do, but moving the format into the tree enables it. Theres a reason no other package format has their actual format definitions (env setup in our case) shoved into the repo, and thats one of them. Actually, the reason they won't like it for will more likely be that it requires adding another eclass to the inherit line for ~15'000 ebuilds. See, that statement shows me that you've missed my point that EAPI can be used to imply which functions are implicitly available. It would be redundant to inherit an eclass containing functions that are already implied by the EAPI. Would require 24,600 (last count) mods to ebuilds to specify an elib import moreso; automagically trying to import an elib out of a repository is pretty much guranteed to not behave as desired (overlays again come to mind). Eclasses are designed as crappy oop; what this change means for eclasses/elibs is that instead of reusing functionality, functionality gets copy/pasted across repositories- not a good thing. ~harring pgpeOqGvPDsqS.pgp Description: PGP signature
Re: [gentoo-portage-dev] Moving ebuild-related where they belong
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Stelling wrote: Zac Medico wrote: Well, if the metadata generation step is viewed as being separate from the rest, and the helpers aren't needed during that step, then it's possible to get the EAPI from the ebuild without the helpers being in the environment. Once the EAPI is known, the package manager can use that to determine what else (if anthing) needs to be added to the environment. Then you'd only need a way to tell the package manager which EAPI levels the functions in your install-helpers.eclass (or whatever) apply to. That is a workaround, but it makes a pretty hard link between the package manager and the functions, which is exactly what I am trying to cut through with the patch. Sure, it'd be a workaround, but just keeping them in the portage package until EAPI=1 is reached is one too... It's not intended as a workaround and it shouldn't create a hard link between the package manager and the functions. The idea is that the tree should provide the necessary information for the package manager (portage or not) to determine how it should setup the environment for a given EAPI. The file containing the functions from install-helpers.eclass would have to be labeled in some way such that any package manager would know that those functions are required when EAPI=0 (and possible other EAPI levels). So, the correct way to do it is to define an EAPI=1 that does no longer include these helper functions and make the eclasses/ebuilds that use it inherit the eclass manually. However, this will need to run through -dev and I'm afraid the ebuild devs wouldn't like it at all :-/ They won't like it because it's expected that EAPI will provide the necessary information. Why should they have to inherit some special eclass if it's already implied by the EAPI that they've specified? It wouldn't be implied anymore. The install-helpers.eclass would actually be like every other eclass, like eutils fex. Fine, but the EAPI can still be used to imply that some other functions may or may not be available. Actually, the reason they won't like it for will more likely be that it requires adding another eclass to the inherit line for ~15'000 ebuilds. See, that statement shows me that you've missed my point that EAPI can be used to imply which functions are implicitly available. It would be redundant to inherit an eclass containing functions that are already implied by the EAPI. Zac -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFAFVc/ejvha5XGaMRAoKBAKDPB+W/e1BVL11NJYWX3NlRdizJUwCfYI4l dPKQMsEBZbs8qkBQBTeUVJU= =1IQL -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
