Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
El jue, 14-05-2009 a las 03:32 +0300, Mart Raudsepp escribió: Hello, I have had this project in my mind for a while, so it's about time to get it out there, as to see if feedback finds it a good one - and if that is so, if there are people who want to make it happen. It is worded as a hypothetical project description for the purpose of the text perhaps being a draft for the projects official description. So in the following text instead of terms like this project would be I'm purposely using terms like this project is, as while writing it, it got quickly very awkward writing would be and such all the time. Please take it still as a proposal to be judged, commented, improved, etc etc. And well, do that commenting and improving and volunteering ;) Project maintainer-wanted = Abstract: There are currently quite some package requests (over 3000) languishing on bugzilla waiting for a developer or team to get interested and package it in the official gentoo-x86 portage tree. However in quite some cases that might not happen for quite a while even with very popular packages desired by users. The purpose of the maintainer-wanted project is to get as many of such packages to the official tree as possible as a stopgap solution. Details/implementation: The maintainer-wanted team is actively looking for popular packages in bugzilla that have been waiting for packaging in the official gentoo-x86 tree for a while, and package and maintain as many of them as the project teams manpower allows without sacrificing quality. To decide which libraries/application get packaged in the official tree by the project, various factors can be considers by the team. These can include metrics such as: * bugzilla vote count amongst open maintainer-wanted packages * recent general useful activity on the packages bugzilla entry * past and present user community activity in providing ebuild improvements, version bumps and fixes in the packages bugzilla maintainer-wanted bug entry * ease of the packaging thanks to active user contributions or consistently good upstream packaging making the workload of the maintainer-team not grow much * team members interest and personal qualification in the type of the package and its packaging methods * ... maintainer-wanted maintained packages are seen as a stopgap solution. As such it is desired that eventually a team or developer takes over maintenance to provide the packages dedicated care and free up the maintainer-wanted team to make available more desired packages that do not yet have a dedicated maintainer. To achieve that, various methods are pursued: * Other teams and developers are encouraged to take over maintenance. This includes proxy maintenance when for example a user is found to consistently and with good quality help out the maintainer-wanted team in providing fixes, improvements and bumps to an in-tree maintainer-wanted maintained package. Taking over maintenance is as easy as for maintainer-needed packages, however a notification to and acknowledgment from a maintainer-wanted team member is appreciated. * Lists of maintainer-wanted packages are generated, sorted by category of interest. Developers and dedicated package teams are encouraged to find packages of interest from these lists and take over maintenance. * Simply the easier availability (and the resulting exposure) of a package in the official tree (as opposed to an unreviewed, yet possibly high quality, ebuild attached to bugzilla, which has thousands of such entries) could catch the interest of another team or developer and they are encouraged to take over maintenance when they have the capacity (manpower/time etc) In other ways the maintainer-wanted team is not significantly different to other package maintaining teams: * The project is responsible for their maintained packages. Quality is not sacrificed; bugs on in-tree packages get acted upon, etc. As such it is likely desired to have a different alias than the default one for new packages (or a different good means of differentiating), as to not have bugs against already in-tree packages get lost amongst the hundreds or thousands of packages still waiting to get into the official package tree. * In-tree maintainer-wanted packages are also tried to be kept up to date in regards to new stable upstream versions. Users are encouraged to file bump requests on bugzilla even as 1-day requests due to the diversity of packages maintained by the project and therefore too many different places and notification mechanisms to manually check and monitor for the team (bugzilla version bump requests solve the diversity); at least until no mechanisms exist for automatic checking of bumps, which could get implemented in the future. The maintainer-team project hopes to make previously directly unavailable popular packages of quality easily available to
[gentoo-dev] Re: Passing arguments to eqmake3
Duncan wrote: Nikos Chantziaras rea...@arcor.de posted gufm71$un...@ger.gmane.org, excerpted below, on Thu, 14 May 2009 02:47:55 +0300: My posts to gmane.linux.gentoo.devhelp don't seem to get through. Does someone know if something is wrong with the list's subscription on GMane? All other GMane Gentoo lists seem to work fine. You may also want to ask on gmane.discuss. I'm not subscribed to .devhelp so can't help you directly on that, but perhaps one of the gmane admins or other users can be of help on gmane.discuss, if no one here has an immediate answer. I worked around it by subscribing manually to that list (using the -nomail list option). After that, postings from GMane get through.
[gentoo-dev] Re: Passing arguments to eqmake3
Nikos Chantziaras rea...@arcor.de posted gugfo5$i9...@ger.gmane.org, excerpted below, on Thu, 14 May 2009 10:03:43 +0300: I worked around it by subscribing manually to that list (using the -nomail list option). After that, postings from GMane get through. Thanks. (Further reply/explanation offlist.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Passing arguments to eqmake3
Hi, Nikos Chantziaras rea...@arcor.de: Daniel Pielmeier wrote: Also this question is not appropriate for this list. The gentoo-devhelp mailing-list or #gentoo-dev-help on IRC are better places for this kind of questions. My posts to gmane.linux.gentoo.devhelp don't seem to get through. Does someone know if something is wrong with the list's subscription on GMane? All other GMane Gentoo lists seem to work fine. As you noticed: You need to be subscribed to a Gentoo mailing list as we won't let through mails from Gmane alone. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: Passing arguments to eqmake3
Hi, Nikos Chantziaras rea...@arcor.de: Btw: Is there a typo in the eclass? Shouldn't it be Project .pro file PREFIX=/usr does not exist instead of Project .pro file PREFIX=/usr does not exists I just checked qt3.eclass and indeed its a typo in there. Which is now gone. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
Hi, Jeremy Olexa darks...@gentoo.org: I don't see any reason to create a team that duplicates the sunrise work. More power to Sunrise, yes. Sunrise is a great project, although I don't dedicate too much time for it nowadays. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On Wed, 2009-05-13 at 20:47 -0500, Jeremy Olexa wrote: Mart Raudsepp wrote: Hello, Hey, I have had this project in my mind for a while, so it's about time to get it out there, as to see if feedback finds it a good one - and if that is so, if there are people who want to make it happen. snip Hmm, I wonder what the point is when there is 400 maintainer-needed bugs open.. The point is making popular packages available in the _portage tree_. When widely used popular packages end up in maintainer-needed, they tend to be relatively quickly picked up by other teams or developers. maintainer-wanted hopes for the same, that they will tend to be picked up by others. Most of the 400 packages affected by maintainer-needed bugs are probably as such because close to no-one cares about them, and caring by the project proposed here doesn't get us any closer to world domination(tm) - we'd just have more packages of quality, except no-one uses those packages. We already have a set of people, of which you Jeremy seem to be participating in, that takes care of maintainer-needed bugs that have user patches available, hence the packages people actually care about are eventually taken care of as well as I understand. Maybe that project should formalize themselves as well. Or we can add that set of tasks to this one. That said, my initial idea months ago was related to the maintainer-needed alias, taking care of the packages of greater interest marked maintainer-needed and introducing new ones that are encouraged to be taken over. But by now I don't think mixing those together is a good idea. The community maintained packages idea from another e-mail was quite good to not mix with maintainer-wanted either (the point about making sure new package requests and bugs against in-tree maintainer-wanted packages don't get mixed), except I think that naming doesn't so strongly express that other dedicated maintainers are desired. I think a maintainer-wanted team won't accomplish much because it just uses more developer time from a pool of not enough time that exists already. Volunteer manpower doesn't work quite like that. Volunteers have as much time as they make for this as a hobby of interest. Developer A is interested in keeping old crufty stuff dropped to maintainer-needed in quality condition as they like that sort of thing, while developer B doesn't and he likes the satisfaction of making much desired new packages available to the wider user base instead. If you don't have a project encouraging that, developer B can end up just not taking more time for Gentoo and does more of other stuff instead, lets say gardening or watching random TV. Because we don't provide monetary motivation to take care of exotic and outdated packages to get that out of the way shouldn't block people motivated in providing popular packages that would be used by a larger set of the user base and contribute to the popularity of Gentoo. If people are a) too lazy to contribute to sunrise, b) don't know about sunrise, or c) don't know enough about ebuilds to contribute to sunrise, then we need to fix[1] that. Sure, the sunrise project can do all of that. That doesn't make the packages available in the official tree. The maintainer-wanted project however can tap into the work done by sunrise when a popular package is to be added to the tree that already exists in Sunrise. If certain interested in the package users are contributing to Sunrise for that package, they could hopefully be turned into proxy maintainers in the official tree version and perhaps even eventually become developers as well when they have interest in a larger set of packages. If they have been maintaining a lot of different package in Sunrise before that, they seem to be a good candidate in joining the maintainer-wanted team too then, as they seem to be motivated by the kind of work they do, as same work was done in an overlay by him/her before. Close collaboration with Sunrise is good, that is. So the end outcome would be that the packages that are used by many people are available in the official tree. I don't see any reason to create a team that duplicates the sunrise work. Keep in mind, I am against pretty much any overlay, I think work should be kept in the main tree. But, for ebuild maintenance with limited developer time, sunrise just makes sense(tm). Developer time is not so strictly limited. The motivation to spend more time on Gentoo instead of other daily non-work not-so productive activities might be limited. Yes, we also have the small set of developers that do a very large chunk of the work - they are limited in time indeed because they already are so motivated to use so much time for Gentoo. I am a strong believer in the correlation of motivation and time spent on volunteer hobby work as you can see. Some other possible directions include: 1) maintainer-needed team - Where a group maintains the set of 761 m-needed packages.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote: Hello, I have had this project in my mind for a while, so it's about time to [..] I think there is no need for this project. Developers can always browse bugzilla and pick every 'maintainer-wanted' ebuild they like. At least this is what I do. I am not sure how this project will make things better. In order to push something on portage, you need to test it and use it and like it and taking care of it. Apparently you wont push a package that you dont give a s*** :) So this project will do what each developer is doing individually. Am I the only one who is searching bugzilla for maintainer-wanted packages? o_0 -- Markos Chandras (hwoarang) Gentoo Linux Developer [KDE/Qt/Sound/Sunrise] Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
On Thu, May 14, 2009 at 07:54:35AM +0200, Patrick Lauer wrote: Yes, one did. Some people just need a good excuse to leave :) You lost the best laptop developer Gentoo had ever had.. -- Alexander Færøy http://dev.exherbo.org/~ahf/ pgpscOKrRfN37.pgp Description: PGP signature
Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
To potential responders to this message: Nothing to see here, please move along. Everytime you reply to this message, a kitten is deleted. 2009/5/14 Alexander Færøy a...@0x90.dk: On Thu, May 14, 2009 at 07:54:35AM +0200, Patrick Lauer wrote: Yes, one did. Some people just need a good excuse to leave :) You lost the best laptop developer Gentoo had ever had.. -- Alexander Færøy http://dev.exherbo.org/~ahf/ -- ~Nirbheek Chauhan
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
On N, 2009-05-14 at 14:02 +0300, Markos Chandras wrote: On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote: Hello, I have had this project in my mind for a while, so it's about time to [..] I think there is no need for this project. Developers can always browse bugzilla and pick every 'maintainer-wanted' ebuild they like. At least this is what I do. I am not sure how this project will make things better. In order to push something on portage, you need to test it and use it and like it and taking care of it. Apparently you wont push a package that you dont give a s*** :) So this project will do what each developer is doing individually. Am I the only one who is searching bugzilla for maintainer-wanted packages? o_0 There are various differences with this being a project instead of individual developers picking up a few. I think most are benefits, but some can be perhaps viewed the opposite way as well, hence the thread :) It is a project and hence a team, so there can be multiple developers in the team, all sharing the workload and making sure quality and up-to-dateness is kept. A separate e-mail alias to get bug reports to that any of the team members can attend to, etc. Basically the typical benefits of a team vs individuals The packages are still kept up for grabs for individual packages. Instead of you looking for packages of interest to maintain from bugzilla maintainer-wanted ones, you have an additional place to look at - one that would be more easily browseable and categorized. If you find a package of interest you would like to maintain out of that list, you simply take over maintenance from maintainer-wanted team, as finding a dedicated is exactly the eventual goal and that gets accomplished then. Meanwhile users have the package available earlier. Liking and using the package yourself shouldn't be a prerequisite for a package getting to be in-tree by the maintainer-wanted team. It is hoped that for them the driving factor is making popular packages available to a larger user base that want to use it themselves, so that popular applications that do not have any existing developers at the time finding deep interest in it will not mean indefinite languishing in bugzilla and not being easily available for users (while it probably is for Fedora or Debian or whatever). I'm quite sure we have developers motivated by that around. For example when I discussed this with Samuli a few months ago, I believe he basically said to already do work like this, except making desktop-misc the dumping ground, loosing the benefits that a separate project and alias would give related to both implied (from the maintaining herd name and knowledge of its purpose) and active seeking (through package lists, etc) for dedicated maintainers. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
AllenJB wrote: All that's going to happen is Gentoo will have many many buggy and out of date packages in the MAIN TREE. Exactly where they shouldn't be. You claim quality won't be sacrificed, but I simply can't see this without any attempt to solve the manpower issues first. Isn't the purpose of this project already somewhat covered by Sunrise? I have to agree with your points. We need to have quality standards for packages. Currently we have a couple of tiers: 1. Main tree - every ebuild has an official maintainer and gets prompt security updates/etc. New features might get a little more stale, but you aren't going to be running at risk if you only use the main tree and routinely emerge -u world. If a package falls behind on security it gets masked and booted. 2. Overlays - you're on your own and at the general mercy of the overlay maintainer. 3. Sunrise (just a special case of an overlay) - somewhere in-between. Again, you have to opt-in. I think that we still need to have defined levels of quality, so if we start putting unmaintained stuff in the main tree then we absolutely need to preserve a mechanism for users to indicate what level of quality they desire. Users running a typical install shouldn't inadvertently have dependencies pulled in which aren't fully controlled for security issues. Could something like sunrise be integrated into the main tree? Sure. However, there would need to be lots of rules and QA checks like non-sunrise packages not depending on sunrise packages and the sunrise packages are somehow clearly marked. Maybe even an ACCEPT_QUALITY = good-luck-with-that setting or something like that in make.conf. We might also need tiered levels of security in cvs. I'm not convinced that in the end it will be any better than just having those who are interested add an overlay to their tree. Maybe a better option would be a way to make overlays more seamless. Additionally we could have rating categories for overlays like security responsiveness, currency with upstream, etc. The gentoo project would ask overlays to declare their policies as a condition of being accessible via the seamless interface, and would drop overlays if they don't follow their policies. It would still be easy for users to pick non-standard overlays but it would be clear that they are venturing off on their own if they do this (just as is the case with layman today). Sure, I'd love to see an extra 1000 supported packages in portage, but the key is supported, not just shoveled-in.
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Mart Raudsepp wrote: Liking and using the package yourself shouldn't be a prerequisite for a package getting to be in-tree by the maintainer-wanted team. How about actually maintaining the package? For example, user contributes ebuild for foo-1.0. I don't use it or like it, but I go ahead and throw it into portage. User logs bug that foo-1.0 wipes out random files from time to time. Nobody looks at said bug since nobody owns foo, and bug starts getting 3000 me-too! comments. Some charitable developer takes a look and the problem isn't obvious and offers to just mask the package. Now 3000 people running foo are upset for it being de-supported (when it wasn't supported in the first place). Wouldn't it make more sense for people who like the foo-1.0 ebuild to just stick it in their own ebuild or an overlay and be on their own (since they're really on their own either way)? Or to move it to sunrise or some other place where it might actually get some level of support? If Gentoo is going to distribute an ebuild Gentoo should Do-It-Right(TM). Why put our name on something we don't really want to care for?
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Mart Raudsepp schrieb: If people are a) too lazy to contribute to sunrise, b) don't know about sunrise, or c) don't know enough about ebuilds to contribute to sunrise, then we need to fix[1] that. Sure, the sunrise project can do all of that. That doesn't make the packages available in the official tree. The maintainer-wanted project however can tap into the work done by sunrise when a popular package is to be added to the tree that already exists in Sunrise. If certain interested in the package users are contributing to Sunrise for that package, they could hopefully be turned into proxy maintainers in the official tree version and perhaps even eventually become developers as well when they have interest in a larger set of packages. If they have been maintaining a lot of different package in Sunrise before that, they seem to be a good candidate in joining the maintainer-wanted team too then, as they seem to be motivated by the kind of work they do, as same work was done in an overlay by him/her before. Close collaboration with Sunrise is good, that is. So the end outcome would be that the packages that are used by many people are available in the official tree. I think, you overrate the possible additional free time that developers are able and willing to contribute to Gentoo for such a project. If a dev is intersted in a package, he can create an ebuild, add it to the main tree and maintain it there. If a dev would like to add a popular package, also not being personally interested, he can still do it, nothing prevents him from that. But this does not happen and i think, there is a simple reason: The number of active developers with access to the main tree is limited and the amount of work they can do is it too. In the end, this project would create some or even many packages, that end as m-needed because the team is not willing or able to maintain the amount of ebuilds they initially added. If users are interested in a package and willing to create an ebuild and maintain it, they can add it to the sunrise overlay. If they do continual good work, they can even become developers themselves and move some apps to the main tree (like i did). If they dont continue the maintainence, the ebuild will stay in sunrise as a base for everyone interested without polluting the main tree. Based on this, i would suggest another basic idea (details can be discussed, if accepted): -Make the sunrise overlay more known on different places like front page, blogs, forum etc -Based on some checks (good QA, maintained, fixed reported problems or whatever), add good ebuilds to the main tree with some restrictions (maybe some additional var, only unstable keywords or similar). If there are no complains and bugs get fixed (either some dev or the maintainer (user) does it), it will stay there, if not, it gets removed from the tree again and moved back to the sunrise overlay. Whith this, users would get a central place to start with reading, contributing, learning and proxy maintaining their ebuilds, would be able to get their work to some audience (either those adding sunrise overlay or with good work even the main tree), could learn enough to become developers with main tree access themselves. And if they leave their work alone, it just gets moved from the main tree back to the sunrise overlay and so cannot harm Gentoo, the security team or anyone else for a longer time. Just for clarification: Those contributors would still only commit to a branch not accessable via layman nor does it automaticly write to the main tree. These contributions then get currently moved to the reviewed tree (which is what users get via layman) after some sunrise dev did review the commit. In this proposal, the move to the main tree and any update would go the same way, so no direct access to the main tree by (user) contributors until they got recruited as ebuild deveopers. With this proposal, we could recruite new people to work on things they are intersted in, so it should be relatively easy to get popular packages in the main tree, while not using some (probably not existing) additional dev-time. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] The fallacies of GLEP55
For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] The proposed solution to a problem that is never refined, in short, is to add the EAPI into the ebuild filename to make things easier. Which is a rather unsubstantiated idea that doesn't really add up if you look at it ... and it adds some artifacts that we've been laughing about for a decade because microsoft did the exact same thing (binding the executable-ness of a file to the filename). Here's just some of the theories in support of GLEP55 that have been thrown at me, and a few words to show how they are not really issues: You need to know the EAPI to parse the ebuild to find the EAPI Obviously that's not true, because somehow we manage at the moment. And if one does a small restriction (which doesn't restrict current behaviour because all in-tree ebuilds currently fit within this limitation) it becomes trivial again: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= As long as ebuilds remain shell-like this is not much of a restriction, and any format that diverges enough to make this inconvenient shouldn't be called an ebuild anyway. Finding the EAPI is then quite unsurprisingly trivial. You need to parse the ebuild and its eclasses to find the EAPI! See above, and eclasses shouldn't change EAPI anyway. It leads to lots of strange effects and is implicitly impossible with GLEP55 anyway, so it might be easier to just declare it invalid. It's slower! The theory here being that a stat() is needed if it is encoded in the filename, but a stat() followed by an open() to parse it from the file. Well then, just cache it! You can use the mtime to check the cache validity (which means you do a stat() anyway, so with glep55 caching it is actually slower!), and then you have to parse the ebuild anyway for the other metadata. So the extra cost of finding the EAPI is ... what extra cost? The only case when it is actually slower is when there is no cache because then you have to parse the ebuild. But that degenerate case will only hit some overlay users and people like developers that can wait .3 seconds longer. And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it anyway. But we need to be able to change things in the future! Well then. Once we have identified such an issue we can do the changes. Until then it's not even clear if there are such changes, so why should we break current known and predictable behaviour to satisfy a need we don't even have? Make a structured proposal defining a concrete problem in unambiguous terms, list all the ways to solve this issue, including advantages and disadvantages, and we can get it voted on and ratified within a month. We want to change the versioning rules! Why do you want that, and what do we gain from it? Having GLEP55 allows us to add GLEP54 without issues! Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? LIVE=true. There. No need to fix the filename. And now stop mixing up issues because it is highly confusing! Obviously you don't understand the issue, because if you did you'd support it! Uhm, obviously you have no idea what you are saying. But just to play along ... if it were that obvious we wouldn't have had to discuss it for so long. Maybe understanding the issue forces one to support the current behaviour! A few words in closing - We can encode all the relevant info in the first line of the ebuild starting with EAPI= The overhead of parsing out this value for all ebuilds in the tree has been timed at ~2 CPU-seconds by solar. It's negligible. The changes are none at the moment, all that changes is the specification. And if we ever have the need to change things around we can still look at the expected costs and benefits and decide to implement something almost, but not completely unlike GLEP55. And maybe we can now spend the same amount of council-time (it has been eating time for over a year!) to get important things done ... hth, Patrick the bonsaikitten P.S. http://dev.gentooexperimental.org/~dreeevil/whargarbl.jpg
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009.05.14 01:32, Mart Raudsepp wrote: Hello, [snip] Project maintainer-wanted = Abstract: There are currently quite some package requests (over 3000) languishing on bugzilla waiting for a developer or team to get interested and package it in the official gentoo-x86 portage tree. However in quite some cases that might not happen for quite a while even with very popular packages desired by users. The purpose of the maintainer-wanted project is to get as many of such packages to the official tree as possible as a stopgap solution. [snip] Discuss! :) Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://planet.gentoo.org/developers/leio Mart, I'm against for many of the reasons AllanJB outlined. There is no point in adding more unmaintained packages to the tree. Over time, the average quality of the tree will suffer. We could use user contributed ebuilds attached to bugs as a way to bring Sunrise to the contributors attention just by posting a comment to the bug. If the contributor follows up, we get another user maintained ebuild in Sunrise, which is good, as the current developers don't have to do all the work. We already know some Sunrise contributors become developers so perhaps we can use this as a way to attract more contributors (both users and developers). Its probably a bad idea to send all the bugspam at the same time, Sunrise might be overwhelmed, which would be bad for Sunrise and user contributors who would feel let down - -- Regards, Roy Bamford (NeddySeagoon) a member of gentoo-ops forum-mods treecleaners trustees -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoMYdYACgkQTE4/y7nJvav1hgCfULFWGyBpvXC5dy5KrekYYM80 QhIAnjM0GQQQKuzkf17Oj56RH7Z1X5cl =wK1Z -END PGP SIGNATURE-
[gentoo-dev] Re: Files owned by multiple slots
Duncan 1i5t5.duncan at cox.net writes: FWIW, that'd not be a portage issue per se, but an EAPI issue, since it I see, very interesting! Sounds like a lengthy process, but never mind. Do you know where EAPI changes are discussed? (Google and the Bugtracker didn't yield a useful reply.) Cheers, -sven
Re: [gentoo-dev] Re: Files owned by multiple slots
On Thu, 14 May 2009 18:34:29 + (UTC) Sven sv...@delirium.ch wrote: Duncan 1i5t5.duncan at cox.net writes: FWIW, that'd not be a portage issue per se, but an EAPI issue, since it I see, very interesting! Sounds like a lengthy process, but never mind. Do you know where EAPI changes are discussed? (Google and the Bugtracker didn't yield a useful reply.) The best way is to make a carefully thought out proposal, mail it to this list and it'll get picked up. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: You need to know the EAPI to parse the ebuild to find the EAPI Obviously that's not true, because somehow we manage at the moment. And if one does a small restriction (which doesn't restrict current behaviour because all in-tree ebuilds currently fit within this limitation) it becomes trivial again: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. If you're looking for a formally correct alternative that works in the way you suggest, I already provided one, and you already read about it -- and it still doesn't solve the problems that 55 does. It's slower! The theory here being that a stat() is needed if it is encoded in the filename, but a stat() followed by an open() to parse it from the file. Well then, just cache it! You can use the mtime to check the cache validity (which means you do a stat() anyway, so with glep55 caching it is actually slower!), and then you have to parse the ebuild anyway for the other metadata. So the extra cost of finding the EAPI is ... what extra cost? The only case when it is actually slower is when there is no cache because then you have to parse the ebuild. But that degenerate case will only hit some overlay users and people like developers that can wait .3 seconds longer. And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it anyway. Where on earth are you getting the idea that GLEP 55 makes things slower? The only difference to the code with GLEP 55 is in checking file extensions against a slightly larger set of strings, which is nowhere near a measurable increase in anything. You're claiming that checking for a suffix of either .ebuild-4 or .ebuild against a fixed string is in any way relevant, which is obviously trolling. Having GLEP55 allows us to add GLEP54 without issues! Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? LIVE=true. There. No need to fix the filename. And now stop mixing up issues because it is highly confusing! There is no existing version ordering solution that accurately represents upstream scm branches. A few words in closing - We can encode all the relevant info in the first line of the ebuild starting with EAPI= No we can't. That's *obviously* completely wrong. The overhead of parsing out this value for all ebuilds in the tree has been timed at ~2 CPU-seconds by solar. It's negligible. Those of us who have been measuring this have been discarding CPU time entirely, since it's utterly irrelevant. That you bring CPU time into this shows you've been deliberately ignoring everything we've said. We all know you're not stupid enough to believe what you've been posting or ignorant enough to miss the point so badly. So please stop pretending -- this issue would have gone through a long time ago were it not for you and your ilk deliberately pretending to be retarded so you can raise straw man arguments against it rather than addressing the issues at hand. You're doing both yourself and everyone else a huge disfavour by acting dumb and assuming everyone else is going to play along with that. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
Roy Bamford schrieb: We could use user contributed ebuilds attached to bugs as a way to bring Sunrise to the contributors attention just by posting a comment to the bug. If the contributor follows up, we get another user maintained ebuild in Sunrise, which is good, as the current developers don't have to do all the work. We already know some Sunrise contributors become developers so perhaps we can use this as a way to attract more contributors (both users and developers). Its probably a bad idea to send all the bugspam at the same time, Sunrise might be overwhelmed, which would be bad for Sunrise and user contributors who would feel let down This is already done. darkside/idl0r did/do suggest sunrise to all maintainer-wanted bugs, that meet some specific criteria. But have to say, while hundreds of messages where sent, there is not much response from this until now. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] The fallacies of GLEP55
On Thursday 14 May 2009 19:06:51 Patrick Lauer wrote: For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] We agree on the latter adjective, if nothing else. The proposed solution to a problem that is never refined, in short, is to add the EAPI into the ebuild filename to make things easier. Which is a rather unsubstantiated idea that doesn't really add up if you look at it ... and it adds some artifacts that we've been laughing about for a decade because microsoft did the exact same thing (binding the executable-ness of a file to the filename). I wonder where people get this strange delusion that only Windows uses file extensions for anything? Here's just some of the theories in support of GLEP55 that have been thrown at me, and a few words to show how they are not really issues: You need to know the EAPI to parse the ebuild to find the EAPI Obviously that's not true, because somehow we manage at the moment. Because we haven't yet introduced any changes that would break it. And if one does a small restriction (which doesn't restrict current behaviour because all in-tree ebuilds currently fit within this limitation) it becomes trivial again: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= As long as ebuilds remain shell-like this is not much of a restriction, It's an arbitrary, magical restriction that doesn't follow from the general rules of the language that ebuilds are written in - you said it yourself, shell-like. printf -v EAPI 1 is perfectly valid shell (at least if we decide to allow bash 3.1 features), and has the same effect as EAPI=1 under the rules of the shell, but it's not compatible with your new rule. You need to parse the ebuild and its eclasses to find the EAPI! See above, and eclasses shouldn't change EAPI anyway. It leads to lots of strange effects and is implicitly impossible with GLEP55 anyway, so it might be easier to just declare it invalid. With GLEP 55 it's naturally invalid, and can't possibly be assumed to be valid. If you keep the assignment-like syntax but disallow it in eclasses, it's an extra weird restriction. It's slower! The theory here being that a stat() is needed if it is encoded in the filename, but a stat() followed by an open() to parse it from the file. Well then, just cache it! You can use the mtime to check the cache validity (which means you do a stat() anyway, so with glep55 caching it is actually slower!), and then you have to parse the ebuild anyway for the other metadata. So the extra cost of finding the EAPI is ... what extra cost? The only case when it is actually slower is when there is no cache because then you have to parse the ebuild. But that degenerate case will only hit some overlay users and people like developers that can wait .3 seconds longer. And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it anyway. And people say Gentoo users are ricers... the whole speed argument is a strawman, relevant only to the extent that we don't want to make things noticeably slower than they are already. You claim that GLEP 55 does that, but this claim seems to be based on the assumption that without it there would be no need to parse the filename in any way, which clearly isn't true. But we need to be able to change things in the future! Well then. Once we have identified such an issue we can do the changes. Until then it's not even clear if there are such changes, so why should we break current known and predictable behaviour to satisfy a need we don't even have? Make a structured proposal defining a concrete problem in unambiguous terms, list all the ways to solve this issue, including advantages and disadvantages, and we can get it voted on and ratified within a month. The same thing happened when EAPI itself was introduced. EAPI support was committed to Portage in late September 2005, but the first new EAPI in mainstream Gentoo was introduced in early October 2007, just over two years later. That's clearly not an argument for rejecting a compatibility mechanism. It's also not necessary to start putting EAPI in the filename as soon as it's approved. The Council could easily state that once we need to make a change that requires a stronger mechanism than EAPI is currently, we'll do it like this - no need to reject it, or keep maybeing it for eternity. Of course, there's at least one GLEP 55-scope change that people want already, to the extent that they're making up hacks to work around the lack of it, namely per-package eclasses. I would hope that everyone agrees that a package manager-supported mechanism would be far preferably (I know that vapier does). We want to change the versioning rules! Why do you want that, and what do we gain from it? Aside from -scm (below), there are
Re: [gentoo-dev] The fallacies of GLEP55
Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a): Where on earth are you getting the idea that GLEP 55 makes things slower? The only difference to the code with GLEP 55 is in checking file extensions against a slightly larger set of strings, which is nowhere near a measurable increase in anything. You're claiming that checking for a suffix of either .ebuild-4 or .ebuild against a fixed string is in any way relevant, which is obviously trolling. Read the block once more, he is not stating that adding suffix to the filename is slower. Having GLEP55 allows us to add GLEP54 without issues! Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? LIVE=true. There. No need to fix the filename. And now stop mixing up issues because it is highly confusing! There is no existing version ordering solution that accurately represents upstream scm branches. A few words in closing - We can encode all the relevant info in the first line of the ebuild starting with EAPI= No we can't. That's *obviously* completely wrong. We actualy can, you consider it wrong, so we all should do so The overhead of parsing out this value for all ebuilds in the tree has been timed at ~2 CPU-seconds by solar. It's negligible. Those of us who have been measuring this have been discarding CPU time entirely, since it's utterly irrelevant. That you bring CPU time into this shows you've been deliberately ignoring everything we've said. Well cpu is not real benchmark, but if it took 2 secs it means the tweaking is not worth efforts. We all know you're not stupid enough to believe what you've been posting or ignorant enough to miss the point so badly. So please stop pretending -- this issue would have gone through a long time ago were it not for you and your ilk deliberately pretending to be retarded so you can raise straw man arguments against it rather than addressing the issues at hand. You're doing both yourself and everyone else a huge disfavour by acting dumb and assuming everyone else is going to play along with that. And this is really just personal offense which you should take out from your mails if you want somebody to take your experience acordingly to your knowledge and not just judge you as 10 year old whining kid. Tomas signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 21:05:52 +0200 Patrick Lauer patr...@gentoo.org wrote: Where on earth are you getting the idea that GLEP 55 makes things slower? The only difference to the code with GLEP 55 is in checking file extensions against a slightly larger set of strings, which is nowhere near a measurable increase in anything. You're claiming that checking for a suffix of either .ebuild-4 or .ebuild against a fixed string is in any way relevant, which is obviously trolling. That is quite definitely not my point. I mean, hombre, did you even READ my email, or do you just apply prewritten text blocks in the hope of solving issues like most technical support does? Please explain why you claimed GLEP 55 makes things slower. Until you answer that, it's hard to take you for anything other than a troll. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, May 14, 2009 at 2:06 PM, David Leverton levert...@googlemail.com wrote: yourself, shell-like. printf -v EAPI 1 is perfectly valid shell (at least if we decide to allow bash 3.1 features), and has the same effect To stir things up: Who decides this? There are more and more bash-3.1 features in the tree and I brought it up to the Council months ago becase the PMS says that only bash-3.0 is allowed but no one cares. -Jeremy
Re: [gentoo-dev] The fallacies of GLEP55
Patrick Lauer wrote: On Thursday 14 May 2009 20:39:07 Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. Interesting, but quite subtly wrong. I'm surprised that you try to slip such an obvious logical mistake in in an attempt to save your arguments. Patrick, in the interest of making this comprehensible to the average schmuck like me, which you seem to be trying to do, could you actually explain WHY this is wrong? Otherwise it looks like you are simply trying the arrogant I am right because I say so line. If you're looking for a formally correct alternative that works in the way you suggest, I already provided one, and you already read about it -- and it still doesn't solve the problems that 55 does. And glep55 doesn't solve the problem either. It's neither formal nor correct, plus in this case ... what on earth are you trying to communicate? Again, see my previous comment. We can encode all the relevant info in the first line of the ebuild starting with EAPI= No we can't. That's *obviously* completely wrong. It's obviously quite specifically not. Can you show any case where that fails or where adding this restriction removes relevant functionality? Both of you need to explain your opinions here. Just my thoughts, R.
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, May 14, 2009 at 13:11, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please explain why you claimed GLEP 55 makes things slower. Until you answer that, it's hard to take you for anything other than a troll. Hell, I'll explain. Read paragraph 8 again. Slowly. Read it a second time, since you obviously didn't read the first time. The paragraph makes the point that the pro-GLEP55 stance says that encoding EAPI inside the file is slower. It is not saying GLEP55 is slower, it is attempting to debunk the theory that it is faster. You may be a lightning-fast typer and emailer, but until your comprehension catches up, you might want to consider reading things that make you angry twice.
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 21:09:58 +0200 Tomáš Chvátal scarab...@gentoo.org wrote: Dne čtvrtek 14 Květen 2009 20:39:07 Ciaran McCreesh napsal(a): Where on earth are you getting the idea that GLEP 55 makes things slower? The only difference to the code with GLEP 55 is in checking file extensions against a slightly larger set of strings, which is nowhere near a measurable increase in anything. You're claiming that checking for a suffix of either .ebuild-4 or .ebuild against a fixed string is in any way relevant, which is obviously trolling. Read the block once more, he is not stating that adding suffix to the filename is slower. He is stating that GLEP 55 makes things slower. I quote: so with glep55 caching it is actually slower! The only possible change to GLEP 55 performance-wise is in the file name recognition, and that's so obviously not an issue that there's no way anyone can take it seriously. Unless you seriously think he's claiming that GLEP 55 does away with the need for storing EAPI in metadata cache, which is even more obviously nonsense... Either way, he's trolling and needs to be called on it. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 13:17:24 -0600 RB aoz@gmail.com wrote: On Thu, May 14, 2009 at 13:11, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please explain why you claimed GLEP 55 makes things slower. Until you answer that, it's hard to take you for anything other than a troll. Hell, I'll explain. Read paragraph 8 again. Slowly. Read it a second time, since you obviously didn't read the first time. The paragraph makes the point that the pro-GLEP55 stance says that encoding EAPI inside the file is slower. It is not saying GLEP55 is slower, it is attempting to debunk the theory that it is faster. so with glep55 caching it is actually slower! There's no possible way that can make sense. Whatever he's claiming by that is obviously nonsense. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Thursday 14 May 2009 21:20:18 Ciaran McCreesh wrote: On Thu, 14 May 2009 13:17:24 -0600 RB aoz@gmail.com wrote: On Thu, May 14, 2009 at 13:11, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Please explain why you claimed GLEP 55 makes things slower. Until you answer that, it's hard to take you for anything other than a troll. Hell, I'll explain. Read paragraph 8 again. Slowly. Read it a second time, since you obviously didn't read the first time. The paragraph makes the point that the pro-GLEP55 stance says that encoding EAPI inside the file is slower. It is not saying GLEP55 is slower, it is attempting to debunk the theory that it is faster. so with glep55 caching it is actually slower! There's no possible way that can make sense. Whatever he's claiming by that is obviously nonsense. Ah. I was not precise enough. Let me rephrase it in less ambiguous terms then - Having EAPI in the ebuild is slower than having it encoded in the filename Counterpoint: No, you use caching if it is that darn slow Bonus: GLEP55 makes caching that slower than accessing it directly Extra bonus: about a dozen emails going around in circles over a careless formulation that gets misinterpreted into The iraqis have weapons of mass destruction!
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 14:15:28 -0500 Jeremy Olexa darks...@gentoo.org wrote: On Thu, May 14, 2009 at 2:06 PM, David Leverton levert...@googlemail.com wrote: yourself, shell-like. printf -v EAPI 1 is perfectly valid shell (at least if we decide to allow bash 3.1 features), and has the same effect To stir things up: Who decides this? There are more and more bash-3.1 features in the tree and I brought it up to the Council months ago becase the PMS says that only bash-3.0 is allowed but no one cares. Can't allow newer bash features in global scope until the whole can't make global scope changes thing is sorted out. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 21:24:14 +0200 Patrick Lauer patr...@gentoo.org wrote: so with glep55 caching it is actually slower! There's no possible way that can make sense. Whatever he's claiming by that is obviously nonsense. Ah. I was not precise enough. Let me rephrase it in less ambiguous terms then - Having EAPI in the ebuild is slower than having it encoded in the filename Counterpoint: No, you use caching if it is that darn slow Cache it where? There's already a cache, and introducing any new cache will only slow things down, not speed them up. And you still haven't justified how glep 55 makes it slower. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] The fallacies of GLEP55
Patrick Lauer wrote: For quite some time (over a year, actually) we've been discussing the mysterious and often misunderstood GLEP55. [http://www.gentoo.org/proj/en/glep/glep-0055.html] The proposed solution to a problem that is never refined, This, in my opinion, is the crux of the matter. Most of us apparently are not sufficiently convinced that there actually is a problem. Until the problem is explained with clarity, the rest of the proposal is useless. Obviously you don't understand the issue, because if you did you'd support it! I concur that speaking for myself, I don't understand the issue. And it looks like many others don't either. So if anyone wants to promote this GLEP, their job is clear: make people understand what the issue is here, and convince them it is actually an issue. (Examples, scenarios usually work well, indeed a lot better than calling people names.) And maybe we can now spend the same amount of council-time (it has been eating time for over a year!) to get important things done ... I want to call on the Council to reject this GLEP in its current form, as the problem has been insufficiently clarified. We should not waste more time on it. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) Gentoo Linux Release Engineering PR liaison __
Re: [gentoo-dev] The fallacies of GLEP55
On Thu, 14 May 2009 22:03:22 +0200 Ben de Groot yng...@gentoo.org wrote: I concur that speaking for myself, I don't understand the issue. And it looks like many others don't either. So if anyone wants to promote this GLEP, their job is clear: make people understand what the issue is here, and convince them it is actually an issue. (Examples, scenarios usually work well, indeed a lot better than calling people names.) We need a mechanism to be able to use newer bash-features in ebuilds. Preferably one that doesn't go Wait a couple of years, hope everyone did X then Just Do it. We want one that goes like Get a new EAPI approved with new minimum bash-version attached, start using cool stuff like ( Bash-4.0 ): shopt -s globstar for i in /usr/share/man/**/*remote* do stuff done Built-in find in bash, how do you like them bananas? :-) find equivalent would be, if you wanted the same level of space-safety: while read -r line do stuff done (find /usr/share/man -name '*remote*') Personally, I like the first version better. It would be cool if we could start using it sooner. GLEP-55 provides the clean solution, by just making the file name indicate what's inside. No need to parse, no nothing. Portage is currently testing a first line with EAPI= determines EAPI method. That's slightly less clean, but has the added benefit of not breaking anything that relies on .ebuild extension for ebuilds and I think it's not an unreasonable limitation on ebuilds to require EAPI= to be parseable by !bash. /loki_val
Re: [gentoo-dev] The fallacies of GLEP55
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, I realize that I'm asking this very late in the discussion, so please bear with me if it has been hashed before. On Thu, May 14, 2009 at 11:16:23PM +0200, Peter Alfredsen wrote: We need a mechanism to be able to use newer bash-features in ebuilds. Preferably one that doesn't go Wait a couple of years, hope everyone did X then Just Do it. We want one that goes like Get a new EAPI approved with new minimum bash-version attached, start using cool stuff like ( Bash-4.0 ): snip Personally, I like the first version better. It would be cool if we could start using it sooner. GLEP-55 provides the clean solution, by just making the file name indicate what's inside. No need to parse, no nothing. Portage is currently testing a first line with EAPI= determines EAPI method. That's slightly less clean, but has the added benefit of not breaking anything that relies on .ebuild extension for ebuilds and I think it's not an unreasonable limitation on ebuilds to require EAPI= to be parseable by !bash. I don't know how strong this argument is, but here is my opinion about the issue, followed up with a question. The second solution seems to be the better one because it does not go against standards. For example, we see extentions like .c, .py and .pl, instead of .c-43, .py-25 and .pl-58. There are ways within the languages to tell which version of the compiler is compiling them as needed. So, If we say that, EAPI 4, for example, requires bash-4.0, Isn't there a way the PM could find out which version of bash is being run, compare that to the EAPI, then take appropriate action? - -- William Hubbs gentoo accessibility team lead willi...@gentoo.org -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkoMkdUACgkQblQW9DDEZTihowCdEynGXsB0Z1r9y43VeWEs9JLF SrQAn2iNPikCR+tZHGyrv+ykr4y1D+81 =6F5i -END PGP SIGNATURE-
Re: [gentoo-dev] The fallacies of GLEP55
On Thursday 14 May 2009 23:53:37 Ciaran McCreesh wrote: On Thu, 14 May 2009 16:49:09 -0500 William Hubbs willi...@gentoo.org wrote: The second solution seems to be the better one because it does not go against standards. For example, we see extentions like .c, .py and .pl, instead of .c-43, .py-25 and .pl-58. There are ways within the languages to tell which version of the compiler is compiling them as needed. So, If we say that, EAPI 4, for example, requires bash-4.0, Isn't there a way the PM could find out which version of bash is being run, compare that to the EAPI, then take appropriate action? It can't, because it doesn't know the EAPI until it's sourced the thing using bash. Using things like += in global scope will break older bash versions to the point that they can't reliably extract EAPI. Trying to pull a Goebbels, eh? As I've said a few times you don't have to do something as complex as sourcing it. In most cases you might get lucky and have some form of caching or pre- parsed data available, so you don't even have to care. And in the other cases, assuming that we're talking about current ebuilds which are shell-ish and either define EAPI explicitly or can be assumed to be EAPI0 you can search with a simple regexp. That's so funky that it even works! So if you were a lazy Unix coder you'd just restrict the current rules a bit so that there's only one line starting with EAPI= allowed (or maybe you just take the first or last one, but that's annoying) and if no such line matches you can safely assume EAPI0 Maybe you're very lazy, so you explicitly forbid eclasses from setting or changing EAPI. That also avoids weird effects that make you lose lots of time for debugging because you didn't think about what would happen if foo.eclass set EAPI=3.14 and bar.eclass inherited later set EAPI=1 ... And magically you haven't really changed current behaviour, can get the EAPI without sourcing it and you can be lazy once more. Isn't it great?
[gentoo-dev] libusb-1/libusb-compat landing - testing and DEPEND changes needed
libusb-1 is in the tree now. This means that you get to go and test all your apps that use it. There's a list further down of all packages and all ebuilds. Every one of these needs to be tested, and amended in one of two ways: - Does work with libusb-compat: 1. Change your [R]DEPEND to virtual/libusb:0 - Does not work with libusb-compat, or you don't have time to fully test right now: 1. Change your [R]DEPEND to dev-libs/libusb:0 (preserve any existing version dependency as well). 2. If it really doesn't work, leave a comment in the ebuild as well as on this thread. Both of these changes require that you move up from EAPI0 to at least EAPI1, where slot dependencies are supported. As part of the migration strategy, I'm going to be going through all of the ebuilds listed here, and just changing them to include the slot dependancy directly on dev-libs/libusb:0 initially, and including a notation that libusb-compat is untested. For the inevitable question, as to why we need to do this, while 99.9% of libusb-applications will be fine, there were specific bad practices that were previously done with libusb-0 that DO break under libusb-compat. They are described in detail in the libusb-compat README. List of packages: = app-accessibility/brltty app-accessibility/gok app-crypt/asedriveiiie-serial app-crypt/asedriveiiie-usb app-crypt/asekey app-crypt/ccid app-crypt/gnupg app-misc/acdctl app-misc/digitemp app-misc/g15daemon app-misc/ifp-line app-misc/lcd4linux app-misc/lcdproc app-misc/lirc app-misc/logitech-applet app-misc/razertool app-misc/rioutil app-mobilephone/bitpim app-mobilephone/gammu app-mobilephone/gnokii app-mobilephone/moto4lin app-mobilephone/obex-data-server app-mobilephone/openmoko-dfu-util app-pda/barry app-pda/coldsync app-pda/pilot-link app-text/calibre dev-embedded/avrdude dev-embedded/ftdi_eeprom dev-embedded/libftdi dev-embedded/openocd dev-embedded/pk2cmd dev-libs/cyberjack dev-libs/libg15 dev-libs/libhid dev-libs/luise-bin dev-libs/openct-.ebuild dev-libs/openct dev-libs/openobex dev-libs/serdisplib dev-util/usb-robot kde-base/kcontrol kde-base/kdebase kde-base/systemsettings media-gfx/gphoto2 media-gfx/iscan media-gfx/sane-backends media-libs/hamlib media-libs/libdjconsole media-libs/libgphoto2 media-libs/libifp media-libs/libkarma media-libs/libmtp media-libs/libnjb media-libs/libptp2 media-sound/ardour media-tv/linuxtv-dvb-apps media-video/isight-firmware-tools net-dialup/umtsmon net-misc/dahdi-tools net-misc/zaptel net-print/hplip net-print/mtink net-wireless/bluez net-wireless/bluez-utils net-wireless/wispy-tools sci-geosciences/gpsbabel sci-geosciences/qlandkartegt-garmindev sci-geosciences/qlandkarte sci-libs/indilib sci-libs/libticables2 sys-apps/hal sys-apps/ifd-gempc sys-apps/lomoco sys-apps/pcsc-lite sys-apps/usb_modeswitch sys-apps/usbutils sys-auth/thinkfinger sys-fs/owfs sys-libs/libchipcard sys-power/nut sys-power/sispmctl x11-misc/ifpgui xfce-extra/xfce4-cellmodem List of all ebuilds: app-accessibility/brltty/brltty-3.10.ebuild app-accessibility/gok/gok-2.24.0.ebuild app-accessibility/gok/gok-2.26.0.ebuild app-crypt/asedriveiiie-serial/asedriveiiie-serial-3.4.ebuild app-crypt/asedriveiiie-serial/asedriveiiie-serial-3.5.ebuild app-crypt/asedriveiiie-usb/asedriveiiie-usb-3.4.ebuild app-crypt/asedriveiiie-usb/asedriveiiie-usb-3.5.ebuild app-crypt/asekey/asekey-3.3.ebuild app-crypt/asekey/asekey-3.4.ebuild app-crypt/ccid/ccid-1.3.0.ebuild app-crypt/ccid/ccid-1.3.10.ebuild app-crypt/ccid/ccid-1.3.1.ebuild app-crypt/ccid/ccid-1.3.5.ebuild app-crypt/ccid/ccid-1.3.8.ebuild app-crypt/gnupg/gnupg-1.4.9.ebuild app-misc/acdctl/acdctl-1.1.ebuild app-misc/digitemp/digitemp-3.3.2.ebuild app-misc/digitemp/digitemp-3.5.0.ebuild app-misc/g15daemon/g15daemon-1.2.7-r1.ebuild app-misc/g15daemon/g15daemon-1.9.5.3-r2.ebuild app-misc/ifp-line/ifp-line-0.2.4.5.ebuild app-misc/ifp-line/ifp-line-0.3.ebuild app-misc/lcd4linux/lcd4linux-0.10.0-r1.ebuild app-misc/lcd4linux/lcd4linux-0.10.1_rc2-r1.ebuild app-misc/lcd4linux/lcd4linux-0.10.1_rc2-r2.ebuild app-misc/lcdproc/lcdproc-0.5.1-r4.ebuild app-misc/lcdproc/lcdproc-0.5.2-r1.ebuild app-misc/lcdproc/lcdproc-0.5.2-r2.ebuild app-misc/lirc/lirc-0.8.3_pre1.ebuild app-misc/lirc/lirc-0.8.3-r2.ebuild app-misc/lirc/lirc-0.8.4a.ebuild app-misc/lirc/lirc-0.8.4.ebuild app-misc/logitech-applet/logitech-applet-0.4_pre1-r2.ebuild app-misc/razertool/razertool-0.0.7.ebuild app-misc/rioutil/rioutil-1.5.0-r1.ebuild app-mobilephone/bitpim/bitpim-1.0.6.ebuild app-mobilephone/gammu/gammu-1.24.0-r1.ebuild app-mobilephone/gnokii/gnokii-0.6.22-r2.ebuild app-mobilephone/gnokii/gnokii-0.6.26-r2.ebuild app-mobilephone/gnokii/gnokii-0.6.27-r2.ebuild app-mobilephone/moto4lin/moto4lin-0.3.ebuild app-mobilephone/moto4lin/moto4lin-0.3_p20051125.ebuild app-mobilephone/obex-data-server/obex-data-server-0.4.4.ebuild app-mobilephone/openmoko-dfu-util/openmoko-dfu-util-.ebuild app-pda/barry/barry-0.10.ebuild
Re: [gentoo-dev] The fallacies of GLEP55
Ciaran McCreesh wrote: On Thu, 14 May 2009 20:06:51 +0200 Patrick Lauer patr...@gentoo.org wrote: You need to know the EAPI to parse the ebuild to find the EAPI Obviously that's not true, because somehow we manage at the moment. And if one does a small restriction (which doesn't restrict current behaviour because all in-tree ebuilds currently fit within this limitation) it becomes trivial again: Let EAPI be defined as (the part behind the = of) the first line of the ebuild starting with EAPI= Uh, so horribly utterly and obviously wrong. inherit foo EAPI=4 where foo is both a global and a non-global eclass that sets metadata. If you're looking for a formally correct alternative that works in the way you suggest, I already provided one, and you already read about it -- and it still doesn't solve the problems that 55 does. It's slower! The theory here being that a stat() is needed if it is encoded in the filename, but a stat() followed by an open() to parse it from the file. Well then, just cache it! You can use the mtime to check the cache validity (which means you do a stat() anyway, so with glep55 caching it is actually slower!), and then you have to parse the ebuild anyway for the other metadata. So the extra cost of finding the EAPI is ... what extra cost? The only case when it is actually slower is when there is no cache because then you have to parse the ebuild. But that degenerate case will only hit some overlay users and people like developers that can wait .3 seconds longer. And ... uhm ... to extract other metadata like DEPENDS you'll have to parse it anyway. Where on earth are you getting the idea that GLEP 55 makes things slower? The only difference to the code with GLEP 55 is in checking file extensions against a slightly larger set of strings, which is nowhere near a measurable increase in anything. You're claiming that checking for a suffix of either .ebuild-4 or .ebuild against a fixed string is in any way relevant, which is obviously trolling. Having GLEP55 allows us to add GLEP54 without issues! Yeah, uhm, the live-ness of an ebuild is an attribute. How about we add it to metadata, as we should for all metadata? Define a key, I don't know ... LIVE ? LIVE=true. There. No need to fix the filename. And now stop mixing up issues because it is highly confusing! There is no existing version ordering solution that accurately represents upstream scm branches. A few words in closing - We can encode all the relevant info in the first line of the ebuild starting with EAPI= No we can't. That's *obviously* completely wrong. The overhead of parsing out this value for all ebuilds in the tree has been timed at ~2 CPU-seconds by solar. It's negligible. Those of us who have been measuring this have been discarding CPU time entirely, since it's utterly irrelevant. That you bring CPU time into this shows you've been deliberately ignoring everything we've said. We all know you're not stupid enough to believe what you've been posting or ignorant enough to miss the point so badly. So please stop pretending -- this issue would have gone through a long time ago were it not for you and your ilk deliberately pretending to be retarded so you can raise straw man arguments against it rather than addressing the issues at hand. You're doing both yourself and everyone else a huge disfavour by acting dumb and assuming everyone else is going to play along with that. Having countered those four points I guess you agree with the other five then. Over 50% success rate (by your definition) is hardly being ignorant or trolling
