Re: [gentoo-dev] Making the developer community more open
On Mon, 2006-03-20 at 15:45 -0800, Bret Towe wrote: perhaps having some proxys of a sort that accept patchs and such from trusted users that would commit fixes to portage would help. similiar to the kernel format that way users can 'commit'/help out quickly without having to go thru the long process of becoming a dev Taking this idea a bit further, what about proxy maintainers? There seem to be quite a few packages that are being effectively maintained by users on bugzilla, but are not in portage because they don't have a maintainer. A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. There could then be a bug for each such package where all the patches, ebuilds and version bumps could be posted. The developer who accepts the package could just take those ebuilds, maybe corrected if necessary, and commit them. If the ebuild breaks, it's up to the developer to fix it. If the package breaks, however, it would be up to the users on the bug to fix it, although of course the developer would be able to fix it if he or she could. If there doesn't seem to be anyone interested in keeping the package working anymore then it could be masked and subsequently removed as packages are now. If there are security problems and the fix is not trivial, it might be sensible to mask the package until someone can fix it rather than waiting for a fix to become available. If the developer working as the proxy disappeared, or retired, then the packages could be assigned back to maintainer-wanted (not maintainer-needed) but left in the tree until they broke, at which point they could be removed again unless anyone wants to pick them up. Similarly, if the users maintaining the package disappeared and the package broke, it could be masked and removed. This would seem to me to add more flexibility, and allow more ebuilds to get into the tree without breaking the tree or causing security problems. The only difference would be that the developer who took the package would not be responsible for making sure the program worked - that would be the responsibility of the users maintaining it in bugzilla. There should probably be some large, friendly warnings to inform anyone installing it that is the case, as well. What do you think? -- Jonathan Coome [EMAIL PROTECTED] Gentoo Forums Moderator -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making the developer community more open
Jonathan Coome posted [EMAIL PROTECTED], excerpted below, on Wed, 22 Mar 2006 10:49:29 +: Taking this idea a bit further, what about proxy maintainers? There seem to be quite a few packages that are being effectively maintained by users on bugzilla, but are not in portage because they don't have a maintainer. A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. [snip the juicy details] I think this sounds very much like the Mandrake contrib packages, back when I was there. It's a decent idea and it seemed to work reasonably well, from a user and active cooker/testing participant. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Unfortunately, for that, portage needs full multi-repository support. Overlays function much that way already, but to do it right, we need multi-repository-update support, and Portage just doesn't have it yet. ... A possible alternative that could be rolled out sooner would be some form of contrib eclass. Make it a simple matter to inherit contrib and get the standard contrib warnings and handling. One thing the eclass could handle would be a USE=contrib flag. With it off, the build wouldn't merge. That would take care of user choice. No non-contrib package could dep on a contrib package so if such a dependency came about, either the non-contrib package would have to be dropped (or at least dropped to contrib status even if it was contributed by a dev), or the dep raised to full support (non-contrib) status. The dependency rule above would by definition mean that nobody could get contrib accidentally, since the only way to get a contrib package would be merging it or another contrib package that depended on it from the command line. This would also solve the interactivity aka broken emerge session issue, since the portage protest and failure would be right up front, before merging started. Making it a use flag would allow control of specific packages thru package.use, just as now, so a user could decide that he trusted one contributor as the author of a specific package (and his opinion of the dep chain) without forcing it to apply to the entire contrib tree. There remains the question of naming. A contrib-cat/package tree paralleling the main category structure would potentially double the categories right there. Not really practical. cat/package-contrib-ver would be more practical, and allow on-sight identification, but would of course necessitate a package rename if the contrib vs. full-supported status changed. This aspect could be debated if the idea in general gains enough favor to consider a glep or the like. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
On 3/22/06, Duncan [EMAIL PROTECTED] wrote: A possible alternative that could be rolled out sooner would be some form of contrib eclass. Make it a simple matter to inherit contrib and get the standard contrib warnings and handling. One thing the eclass could handle would be a USE=contrib flag. With it off, the build wouldn't merge. That would take care of user choice. No non-contrib package could dep on a contrib package so if such a dependency came about, either the non-contrib package would have to be dropped (or at least dropped to contrib status even if it was contributed by a dev), or the dep raised to full support (non-contrib) status. The dependency rule above would by definition mean that nobody could get contrib accidentally, since the only way to get a contrib package would be merging it or another contrib package that depended on it from the command line. This would also solve the interactivity aka broken emerge session issue, since the portage protest and failure would be right up front, before merging started. Making it a use flag would allow control of specific packages thru package.use, just as now, so a user could decide that he trusted one contributor as the author of a specific package (and his opinion of the dep chain) without forcing it to apply to the entire contrib tree. There remains the question of naming. A contrib-cat/package tree paralleling the main category structure would potentially double the categories right there. Not really practical. cat/package-contrib-ver would be more practical, and allow on-sight identification, but would of course necessitate a package rename if the contrib vs. full-supported status changed. This aspect could be debated if the idea in general gains enough favor to consider a glep or the like. Maybe taking a slightly different approach at this same idea is what needs done. Create a new mask level for contrib where anything deemed stable yet unmaintained could go so that users will have access to it without needing to search bugzilla or some third-party site. I would also propose an unstable mask as well where testing ebuilds can go, things that are in bugzilla but have not yet been vetted. The process for getting unstable ebuilds from bugzilla to portage could even be automated to the extent that when an ebuild is put into bugzilla it gets auto committed to the tree but masked unstable. This way all the latest greatest ebuilds are always available in the tree but it requires the user to consciously unmask them for use. You could even add a big red warning for unstable ebuilds to let people know that they should examine the ebuild before emerging... just so if they DO get rooted due to a bad ebuild you can say they where warned. You could further extend the process of emerging unstable ebuilds so that a successful emerge would create a vote for the ebuild in bugzilla (attached to the original ebuild bug) and an unsuccessful emerge would allow the user to add a comment/vote against the ebuild in bugzilla. Perhaps it is a radical approach but that's just my $0.02 on how to open the dev community. -Mike -- Michael E. Crute http://mike.crute.org It is a mistake to think you can solve any major problems just with potatoes. --Douglas Adams -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a big warning/overlay/eclass if they were checked by a developer to make sure they don't do anything malicious, or break QA, or whatever? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a contrib overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with making the developer community more open. Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
The process for getting unstable ebuilds from bugzilla to portage could even be automated to the extent that when an ebuild is put into bugzilla it gets auto committed to the tree but masked unstable. I don't think that auto committing user submitted ebuilds is safe, even if they are masked. For instance, someone could put something malicious in global scope in the ebuild. Stuff in global scope gets interpreted whenever the ebuild is sourced. More info on scope: http://www.gentoolinux.org/proj/en/devrel/handbook/handbook.xml?part=3chap=1#doc_chap3_sect4 -Thomas -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making the developer community more open
Asking developers to proxy takes almost as much time as it does to ask them to maintain a package by themselves. The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. On 3/22/06, Thomas Cort [EMAIL PROTECTED] wrote: A developer could then take these ebuilds, make sure they don't do anything malicious, or break QA, or whatever, and act as the bridge between the portage tree and the users actually working on the ebuild and keeping things up to date and working. The easiest way to handle contrib as far as that big warning is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to risk it, don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Why would the packages need a big warning/overlay/eclass if they were checked by a developer to make sure they don't do anything malicious, or break QA, or whatever? There are many user contributed ebuilds that have made their way into portage after being reviewed by devs that don't have any such warnings. I don't think creating a contrib overlay as an official part of Gentoo would be a good idea because making it an official Gentoo project conveys a certain level of quality. If the quality is there, then why not add the ebuilds to portage in the first place? If the quality isn't there, then you will have a lot of unhappy users complaining that an official Gentoo overlay broke their system. Having a non-Gentoo sponsored contrib overlay wouldn't be a good idea either IMO because the contributors wouldn't be contributing to Gentoo, and they wouldn't be interacting as much with the Gentoo developer community. Sure they would learn a lot of the skills required to be a Gentoo developer, but they wouldn't be increasing the value of anything in portage (unless they got a proxy to commit some of their work to portage). Also, there are many overlays out there already. Adding another one won't help with making the developer community more open. Additionally, I don't personally know of a lot of people who actually use third party overlays except to get an ebuild for a particular package they want or to beta test ebuilds. -Thomas -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
Hi Daniel, On 3/20/06, Daniel Drake [EMAIL PROTECTED] wrote: One of the bigger problems is that we have a huge user community who are keen on contributing, but we have such a high barrier for entry to the developer community. Quite rightly so - we're dealing with a live tree, so we can't give out commit access on the street. At the same time, I feel that we're missing out. Comparing Gentoo with some other large open-source communities that I am personally involved in, I feel that we're too closed. The two big problems are that non-devs don't know where to go to get involved, and if they want to do more than just chat, there isn't anywhere for them to go. I've been very happy with using svn+trac overlays to bridge this gap. They provide a sandbox for contributions to be shared and evaluated. They provide a place where I've been able to give commit access to non-devs, so that they can learn the ropes w/out threatening the Portage tree proper. They provide a place where people who just want to write docs for a single package can contribute. Overlays create a sense of participation that's lacking with Bugzilla patch submissions. Backed up with regular communication (I recommend not recruiting anyone who won't spend time in the IRC channels, but that's a personal preference), they help us get things done quicker. The downside with overlays at the moment is that they're scattered around the net, and if you don't know where to look they can be very hard to find. I've been talking with infra about providing overlays.g.o as a central hosting service for herd and individual developer overlays. Infra have been very supportive of the idea. I just need to free up some time to get the service launched. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Making the developer community more open
On Wed, 2006-03-22 at 09:15 -0500, Dan Meltzer wrote: Asking developers to proxy takes almost as much time as it does to ask them to maintain a package by themselves. The developer is directly responsible for anything he commits, so he will have to still test the ebuild, still test any revisions, and still follow the package to make sure there are no problems. The writing the ebuild part of the process is not that much of the commitment, I don't see the point. Well no, that's not really what I was suggesting. Developers who took on these ebuilds would only be responsible for checking that they don't break the tree and that they do actually work. They aren't responsible for fixing the package when it breaks, or for following its development at all - that's the responsibility of the _users_ maintaining the package. Yes, writing the ebuild is the least part of the process, but there's often a lot more involved, and it's that that's being done in bugzilla at the moment. The way I see it, the developer would only be responsible for the ebuilds, and not for doing everything else. -- Jonathan Coome [EMAIL PROTECTED] Gentoo Forums Moderator -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Security team meeting summary
This is the summary of the IRC meeting the Gentoo Linux Security Team had on Monday, March 20, 20:00 UTC in #gentoo-security (freenode). A raw IRC log of the meeting can be found here: http://dev.gentoo.org/~dercorny/security/sec-meeting-20060320.log Agenda was: --- 1/ Project status a) GLSA team status b) Kernel team status c) Audit team status 2/ Improvements areas a) Maintainers involvement b) Recruitment c) Portage integration d) Other process or policy improvements 3/ Lead(s) election 4/ Public QA 1/ Project status: -- a) GLSA team status The number of late GLSAs (means not delivered within the timeframe given by the policy) drastically increased by almost 50% [1]. Two main causes have been identified: - The GLSA team is operating close or below to the critical mass of GLSA coordinators, which causes delays in certain areas like GLSA voting, drafting and reviewing. - Package maintainer security awareness is bad: sometimes maintainers don't care about security, don't fix bugs in time, don't respond or are completely missing. This causes huge delays in the GLSA processing. Possible methods to resolve these issues are discussed in Improvements areas. [1] http://dev.gentoo.org/~koon/arch_ratings.png b) Kernel team status Just as the GLSA team, the kernel team lacks the sufficient amount of manpower needed to operate as wished. As a result, the KISS project (a system designed to release kernel security advisories), originally thought to go live by 2005, still isn't ready for production use since the manpower to keep it fully updated is lacking. Although KISS is closely tied to the kernel work, a scout and a coordinator, who help finding and handling kernel bugs, are needed to fully implement it. Besides that, a draft of the kernel security policy [2] has been presented, which is expected to reduce the workload for the kernel team while improving the general enduser kernel security awareness. [2] http://dev.gentoo.org/~johnm/files/kernel-security-policy.txt c) Audit team status The overall status of the audit team isn't too bad. Altough the majority of the audit team is quite busy with non-gentoo stuff or inactive, a nice list of high profile security vulnerabilities was discovered. New developers and better coordination within the team could help to improve the speed of the audit project, so that bugs get dealt with faster. 2/ Improvement areas: - a) Maintainers involvement Increasing the security awareness of maintainers is vital to the success of the Gentoo Linux Security Team. Unfortunately, missing or inactive maintainers are a general Gentoo problem. The security team can't deal with that alone because it has no means to punish bad maintainers, thus this has to be brought to the Gentoo council. A powerful QA team could improve the situation by cleaning out unmaintained packages or taking over if a maintainer doesn't reply in timely manner, but this will require changes in the QA policy which are still being discussed. b) Recruitment As mentioned in the status reports above, every team badly needs more developers. Since a lot of recruits drop out during recruitement or vanish after becoming a new developer, it was decided to rethink the recruitement process. The Security Team will now start to actively look for new members, for example by writing an article within the GWN. Also recruits should get more attention of senior developers, so that they feel involved and learn faster. The progress of the recruits should be followed closely, so that they can be upgraded appropriate to their skills, additionally more documentation will be written, for example about GLSAmaker. c) Portage integration A goal of the security project is to integrate glsa-check and other useful security related tools into portage. glsa-check had a lot of improvements recently but unfortunately the portage code is considered as not yet ready for a glsa-check integration. Until this changes, portage 2.1 is expected to bring up some new and interesting features in a security point of view, like security.mask or running glsa-check in a post_sync. d) Other process or policy improvements Nothing special to mention here. 3/ Lead(s) election: - Koon (Thierry Carrez) stepped back from operational lead - Plasmaroo (Tim Yamin) is old and new kernel subproject leader - Taviso (Tavis Ormandy) is old and new auditing subprojet leader - Jaervosz (Sune Kloppenborg Jeppesen) is old and new operational lead - DerCorny (Stefan Cornelius) is new operational lead 4/ Public QA: -- Nothing special to mention here, too. The Gentoo Linux Security team is always open to new ideas or questions. Write an email to [EMAIL PROTECTED] or visit us on IRC, #gentoo-security in the freenode network. EOF -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
Stuart Herbert wrote: I've been very happy with using svn+trac overlays to bridge this gap. They provide a sandbox for contributions to be shared and evaluated. They provide a place where I've been able to give commit access to non-devs, so that they can learn the ropes w/out threatening the Portage tree proper. They provide a place where people who just want to write docs for a single package can contribute. Overlays create a sense of participation that's lacking with Bugzilla patch submissions. Backed up with regular communication (I recommend not recruiting anyone who won't spend time in the IRC channels, but that's a personal preference), they help us get things done quicker. The downside with overlays at the moment is that they're scattered around the net, and if you don't know where to look they can be very hard to find. I've been talking with infra about providing overlays.g.o as a central hosting service for herd and individual developer overlays. Infra have been very supportive of the idea. I just need to free up some time to get the service launched. This definitely sounds like a fun idea. It would be even cooler if we were using a distributed SCM on both ends that allowed for easy merging. Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Official overlay support
On Wednesday 22 March 2006 12:03, Donnie Berkholz wrote:
Stuart Herbert wrote:
I've been very happy with using svn+trac overlays to bridge this gap.
They provide a sandbox for contributions to be shared and evaluated.
They provide a place where I've been able to give commit access to
non-devs, so that they can learn the ropes w/out threatening the
Portage tree proper. They provide a place where people who just want
to write docs for a single package can contribute.
Overlays create a sense of participation that's lacking with Bugzilla
patch submissions. Backed up with regular communication (I recommend
not recruiting anyone who won't spend time in the IRC channels, but
that's a personal preference), they help us get things done quicker.
The downside with overlays at the moment is that they're scattered
around the net, and if you don't know where to look they can be very
hard to find. I've been talking with infra about providing
overlays.g.o as a central hosting service for herd and individual
developer overlays. Infra have been very supportive of the idea. I
just need to free up some time to get the service launched.
This definitely sounds like a fun idea. It would be even cooler if we
were using a distributed SCM on both ends that allowed for easy merging.
I agree, I'd love to see something like this, that way I could have my xfce
stuff someplace more public then my devspacethe only thing that would
have to be clear is how official the overlays actually were, e.g. how prone
the team looking after the overlay would be to accepting bugs via the usual
b.g.o channels etc.
--
Daniel Ostrow
Gentoo Foundation Board of Trustees
Gentoo/{PPC,PPC64,DevRel}
[EMAIL PROTECTED]
pgpwacZblRAun.pgp
Description: PGP signature
Re: [gentoo-dev] Official overlay support
On Wed, 22 Mar 2006 09:03:38 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | This definitely sounds like a fun idea. It would be even cooler if we | were using a distributed SCM on both ends that allowed for easy | merging. Word of warning to anyone planning to implement one of these that includes rsync with cache as a frontend: you will be giving root access to your box to any user with commit access. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Official overlay support
On Wed, 2006-03-22 at 09:03 -0800, Donnie Berkholz wrote: Stuart Herbert wrote: I've been very happy with using svn+trac overlays to bridge this gap. They provide a sandbox for contributions to be shared and evaluated. They provide a place where I've been able to give commit access to non-devs, so that they can learn the ropes w/out threatening the Portage tree proper. They provide a place where people who just want to write docs for a single package can contribute. Overlays create a sense of participation that's lacking with Bugzilla patch submissions. Backed up with regular communication (I recommend not recruiting anyone who won't spend time in the IRC channels, but that's a personal preference), they help us get things done quicker. The downside with overlays at the moment is that they're scattered around the net, and if you don't know where to look they can be very hard to find. I've been talking with infra about providing overlays.g.o as a central hosting service for herd and individual developer overlays. Infra have been very supportive of the idea. I just need to free up some time to get the service launched. This definitely sounds like a fun idea. It would be even cooler if we were using a distributed SCM on both ends that allowed for easy merging. We do this within the Haskell herd and with a small handful of outside contributers. We use darcs for our distributed SCM which makes the merging trivial. If works like so: We keep our testing ebuilds in a shared overlay managed with darcs. The Haskell herd members have write access. Trusted external contributers have write access to the overlay too (mostly people who are in the middle of the recruitment process). The existing devs are of course responsible for actually committing anything to portage cvs. Other contributers have read only access but they can darcs send us patches. These do not automatically get applied (as with our trusted contributers) but get emailed to us and any Haskell herd dev can review and apply patches sent in this manner quite easily. We have found that this system works rather well. It allows our testers and helpers to participate in writing ebuilds which has made the recruitment process smoother. It provides an intermediate phase in the recruitment process where they can participate in the herd's work without any danger of messing up portage cvs. Bugzilla is ok for submitting whole new ebuilds but it's got far too large an overhead for one line patches. Using darcs gives us a very low overhead. We also use the shared overlay as a testing zone for our herd's ebuilds. Our modus-operandi is to commit changes in ebuilds to the overlay, get peer review from other herd members and then commit to portage when we are satisfied. Of course this also makes it easy for our testers to keep up with the latest versions of ebuilds. With the combination of darcs and irc, we can get very quick turnaround on our testers finding bugs to fixing them and getting those changes back to our testers. -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
This definitely sounds like a fun idea. It would be even cooler if we were using a distributed SCM on both ends that allowed for easy merging. Donnie It's probably the right time for me to flesh out what I've been planning for overlays.g.o. The vision I have for overlays.g.o is one official home for all Gentoo overlays run by projects and by individual Gentoo devs. I see the homepage itself running Planet (just like planet.g.o), using the RSS feeds from the overlays to display the changelogs from all the overlays. The links down the left hand side of the page go to the homepage for each of the overlays. The homepages are separate wiki instances. http://overlays.g.o/proj/project-name/ for overlays run by herds listed in herds.xml http://overlays.g.o/svn/project-name/ for the SVN repos and http://overlays.g.o/dev/developer/ for overlays run by individual developers http://overlays.g.o/svn/developer/ for the SVN repos There's a practical limit to the amount of software we can support on overlays.g.o. The less we install, the less the overhead of administrating this system for infra and the overlays admin team (I'm looking for responsible volunteers to join that team, if you're interested). I'd like to offer two wiki engines and two version control systems on overlays.g.o. I believe that gives us enough choice without us loading the box with too much software for us to keep on top of. One thing that was never planned was any form of shell access to this box, except for the team creating/destroying overlays. It looks like this will be necessary to support a distributed vcs. I'll talk to infra and see what we could do about providing some form of ssh access to help us support a distributed vcs. Trac and SVN would be my first choice. MoinMoin would be my recommendation for the second wiki engine. What should the second version control system be? I don't use them, I have no experience with them, and so I have no preference of what this should be. To answer Daniel's question about official ... the overlays hosted on overlays.g.o would be official. The overlays project will be accountable for overlays.g.o overall. It would make sense for the overlays project to be a sub-project of infra. To ensure officialness and (what I personally care more about) accountability, project overlays will be created for projects that meet the description of a project in the metastructure [1]. The overlays team will have to be strict on this, to ensure officialness. The overlay must be requested by one of the leads of the project. The lead(s) would be jointly accountable for the overlay and all its contents. Leads will be able to ask for commit / wiki edit access for non-devs. Developer overlays would only be created for active Gentoo developers, and they would be accountable for its contents. Non-developers will not be given write access to developer overlays. By default - working on the same principle of trust that governs all developers w.r.t. the Portage tree - all developers will be able to commit to all overlays. If we can't trust you to respect other people's overlays, then we can't trust you with commit access to the Portage tree, and you're not fit to be a Gentoo dev in the first place :P The only restriction will be that you'll need to ask the overlay project team to setup your access the very first time. Anyone wanting a secret overlay needs to make their own hosting arrangements. To answer Daniel's other question, about bugs.g.o ... trac on overlays.g.o will have its bug tracking system disabled. We already have one bug tracking system - bugs.g.o - and that's sufficient. [1] http://www.gentoo.org/proj/en/glep/glep-0039.html Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Modular X: unmasking tonight, RFC
Hi all, There aren't really any remaining blockers to keep modular X out of ~arch, as far as I can see. If anyone's got one, please bring it up now. I'm planning to unmask later tonight. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On Wed, 2006-22-03 at 15:16 -0800, Donnie Berkholz wrote: Hi all, There aren't really any remaining blockers to keep modular X out of ~arch, as far as I can see. If anyone's got one, please bring it up now. I'm planning to unmask later tonight. If modular X is used and gnome-base/control-center is not patched.. gnome-settings-daemon on some evdev combinations... Not sure if that's a blocker... but we should rush in a new version of control-center with the patch Ref: http://bugs.gentoo.org/show_bug.cgi?id=116195 Btw, how many ebuilds are left to be ported ? -- Olivier Crête [EMAIL PROTECTED] Gentoo Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On Mar 22, 2006, at 4:13 PM, Olivier Crete wrote: If modular X is used and gnome-base/control-center is not patched.. gnome-settings-daemon on some evdev combinations... Not sure if that's a blocker... but we should rush in a new version of control-center with the patch Nah, not a blocker for unmasking. Most people aren't even using the evdev driver, they're using keyboard and mouse. Ref: http://bugs.gentoo.org/show_bug.cgi?id=116195 Btw, how many ebuilds are left to be ported ? Less than 130, that's what it was some days ago. Haven't checked more recently. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On Wednesday 22 March 2006 19:59, Donnie Berkholz wrote: On Mar 22, 2006, at 4:13 PM, Olivier Crete wrote: If modular X is used and gnome-base/control-center is not patched.. gnome-settings-daemon on some evdev combinations... Not sure if that's a blocker... but we should rush in a new version of control-center with the patch Nah, not a blocker for unmasking. Most people aren't even using the evdev driver, they're using keyboard and mouse. i know last time i upgraded, the evdev driver was broken to crap anyways ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X: unmasking tonight, RFC
On Wed, Mar 22, 2006 at 08:20:01PM -0500, Mike Frysinger wrote: On Wednesday 22 March 2006 19:59, Donnie Berkholz wrote: On Mar 22, 2006, at 4:13 PM, Olivier Crete wrote: If modular X is used and gnome-base/control-center is not patched.. gnome-settings-daemon on some evdev combinations... Not sure if that's a blocker... but we should rush in a new version of control-center with the patch Nah, not a blocker for unmasking. Most people aren't even using the evdev driver, they're using keyboard and mouse. i know last time i upgraded, the evdev driver was broken to crap anyways ;) The evdev kernel driver, or evdev X driver? thanks, greg k-h -- gentoo-dev@gentoo.org mailing list
[gentoo-portage-dev] python trace support for --debug mode
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I've written a patch [1] that adds support for tracing python. It uses pythons debugger hooks [2] to trace execution events (mostly function calls and returns). The patch causes python tracing to be enabled in --debug mode if python-trace is in features. This feature will be a useful troubleshooting tool, especially for problems occurring withing the python parts of portage that are reported by users but we are unable to reproduce locally. We can simply ask the user to do a --debug run with FEATURES=python-trace and hopefully the resulting trace will give us the information necessary to diagnose the problem. The trace output currently includes file name, line number, event type, and a dictionary of local variables. When the representation of a local variable is greater than a maximum number of characters (currently 200), the value of the variable is omitted in order to prevent the output from getting too large (hundreds of megabytes). With a minimal ebuild compilation and install, expect about 70MB of output that will compress to about 1.5MB with bzip2. I'd like to merge this patch soon (by Friday, for release in 2.1_pre7). Feedback would be appreciated. Zac [1] http://dev.gentoo.org/~zmedico/portage/branches/2.1/patches/portage_debug/portage_debug.patch [2] http://docs.python.org/lib/debugger-hooks.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEIQgh/ejvha5XGaMRAt+aAJ9OLRx/PnqgP+gGlzWXetb76MQQXwCbBxWP hibXI9uFbxc9Pz6Cki6xOLo= =DrWx -END PGP SIGNATURE- -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] [PATCH] lirc-0.8.0 with kernel 2.6.16
Paul Marks wrote: Paul Marks wrote: I couldn't get my lirc-0.8.0 to compile with the new kernel 2.6.16, so I pulled a couple files out of CVS and generated this patch. It works for me on 2.6.16 now. Sorry, I think I may have sent this to the wrong list. I better go read more carefully and figure out where this is supposed to go. This should go on https://bugs.gentoo.org. Please fill a new bug report with attached patch. -- Karol 'sekretarz' Wojtaszek [EMAIL PROTECTED] Gentoo Developerhttp://www.gentoo.org/ GnuPG key id# A3C247FA available from http://pgp.mit.edu Key fingerprint = 4829 0B0F 9533 4D93 344E CE75 B9BE 3ECD A3C2 47FA signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] DB and binary dependency
I was thinking about it, too, and found something i do like maybe more. It would be not binary, but code dependancy. This is limited to specific languages, then, but after all, there may also be different binary dependencies, too [for example, you may depend on fonts images from another package]. Ok, my thought is like that. Lets imagine a simple c file: #ifdef usepackagex #include packagex.h #endif As it is simple to see, this file could be used to calculate non-binary dependency, inluding useflags. And there is a plus -- tool, which just reads those #ifdef's and #includes, could easily understand, which flags make up which dependancy, without building package again and again with different useflags. PS. i dont mean X by packagex, but rather a random pack. I write here as if #define always includes useflag name - i may be wrong, but it doesnt make a huge difference. Sure, there are #ifdef's in code, which should not read, so we must have an array for legal useflags - but this is also not important in my explanation. Lets add some custom comment syntax (line numbers are given for explanation): 1. #ifdef usepackagex 2. /* Portage: packagex.h = abc-def/packagex = 1.0.2 */ 3. /* Portage: use fonts/customfontpackage */ 4. #include packagex.h 5. #endif Now, what a parser does: Start parse: setup empty array UseFlags = [] Line 1: #ifdef usepackagex Add useflag name into useflags array: UseFlags = ['usepackagex'] Line 2: /* Portage: packagex.h = abc-def/packagex = 1.0.2 */ This line maybe outside of any #ifdef's as well, but in our small application there is no external conf.c file ;) Dictionary 'Links' will contain a notice that whenever packagex is included, it must be at least version 1.0.2 of package abc-def/packagex. Line 3: /* Portage: use fonts/customfontpackage */ Dependancy on fonts/customfontpackage, therefore add to dependancies: [['usepackagex'], 'fonts/customfontpackage'] Line 4: #include packagex.h Dependancy on fonts/customfontpackage, therefore add to dependancies: [['usepackagex'], 'abc-def/packagex = 1.0.2'] Line 5: #endif Remove 'usepackagex' from useflags: UseFlags = [] 2006/3/22, Gustavo Sverzut Barbieri [EMAIL PROTECTED]: On 3/20/06, tvali [EMAIL PROTECTED] wrote: 2006/3/20, Gustavo Sverzut Barbieri [EMAIL PROTECTED]: I do think you're overcomplicating things where you shouldn't. Declaring stuff manually will always break, and to ensure a safe system, it's better to use compiler information. In all cases, dependancy should be based on interfaces, not code. All packages may: * Provide an interface * Use an interface Depending on useflags, OS and other compile options, it differs, which interfaces are provided and used. This is, abstractly, what portage does with interfaces. If portage uses some interface, it may need it's header files when building. It may also need another lib for static build. This means that binary check is not possible in all cases. Now, the problem is: * How to get an information about a package, which specifies exactly, which interface is needed. How to get it before building in case when this interface is needed to be emerged before compilation [before linking everything together, at least]. Which is a form of this information and what could be read out from that? * How to get information about which interfaces are provided by which packages *not yet emerged* -- by their current use flags(?). This means that it must be possible to know, which interfaces are provided by packages, without first building it -- and the form given by binary check must be the same as the form of descriptor used by this package check. So, how to get correct provider together with correct client?Ok, I agree with you that this would be the perfect solution, but it would demand too much effort to have this right.I'm not proposing the final-perfect solution, just something betterthan we have now. It would not cover every case, but would cover mostcases in a satisfactory way. --Gustavo Sverzut Barbieri--Jabber: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] ICQ#: 17249123 Skype: gsbarbieriMobile: +55 (81) 9927 0010 Phone:+1 (347) 624 6296; [EMAIL PROTECTED] GPG: 0xB640E1A2 @ wwwkeys.pgp.net--gentoo-portage-dev@gentoo.org mailing list-- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. Williams If you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[ http://www.softwarequotes.com/ ] - http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S. - http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry
Re: [gentoo-portage-dev] DB and binary dependency
I hope you did read my previous mail of code dependancy -- if not, it's at the end of message. This here is not so much overthought thing, but a good starting point, maybe, if code deps are used. Anyway, i give here the same idea in more complete form and good syntax (good, because it could be added to compilers, for example): /* As compiler may give warnings or errors otherwise, portage code parses defines portage-providers. */ #ifdef runasdaemon #ifdef portage-providers #provide interface customdaemon /* if provided *as*, then does not actually provide anything before include clause */ #use interface daemonheaders 1.0.2 as dhead.h /* when test.h is included, depends on dev-apps/test at least version 1.0.2 */ #provider-atom test set package=dev-apps/test #provider-atom test set version=1.0.2 /* require testflag to be set */ #provider-atom test need useflag testflag Hello world! /* require testflag2 to be unset */ #provider-atom test hate useflag testflag2 Testflag2 bad :( /* have some good taste in warnings */ #provider-atom test warn useflag testflag3 Test warning! #provider-atom test ask useflag testflag4 Testflag4 good :) #use atom test as test.h #provider-atom otheratom set package=dev-apps/otherpackage /* if runasdaemon, otheratom will be required */ #use atom otheratom #endif #ifdef something /* if runasdaemon and something, daemonheaders 1.0.2 is needed */ #include dhead.h /* if runasdaemon and something, atom test is needed */ #include test.h /* atoms could be provided as well; interface is a simple atom with few params; just test.h could be provided, also: */ #ifdef portage-providers #provide header welcome.h #use header someheader.h #endif #endif #endif2006/3/22, tvali [EMAIL PROTECTED]: I was thinking about it, too, and found something i do like maybe more. It would be not binary, but code dependancy. This is limited to specific languages, then, but after all, there may also be different binary dependencies, too [for example, you may depend on fonts images from another package]. Ok, my thought is like that. Lets imagine a simple c file: #ifdef usepackagex #include packagex.h #endif As it is simple to see, this file could be used to calculate non-binary dependency, inluding useflags. And there is a plus -- tool, which just reads those #ifdef's and #includes, could easily understand, which flags make up which dependancy, without building package again and again with different useflags. PS. i dont mean X by packagex, but rather a random pack. I write here as if #define always includes useflag name - i may be wrong, but it doesnt make a huge difference. Sure, there are #ifdef's in code, which should not read, so we must have an array for legal useflags - but this is also not important in my explanation. Lets add some custom comment syntax (line numbers are given for explanation): 1. #ifdef usepackagex 2. /* Portage: packagex.h = abc-def/packagex = 1.0.2 */ 3. /* Portage: use fonts/customfontpackage */ 4. #include packagex.h 5. #endif Now, what a parser does: Start parse: setup empty array UseFlags = [] Line 1: #ifdef usepackagex Add useflag name into useflags array: UseFlags = ['usepackagex'] Line 2: /* Portage: packagex.h = abc-def/packagex = 1.0.2 */ This line maybe outside of any #ifdef's as well, but in our small application there is no external conf.c file ;) Dictionary 'Links' will contain a notice that whenever packagex is included, it must be at least version 1.0.2 of package abc-def/packagex. Line 3: /* Portage: use fonts/customfontpackage */ Dependancy on fonts/customfontpackage, therefore add to dependancies: [['usepackagex'], 'fonts/customfontpackage'] Line 4: #include packagex.h Dependancy on fonts/customfontpackage, therefore add to dependancies: [['usepackagex'], 'abc-def/packagex = 1.0.2'] Line 5: #endif Remove 'usepackagex' from useflags: UseFlags = [] -- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. WilliamsIf you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[ http://www.softwarequotes.com/ ] - http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S. - http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry
Re: [gentoo-portage-dev] DB and binary dependency
On Wed, 2006-03-22 at 19:40 +0200, tvali wrote: I was thinking about it, too, and found something i do like maybe more. It would be not binary, but code dependancy. This is limited to specific languages, then, but after all, there may also be different binary dependencies, too [for example, you may depend on fonts images from another package]. Ok, my thought is like that. Lets imagine a simple c file: #ifdef usepackagex #include packagex.h #endif As it is simple to see, this file could be used to calculate non-binary dependency, inluding useflags. And there is a plus -- tool, which just reads those #ifdef's and #includes, could easily understand, which flags make up which dependancy, without building package again and again with different useflags. There are a few reasons why this won't work :-) First: What if I have assembler? python? perl? Your example is limited to the C preprocessor. Second: You'll have to get this depend information applied by upstream unless you want to patch every file ... and as upstream I'd laugh at anyone proposing that Third: Since there is no easy way of generating this automatically you'll have to replicate every bit of dependency information that is in the ebuilds. That will be much work, you won't keep ebuilds synchronized to the included dep info ... So in short, interesting concept, but I don't see how it can work and how it is an improvement over what we have now. Please don't reinvent the wheel ;-) Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] DB and binary dependency
2006/3/22, Patrick Lauer [EMAIL PROTECTED]: There are a few reasons why this won't work :-)First: What if I have assembler? python? perl?Your example is limited to the C preprocessor. Yes that i did tell there that it's limited to c already :) but bin dep, after all, is limited to lib dependencies and probably just .so files -- which means probably not python (as it's too dynamic to programmatically understand, where and which libs are used), not perl (as it doesnt have binaries). So i dont see my version being much worse than bin. If you have an assembler, then everything depends on which one you have. If that's internal assembler of c, everything works fine ;) If that is some macro-assembler, then there is a bit different syntax from c, but other code is basically the same (parsing needed information out from assembler code is not too hard). If that's python, then you cant anymore make it so simple -- there is nothing like #define in python, as it's dynamic. In python, you have several ways -- adding dependencies in classical way; adding a *.c file, which talks about dependancies or making some python script, which is able to tell on what it depends -- the last way has the same weakness with bin dep that it should be downloaded before. About perl, i dont know enough to tell, how it could be used there, but anyway, as it is scripting language, i think that smth similar to py applies. I think that there could be simple dependency builder for packages, which will be compiled, but not for dynamic languages. There is no simple way in dynamic languages for knowing, which libs will be used, even if you know the useflags or have them built into pyc files. As code deps are only my thought about repairing the biggest bottleneck in bin-dep - that you cant say anything about deps of a random combination of flags without rebuilding with excactly that combination -, i am not trying to make it usable in dynamic/scripting languages. Second: You'll have to get this depend information applied by upstreamunless you want to patch every file ... and as upstream I'd laugh at anyone proposing that This is actually simple build. I just told about method, which would allow you to include dependancy metadata directly in c code. It could be compiled into current portage dependancy data as well. Third: Since there is no easy way of generating this automaticallyyou'll have to replicate every bit of dependency information that is in the ebuilds. That will be much work, you won't keep ebuilds synchronizedto the included dep info ... Data in ebuilds should be generated from that data. So in short, interesting concept, but I don't see how it can work andhow it is an improvement over what we have now. Please don't reinvent the wheel ;-) Yes, if it comes to wheels, i better try to invent a better wheel, not reinvent an old wheel ;) PS. in my last example, i dont show how useflags are related to #defines. That's because i guess that it must be already described somewhere and have not to be in c code :) I hope it is so ;) Patrick--Stand still, and let the rest of the universe move-BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)iD8DBQBEIZTiqER3hOUoZM4RAkEtAJ913WnthMPjRZrUGQCgYnOw9Xcu7ACeO1DhVKWKYb6XcDuugBJSSBFMgc0==xD2e-END PGP SIGNATURE- -- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. WilliamsIf you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[ http://www.softwarequotes.com/ ] - http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S. - http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry
Re: [gentoo-portage-dev] DB and binary dependency
As an addition to code deps discussion. I didnt understand exactly, why bin deps were supposed to be better than what we have now, as i am not yet exactly sure what we have :) Anyway, i see one basic plus of code deps. It's that you may have huge number of codelines, all containing #defines and #ifdefs. You may know that whenever it uses ?.h header, it needs library ? -- but when you need ?.h may be somewhat complex case. There may be, for example, 40 different .h files of your own, which include ?.h file -- and each of them may be included only if corresponding useflag is set. In such case, it's easier to describe, which package you need when ?.h is used than to write all those if's twise in code and some other place, which make sure if you need that ? pack or not. I havent done such thing in reality, so i dont know, how big problem it is for a programmer (how much you have that situation i described in real life), but i guess that this is the problem what binary deps were supposed to solve. -- tvaliFrom a programmer's point of view, the user is a peripheral that types when you issue a read request.-P. WilliamsIf you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave.-Ed YourdonWe all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall[ http://www.softwarequotes.com/ ] - http://www.softwarequotes.com/ShowQuotes.asp?ID=544Name=Borenstein,_Nathaniel_S. - http://www.softwarequotes.com/ShowQuotes.asp?ID=571Name=Boehm,_Barry
Re: [gentoo-portage-dev] Re: User created package lists
On Tue, 2006-21-03 at 10:50 -0600, MIkey wrote: tvali wrote: So, if portage would be looked as lists and operations with lists (calculating dependencies of package would be operation with list of that package and list of all - portage tree -, then); building tools [shell commands] for creating those lists and tools for operations with those lists and leaving emerge tool just a handy interface to command them would be imho great. For a completely re-vamped portage, broken up into many smaller modules check out the pkgcore development. http://gentooexperimental.org/~ferringb/bzr/pkgcore/ What about something along these lines... Add the capability for emerge to take a category as an argument, emerge www-apps for example, and emerge all packages within that category. Optionally make it so this will only work on categories within PORTDIR_OVERLAY, or create a new type of overlay, LIST_OVERLAY. Then the user can create overlays with their own category names and symlink in the package directories they want from the real portage tree. I think you both are making it more complicated than it needs to be. Creating meta packages listing all the deps etc. may make portage work for emerges but won't give a user the heads up when one of those deps are upgradable so easily. Marius has stated that user package lists are to be supported in the future (OK), Porthole will have the ability to get ahead of portage because it is not concerned with the direct merging/unmerging of packages and system management. It is merely a way to display package data and ask portage (emerge) to merge/unmerge packages. So back to my original question: Will user created lists be located in the /etc/portage directory along with the other user configs? If so will the format be similar to the package.* files? For user package lists I imagine there could be the need to control version ranges, so the standard atoms should somehow apply. I would like to try and get as close to a portage format as can be foreseen so that it will require less updates/re-coding later when that feature is implemented. eg. /etc/portage/lists/ This directory would hold any number of user created lists. I am not sure that additional subdirectories would be desired or needed. After all this feature would be to help simplify some tasks, not make ones head explode trying to follow something overly complex. /etc/portage/lists/userlist1 format: net-www/apache www-apache/mod_perl ... How would you atomize a version range? =, =, =, , for one ended range limits the existing format from package.* files could be used. eg. limit net-www/apache to version 2 only? Lets pretend a version 3 is already released, so there could be versions series1, series 2, series 3. =net-www/apache-2.0.0 =net-www/apache-2.99.99 www-apache/mod_perl ... Where the upper range limit would immediately follow the lower range limit Or would an fstab type format be used. More available options could be easily assigned. # package lowest-version highest-version updates net-www/apache 2.0.0 2.99.0 M,K Where updates could be one or more of M manual, A automatic, N never, K binary packages only. It would not be that hard to implement features like the updates field and range limits in porthole. Since it is not feasible in the current portage code-base, a wrapper module/script could be made to implement it for cli. -- Brian [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
