Re: [gentoo-dev] [rfc] repo_name/layman-global.txt overlay name mismatches
On 15:53 Sun 12 Jul , Sebastian Pipping wrote: The output produces line like MISMATCH gentoo-china (layman-global) versus china (repo_name) I have just changed gentoo-china overlay's repo_name to gentoo-china. -- Zhang, Le Gentoo/Loongson Developer http://zhangle.is-a-geek.org 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 pgpohUiov0DfE.pgp Description: PGP signature
Re: [gentoo-dev] 2009 Council Elections
On 11:41 Fri 26 Jun , Richard Freeman wrote: However, those who have questioned the wisdom of cirianm as a proxy do have a point. Technical knowledge alone is not the critiera of a council member. One needs to be able to build consensus - not that we need to be strangled by consensus, but we can't afford to rule by edict either. I'm happy that everybody seems to be getting along better, but council leadership requires maturity, and maturity is reflected by how people behave over the long haul. Cirianm's best bet to get accepted by the gentoo devs is to just start working with them - if he works positively with enough different people (especially those with different opinions) he'll have no trouble gaining their support. However, that is something that can take months or years - not weeks to a few months. I might be willing to give him the benefit of the doubt, but that is just me. I'm not so sure I'd be eager to have him be a proxy if I were on the council. Sure, I'd be happy to yield my floor time to him if I thought he had something worth listening to, but a proxy is more than just a platform to talk - any mailing list subscriber already has that. Agreed. -- Zhang, Le Gentoo/Loongson Developer http://zhangle.is-a-geek.org 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 pgpDo0wS2P2Fi.pgp Description: PGP signature
[gentoo-portage-dev] a little patch related to arrow in SRC_URI
Hi, all,
It seems that arrow in SRC_URI needs a little patch in order to work.
Please check the attachment.
Thanks!
Zhang, Le
Index: pym/portage/__init__.py
===
--- pym/portage/__init__.py (revision 12119)
+++ pym/portage/__init__.py (working copy)
@@ -3991,7 +3991,7 @@
variables = {
DISTDIR:
mysettings[DISTDIR],
URI: loc,
- FILE:myfile
+ FILE:myfile_path
}
import shlex, StringIO
lexer =
shlex.shlex(StringIO.StringIO(locfetch), posix=True)
Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
On 14:18 Wed 06 Aug , Robin H. Johnson wrote: Getting the bot out there - If you would like to have the new bot in your #gentoo-* channel, would each channel founder/leader please respond to this thread, stating the channel name, and that they are the contact for any problems/troubles. #gentoo-cn Thanks Robin! Zhang Le
Re: [gentoo-portage-dev] A seemingly bug found when emerging @preserved-rebuild
On 21:05 Tue 01 Jul , Marius Mauch wrote: On Wed, 2 Jul 2008 02:41:14 +0800 Zhang Le [EMAIL PROTECTED] wrote: Is this a bug? or did I miss something here? Thanks for your time! The 'bug' here is that USE=multislot shouldn't exist. People using it should be able to deal with resulting breakages on their own Marius, thanks for this info and sorry for the noise. Maybe I should ask vapier the purpose of multislot. Zhang Le -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-portage-dev] A seemingly bug found when emerging @preserved-rebuild
On 21:05 Tue 01 Jul , Marius Mauch wrote: On Wed, 2 Jul 2008 02:41:14 +0800 Zhang Le [EMAIL PROTECTED] wrote: Is this a bug? or did I miss something here? Thanks for your time! The 'bug' here is that USE=multislot shouldn't exist. People using it should be able to deal with resulting breakages on their own Sorry, forget to mention: I solved this by manually modifying /var/db/pkg/sys-devel/gcc-x.y.z/SLOT directly. Hope this would be useful to others. Zhang Le -- gentoo-portage-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] How can I get the ebuild I wrote noticed by someone(maybe developer)?
On 23:26 Sat 05 Apr , Shaochun Wang wrote: Hi all: I wrote an ebuild games-misc/llk_linux-2.3 and uploaded it on bugzilla of gentoo on Mar 2007. After one year, this ebuild still just stays on bugzilla. I don't know whether someone used it or not. How can I found this type of information from bugzilla? I can put it in gentoo-china overlay, if you like. I think llk(lian lian kan) is not so popular outside China. It is understandable that none has shown interest in maintaining it. I'll try to finish ebuild quiz soon, so that I can add it to tree. Or you can become a dev and maintain this package yourself. Zhang Le Simplifid Chinese Doc/GMN Lead -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On 21:07 Wed 05 Mar , Santiago M. Mola wrote: On Wed, Mar 5, 2008 at 6:11 PM, Anant Narayanan [EMAIL PROTECTED] wrote: Some of you may argue that we already have proxy-maintainers. That's a great idea, all I'm asking for is for us to formalize the position. Giving a proxy-maintainer an official acknowledgement will definitely attract more users to contribute. IMO the problem with proxy-maintainers is that most users don't know such a thing exists. I bet some users could proxy-maintain a lot of orphaned packages if we potentiate proxy-maint. ++ IMO giving proxy-maintainer due credit and publicity, meaning make it a formal position, could solve the very problem Anant's proposal intended to solve. Zhang Le -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Thomas Pani wrote: Ciaran McCreesh wrote: On Fri, 21 Dec 2007 10:59:14 +0800 Zhang Le [EMAIL PROTECTED] wrote: And file extension like welcome.html.fr is quite self-explanatory. But an total outsider has no chance to deduce what the 1 in ebuild-1 means on his own. A total outsider doesn't need to know. The only people who will be dealing with .ebuild-* files are developers and power users. And you are trying to set an even higher barrier for people to reach that level. How many power users or devs do actually care/know what EAPI=1 means? http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt We should've made it appear in our front page or GWN. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Piotr Jaroszyński wrote: On Thursday 20 of December 2007 19:29:22 Zhang Le wrote: So please make those people understand, so they can comment usefully. Are we in the elementary school or something? This is really getting ridiculous. IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Bo Ørsted Andresen wrote: On Friday 21 December 2007 05:25:00 Zhang Le wrote: The question is really simple. Whether we should have two different place to define EAPI? We need two places because it wasn't implemented properly in the first place and we want to retain backwards compatibility for people who use old versions of portage. The whole point is to keep a sane upgrade path available indefinitely for people with old versions of portage. Thanks, now I understand this. However, in the first draft the majority part of the glep talks about how to decide EAPI value, which could make others misunderstand the real point behind it. It should be made more clear in the first place, fortunately peper has done that in the new draft of glep-55. BTW, thanks to peper for drafting this glep! However, this doesn't mean I have wholehearted accept this glep. This just means if we ever decided we need .ebuild-1 suffix, then surely we need such an agreement on how to decide EAPI value. Proponents are trying to prove that we should at least need it be in file name. We need the file name to change because otherwise old versions of portage will try to source the ebuild when the EAPI is unknown. This either blocks new useful features that will make old versions of portage fail to source them or results in more bug reports with zillions of dupes (like the bugs in [1]) because people with ancient versions of portage feel the need to report bug reports when portage fails after a sync. I think we can educate our user about what is really going on and how to sovle this problem (upgrade PM), by GWN/NEWs on front page/IRC topics/Forums stick threads and so no. At the very least it means waiting for a year between a release with a version of portage that supports this and an EAPI that takes advantage of it. So now that leaves the question whether we want to change the file name once and hope that we won't need to do it again or whether we want to use the technically more flexible way where the file name changes whenever a new EAPI gets agreed upon. This is another thing needed to be sorted out before we decide to take this suffix approach. Or alternatively whether we want to limit ourselves by using an inferior solution that limits or delays progress considerably and results in more bug reports with zillions of dupes... Honestly I really don't think our progress would be delayed in any way. The argument to which other approach would delay our progress is that we need to wait people to upgrade their PM. (If this assertion is wrong please ignore th e following sentence) But upgrading PM is very easy, we can use all the channels we have to inform user to upgrade their PM. And people are themselves doing this all the time. BTW, if we decide to use .ebuild-1, will we provide a ebuild file for each EAPI for a specific version of software? I guess probably not, coz that is a huge waste of time and energy. If this is the case, then presumably we only provide new EAPI ebuild for new versions. If a user want to use the new version, he *has* to upgrade his PM so that it could support the new EAPI. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: As long as there is an agreement in any given point of time, it is OK. Such as, put your EAPI definition on the first line of your ebuild, like EAPI=value No good for package managers written before the agreement. Why not force user to upgrade their PM? After all, upgrading is part of our normal life. Now I will try read portage to understand how the metadata generation process works and try to make a doc of it. So before that, I will probably be not so responsive. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Sat, 22 Dec 2007 00:59:53 + Steve Long [EMAIL PROTECTED] wrote: It's so that the ebuild's EAPI can be extracted. The way things are currently, there is no way to get an ebuild's EAPI without already knowing its EAPI. Like I said, it's trivial to extract a line from the ebuild without sourcing. You know it is, and so does everyone else. Note *the way things are currently*. If you think this is untrue, provide an algorithm that will correctly give the EAPI of any current or future ebuild given that ebuild's filename (hint: you can't). Simple. Whatever you'd like to have in the suffix, we can put it on the first line of the ebuild. Just go and get it, and that's the EAPI. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Sat, 22 Dec 2007 16:09:27 +0800 Zhang Le [EMAIL PROTECTED] wrote: IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. It's open to anyone who cares about it and is knowledgeable enough to provide informed commentary. Anything else is just noise. At least not to tell others to be quiet. It is a discussion after all. We can let them become knowledgeable, at least we should try. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Still I think we should just postpone this discussion and get a 2008.0 out. And postpone until some doc is out. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Sat, 22 Dec 2007 17:01:23 +0800 Zhang Le [EMAIL PROTECTED] wrote: Luca Barbato wrote: Still I think we should just postpone this discussion and get a 2008.0 out. And postpone until some doc is out. There is absolutely no need for such a doc. You don't need to understand every last detail of why things are the way they are in order to use the new format. The only people who need to understand the technicalities are those writing the package managers. And what if that is my real intent? No, just joking, but I am curious. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Bo Ørsted Andresen wrote: On Thursday 20 December 2007 20:01:55 Zhang Le wrote: IMO, we can not have more than two EAPI's simultaneously. That defeats the whole purpose of having EAPIs. Which is to keep a sane upgrade path... Upgrading happens between two versions. When a new version comes out, we should educate developers about it and encourage them to convert their ebuilds to use new EAPI. When this finished, we can start upgrading to a more new version of EAPI. IMHO, that should be the right way to go. However, I think there is still devs don't know about EAPI-1. If we allow multiple EAPI's to co-exist, do we need a upper limit on that number? Or as many as someone likes? then our tree IMO will become a total mess. People will not remember clearly differences between so many EAPI's. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Sat, 22 Dec 2007 16:55:50 +0800 Zhang Le [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Note *the way things are currently*. If you think this is untrue, provide an algorithm that will correctly give the EAPI of any current or future ebuild given that ebuild's filename (hint: you can't). Simple. Whatever you'd like to have in the suffix, we can put it on the first line of the ebuild. Just go and get it, and that's the EAPI. Your algorithm: Does not work for existing ebuilds that have implicit EAPI 0. That's obvious. If no suffix, just treat it as EAPI 0. I thought I don't need to say this explicitly. Does not work for existing ebuilds that have explicit EAPI. Even better, since we don't need suffix in the first place. Just define it in ebuild. Does not work for future ebuilds. If defined in file does not work, then define in file name doesn't either. They are interchangeable. All could be get before sourcing. I know you'd say people will use all syntaxes to define. But how many are there? EAPI=1, EAPI=1 these are the two ways currently used in tree. A simple qgrep can show that. Two steps can guarantee you get the value 1. strip 2. get the value -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Sat, 22 Dec 2007 16:49:10 +0800 Zhang Le [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: As long as there is an agreement in any given point of time, it is OK. Such as, put your EAPI definition on the first line of your ebuild, like EAPI=value No good for package managers written before the agreement. Why not force user to upgrade their PM? That's a) exactly what we're trying to avoid with EAPIs, b) no good because there isn't a sane way of forcing a package manager upgrade and c) another one of those wait a year until we can use anything things. People have to upgrade even if we adopt the suffix approach, as like I just said. We don't actually need to force people upgrade their PM, if they need new version of software whose ebuild is in new EAPI, they will want to upgrade their PM themselves, either way. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 12:27:31 +0800 Zhang Le [EMAIL PROTECTED] wrote: But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's. What? All two of them that you need to know about, where the second one is the first one with three new features? Sorry, I made you confused. I was not talking about now, I am talking about the consequences of this glep. At least we already have a EAPI 2 tracker in our bugzilla. I am afraid we lose the control of EAPI development. or maybe I just over reacted, but you get my point. We need to make a formal development model and development cycle of EAPI. We need to make sure all developers and as many users as possible to know it. I have just created a page of EAPI on wikipedia, let's improve it together. http://en.wikipedia.org/wiki/EAPI -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Zhang Le wrote: I have just created a page of EAPI on wikipedia, let's improve it together. http://en.wikipedia.org/wiki/EAPI And later convert it to guidexml and put it on gentoo.org, of course. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: On Sat, Dec 22, 2007 at 04:58:28PM +0800, Zhang Le wrote: Ciaran McCreesh wrote: On Sat, 22 Dec 2007 16:09:27 +0800 Zhang Le [EMAIL PROTECTED] wrote: IMHO, what is more ridiculous is keeping ask other to be quiet in a discussion which is supposed to be open to everyone who cares about it. It's open to anyone who cares about it and is knowledgeable enough to provide informed commentary. Anything else is just noise. At least not to tell others to be quiet. It is a discussion after all. We can let them become knowledgeable, at least we should try. Heh... unfortunately this is gentoo and this behaviour is tolerated. Try to go with this same thing to the lkml[*1*]. Ask them to teach you C so you can contribute with your opinion to every single patch and design decision that is made. Then tell them they should teach you stuff about OS design because you _are_entitled_ an opinion, then [then, sane people see how this approach gets silly] I have mailed my patch to LKML. So I know the situation there. Linux kernel community has a kernelnewbie mailing list. But we don't have one. We don't even have enough docs to educate our future potential package manager maintainer. Note I am not blaming anyone there. Let's start from ourselves. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Richard Freeman wrote: Fernando J. Pereda wrote: On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: All could be get before sourcing. I know you'd say people will use all syntaxes to define. But how many are there? EAPI=1, EAPI=1 these are the two ways currently used in tree. A simple qgrep can show that. Two steps can guarantee you get the value 1. strip 2. get the value And then you are stuck FOREVER into defining EAPI as a variable. And with the proposed GLEP you are stuck FOREVER into defining EAPI as part of the filename. What's the difference? Ditto. You clearly haven't read anything on this thread. I suggest you go and do so before making a fool of yourself again. Please. If I haven't read previous posts, then I would not participate in this discussion in the first place. I have read a lot and feel like I should say something so that my previous reading are not totally wasted. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: On Sat, Dec 22, 2007 at 06:01:04PM +0800, Zhang Le wrote: Your algorithm: Does not work for existing ebuilds that have implicit EAPI 0. That's obvious. If no suffix, just treat it as EAPI 0. I thought I don't need to say this explicitly. '# Copyright 1999-2007 Gentoo Foundation' Is that an EAPI? of course it is not, are you going to hardcode every possible ebuild header in your stupid _hack_ ? We are doing this in almost every file format we are using. ELF(exacutable and linkable format) JPEG GIF ... If this is stupidity, then we are all stupid. Does not work for future ebuilds. If defined in file does not work, then define in file name doesn't either. They are interchangeable. No, they are not. Why not? Please always add a reason, which is helpful to the discussion. Thanks! -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Fernando J. Pereda wrote: Their docs are usually the source. And files under Documentation And they have a policy which requires them to write a doc for any new feature/functionality to be accepted -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Thu, 20 Dec 2007 09:43:59 + (UTC) Duncan [EMAIL PROTECTED] wrote: Because a) a future EAPI might want to change EAPI into a function rather than a variable, b) there are a zillion ways of setting a variable in bash and people already use all of them and c) introducing new weird format requirements is silly. So you're proposing putting the function into the filename? No, I'm saying that the data goes into the filename. then why not let it go into the file content? if data goes into file content, then function is not needed you are contradicting with yourself here. As he stated, the only credible reason (so far given) bash must be used to parse EAPI is if it's dynamic, say a function, and that won't work so well in a filename either. No no no. Bash is the only thing that can parse bash. Ebuilds are bash. Getting the first line of a file using whatever language is just a piece of cake. And I don't see why setting a rule on the syntax of EAPI definition is so silly. How many ways to define a variable in bash can you think of? Is it that hard to come up with a way to normalized the definition? Just like charset code normalization, e.g. from UTF-8 to utf8? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: You need to understand the metadata generation process to understand why the package manger has to assume a particular EAPI when generating the metadata. There are many people watching this thread all over the world I think. Not all of them understand the process. And you are keeping scolding people for not understanding the process. So, why not introduce the process a little bit? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... So please make those people understand, so they can comment usefully. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: And again, you show that you don't understand what's going on. EAPI is only specified once except where developers screw up. The GLEP merely moves the EAPI to being set *before* the metadata is generated, which removes all the restrictions that having EAPI as part of the ebuild's content imposes. So, you are saying if developers screw up, then the EAPI could be specified twice, namely in file name and in file content. But why should we tolerate that? And as I have said before, I don't see why having EAPI as part of the ebuild's content has any restrictions. You can extrace the definition from file content no matter how it is defined using whatever way you like. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Jim Ramsay wrote: Luca Barbato [EMAIL PROTECTED] wrote: How would it be different than having EAPI=string put in a defined position of the file? It's not - It is just defining that position to be in the name of the file instead of the contents :) Exactly. And this way is not elegant. File name is used to uniquely identify a file in a system, not to decide how the content of the file should be interpreted. Never ever seen a file type extension with a version number. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Luca Barbato wrote: Before spending even more time on it, could we try to come up with a definition of what eapi is, which problem is trying to solve and put that somewhere that isn't a long thread or an handful of threads scattered across mailing lists. I think we also need to know: How many EAPI's do we have now? Where is the detailed definition of those EAPI's? How can we produce a new EAPI? IMO, we can not have more than two EAPI's simultaneously. The only situation in which we can have two EAPI is in the transition period of those two EAPI's. And we should set a time constraint on the transition. Other than that we can only have one working EAPI which all package managers conforms to. Otherwise, I think we may be risking forking the portage tree. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 02:52:16 +0800 Zhang Le [EMAIL PROTECTED] wrote: Exactly. And this way is not elegant. File name is used to uniquely identify a file in a system, not to decide how the content of the file should be interpreted. Never ever seen a file type extension with a version number. http://httpd.apache.org/docs/2.0/mod/mod_mime.html You might find that interesting reading. Thanks. Actually coldwind also reminded me of mp3. However, it is only 3 chars. ebuild-1 is way too long, which is what I think not elegant. And file extension like welcome.html.fr is quite self-explanatory. But an total outsider has no chance to deduce what the 1 in ebuild-1 means on his own. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Thu, 20 Dec 2007 14:54:10 +0100 Denis Dupeyron [EMAIL PROTECTED] wrote: On Dec 20, 2007 12:12 PM, Ciaran McCreesh [EMAIL PROTECTED] wrote: I'm guessing there're lots of people moaning because they think they understand filenames and can therefore comment. Unfortunately, most of those people don't understand the metadata generation process, and therefore can't comment usefully... Stop guessing, then. You're way off. You apparently do not understand that an assertion without justification has no value in a serious discussion. I was being nice. Next time I'll post a list of names of people who don't understand the metadata generation process and who therefore can't comment usefully... no slang in one's words is just a minimum requirement of communication. And sorry to disappoint you but you're not alway right. You have to give people a chance to contradict you, for your own good. People who know what they're talking about are more than welcome to contradict me. People who don't understand what's being discussed (which is most people in this thread) need to learn to stop wasting people's time. I see it differently. Everyone participated in this discussion has shown their concerns about their distro. If someone don't understand, we should help them to understand, not just exclude them from this discussion. They should learn, however we should at least give them directions. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Santiago M. Mola wrote: On Dec 20, 2007 8:01 PM, Zhang Le [EMAIL PROTECTED] wrote: How many EAPI's do we have now? In Portage tree we have 0 (default) and 1. There are others in external projects, for example prefix (in Gentoo/Alt:Prefix) or paludis-1 (used in paludis repositories). Where is the detailed definition of those EAPI's? 0, 1 and any further official EAPI are defined in PMS. There's a svn repository at http://svn.repogirl.net/pms How can we produce a new EAPI? I can't tell you the exact process, but look at EAPI bug trackers or search for bugs assigned to [EMAIL PROTECTED] Also, search in @-dev's archive. We should make a FAQ about all this. IMO, we can not have more than two EAPI's simultaneously. The only situation in which we can have two EAPI is in the transition period of those two EAPI's. And we should set a time constraint on the transition. Quite the opposite. EAPI's are designed to live happily together in the same repository. A current example: most (or lots...) ebuilds in the tree don't need EAPI=1 and it's pointless to migrate all of them. We can switch EAPI on an as needed basis. But EAPI's can not always co-exist harmoniously. What if a future EAPI come up with a totally new DEPENDENCY setting[1], which is incompatible with existing ones. I really don't see the necessity to have so many EAPI's, especially PM specific EAPI. We can't have PM specific EAPI, otherwise we are risking forking/splitting ourself. [1] https://bugs.gentoo.org/show_bug.cgi?id=201499 -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 03:17:12 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Putting a tag in the file name or at the to of the file as comment (maybe using a #! line) is the same ... Three problems: * We have to wait a year before we can use it. Why rush on this thing? If the EAPI's feature is not freezing, I think we should do nothing but wait. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 11:09:44 +0800 Zhang Le [EMAIL PROTECTED] wrote: I see it differently. Everyone participated in this discussion has shown their concerns about their distro. If someone don't understand, we should help them to understand, not just exclude them from this discussion. They should learn, however we should at least give them directions. Which is all very well, but highly impractical. If someone wants to write up a document explaining the metadata process then they're more than welcome to -- but there are much more useful things that could be documented if people had time... I am afraid if we want all people accept this GLEP wholeheartedly, someone ought to be stand out and take this responsibility. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 10:49:04 +0800 Zhang Le [EMAIL PROTECTED] wrote: It should not appear as a black box, and effectively prevent normal gentoo users and developers from contributing to decisions which may have a great impact on their distro. The GLEP doesn't have a great impact. It's a purely internal matter that shouldn't be visible to users at all and should be very easy for developers to follow once implemented. Really, the idea that anyone can contribute and express a useful opinion is all very well, but it's terribly naive. Do you expect to be asked to give your opinion upon the proportion of zinc mixed in with the aluminium in your car? Do you tell your doctor how much thimerosal you want in your medicine? Those are not analogous to open source software development, IMO. People can't decide on those things. But they can and should be able to influence on decision we are making here. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 10:52:04 +0800 Zhang Le [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: On Fri, 21 Dec 2007 03:14:12 +0100 Luca Barbato [EMAIL PROTECTED] wrote: Ciaran McCreesh wrote: Ok. What's the EAPI for the following ebuild that's written in an EAPI that hasn't been published yet? And how would I extract it? # Copyright blah blah import vim-spell using language=en If isn't published it doesn't exist in the main tree... You miss my point. If a package manager encounters the above, how does it determine the EAPI? As long as there is an agreement between the PM and ebuild, you can get what you want no matter how it is defined. So how does one get the EAPI in the above example? That's the problem about the agreement between PM and ebuild. If this is agreed upon import vim-spell using language=en You should be able to get it. If not, then blame the ebuild writer. There is no problem with the agreement. Bear in mind that package managers can only use what's been agreed upon at the time they were released, not what might be agreed upon later -- and yet they need to be able to extract the EAPI from anything agreed upon later. Exactly my point. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 11:26:06 +0800 Zhang Le [EMAIL PROTECTED] wrote: And no, it's not worth writing them. If people have time to spend documenting ebuildy things, there are a lot more useful places to start. It worths. It will influence our future. And bringing devmanual up to date will influence it a lot more. That's a different question. Please keep on topic. For this glep to pass, we don't need devmanual to be up-to-date. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 11:38:43 +0800 Zhang Le [EMAIL PROTECTED] wrote: I am afraid if we want all people accept this GLEP wholeheartedly, someone ought to be stand out and take this responsibility. No no, we want all the people who are qualified to discuss it to accept it, and the rest to accept that those people know what they're doing. By all people, I mean all those who have participated in this discussion. They shown their concern. We should listen to what they said. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: EAPI definition Was: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 11:23:08 +0800 Zhang Le [EMAIL PROTECTED] wrote: I really don't see the necessity to have so many EAPI's A new EAPI is needed for new features, so new EAPIs will be needed in the future. Equally, migrating the whole tree at once to newer EAPIs is a) a lot of unnecessary work, and b) unnecessarily irritating to people using older package managers. I think we should first decide on how EAPI works. This is also a prerequisite for this glep to be further discussed. Just because we need a new feature, then we produce a new EAPI? I think that is not feasible, and will confuse developers. especially PM specific EAPI. We can't have PM specific EAPI, otherwise we are risking forking/splitting ourself. Package manager EAPIs don't belong in the main tree, but they have uses outside of it. Then would you please introduce how paludis-1 EAPI differs from official EAPI's? -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: Re: Re: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 11:51:03 +0800 Zhang Le [EMAIL PROTECTED] wrote: That's the problem about the agreement between PM and ebuild. If this is agreed upon import vim-spell using language=en You should be able to get it. If not, then blame the ebuild writer. There is no problem with the agreement. Uh... It's not agreed upon currently. It is not about whether it is agreed upon currently. As long as there is an agreement in any given point of time, it is OK. Such as, put your EAPI definition on the first line of your ebuild, like EAPI=value Bear in mind that package managers can only use what's been agreed upon at the time they were released, not what might be agreed upon later -- and yet they need to be able to extract the EAPI from anything agreed upon later. Exactly my point. So we all agree that suffixes are the solution, since they solve this problem and in-ebuild-content restrictions don't. Good. No, quite contrary. See above. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Ciaran McCreesh wrote: On Fri, 21 Dec 2007 12:03:25 +0800 Zhang Le [EMAIL PROTECTED] wrote: We can't take the risk of forking/splitting ourselves in exchange of only a little features. EAPI introduces no risk of that. Quite the opposite -- it reduces it by making it less likely that people will get sick of the inability to add new features and go and do so elsewhere instead. Yes and no. I agree with your above sentence. But I am not sick of EAPI's. You see? I am sick of so *many* EAPI's. -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] [RFC] Features and documentation
Rémi Cardona wrote: Alec Warner wrote: On 11/27/07, Donnie Berkholz [EMAIL PROTECTED] wrote: How the recent changes happened to allow USE flag descriptions in metadata.xml (which I'm not taking any position on now) gave me an idea. The Linux kernel requires that any needed documentation accompany all changes requiring said documentation -- part of the source-code patch must apply to the Documentation/ directory. Should we require that before you commit any changes, you (or someone) write the documentation for them and commit it or submit a patch at the same time? To sum up: No undocumented changes. No, because this is not a realistic requirement, it's an ideal case. People will just commit changes without documentation anyway. What if Donnie had used s/changes/new features/ ? Then his proposal makes much more sense. I agree that new features makes more sense here. USE flag description in metadata.xml is just an example of new feature, IMO. My 2 HK$, ;) -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New Developer: Le Zhang (r0bertz)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heim : It's my please to introduce to you Le Robert Zhang (also known as r0bertz on IRC), our latest addition joining the GWN Translators. Thanks to all of you who have helped in the process of mentoring and recuiting me! You can just call me Robert. Or if you prefer to call me my Chinese name, please call me Zhang Le whenever possible. Thanks! In Chinese tradition, family name is placed before given name. ;) Le is joining us from Hong Kong (yes, that's in China boys and girls) where he's currently working for Thizlinux (a Hong Kong based Linux company). I regret to tell you that I have already resigned from ThizLinux. I was working for ThizLinux when I drafting my quiz answer. Now I am looking for a new one. When Le isn't around computers, he enjoys reading a good book, singing, or playing soccer (either for real or on PS2/PSP). So please welcome Le as a new fellow developer among us ! Wish to have a good time to work with you guys together! Best Regards, Robert - -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTHHqvFHICB5OKXMRAp6UAKCJ8R4+gOi7qVBLlYcQtlcZiicFAACfY6+j PiDuwyZr2GY3Yy4FGbWP6/M= =AJne -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] New Developer: Le Zhang (r0bertz)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Heim wrote: It's my please to introduce to you Le Robert Zhang (also known as r0bertz on IRC), our latest addition joining the GWN Translators. Thanks to all of you who have helped in the process of mentoring and recuiting me! You can just call me Robert. Or if you prefer to call me my Chinese name, please call me Zhang Le whenever possible. Thanks! In Chinese tradition, family name is placed before given name. ;) Le is joining us from Hong Kong (yes, that's in China boys and girls) where he's currently working for Thizlinux (a Hong Kong based Linux company). I regret to tell you that I have already resigned from ThizLinux. I was working for ThizLinux when I was drafting my quiz answer. Now I am looking for a new job. When Le isn't around computers, he enjoys reading a good book, singing, or playing soccer (either for real or on PS2/PSP). So please welcome Le as a new fellow developer among us ! Wish to have a good time to work with you guys together! Best Regards, Robert - - -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTHP1vFHICB5OKXMRAqX8AJ9X/FuP9+CXY8b6jeKQ0xYCqh6cGACaA5SG 7Vi2dd2dGUP86cbA27POFWs= =Mm+L -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: New Developer: Le Zhang (r0bertz)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Duncan wrote: Zhang Le [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Thu, 17 May 2007 23:16:59 +0800: Le is joining us from Hong Kong (yes, that's in China boys and girls) where he's currently working for Thizlinux (a Hong Kong based Linux company). I regret to tell you that I have already resigned from ThizLinux. I was working for ThizLinux when I drafting my quiz answer. Now I am looking for a new one. While I'm not a dev, just a lurker and sometimes poster on the dev group, welcome. =8^) Thank you! I recall seeing Linux computers at Fry's Electronics running Thiz, and checking out the web site a bit. I know you're not working there any more, but Would they be a decent choice for new Linux and possibly new (English speaking, possibly Spanish) computer users here in the US? What about updates, likely over dialup? I'd say ThizLinux's focus is Mainland China nowadays. If I were you, I will choose local suppliers. Hope you find an enjoyable new paying job, to go with your enjoyable volunteer one, Gentoo. =8^) Thanks again! Regards, - -- Zhang Le, Robert GPG key ID: 1E4E2973 Fingerprint: 0260 C902 B8F8 6506 6586 2B90 BC51 C808 1E4E 2973 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGTSeCvFHICB5OKXMRAow/AJ9KGq0eK405d/VFuxcelnEehzvxJgCeP6RO h+YwS4MJBN3TgGHU/NbShsQ= =sD4/ -END PGP SIGNATURE- -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] how to publish ebuild
On 3/22/07, Shaochun Wang [EMAIL PROTECTED] wrote: I write several ebuilds for packages which aren't available in the portage currently. I'd like to share them with gentoo community, but I don't know how to publish these ebuilds. And I also don't know by which way a package will be added to the gentoo portage system. Any suggestion? Are thoses software widely used in Chinese user community? If so, I can put them in gentoo-china overlay. -- Zhang Le, Robert http://zhllg.blogspot.com http://zh.gentoo-wiki.com http://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [gentoo dev]suggestion to distutils eclass
Some packages don't provide standard setup.py. Take a look at the attachment.This is a new ebuld.So my suggestion is to add a new variable to distutils.eclass, e.g. SETUP.PY, if it's set, then use it, otherwise let it defaults to setup.py.Looking forward to hear your feedback on this.-- Zhang Le, RobertLinux Engineer/Trainerhttp://zhllg.spaces.msn.com http://zh.gentoo-wiki.comhttp://savannah.nongnu.org/projects/pgubookhttp://groups.google.com/group/gentoo-china http://groups.google.com/group/szlug jToolkit-0.7.8.ebuild Description: Binary data
Re: [gentoo-dev] [gentoo dev]suggestion to distutils eclass
On 7/17/06, Alastair Tse [EMAIL PROTECTED] wrote: On Mon, 2006-07-17 at 00:49 +0800, Zhang Le wrote: Some packages don't provide standard setup.py. Take a look at the attachment. This is a new ebuld.I agree with Stefan, just put a symlink in from whatever their distutils install script is to setup.py in src_unpack(). This seems to be such arare corner case that it isn't worth adding extra complexity in.Thanks for you and Stefan's advice. Cheers,Alastair--gentoo-dev@gentoo.org mailing list-- Zhang Le, RobertLinux Engineer/Trainer http://zhllg.spaces.msn.comhttp://zh.gentoo-wiki.comhttp://savannah.nongnu.org/projects/pgubook http://groups.google.com/group/gentoo-chinahttp://groups.google.com/group/szlug
