Re: [gentoo-dev] Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
Ciaran McCreesh wrote: ..and it means we can't change name or version rules. Why? Just parse the EAPI out of the file before you interpret the version and name from the filename. Indeed - you could have a future EAPI remove the name and version from the filename entirely. If a package manager doesn't understand the EAPI in a file it shouldn't do anything at all with it. ..and it means over doubling the best possible time to work out a dependency tree in the common case where the metadata cache is valid. I can see why it takes an extra pass - but does that mean a doubling of time? Couldn't the EAPI be cached as well to reduce disk access? ..and it means we can't make arbitrary format changes. Well, you would need to preserve the EAPI in the header, but other than that you could actually turn an ebuild into an otherwise completely binary file, or whatever. Just how much more flexibility than that is needed?
Re: [gentoo-dev] Collecting opinions about GLEP 55 and alternatives
Petteri Räty wrote: 3) EAPI in locked down place in the ebuild - Allows changing global scope - EAPI can't be changed in an existing ebuild so the PM can trust the value in the cache I don't see how this follows. The PM can compare the mtime on the file with the time the cache was updated and refresh if needed. Or we could require users to manually refresh the cache if they modify an ebuild. - Does not allow changing versioning rules unless version becomes a normal metadata variable I don't see how this follows. You can put any version in the filename that you like just as with the EAPI in the filename approach. A package manager won't process the filename if it doesn't understand the EAPI. The order of processing for a package manager would be: 1. Scan for files named *.ebuild. 2. Scan the nth line inside to obtain the EAPI. 3. Take further action in accordance with the EAPI - possibly including obtaining the package name/version from the filename, or maybe somewhere else entirely. * Needs more accesses to cache as now you don't have to load older versions if the latest is not masked Why wouldn't you cache every version of a package with its EAPI for reference? I don't follow why this needs more cache hits. However, even if you had to hit the cache more often I don't see why a cache lookup would be expensive. Isn't it stored in a sensible format for rapid random access? My preference is obviously for embedding the EAPI inside the file in some manner. My second preference would be for only changing the file extension on rare occasions that are individually approved by the Council when things need to change dramatically, as opposed to any time the EAPI changes.
Re: [gentoo-dev] Re: Collecting opinions about GLEP 55 and alternatives
Duncan wrote: So putting it in the manifest but generated from the ebuild info really doesn't change the problem, leaving us precisely where we were before, except that it may be useful as a component of one of the other solutions, and has been proposed as such in a few of the suggested variants. I think that it does address ONE aspect of the limitations of putting EAPI in the build - but not all. One issue with EAPI in the build is figuring out what it is without sourcing the ebuild (possibly using a package manager that doesn't realize that it doesn't know how to source it). If the developer of an ebuild prepares the manifest, then at least their package manager will know how to handle the ebuild and extract the EAPI. Now, that could still be messy if it needs to source the ebuild 3 ways before finding the one that delivers the correct EAPI. However, end-user package managers wouldn't need to source the ebuild to figure out the EAPI. Potentially the developer could just manually put the EAPI in the manifest (or use a tool to do this). Obviously this is an extra step when adding ebuilds to the tree, but that would completely address the issues with sourcing builds. Changing the manifest format of course creates backwards compatibility issues. So, I wouldn't dismiss this idea out of hand - it isn't completely equivalent to the other options.
Re: [gentoo-dev] devs on IRC (was :Regen2 ( was QA Overlay Layout support ))
Donnie Berkholz wrote: On 14:05 Fri 13 Mar , Michael Higgins wrote: Even if they are, an IRC log is a *terrible* way to document an issue. I agree. So is a mailing-list archive that is also never summarized. It's not the location that makes it a problem, it's the volume of information and the lack of a summary of important decisions or long, important discussions. I certainly don't consider the use of IRC harmful per-se or consider it a cabal, but I can't consider IRC and an unsummarized mailing list equivalent communication mediums. If I want to know what is going on in IRC I need to leave a client connected 24x7 (and if my connection goes down for whatever reason I just miss whatever happens). Then I need to read through thousands of lines of banter to see what is going on. If I want to know what is going on in a mailing list I launch my threaded email client. If a computer goes down SMTP, IMAP, and various redundant servers will eventually get the messages to me. The discussion is threaded and categorized by topic, so I can mercilessly hit delete and not have much risk of missing something I'm interested in. Essentially even an unsummarized mailing list is fairly well summarized compared to IRC. Don't get me wrong - I like the team-building aspects of IRC. However, it is not a good communication medium when you're dealing with volunteers that might only spend a few hours per week total working on Gentoo (or maybe only a few hours per month), spread across 24 time zones. It is perfect for realtime collaboration on solving specific problems. It is also great for brainstorming ideas, and just having fun. Unfortunately, it also shares certain drawbacks with the phone - for starters it tends to prioritize tasks by urgency rather than by importance. It also encourages shooting from the hip - just like having meetings without an agenda, pre-discussion, and general preparation. No problem for trivial tasks, but not a good idea when making final decisions of strategic importance. However, if certain work takes place exclusively on IRC then you're going to exclude some people. Many of those people could be strong contributors but they might not like working in realtime. This might not be because of communication skills/etc - maybe they have a family and they'd rather see what needs to be done and take care of it here and there without being given an assignment and having 10 other people bugging them about whether it is done yet when they have 14 other things to do. Sure, such a dev is probably not a good candidate to be leading a major Gentoo project, but that doesn't mean that they have little to contribute. For example, I typed this email in one sitting but I could have just as conveniently taken 3 days to piece it together in 5 minute bursts. I'd consider the current council format a good example of how IRC can be used in conjunction with mailing lists, agendas, and scheduled meeting times. IRC can be used to finalize thinking and make decisions. It can also be used for informal discussion anytime before a meeting. Much of the serious contribution is captured on mailing lists, however, and when decisions are made it is based upon the widely-gathered input. Everybody knows what decisions are going to be made in advance and can show up if desired. If they can't show up they can at least contact council members in advance (and the world at large) to state their opinions. This certainly doesn't need to be used for every tiny Gentoo decision - but it is a great model for how to handle things of importance.
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Andrew D Kirch wrote: I reject the premise that war should always be prevented. I am however concerned that criticism where criticism is due is flame baiting. The original post did not contain any constructive criticism of paludis at all. It simply stated that under no circumstances should anybody ever adopt anything that was done first in paludis. That is simply flamebait. If you think there is a good reason not to have an emerge --info package feature by all means state it. However, let's discuss issues based on their merits -- preferably their technical merits. I fully acknowledge that other non-technical aspects of decisions also matter, but they need to be talked about constructively. Ironically the relationship between the paludis and portage camps is probably the best I've seen it in the last year or two. Maybe I just don't get on IRC often enough. :) I think that taking these steps is a good move. Package maintainers should be focusing on the ebuild's environment and not the particular program being used to invoke the ebuild. If it becomes clear that the problem is that a package manager isn't complying with the PMS then by all means point fingers at the guilty parties. Gentoo is about choice...
Re: [gentoo-dev] EAPI 3 PMS Draft
Ciaran McCreesh wrote: Most packages that have tests have working tests. For those that don't, the tests have to be restricted. All this proposal does is ensures that that happens in a progressive, incremental and safe way. I agree with this point - failing tests are more the exception than the rule. Looking at my system the only packages I'm skipping tests for are: openldap|parted|orbit|samba|kpilot|nautilus|libksieve|karm|libbonoboui|gnome-vfs|pkgconfig|pam|coreutils|pan|mono|glibc|gettext|curl Some of those might be fixed now. If packages are failing tests, either it's a legitimate reason, in which case it needs to be fixed, or it's not, in which case it needs to be restricted. The problem is, currently there's no way for users to know which is which. With an EAPI mandated src_test, users will know that any failure that gets to them is legitimate. Hence my having the list posted above (which is just the ones I use that I've found problems with). I also would like to say that the slow-test compromise sounds like a good idea. A fast-running automated test routine is a good sanity check to show that nothing went wrong during the build. Maybe the user has some odd version of a dependency that no developer checked with the new package. Arch testers can't test every combination of dependencies, configurations, use-flags, etc. I would think that this might even cut down on user-reported issues. Better to find out that a package has a problem BEFORE it is actually installed. If a user is going to spend 10 minutes building a bunch of packages spending another 30-60 seconds on some basic tests doesn't sound unreasonable. We could also make it easy for users to disable testing entirely if they want to live dangerously.
Re: [gentoo-dev] `paludis --info' is not like `emerge --info'
Ciaran McCreesh wrote: This isn't a usability request. Making the use paludis --info cat/pkg text stand out more was a usability request, and I was happy to make that change. This is a few noxious trolls whining in an attempt to cause trouble. For those who have concerns with the paludis output - is there anything present in emerge --info that the paludis output omits? I'd see that as a completely legitimate concern. Also - if a better way of organizing the paludis output would make it easier to find what you're looking for I'd think that would be a constructive piece of criticism. It does seem a bit odd to ask somebody to imitate the emerge formatting of the output just to say that it matches. If somebody wants to create a script to do it they can post it online so that everybody who cares can run it and not have to look at evil paludis output... :) Now, if were were talking about data that was an input to some kind of automated routine then that would be a different story. However, in that case we might start by xmlifying it or something...
Re: [gentoo-dev] Gentoo Council Reminder for April 23
Mart Raudsepp wrote: So my point is that the whole of the council should consider the objections of an individual council member, so that potentially bad things don't end up accepted based on some kind of an uninformed majority vote or concensus. Probably the best way to accomplish something like this is for a council member to publish their no vote BEFORE the actual council meeting so that there is actually time to discuss it. The actual council meeting isn't really a great forum to resolve issues - there just isn't that much time. I appreciate the fact that council members are avoiding huge amounts of back-and-forth on the mailing list, but waiting until the last minute for a surprise no vote isn't helpful either. I think one of the great things Donnie has done for the council is to push the discussion into the mailing list well in advance of the meeting, and to defer issues that haven't gotten properly hashed out on-list. If something really needs interactive discussion that is one thing, but going into a topic cold just results in a lot of shooting from the hip and not much constructive progress.
Re: [gentoo-dev] Retiring
Markos Chandras wrote: I am sure that you know them. But those problems are the reasons why more and more developers are demotivated and leaving Gentoo. 'Fixing' those problems should be a N1 priority on every gentoo council meeting until they are gone. There is absolutely no point in trying to introduce new features and stuff when we are so understaffed. First we need to bring more people on Gentoo and keep the current manpower motivated. When we are done with that, we can focus on features :\ While I see where you are coming from, I can't agree with the approach of halting all forward movement until all current issues are resolved. The problem is that we're a volunteer-driven organization, so we can't simply tell people close STABLEREQ bugs first, work on fun stuff later. We can certainly encourage people to do this, but there will ALWAYS be more maintenance items and I think we'll do better to keep Gentoo exciting and dynamic and try to attract more help, and then there will be more bodies around to take care of the grind of bugs. Essentially features are what keeps a significant portion of the current manpower motivated. Now, there are lots of people around who actually like doing maintenance and caring for specific packages, and we should certainly try to find more people like this. However, those who would rather be implementing new EAPIs in Portage/Paludis/Pkgcore/whatever won't necessarily work on arch bugs just because there is a need for this. I think the best we can do is try to highlight the issues so that those who are interested are aware of them and can sign up to help. I'd also love to see the council and trustees actively looking for solutions to these problems, but it can't be the only issue on the agenda. I've never been big on the whole Gentoo is dying meme. All people and organizations are dying - we're all born dying. Death is just the natural state of the universe in the absence of life. Even if Gentoo were perfect and full of activity we would have people leaving for various reasons - the key is to have people coming in to replace and even surpass those who leave. Gentoo has a LOT to offer the linux community - and if anything I'd say the level of innovation in Gentoo (and related projects) has been trending upwards in recent months.
Re: [gentoo-dev] license issue with fretsonfire
Arun Raghavan wrote: As for the songs, does it make sense to put that in a separate package that the code package depends on? The package can have the restrictive license it is distributed under and RESTRICT=mirror bindist. That was my first thought as well - just split out the songs and restrict mirroring. This also works well if more open community-based songs come out - just add packages for them.
Re: [gentoo-dev] Retiring
Markos Chandras wrote: Even a volunteer-driven organization needs some standard rules in order to survive. From time to time this volunteer moto is what some people consider as anarchy As far as survival goes - I think the rumors of Gentoo's death are greatly exaggerated. I certainly agree that we need standards, but as far as I can tell those exist. I'm not exactly sure what the actual problem is. What resolvable issue is directly impacting the Gentoo community, and how would things actually be better if that issue didn't exist? What is the itch that needs scratching? I don't see developers putting QA violations into the portage tree left and right. For the most part I'd say the level of abuse in bugzilla is down and continues to trend down. Sure, manpower is limited, but the solution to that isn't to tell the people who are here to work harder or quit (which means quit) but instead to recruit more help. Arch teams seem to be generally doing a good job keeping up with STABLEREQs on the major archs - if you use a minor arch that isn't as well supported I'm sure we'd be happy to have more help. Is the issue anarchy, or the bazaar model in general? You can't always have it both ways...
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Thomas Anderson wrote: It seems to me you're on a irc-hate rampage. There are many devs who rarely, if ever, go on irc. The _only_ requirement is that you conduct a real-time interview with a recruiter. I have to agree with this sentiment - I have nothing against IRC but it is a bit too realtime for me to be on it routinely. However, I didn't have any trouble spending time with my mentor on IRC as it is a much more productive way to learn the ropes. Sure, lots of time was spent reading docs/etc, and doing ebuild exercises/etc. However, the direct conversations were also an invaluable part of the process (even if it is hard to schedule an hour just sitting at the keyboard with family/etc). Plus, it is essential that there be some kind of interviewing process to become a dev. A gentoo dev potentially has the power to hose the systems of everybody running gentoo - so we owe it to ourselves and our user communities to vet any candidate for this position. Sure, we want to know that they know how to write ebuilds, but we also want to know that they have a good attitude and some common sense as well. We count on devs to understand their own limitations and to not try to singlehandedly revamp baselayout/etc without careful coordination with the rest of the community. I also echo what has been said about projects like Sunrise and overlays as being good gateways into gentoo. Oh, I'm not sure I agree that new devs should be grilled to the n'th degree on obscure ebuild knowledge. It is more important that they know where to go and have demonstrated the ability to use this knowledge than it is for them to have this memorized. If it takes a dev 28 hours of tinkering to get an ebuild right I could care less as long as it is right on the first actual commit. When it comes to package management being careful is generally more important than being quick. It is also critical that devs be able to interact in a professional manner and relate well to our user community as well.
Re: [gentoo-dev] Re: Training points for users interested in helping out with ebuild development
Duncan wrote: But no matter, the practical fact of the matter is that for someone who would otherwise not do IRC, it's just one more hurdle in the process. Whether it's useful or not, trivial or vital, no longer matters, it's defined by the gatekeepers as a requirement, therefore, by said definition, it is a requirement. If an otherwise-capable candidate developer is stuck in some backwater where the only ISP in the country has a 14-layer impenetrable protocol filter on IRC I'm sure their mentor will bend over backwards to work with them. However, this is becoming more of an argument over points of rhetoric than anything with a practical impact. If somebody is qualified to author gentoo documentation or write ebuilds they're going to be able to figure out how to use /query or /msg in any of 47 irc clients. If somebody has some kind of physical/mental handicap that would prevent realtime communications but not otherwise interfere with contributions I'm sure a mentor would also be happy to try to work with that. However, it is important that mentors have an opportunity to get to know a candidate - they are responsible for their actions and you can't build trust by only sending a few emails back and forth. Ultimately that is the goal - Gentoo is a community and those who want to be devs do need to be able to interact in at least a fairly nominal way with the community at large. Gentoo has MANY things that could stand some change/improvement. An over-dependence on IRC could arguably be said to be one of them. However, completely avoiding an effective realtime communications technology simply for the sake of doing so seems a bit over the top.
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
Thilo Bangert wrote: AFAIK, we have never explicitly made this distinction clear. if we had, we would have to remove stuff from portage which doesnt live up to the standards. I'm all for that. In reality we tend to leave them alone until a security issue actually comes up, which is probably a reasonable compromise (since it also takes work to remove them). In any case, failure to completely meet a standard does not automatically imply that the standard is worthless. it is also not true from a more real world perspective: there are many packages in portage that have a standard which is much lower than what is in some overlays. and there are many packages in overlays which live up to a quality standard way above portage's average. I don't think anybody has issues with overlays that choose to have higher quality standards than portage. I'm all for that. I'm concerned with the quality level in portage - since that is what we attach our name to. If some other repository wants to do a better job than more power to them! However, Gentoo cannot endorse all overlays as being official repositories, because clearly there is no standard for quality when all it takes to have an overlay is to set up an rsync or http server and put some ebuilds on it. if you want to exaggerate a bit, we have roughly 500 ebuilds in portage which are maintainer-needed and have only a few users and thats why you want to keep popular packages out of the tree? Actually, where any of those ebuilds cause problems I'm fine with getting rid of them. I'm certainly not arguing for inconsistency. I'm just suggesting that we shouldn't make the problem worse. If a package is popular then somebody should volunteer to maintain it (whether by becoming a gentoo dev or by starting their own overlay). If that isn't happening than clearly the package isn't THAT important. This is open source - if you have an itch, then scratch it! Don't just complain that nobody else is scratching YOUR itch (even if it is a popular itch). In any case, my opinion is that for packages to be in portage they should be of a certain level of quality, and a developer should be accountable for the packages they commit. Anybody is welcome to grab ebuilds out of CVS, screen them, and commit them. However, if they cause havoc then the developer can't just say but it was popular and unmaintained, so I figured I'd just commit something without looking at it. If a developer is willing to commit an appropriate amount of time to QA then they essentially have become a maintainer and the package is no-longer maintainer-wanted.
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: 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. This seems to come up from time to time but I don't see how this is a problem that GLEP 55 solves. If the rule is first line of the ebuild starting with EAPI= and the ebuild is as you suggest above, then the EAPI is 4 (without any regard whatsoever to what might be in foo). The counterargument seems to be that eclasses should be able to modify EAPI behavior. However, if you want to do this then you DEFINITELY don't want to put the EAPI in the filename - unless you want eclasses to start renaming the ebuilds to change their EAPIs and then trigger a metadata regen. This seems to be a case where a problem is proposed, with a solution. Somebody proposes an alternate solution and the complaint is raised that it doesn't handle situation X. However, the original proposed solution doesn't handle situation X either, so that can hardly be grounds for accepting it over the alternate. I'm actually more in favor of an approach like putting the EAPI in a comment line or some other place that is more out-of-band. Almost all modern file formats incorporate a version number into a fixed position in the file header so that it is trivial for a program to figure out whether or not it knows how to handle the file. Another common approach is to put a header-length field and add extensions to the end of a header, so that as long as you don't break past behavior you could create a file that is readable by older program versions (perhaps with the loss of some metadata that the older version doesn't understand). Just look up the UStar tar file format or the gzip file format for examples. Of course, such file formats generally aren't designed to be human-readable or created with a text editor. The same applies to executables. It is impossible from the filename to tell if /bin/bash is in a.out or ELF format, or if it is a shell script. Instead a simple standard is defined that allows the OS to figure it out and handle it appropriately. If you try to run an ELF on some ancient version of linux it doesn't crash or perform erratic behavior - it will simply tell you that it doesn't understand the file format (invalid magic number). In any case, I'm going to try to restrain myself from replying further in this thread unless something genuinely new comes up. When I see 26 new messages in my gentoo-dev folder I should know by now that somebody has managed to bring up GLEP 55 again... :)
Re: [gentoo-dev] Re: The fallacies of GLEP55
Ciaran McCreesh wrote: You've missed the point. The point is, the EAPI process can't avoid the huge wait before we can use it for certain types of change that would be extremely useful. GLEP 55 fixes this limitation, and it's the *only* thing that fixes this limitation. Except that if we had just implemented one of other proposals a year ago we probably would be done waiting now, while refusal to accept anything other than EAPI-in-filename might have you waiting for this ten years from now. Sure, you might disagree with this, but that doesn't change the fact that we are at an impasse and I see no sign of this changing anytime soon - the last council clearly wasn't a big fan of GLEP 55 as it stands, and the current council seems to be going in the same direction. I guess you can always wait for the next council election and see what 2010 brings. However, I hope you're not going to do that to speed things up!
Re: [gentoo-dev] Can we stop wasting time and bandwidth? (was: The fallacies of GLEP55)
Nirbheek Chauhan wrote: Let's not blatantly ignore our REAL problems. We can no longer afford to maintain the status-quo of pedantic masturbatory discussions on the finer points of ebuild formats. We cannot AFFORD to look the other way while the distro rots away. What exactly is your proposal? Ban discussion of GLEP 55? I doubt less posts on GLEP 55 will mean more developers joining arch teams instead, or whatever. People work on the things they want to work on. If they want to work on EAPIs that is fine by me - that is forward progress. The solution to progress in one area and not another is not to stop the area that is moving forward. Sure, if there were actual resource contention at stake that would make sense. However, if you tell a dev not to work on A but instead to work on B the most likely outcomes are that they'll: 1. Work on A anyway. 2. Start a separate project to work on A if you actively prevent them from doing so. 3. Work on C, or D, or on nothing at all. At best they might give B a token effort. After all, if they wanted to work on B they would have done so in the first place. By all means advertise needs in case people aren't aware of them and find them interesting, but you can put a gun to people's heads and tell them what to do. If you want more people in the arch team start with the -user mailing list and take time to mentor somebody who is interested in maintaining packages as a dev. Or, if you'd rather donate money to a fund to offer to pay people to do maintenance.
Re: [gentoo-dev] Re: The fallacies of GLEP55
Ciaran McCreesh wrote: Had we gone with any of the other proposals a year ago, we'd be waiting a year every time a new change came along. Only if that change prevented obtaining EAPI from wherever it was placed. If you want to make the rule EAPI=foo appears at the start of a new line at the top of the ebuild - EAPI is obtained from the first such line then that would handle any situation except where the ebuild format can't have EAPI=foo at the start of a line. Even XML could handle that (just put it in tags flanking it on different lines - since XML ignores newlines). Even a binary file format could handle that if you just put newlineEAPI=eapinewline in the header. The only thing it wouldn't handle is dynamically setting the EAPI, but I'm not aware of any proposals that do (except for splitting the EAPI into two parts - one part defines how to obtain the EAPI the other part does it - but that also works with EAPI=foo in the ebuild). If the Council were not a fan of GLEP 55, they would have voted against it. Why? If there is no reason to move forward with haste why not just leave it out there and see if somebody comes up with a better idea or see if circumstances change? If the perception was that there were a pressing need for forward movement on this chances are that somebody would have proposed an alternative GLEP and the council would have just approved that instead.
Re: [gentoo-dev] The fallacies of GLEP55
Ravi Pinjala wrote: Nick Fortino wrote: Such a transformation is possible, given the restrictions on arg, as well as ebuild format. Isn't this a bit circular? The whole point of wanting to change the extension is to get rid of exactly these restrictions; if you assume the restrictions, then the whole thing is kind of pointless. :) What restrictions? The restriction that EAPI be fixed on the 5th line of the build, or the restriction that EAPI be fixed in the filename. I don't really see much difference between them. What can the one do that the other can't. The only thing that has been suggested is changing the package versioning scheme. That is handled in a straightforward way - parse the EAPI before you try to extract the version from the filename. Sure, that isn't compatible with older versions of portage, but if we start now I'm sure we can get there in the reasonably near future. Personally, I'm not a fan of parsing ANYTHING out of the filename. Sure, keep the file naming convention for the sake of convenience, but I think a better design would be to field everything inside the file - including category, packagename, and version. Then you no longer have to worry about whether a given hyphen is a separator or part of one of the components (among other things). Sure, you can't just bump an ebuild by renaming it, but if we had been doing it this way all along then the versioning issue we're debating now would be a non-issue.
Re: [gentoo-dev] Re: The fallacies of GLEP55
Duncan wrote: So I believe the cost to be quite reasonably managed, after all. Benchmarks would of course be needed to demonstrate that, but I believe it worth pursuing. Agreed. Perhaps I'm just spoiled by RDBMS's at work or something, but it seems like we're trying to squeeze every ounce of speed out of a non-indexed flat file database and do everything we can to avoid actually putting all that metadata in something that actually is queryable no matter how lousy the final design ends up being. Expressing the package database as a set of flat files works nicely - especially with cvs/git/etc. Actually working with that data directly on a real system doesn't make sense at all. Index it once and then only open the flat files on the rare occasion that you actually need to install one of them. Such an index can be centrally distributed, or it could be maintained as packages are rsynced (and of course users should be able to update it on demand as well). When the speed of your package management system depends on the performance of find vs grep -r, you are doing something wrong. Neither works all that well.
Re: [gentoo-dev] The fallacies of GLEP55
Ciaran McCreesh wrote: The only way it'll be in the next ten years rather than in the next two years is if Gentoo continues its current approach of making changes require every single person to agree... Frankly, I won't be at all surprised if this thread (in some form) is still going on in the next two years, and nothing at all has been implemented. As far as Gentoo requiring EVERY single person to agree - that is hardly the case. But there does need to be a general consensus or some impetus for moving forward without one. I don't really see either. If consensus isn't necessary then I'll solve the whole debate for you now - EAPI goes on line 5 of the ebuild in the syntax EAPI=foo, and filenames remain as they are now. There we are - done. Now, lets go ahead and start implementing it so that in 6-12 months we can roll out new version numbering schemes. Surely you're not suggesting that we shouldn't move forward with this merely because some people (like you) don't agree? Since the inevitable reply is going to be that it isn't about consensus, but rather it is about merit - as the official arbiter of all things meritorious I hereby declare that my idea is the best one out there. Now, back in the real world where neither of us is the dictator of Gentoo, I'm quite happy to wait for the Council to rule on this, or to choose to not rule on this. Their reluctance to do so to date just reflects how divided the developer community is over the issue.
Re: [gentoo-dev] The fallacies of GLEP55
Alistair Bush wrote: Is it really necessary to convince the entire community for every GLEP? I thought that the reason we have the council is so they can make decisions. You know specialization of decision making. If the council is going to expect anyone else, besides themselves, to understand an issue then why have the council. They are a representative body. OF COURSE they should care what the community thinks. They weren't elected SOLELY for technical ability. Sure, they should use their own judgment as well. However, GLEPs should certainly be debated by the community before they are adopted, and the opinions expressed on-list should certainly be taken into account. Now, does that mean that every decision requires unanimous community agreement? Of course not! However, the vigorous debate that GLEP55 seems to inspire suggests that there are more than just a few hold-outs.
Re: [gentoo-dev] RFC: ACCEPT_LICENSE default value (GLEP 23)
Disclaimer - I too am not a lawyer. Mounir Lamouri wrote: I'm not a lawyer so I can't say for sure some software _need_ explicit license acceptance to be used. However, I'm quite sure using a software means accept the license. Someone experienced in this area is welcome for clarifications. Well, the basic gist of the argument is this: 1. A license is required to do something that you otherwise wouldn't be allowed to do. For example, in my town I'm not allowed to burn garbage, but if I got special permission (a license) from the local government I could legally disregard the law. 2. There are no laws that state that it is illegal to run software. 3. Therefore, I don't need a license to run software - if I obtained it legally then it is mine to do with as I wish. Copying or distribution is a different matter - copyright law forbids doing these (except under fair use), and therefore to distribute copies of software one requires a license. I think this vision is too simple. Some licenses add rules and rights users should know. Well, some licenses _claim_ to add rules and rights. Whether they actually do so is debatable, and it can depend on the specifics of the situation and your legal jurisdiction. Some applications can use your personal data (like picasa) or forbid you to try to do reverse engineering even if authorized in your country (can't remember name). Use of personal data is probably more about using an online service, and that falls more under the category of a service agreement and not a license. They really aren't the same thing even if companies tend to blend them together. Legally they aren't quite the same thing. I am not aware of any court which has upheld license provisions that prohibit reverse engineering. Again, almost EVERY proprietary license out there makes that claim, but that doesn't make it legally binding. So, even if most users don't care, we should at least help them know. Because, at the moment, I can install something with a license saying i can use personal data you put in this app without even have a clue. I agree that we should make this information available, and I'm all for giving users tools to pick and choose what kinds of licenses they're willing to potentially subject themselves to. I just don't think we want to be the license police - so even if ACCEPT_LICENSE doesn't default to * we shouldn't prohibit this setting (and the example config file should contain a comment that clearly indicates that portage has this option). Also - any service that makes use of personal data without going to a fair amount of effort to ensure the user has agreed with this is asking for trouble. Indeed, in many countries this kind of data is subject to a great deal of protection no matter what the dialog box might say to the contrary. By auto-enabling only a set of licenses we can be sure at 99% users will be safe. By auto-enabling everything, we can put our users in an illegal situation where he is living. Better to be a little bit restrictive than too comprehensive. I do see the virtue of your argument - probably the practical solution would be ACCEPT_LICENSE=* -...@eula or equivalent. However, we should certainly allow users to change this to ACCEPT_LICENSE=* if they so desire. In any case, not doing so is silly - somebody will just issue a patch for portage that does exactly this if we make it hard. I'd be happy to host it in an overlay (or in portage if there were no strong objections - though it seems silly to have an internal fork of the package manager which is why it should simply be configurable). Gentoo is about choice - we provide the tools, we don't tell users that live in Freedomland that Freedom isn't allowed for Gentoo users. Likewise, if Saint Ignutious wants to run -* GPL more power to him. And maybe it will help users to think about alternatives before using proprietary software. Again, as long as the implementation is one that is designed to _help_ our users I think that this is exactly the gentoo way to do things. What we don't want to do is police our users, or help them in ways they don't want to be helped.
Re: [gentoo-dev] Re: How not to discuss
Ryan Hill wrote: I'm tired of playing, as I'm sure you are. So please, let's be quiet now, and let the big people talk. This is a public list designed to facilitate discussion of gentoo software development. Anybody with something constructive to say is more than welcome to speak up - particularly gentoo staff. I don't pretend to be an expert on package management. However, hiding internal implementation details is just good design. I can see how putting eapi in the filename can be a convenience to the package manager, but it still seems like a bad design, as it exposes end users to an implementation detail of the package management system. There are lots of ways that EAPI could be cached that would avoid the various penalties that have been referred to. Even without an improved cache the penalty seems superior to accepting the design compromise of EAPI in the filename. As to how EAPI could be cached goes - I could think of a few high-level design options: 1. Cache files are distributed with the portage tree. EAPIs that break the cache format would use different files that older package managers would ignore. Downside is that it doesn't handle user-modified ebuilds (unless the user tells the package manager to regenerate the cache), and it doesn't handle overlays unless the maintainer generates the cache. 2. Cache files are generated when the tree is synced. The package manager would look at the list of modified files and scan only those files one time to index them. The index could contain the mtime and path of the file. Then, when you perform an operation the package manager could check the mtimes in the directories containing those files and see if anything was touched and regenerate the cache if needed. This takes a little more time during syncing but I suspect that it would perform very well - after all after a sync all those files would be in the disk cache anyway. A suitably clever package manager could read the files as they are being synced and guarantee they are in-memory. If we were talking about a 300TB table that got 300k transactions per second I could see why we'd be talking about hacks to sacrifice normalized design for speed. We're talking about a package database - one that contains 150k records. Sacrificing good design for speed (instead of improving the algorithm) is a short term gain for a long-term cost.
Re: [gentoo-dev] Re: How not to discuss
Duncan wrote: A team can have the best rhetoric in the world, but if they don't actually show up and field a team on game day, they lose by default. Fortunately or unfortunately, that looks to be where this is headed. Agreed, there is definitely something to be said for offering solutions. I think that parts of GLEP55 are an ugly hack, but since I'm not the one writing code the best I can do is ask those who are to think carefully about what they're about to do. In the end, it is better for gentoo for something to happen rather than nothing.
Re: [gentoo-dev] A new glep: Ebuild format and metadata handling
Patrick Lauer wrote: If I should have forgotten any approach or misrepresented one I'd appreciate an updated or rephrased section so it can be easily updated. This keeps coming up for some reason: parsers: It enforces some minor limitations, for example EAPI needs to be unique and cannot be overridden by eclasses. I agree with this sentence. However, the exact same limitation applies to GLEP55 and it isn't mentioned there. So, that paragraph should read: glep55: See GLEP55. To summarize: The eapi is put into the file name so that the package manager knows the EAPI (and thus how to handle this file format). While it simplifies the eapi discovery this comes at a high price as there is no reliable way to find and validate all ebuilds. It also enforces some minor limitations, for example EAPI needs to be unique and cannot be overridden by eclasses. Some people also see it as bad design as it exposes file internals in the filename. Likwise, the pro/con list for glep55 should include the line: (+-) enforces some restriction on the possible changes in future EAPIs In this particular regard the parser and the glep55 approach have the exact same limitations. Now, an alternative to glep55 that has two different EAPI-like values (one for the initial file parsing and one for actually performing the build) might lose this limitation. However, this is not the case with glep55 as it is presently stated.
Re: [gentoo-dev] Monthly Gentoo Council Reminder for June
Mounir Lamouri wrote: I would like to get ACCEPT_LICENSE default value [1] discussed in the next Council. If I can even get it widely discussed in gentoo-dev before the council, a vote will be great. But it looks like it is not interesting so much people out there. Why not make a definitive proposal so that the council doesn't just have to figure one out on the fly - that will probably lead to faster closure (and give people something to throw darts at if they hate it). Here is a suggestion: Default is ACCEPT_LICENSE=* -...@eula. My intent isn't to divert the discussion into this thread (everybody who cares is reading the other one I'm sure). However, the basic point is to propose one thing and then let everybody throw stones at it, so that they know what will happen if they don't complain. If you word it appropriately nobody will be offended that you're proposing a solution. Then the council can just look at the list and see no big flamewars and just approve it, rather than debating what it should actually be. Also - I wouldn't consider it a negative thing that your proposal hasn't gotten as many replies as glep55. You have proposed a small and (mostly) well-defined change to gentoo and if nobody complains then we should run with it!
Re: [gentoo-dev] Re: How not to discuss
Marijn Schouten (hkBst) wrote: Richard Freeman wrote: Without actually intending to open a new debate on that issue cringes, I'm actually a fan of NOT obtaining PN and PV from the filename. I've seen an approach like this used in various systems and I happen to like it: In which systems did you see this approach? A bunch of proprietary systems that nobody here would have heard of (well, most likely). They had nothing to do with package management. The systems in question use a distinct field to display record names (which is user definable) and use separate fields to capture the content of the record. In many cases the contents of some of these separate fields end up in the informal record name field, but it is still desirable that they be distinct. Sorry if I implied that my example was directly related to gentoo or package management. I was extrapolating from a completely different field. However, I still think this is worth considering (entirely apart from glep55). If I were building a portage system from scratch I'd consider doing it this way. With all the history we have currently I'm not sure I'd be eager to make this change now (though I guess we actually could as part of a new EAPI).
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Denis Dupeyron wrote: In my manifesto [1] I have proposed something significantly different which simply consists in spinning the long discussions off the council meetings using more focused groups ++ I've seen this used to good effect on projects at work. The only challenge might be the fact that this works best when groups actually meet (as in everybody talking at the same time in the same place - or at least virtual place). Also - such working groups are not a substitute for community involvement. Usually the way these things happen are: 1. Topic is brought up. 2. Lots of people weigh in. 3. People volunteer to form a short-term team to work it out. 4. Team presents proposal. 5. Lots of people cheer (hopefully). 6. Oversight group (ie council) approves. This of course requires a team mentality at a few points along the process. Also - at work it helps that people without this kind of mindset get weeded out fairly quickly since the issue wouldn't be discussed if it weren't holding something up.
Re: [gentoo-dev] Jun 11th, 2009 Council Meeting Format
Doug Goldstein wrote: The amount of time spent debating something over the pretty look and not over technical merits creates terrible signal-to-noise ratios (where I consider the pretty debates as noise and the technical merits as signal). I'm not sure that much time on this list is spent debating pretty look - unless you're concerned that the EAPI-in-filename objection comes down to looks. This is really a matter of elegant design and that certainly is a technical consideration. In any case, if the KDE team wanted to make the default color scheme dark gray on black I'd hope the council would step in. The council has overall responsibility for the direction of Gentoo and is not limited to considering only technical matters. I think that half the reason the glep55 debate seems to have gotten so many people angry is that half of the flames amount to you have no right to voice that opinion or your opinion doesn't matter. Maybe that should be true, and maybe it shouldn't be true. However, you aren't going to be making many friends with that approach. Likewise, if 90% of the developers on a project don't think a change should happen, I'm not convinced that it should happen regardless of its merits. The 10% who think they have all the winning technical arguments should try persuading the 90% to agree rather than simply pointing out that they are wrong. It isn't like the average gentoo developer can't follow this stuff...
Re: [gentoo-dev] Re: GLEP 55 Version 2
Ulrich Mueller wrote: Let's assume for the moment that we change from .ebuild to .eb. Then we obviously cannot change all ebuilds in the tree to .eb, otherwise old Portage versions would see an empty tree and there would be no upgrade path. Or am I missing something? That is a good point. Although things would probably break more gracefully than having old portage versions attempting to parse new ebuilds (maybe, maybe not). That actually makes me wonder - if we didn't change the extension at all could we somehow poison the portage tree so that old versions of portage would abort before doing anything dumb with a meaningful error message? As far as an upgrade path goes - we could provide a one-time tarball that will update portage (and its essential dependencies) to a version that can get users out of this bind. If a user has a system THAT old then they might just want to extract a stage1 tarball (manually - without overwriting /etc without care) and go from there. I'm not sure that gentoo generally supports graceful upgrades from very ancient systems to modern ones without keeping up to date. Other distros can do it since they do ~annual releases and users could just apply those sequentially. For portage we don't keep around all the files needed to do a sequential upgrade like this - if a user were to try to upgrade to a 3-year-old version of some package most likely it wouldn't be mirrored and upstream might not have it either. We obviously need to give some thought to not breaking old versions of portage, but given that portage will be only one of many problems if a user doesn't do an emerge -u world for 5 years I'm not sure we need a bulletproof solution...
Re: [gentoo-dev] Re: GLEP 55 Version 2
Patrick Lauer wrote: And if you really absolutely have to do that you can change the sync location on every disruptive change, but (imo) that should be avoided. If mirroring and other practical concerns weren't an issue what you're essentially describing is just moving to a CVS/git/etc repository and using such a tool to do all the syncs (ie not using rsync at all). Then all you need is an update page that has a list of commands like: emerge --sync --date 2008-01-01 emerge -u world emerge --sync --date 2008-08-10 Follow this xorg update doc: link emerge --sync --date 2034-04-02 emerge -u portage so that you have support for the finally-approved glep55 And so on... :) That actually gives you a best-of-both-worlds option: continue to use rsync for normal use to ease distribution, but have a cvs tree that anybody can read from which could be used in upgrade guides for out-of-date users.
Re: [gentoo-dev] Re: Council meeting summary for meeting on June 11, 2009
Nirbheek Chauhan wrote: Please, do not waste everyone's time and bandwidth with thoughts that do not belong on this list, and hence they do not care about. Let's be nice. Somehow I don't think Duncan's goal was to get the mailing lists to be as flame-filled as he perceives IRC to be... :) Agreed that just about everything but the original council summary in this thread (and I mean the first original one) probably belongs in -project.
Re: [gentoo-dev] 2009 Council Elections
Ben de Groot wrote: In my opinion it is in the best interest of Gentoo at this point to ignore Exherbo and to silence those people involved with Exherbo that have been so divisive and generated so much conflict in Gentoo channels. Nobody needs to be silenced (unless they're litereally spamming the list - as close as cirianm comes to this his posts are at least relevant to the topic and even if I sometimes disagree with them and he could exercise restraint I don't think he should be banned). I suspect most devs just avoid the drama. I do echo the sentiment that the Gentoo council should be focused on Gentoo. Sure, nothing wrong with cooperating with other projects and learning from them. Certainly I don't want a not-invented-here attitude, and I think paludis has a lot to offer. However, those who have questioned the wisdom of cirianm as a proxy do have a point. Technical knowledge alone is not the critiera of a council member. One needs to be able to build consensus - not that we need to be strangled by consensus, but we can't afford to rule by edict either. I'm happy that everybody seems to be getting along better, but council leadership requires maturity, and maturity is reflected by how people behave over the long haul. Cirianm's best bet to get accepted by the gentoo devs is to just start working with them - if he works positively with enough different people (especially those with different opinions) he'll have no trouble gaining their support. However, that is something that can take months or years - not weeks to a few months. I might be willing to give him the benefit of the doubt, but that is just me. I'm not so sure I'd be eager to have him be a proxy if I were on the council. Sure, I'd be happy to yield my floor time to him if I thought he had something worth listening to, but a proxy is more than just a platform to talk - any mailing list subscriber already has that.
Re: [gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Doug Goldstein wrote: On Wed, Jul 1, 2009 at 9:33 PM, Ned Luddso...@gentoo.org wrote: Meetings will likely go back to one time per month and be +m with +v be handed out per request with open chat pre/post meetings. The reason for this is to keep the meetings on-track. I won't engage in endless discussions. Facts can be presented. They will be reviewed on merit, technical and social. Thank you again. I tried the +m/+v thing a year ago and received a few pieces of hate e-mail from mostly non-developer people. Please do go to +m. I usually just read council summaries - when I've tried to read the actual logs it is a COMPLETE mess. In most organizational board-like bodies the board meeting is NOT the place to have open discussion on topics. The open discussion happens everywhere BUT the board meeting. It happens on the phone, on mailing lists, in newspapers, on TV, on talk radio, etc. During the board meeting people who want to make a statement can do so within a limited amount of time, and then the board casts its vote. 95% of the time the way the vote will go is known before the meeting happens. The meeting is just a formality. If there is to be a 300 line argument over proposal-A vs proposal-B, do it on the mailing lists, or on IRC. Council votes should be straightforward matters. If we want to have more interaction - how about this idea: Formal council meetings happen once per month, and they are the ONLY place votes take place. However, the council will try to meet more often for less formal discussion. +m/+v may be imposed at any time if there is a large turnout just to keep things somewhat orderly. Attendance is not mandatory for these meetings, but is encouraged. You could also schedule them at a variety of times - again, you're not missing any votes so if only 1/3rd of the council makes any particular meeting it isn't a big deal. As far as having two council members temporarily approve items goes - it isn't a bad thing to have in general, but it should really only be used in emergency situations. I'm not sure if we even need it - I suspect that groups like infra will do the right thing most of the time if there is an emergency (dev starts committing rm -rf /* scripts all over the portage tree - infra suspends cvs access first and finds devrel later). Maybe a quick way to assess developer opinions on issues would be forum polls? The votify system is potentially good as well, but I'm not sure how much work it requires on the part of infra to gather/tally the votes. We really don't need the full rigor of votify for most issues (though it probably should be used if there are true referendums on serious matters). And, of course, there is always the measure the noise on the mailing list approach, but I'm not a big fan of that (though I am a fan of lists in general).
Re: [gentoo-dev] Re: [gentoo-council] A Little Council Reform Anyone?
Luca Barbato wrote: Jorge Manuel B. S. Vicetto wrote: I have a few ideas about this that I'll have to put in writing and share later, but let me start by proposing that for such a change we require the support of at least 2/3 of the devs that vote *and* a minimum of 1/3 of all devs. I'd use absolute majority even if it is more strict. The only concern I have with these kinds of approaches is that right now we tend to be pretty liberal with allowing people to be devs even if they aren't heavily involved in gentoo. As long as their commits are of sufficient quality that isn't a big deal. However, it does allow the voting rolls to get pretty big with people that don't have a huge stake in the outcome of an election. Organizations that tend to have supermajority policies tend to have other kinds of requirements on dues or activity, and they also tend to routinely clean out their rolls. A supermajority policy might work fine if we also had a policy that a dev who fails to vote in two consecutive elections gets the boot. I'm not sure that we really want that kind of a policy, however. My feeling is that if you don't care enough to vote, you should have to live with the consequences. Now, all elections of any kind should be announced well in advance, and should span a period of a few weeks (as they currently do). If an issue is particularly critical and nobody can get around to voting for it in a 2 weeks span while there are hundreds of arguments raging in IRC and the lists, then I'm not sure we can take their silence as a vote of disapproval.
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Jesús Guerrero wrote: Most Gentoo users will have no problem to use overlays as they need them. If we had more developers we could as maintain more packages, as simple as that. I actually tend to agree with this position, however to use overlays as a valid solution for end-users we need to do more to support them. Right now it is at least a little painful to get set up with an overlay. There also isn't really any official place to vet overlays, and there isn't any official source for overlays that aren't maintained by gentoo. Sure, overlays.g.o has tons of overlays - but which ones are mostly-stable, and which ones are intended to break systems? What is the QA policy for each overlay? If I'm an end-user not interested in breaking my system, what overlays are safe for me to use? If we really want overlays to be an outlet to allow more non-devs to contribute, then there needs to be some way to standardize them. Maybe a simple ratings system - an overlay needs to comply with one set of rules just to get listed on o.g.o. If you want to be marked as stable, then you obey some additional rules. And so on... Then we can have overlays of various types for various purposes, and users can pick which ones they want to follow. We could also have things like overlay groups - like stable or desktop or KDE / etc. Maybe a fancy GUI to allow users to configure all of this. Of course, for this to work somebody needs to develop it. If somebody were willing to do the work I doubt anybody would get in their way. It isn't like any of this would interfere with anybody who just wanted to make their own overlay without rules and not have it listed on some official site.
Re: [gentoo-dev] DistroWatch and Gentoo packages: status quo and future
Jesús Guerrero wrote: Yeah, devs for that as well. Yup - I think we're actually on the same page. Ultimately quality matters more than quantity and everybody does what they can given the resources we have. Right now it is at least a little painful to get set up with an overlay. No, it's a matter of using layman -a whatever Sure, and that is fine if overlays are intended only as experimental development spaces. However, some (not necessarily including yourself) advocate that it is perfectly fine that the portage tree gets stale since we have all those overlays. That certainly is a possible approach to take, but to go that route overlays need to become more robust. Right now they're really not a replacement for /usr/portage. There's no policy. Just like unofficial repos for any other distro. We can't control that. It's outside Gentoo. Exactly. And, because it is outside of Gentoo - packages in overlays don't count when we consider how up-to-date Gentoo is. If we want to say that package foo isn't stale because there are recent versions in some overlay, then Gentoo needs to take responsibility for the overlays. That might be as simple as being a gatekeeper - auditing overlays and booting ones that drift out of control. I don't think we can do any more with the number of developers we have right now unless we start dumping blindingly and without any check every ebuild that we get across. Absolutely. The whole logic behind going to an overlay-based approach is that it allows developers to leverage external help more effectively - a developer can essentially delegate a whole mini portage-tree to some other entity to manage, simply providing oversight and QA. In theory you could even have official overlays - which would allow better delineation of responsibilities (you don't need to grant people commit access to everything - just their project's overlay). Ultimately, as you argue, it doesn't make a difference if nobody is willing to step up and actually maintain ebuilds. Personally, I like the overlay idea, but right now it just isn't necessary. In theory proxy maintainers work almost as well, and we're not really making heavy use of this model right now. If we had hundreds of users submitting high-quality ebuilds in bugzilla and simply couldn't find enough devs to commit them all, then a more overlay-based approach would help reduce the bottleneck of having a centralized group of committers. Right now we probably have far more devs than proxy-devs, so the need to delegate the tree further really isn't there.
Re: [gentoo-dev] Stabilization of Python 3.1
Olivier Crête wrote: ~arch is for testing ebuilds, not the upstream package I'm pretty sure this isn't the case - at least not as cleanly as you suggest. Certainly testing the ebuilds themselves is part of the reason for having ~arch, but upstream readiness is part of it as well. If a package hit ~arch and we got 10 serious bugs that were all upstream problems and then somebody filed a STABLEREQ I know that I wouldn't be the one to stabilize it. The whole point of having QA is so that people who don't want to be bothered with bleeding-edge packages aren't bothered with them. Masking is for packages with known serious problems, ~arch is for packages that we think are fine but don't have much production history with, and stable is for packages that are known to be decent with history. However, I'm not convinced that the 3.1 issues need to be a showstopper for going stable. Others have made some of these suggestions, but let me consolidate some ideas that have come up: 1. A tracking bug should be created to track 3.1 stabilization issues (assuming it doesn't already exist). 2. Portage (and other system packages) deps should be checked to ensure it pulls in the current version. This should be carefully coordinated. 3. -dev-announce message sent out to check your python deps and fix them (logging blockers as needed). This need not be carefully coordinated. 4. einfo message about not eselecting the new version of python. News message as well. As long as the current version doesn't go anywhere and the current version can be re-selected at-will, then I don't see how users can get themselves into a corner. The ability to support stuff like this is the reason we have SLOTs in the first place.
Re: [gentoo-dev] EAPI and system packages
Ryan Hill wrote: So, should we always keep a working EAPI 0 version around? If not, when can we drop support for old EAPIs? Your opinions please. You might want to define what you mean by dropping support for old EAPIs? Do you mean: 1. No longer ensuring that users who have pre-EAPI versions of portage have a clean upgrade path. or 2. No longer supporting EAPI=0/1 in package managers. The former seems to be what we're talking about, but your question sounds like it is suggesting the latter. If we want to drop support for EAPI=0/1 then EVERY package in portage needs to be updated to a more recent EAPI. I suspect we're not there yet (at the very least all those system packages that are deliberately held back need to change). I can see why package managers would benefit from fewer cases to support, however...
Re: [gentoo-dev] Re: Xorg 1.6/libxcb 1.4 stabilization news item
Rémi Cardona wrote: May I request a faster commit time since I didn't expect Samuli to stabilize everything so quickly? Yup - I wouldn't be surprised if within a few hours 80% of the concerned users will have already installed it. Even if you send out the news now anybody who synced overnight wouldn't get it in time anyway. Might not hurt to log a blocker bug just to track the news item the next time you consider a major upgrade like this. Then you don't actually stabilize anything until AFTER the news goes out. :)
Re: [gentoo-dev] Anyone interested in maintaining the Gentoo Handbooks?
Joshua Saddler wrote: On Sat, 3 Oct 2009 20:45:21 +0300 Markos Chandras hwoar...@gentoo.org wrote: This is actually true. Maybe all devs should have access on docs since the docs teams are dead. I would suggest to let all developers contribute to documentation whether they belong to docs team or not No. Many (most?) devs do not write good documentation. snip They don't know all the myriad documents that need editing to pick up the change made to one part of a different document. They say that the enemy of the great is the good, but I think that in this case the enemy of the good is the great. Since many devs can't write excellent documentation the argument is that they shouldn't be permitted to write any documentation. The problem with this is that some of our official documentation is just outright wrong. Right now if somebody follows the docs they are guaranteed to end up with a non-functional system. Suppose a dev edits those docs and fixes the version but doesn't completely clean up the accompanying text or misses some obscure cross-reference. Well, maybe now a user has a 50% chance of getting it wrong - which is better than a 100% chance of getting it wrong. Others can then clean it up (such as the folks on the forums who get all kinds of feedback about these sorts of issues). I'd be the first to agree that it would be better to just file a bug and let the doc team clean up the docs. Perhaps this situation is just an anomoly, in which case we shouldn't be changing overall policy as a result. However, if we have a resource bottleneck here then we need to do something to help clear it up. That isn't meant to reflect poorly on anybody who is contributing to docs - you might be doing a wonderful job but unless we can find more of you then you're going to be playing whack-a-mole. The amd64 team ran into a similar issue which is why there is a policy that package maintainers are trusted to stabilize their own packages as long as they've tested them on the platform. That doesn't mean that there aren't decent amd64 team members - only that there simply aren't enough of us to keep up with everything.
Re: [gentoo-dev] Init systems portage category
Jesús Guerrero wrote: In my opinion, if we really want to speak about a way to implement that kind of snapshoting, we should start thinking about providing a better integration with lvm, from the root. lvm can take care of the snapshots on a non-expensive way, and it would be relatively easy to implement. However a lot of stuff would need to be re-documented, starting from the handbook, and the init system. LVM snapshotting is extremely wasteful - it has no knowledge of the underlying structure of a filesystem. For example, if I moved all the files around on a fairly full ext3 filesystem, an LVM snapshot would consume the full size of the filesystem. However, a filesystem-level solution wouldn't need to store a single byte of data since nothing actually changed. Also - a snapshot restoration obliterates ALL data on the partition that has changed since the snapshot was taken - so unless the essential files are on a separate partition it won't work out well. LVM snapshots really seem to be a solution to atomic backups - if you unmount, snapshot, and remount a filesystem then you can run a self-consistent backup off of the snapshot with minimal downtime. The wasted space isn't a big deal since the snapshot would be deleted before it grew too far. Finally - I'm not to eager to try out lvm2 again anytime soon - I lost a ton of data when something glitched and wiped out data across multiple lvm partitions. I know that the error must have been in the lvm layer (not md or the filesystem), because when I fscked and repaired one filesystem, another filesystem instantly became hosed (on a separate lvm partition). Somehow the partitions had gotten scrambled together and the fsck was crossing partition boundaries. Plus, dmesg was dumping all kinds of compliants at the md layer about the lvm device trying to access out-of-range clusters. Googling I found a few other reports of similar behavior - it seems extremely rare, but very nasty. Fortunately the most important stuff on my PC was backed up (good planning), but it was still a pain - I lost tons of DVR recordings since I don't back that up (not worth the cost vs the value of the data). Now I just run ext3 on top of md and I haven't had any problems. You're right that btrfs will definitely help. However, being able to create a personal stage1 tarball at will would certainly also be useful, and it wouldn't actually consume much disk space.
Re: [gentoo-dev] Re: [RFC] Splitting desktop profile to KDE and GNOME
Duncan wrote: Actually, yes. Gentoo has never been a hand-holding distribution. We try to provide documentation and reasonable defaults for any apps the user chooses to install, and let the user configure what they will. Gentoo is about choice. Well, except for the choice to not have to choose... I don't see why having some nice polished sets of use flags is a bad thing. Personally, I find it a pain when I've emerged half of my system only to find out I left out some critical use flag (my use flags take up several lines now). Sure, leave users a choice, but there is no harm in giving them some pointers. Gentoo should be fully usable in a USE= state, but that doesn't mean that we need to make users start out from this point.
Re: [gentoo-dev] [RFC] Improve policy of stabilizations
Mart Raudsepp wrote: Is it stated in any documentation that 30 days is a policy? Not that I'm aware of - it is a guideline as you indicate. However, don't expect anybody to actually take action on a STABLEREQ if there isn't some kind of rationale for going stable so quickly. The whole point of stable is that they provide some sanity to the release process - if upstream releases a new version every other week then perhaps we should either: 1. Question whether it should go stable at all. 2. Pick a version once in a while and target it for stabilization, backporting fixes as needed. We don't need to be Debian stable, but if the only reason for stabilizing a package is that upstream has already moved on, then I think we're making a mistake. In fact, if upstream abandoned a release after only two weeks that would be a good reason NOT to stabilize it. End users can always run ~arch if they need to - at least this way they know in advance what they're getting into.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in app-forensics/foremost: ChangeLog foremost-1.5.6.ebuild
Petteri Räty wrote:
#SRC_URI=mirror://sourceforge/${PN}/${P}.tar.gz
# starting to hate sf.net ...
SRC_URI=http://foremost.sourceforge.net/pkg/foremost-1.5.6.tar.gz;
The filename that violates our policies hasn't changed between the new
and old SRC_URI.
Is this policy actually written down someplace? Sure, having the
SRC_URI pick up the package version automatically is good practice and
all, but does this actually rise to the level of a QA policy violation?
To me the word policy violation means more than just something that
could have been done better. It means that someplace there is an
official rule in writing that wasn't followed, and that rule was
endorsed by some official body recognized by gentoo. I don't think
quizzes can be considered policy since by design their answers aren't
written anywhere.
The only downside to not being clever with the SRC_URI is that to bump
the package you'd need to edit the URL. That isn't exactly the end of
the world, and while this is a trivial one to fix I've certainly seen a
few that are quite messy to automate.
Now, if there were no version in the filename I'd consider that a policy
issue as it would mean that the distfiles would get confused rather
quickly. However, not every lack of ideality is a policy violation
worthy of a 30-post -dev thread.
Even so, it doesn't hurt to point out non-idealities so that they can be
corrected. Let's just try not to treat them the same as if somebody had
keyworded something that breaks stable systems...
Re: [gentoo-dev] QA is unimportant?
Peter Volkov wrote: 1. Our good non-formal policy if developer touched anything he becames responsible for that ebuild and should fix issues noticed is sometimes ignored. We see people reacting: you've noticed - you fix. I think such attitude is unacceptable. Keep in mind the downside to such a policy is that people just ignore problems that are trivial to fix, because they don't have the time to go over the ebuild with a fine-toothed comb. Then, if people get their heads chewed off on -dev if they do miss something that lowers the motivation just a bit more. Sure, if a dev fixes an ebuild they should give it a once-over to make sure there are no major problems, and obviously they should do moderate testing to make sure it builds and works. However, if I spotted a minor problem with an ebuild that I could fix, and a major problem that I couldn't fix, chances are that I wouldn't touch it at all. Then the ebuild stays in the tree with both problems, instead of one fewer. I think it all boils down to we're all in this together. If you see a problem try to fix it, and if you see somebody make a mistake try to help them out.While we do need policies, and policies do imply police, nobody likes the police, so let's try to make that work with the minimum in fuss. A good rule of thumb is whether a dev has left a situation better off or worse off than when they touched something, and in this case I'd have to say that we're better off. While the good can be the enemy of the best, sometimes the best can be the enemy of the good, and I think that sums up the current situation well.
[gentoo-dev] GPG Infrastructure for Gentoo (Was Council Meeting)
Antoni Grzymala wrote: How about getting back to GLEP-57 [1]? Robin Hugh Johnson made an effort a year ago to summarize the then-current state of things regarding tree and package signing, however the matter seems to have lain idle and untouched for more than a year since. One concern I have with the GLEP-57 is that it is a bit hazy on some of the implementation details, and the current implementation has some weaknesses. I go ahead and sign my commits. However, when I do this I'm signing the WHOLE manifest. So, if I stabilize foo-1.23-r5 on my arch, at best I've tested that one particular version of that package works fine for me. My signature applies to ALL versions of the package even though I haven't tested those. Now, if we had an unbroken chain of custody then that wouldn't be a problem. However, repoman commit doesn't enforce this and the manifest file doesn't really contain any indication of what packages are assured to what level of confidence. If we want to sign manifests then the only way I see it actually providing real security benefits is if either: 1. The distro does this in the background in some way in a secure manner (ensuring it happens 100% of the time). 2. Every developer signs everything 100% of the time (make it a QA check). The instant you have a break in the signature chain you can potentially have a modification. If somebody cares enough to check signatures, then they're going to care that the signature means something. Otherwise it only protects against accidental modifications, and the hashes already provide pretty good protection against this.
Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)
On 12/13/2009 02:49 PM, Robin H. Johnson wrote: On Sun, Dec 13, 2009 at 10:44:05PM +1100, Daniel Black wrote: Recently this got produced as a draft license for parties distributing CAcert's root certificate(s) (like us). https://svn.cacert.org/CAcert/Policies/Agreements/3PVDisclaimerAndLicence.html That's a pretty dense license. I can see why you had a headache. I believe that in it's current form, we will have to make sure we have a liability disclaimer to users for the license, but that should be about it. First, I am not a lawyer. The 3PV license does require that the user be presented with: http://www.cacert.org/policy/NRPDisclaimerAndLicence.php I'm not sure that simply posting the link in an einfo would satisfy the requirements. We might need to post the full text to qualify as having presented it to the user - not sure about that. I don't see anything in there that requires interaction though (hitting a yes button or anything like that). The license itself is fairly short - we only need to post the NRP and not the 3PV license. The 3PV is a license for Gentoo to distribute content to users under the NRP. Users who don't redistribute the key don't need to worry about it. An option would be to RESTRICT=mirror their root key, and install it directly from their site, assuming they don't start messing with the URL. Then we can just put the license in the ebuild like any other. Since we don't redistribute anything copyrighted, Gentoo itself doesn't enter into any license agreement. Only issue with that is that it is often bundled with a bunch of others and I don't know that you can restrict only one URL in the ebuild.
Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)
On 12/14/2009 03:10 PM, Robin H. Johnson wrote: 1.4 Vendor's Agreement with End-User Vendor agrees 1. to distribute both the NRP-DaL and this present agreement to end-user, Ah, this was my mistake. I read that as to distribute both the NRP-DaL and present this agreement to [the] end-user, Funny how swapping the order of two words changes an adjective to a verb... :)
Re: [gentoo-dev] CAcert certificate distribution license to third parties (i.e. distributors like gentoo)
On 12/15/2009 01:46 AM, Daniel Black wrote: I did email the debian maintainer too. no response yet. They have interactive builds though and I guess we do too now. Will be a royal pain if every CA/software did the same thing. The last thing gentoo needs is interactive builds. XFree86 was forked over something less annoying than that (advertising clause)... I'd rather put a disclaimer in the handbook that when you install gentoo you bear the consequences of anything you do with it: if you're in a jurisdiction where software licenses are binding on those who use software then be sure to set ACCEPT_LICENSE accordingly, and all users should monitor the outputs of their builds for important notices. On that note, perhaps the default make.conf should send ELOGs to r...@localhost or something? People can disable it if they don't like it, but I don't think we want our default to be that important notices are lost. If legal experts feel that the only thing that will work would be an interactive build, then we should: 1. Have the build by default terminate with an error that it requires some kind of acknowledgment. Ideally have the package manager detect this condition at --pretend time. 2. Have the user set this acknowledgment using an environment variable in make.conf (perhaps a setting for these purposes), or a local use flag, or some other one-time non-interactive mechanism. 3. Have the build notice this and proceed normally (so the actual build and future upgrades are non-interactive). 4. Ensure that this package is NOT required by anything in system, or installed by default by any major popular package (so maybe we have ca-certificates, and ca-certificates-annoying or something). We definitely don't want the gentoo experience to be one of typing emerge world and then having to check back on it every three minutes to see what the latest prompt is. I'm generally in favor of including CACert by default, but if they're going to shoot themselves in the foot over licensing then that is their loss. I already have to install it manually for chromium (a real pita, btw). I can't see the council voting to allow interactive builds for a certificate, and I really don't see why CACert is pushing this either...
Re: [gentoo-dev] Re: [gentoo-dev-announce] January 2010 meeting date
On 12/21/2009 02:54 AM, Fabian Groffen wrote: If all mail that would go to -dev-announce would guaranteed be sent to -dev as well, I didn't have to check -dev-announce, and archives.g.o would also have the original January 2010 meeting date mail in the thread on -dev. Or you could just subscribe to both and add this to your procmailrc: :0 Wh: msgid.lock | formail -D 8192 msgid.cache :0 a: .duplicates/new Cross-posting in general tends to mess up threads, but there isn't much that can be done about that unless we just ban it. However, most cross-posts are honest attempts to try to move list discussion to a place where it might better belong. Honestly, list traffic is a lot better than it used to be, and I'm not sure that this is really a big problem these days.
Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat
On 12/20/2009 01:04 PM, Jeremy Olexa wrote: Flattered, but I decline. I don't agree with the way the Council works and don't have motivation to attempt to change it. Out of curiosity, would you care to elaborate? I don't have much of a political axe to grind so I guess I tend to stay out of the politics...
Re: [gentoo-dev] Re: [gentoo-dev-announce] Election for the Gentoo Council empty seat
On 12/21/2009 06:33 AM, Richard Freeman wrote: On 12/20/2009 01:04 PM, Jeremy Olexa wrote: Flattered, but I decline. I don't agree with the way the Council works and don't have motivation to attempt to change it. Out of curiosity, would you care to elaborate? I don't have much of a political axe to grind so I guess I tend to stay out of the politics... Sorry - that was not meant to go to the list, although list-replies in -project might be appropriate if they are constructive...
Re: [gentoo-dev] metdata.dtd should require herd/
On 12/23/2009 01:36 PM, Paul de Vrieze wrote: Perhaps we should create a schema to validate the file. XMLSchema (or any of the other standards) allows for much more flexibility in specifying these things. Btw. I did not design the metadata DTD for order to be significant. The only priority is that maintainer goes before herd, that's all. I think we should definitely have some way of designating which should be the contact for bugs. I've had some bugs sit around for a while without being noticed because they were assigned to the herd the package is in, and not to me personally, and I don't generally work with that herd, and the project associated with the herd doesn't generally maintain the package. I'm sure there are many cases where a similar situation exists. Another way to handle this is at least CC EVERYBODY in the metadata in new bugs, and not assume that copying the project will get all the maintainers.
[gentoo-dev] QA Documentation
Started new subject since this is only tangentially related to the election. On 12/27/2009 06:16 PM, Tomáš Chvátal wrote: Anyway, i wont write huge manifesto but these things i would like spent my time: QA propagation (motivating people, explaining why we are doing stuff and so on) Could this include documenting QA policies a bit better? Some are documented in scattered docs, some are in the ebuild quiz answers (which of course no two developers have the exact same answers to, and they aren't anywhere you can point to for reference), and many are learned when QA files a bug on a package one maintains. It would be really nice to just have a list somewhere that we could periodically look at and refresh our memories against. Plus, some policies aren't always obvious or can be misinterpreted. Don't get me wrong - the QA team is doing a great job and I love Diego's work on the tinderbox. I've had a bug or two filed by them, and I've found that they've only been helpful when somebody actually bothers to try to resolve them.
Re: [gentoo-dev] QA Documentation
On 12/28/2009 06:23 AM, Tomáš Chvátal wrote: we should ENFORCE it, not just fill bugs about it, because mostly people tend to ignore that things. Agreed, although some presumption of innocence should be assumed. If a dev is ignoring repoman output that is a fairly big violation, but if a dev missed that compiling under some strange set of circumstances or combination of use flags causes a problem, well, that's a bug that needs to be fixed. There were some --as-needed issues detected by the tinderbox that only show up when you use a modified gcc profile, for example. That doesn't mean they're not worth fixing, but we shouldn't punish people for that stuff. I don't think the QA team has an issue with mistakes (not that I can really speak for them) - their main frustration is probably when bugs get filed and then get ignored. Expecting people to resolve bugs in a week for minor issues is probably asking a bit much, but if a dev has 14 packages with 25 open bugs each that are six months old that is probably a cause for concern that should be escalated to devrel. On the other hand, some allowance for brain-dead upstream tactics should be made. I'd consider embedded libraries a QA issue, but if we made that a stern policy we'd never see chromium in the tree for quite a long time. I'm sure the guys maintaining that would love to try to patch out as much of the embedded stuff as they can, but they've got a LOT of work to do due to the way it was written. I'm not sure that simply banning chromium from the tree is the right approach either as long as upstream deals with the inevitable security issues when they come up.
Re: [gentoo-dev] Non-free software in Gentoo
On 12/28/2009 01:56 PM, Robin H. Johnson wrote: Actually, this is a case where the license on the ebuild is wrong, not the license group. The kernel ebuilds should have GPL-2 and something else, and by definition should not pass @FSF-APPROVED alone. Is this appropriate? The kernel sources indicate that they are licensed under GPLv2, and they make no mention of other licenses for any component of the sources. Perhaps Linus/etc are wrong about this - but shouldn't that be something that people take up with them, unless Gentoo gets a letter from some lawyers claiming that we're infringing? For that matter, for all we know kdelibs contains 10 lines of code from Jack Smith, who didn't agree to the LGPL and those 10 lines are under the Jack Smith Distribution License. However, it would be best if Jack Smith were to take this up with the KDE team and not with every distro that uses KDE. If Gentoo starts second-guessing the licenses on packages, do we then become liable if we fail to do this for a package?
Re: [gentoo-dev] Non-free software in Gentoo
On 12/28/2009 05:53 PM, Robin H. Johnson wrote: You're wrong there. The kernel does contain additional licenses, and EXPLICITLY mentions them. Go and read 'firmware/WHENCE'. The licenses listed therein range from use-permitted only no-modification, to GPL-compliant and BSD-like. I stand corrected. Somebody should tell Linus that his readme/copying is a bit misleading. They really shouldn't bury licenses in subdirectories. There is no second-guessing. What I am concerned with is that Gentoo's statement of licensing does not accurately reflect what licenses are on the package. Agreed - I think the key is for the package maintainer to ensure the license is accurate, and if anybody notices a problem just file a bug. I think the kernel is a bit of an oddball since the sources are so large - most packages are much smaller and have a single license, and the maintainer will probably be familiar enough to sort it out.
Re: [gentoo-dev] Non-free software in Gentoo
On 12/29/2009 07:52 PM, Greg KH wrote: No, the readme/copying is correct, it covers all of the code that runs on the processor as one body of work. Firmware blobs are different in that they do not run in the same processor, and can be of a different license. Yes, but they don't cover everything in the tarball. If I want to copy the tarball, then I need to comply with the distribution license of the tarball. That license isn't clearly advertised. It is a mix of a number of licenses from GPL v2 to allowed-to-copy-without-modifications. The processor that the software runs on is fairly irrelevant. In any case, I'm sure the kernel team will update the ebuild license string appropriately - this is more of a debate for the LKML. I just don't think that they've done a good job with it. Others are welcome to hold differing opinions. :)
Re: [gentoo-dev] Why do packages which will not build remain in the distribution list?
On 12/30/2009 05:18 AM, Petteri Räty wrote: You need to understand what the world set means. The world set is the packages in /var/lib/portage/world and the sets from /var/lib/portage/world_sets . From this follows that we can't change the content of the world set as it's a user specific configuration issue. Just to clarify a little (the above is completely accurate, but it might not be obvious how portage works just from reading this): The world set is a list of every package that you've executed an emerge package command on, without a -1 on the command line. So, if you type emerge xterm, then xterm is in your world set. A package is removed from world if you uninstall it, or if you edit that file manually. Packages that are installed because they are needed by packages that you install are not added to world, unless you later manually emerge them without a -1 on the command line. The idea is that anything you explicitly ask for is something that portage will try to keep around for you, and anything you don't explicitly ask for is something that portage will try to get rid of if it isn't needed later. So, those ruby packages ended up in world because you emerged them. Any new version that goes stable/testing on those packages will consequently get pulled in by an emerge -u world. The real issue (as was pointed out) is that packages shouldn't even be marked for testing (let alone stable) if they don't actually build, or if they have serious problems. They should be masked, so that only those interested in developing/debugging the package get hit with it. I don't want to comment on the packages you listed in particular, but sometimes you can run into build issues due to a need to run revdep-rebuild, or lafilefixer, or to rebuild some library. I had an x86 chroot that absolutely refused to build imagemagick until I just reinstalled the whole thing from stage3 - probably some obscure library/compiler problem. So a build error might not reflect a problem with the package you're trying to build. Obviously we still try to avoid these kinds of issues and warn users when they are likely to happen. I'd continue to follow the bug, and if it seems like something like this isn't being resolved expediently feel free to contact the QA team: http://www.gentoo.org/proj/en/qa/ The QA team ensures that Gentoo quality policies are being followed and can poke maintainers or step in as appropriate. Note that I haven't reviewed the packages/bugs that are being discussed here, so none of this is targeted at anybody in particular. I'm just pointing out how things like this are supposed to work in general. Rich
Re: [gentoo-dev] Non-free software in Gentoo
On 12/30/2009 11:48 PM, Greg KH wrote: Heh, no, it does not, unless your BIOS, and your keyboard firmware, and your mouse firmware are all under a free license. The only thing close to this type of machine is the OLPC, and even then, I don't think all the microcode for the box was ever released. So it's a pointless effort. Actually, you describe the futility of the effort, not the pointlessness of the effort. The fact that an effort is difficult or even futile does not make it pointless. Some might disagree about it being impossible as well (there are open-source BIOS implementations, for example). I'm sure the people who have such philosophies try to run free software anytime that it is possible. They might not be able to run free software on their microwave, but if one came out with an open-source firmware they'd probably try to buy it. I don't see this as being inconsistent, just practical. The fact that they can't buy an open-source toaster or mouse doesn't mean that they can't use an open-source kernel. Hint, these firmware blobs do not run on your processor, so they have nothing to do with the license of your system. I'm not really sure where you're coming up with this argument. The purpose of a license is to ALLOW you to do something you otherwise wouldn't be allowed to do. Licenses don't actually take away rights, they grant them. Laws do take away rights. There is a law that says that if I write a program and give it to you, you can't copy it and give it to somebody else. However, if I give you a license to copy the file under some conditions, then you can copy it legally if you follow those conditions. Nowhere in copyright law is the word processor found or implied - the technology used to copy is also irrelevant except to the degree that it impacts fair use. When you run software you aren't distributing it. The concept of a use-license is a bit blurry - some people think that you don't need a license to use software, and other people think you do. I don't believe that court rulings are as uniform on the topic of use as they are on the concept of copying. In any case, the GPL v2 does not in any way attempt to restrict or grant the rights to use software - only to distribute it. GPL v3 is a bit murkier in this regard, but irrelevant to a discussion on the kernel. Again, no, the GPLv2 covers the license of all of the code you run in the kernel package. The concern isn't about RUNNING the software - it is about DISTRIBUTING the software. And again, you do not run those firmware images on your processor, so the point is moot. Sure you do - you run them on your sound card processor, or your video capture card processor, or whatever. However, the concern isn't running the software, it is redistributing it. And note, _I_ placed those images in the kernel image, after consulting lawyers about this issue, so it's not like I don't know what I am talking about here. Did they say that the GPLv2 applied to the entire tarball containing the firmware? Or did they simply state that building/running kernels using the tarball was legal? Nobody is saying that the presence of the proprietary bits violates the GPL (v1, v2, OR v3). You're not doing anything illegal. However, the tarball is not licensed under the GPLv2. I can't modify that tarball at will, for example, and redistribute it. If I modify 10 bytes in the middle of one of those firmware blobs, reassemble the tarball, and post that on my website, I can be sued by the maker of that firmware blob. I haven't violated the GPL in doing any of that - the problem is that the firmware blob isn't licensed under the GPL. The license to redistribute the gentoo-sources tarball is NOT GPLv2 - it is GPLv2 for 98% of it, and a mix of other licenses for the rest. I don't own a keyspan usb serial device, but that doesn't mean I can modify the usa28.fw file and put it in a kernel tarball on my website, as the license for that file SPECIFICALLY states that I'm not allowed to do this and it is copyrighted. Doing this doesn't violate the GPL, but the GPL doesn't apply to this file. The point of this thread is that the gentoo-sources package is mislabeled as GPLv2 when the entire package is not licensed under GPL v2. Nobody is saying that it is illegal to distribute gentoo-sources, only that it cannot be entirely distributed solely under GPLv2.
Re: [gentoo-dev] Qt3 deprecation and removal policy
On 12/30/2009 12:14 PM, Ben de Groot wrote: 2010-01-21: * Qt team meeting: discuss actions to be taken regarding remaining pkgs that use qt:3 2010-02-21: * mask qt:3 and depending ebuilds, pending removal 30 days isn't a long time. How about filing bugs against anything that currently uses qt3 right away, so that maintainers have an extra three weeks to resolve these issues? Granted, one would hope they've been paying attention. As a random example, the current stable version of mythtv uses qt3, but I don't see any open bugs about that (that package is probably an easy fix as the newer versions use qt3support, and that version is already stable upstream). Usually the approach in these situations is to have a big tracker bug for qt3 removal and a million blocker bugs against individual packages. I'm not saying you can't move forward until everybody else gets their acts together, but tracking this in bugzilla probably isn't a bad move if it isn't too much work. Plus, you might decide that one or two of the blockers really are critical, and decide to work with those maintainers more closely or escalate the issue.
Re: [gentoo-dev] Re: Qt3 deprecation and removal policy
On 12/31/2009 08:24 AM, Samuli Suominen wrote: On 12/31/2009 03:13 PM, Christian Faulhammer wrote: Hi, Samuli Suominenssuomi...@gentoo.org: Just saying... Please track progress somehow. I know it is a lot of work, but makes understanding the process easier. V-Li It's been done in, http://bugs.gentoo.org/show_bug.cgi?id=292791 That is for kdelibs-3.5 - not for qt-3. However, it wouldn't shock me if the list is almost identical. If the opinion of those with more knowledge of such things it that the one effectively covers the other I have no objections to not duplicating work... If not maybe a tracker for any additional qt3 packages that aren't already tracked might not hurt, or we could lump them in together since from a work perspective they're almost the same.
Re: [gentoo-dev] Qt3 deprecation and removal policy
On 12/31/2009 07:51 AM, Samuli Suominen wrote: Stable MythTV has more issues than just Qt3, as the current stable doesn't compile anymore, http://bugs.gentoo.org/show_bug.cgi?id=280303 which is about to get masked tomorrow with kdelibs-3... Those of us who run it wouldn't mind seeing a STABLEREQ if cardoe thinks it is ready... :) I've been thinking about taking the plunge anyway. A news item about the utf-8 issues might not hurt though as doing the upgrade right involves backups/etc. The news item should be released BEFORE it goes stable. That is, unless the upgrade process has become seamless now.
Re: [gentoo-dev] Re: Documentation licenses and license_groups
On 01/05/2010 01:07 PM, Duncan wrote: Periodically there's talk of adding + versions of at least the FSF licenses, but while it would probably be quite a good thing, it'd be a LOT of VERY boring work poring thru all those packages and either updating to the + version, or leaving comments in each one saying they'd been checked already. I think that this should at least be added. If some things are more conservatively labeled as v2 when it should be v2+ it doesn't cause all that much harm. Over time the licenses would get updated, and then we'd have more useful metadata. The whole concept of GPL-compatible doesn't work when GPL2 isn't compatible with GPL3, and vice-versa, and all the way back to 1. At best we can have GPL3-compatible or GPL2-compatible or whatever. What happens when GPL4 comes out and we need to edit the group again? What will that break?
Re: [gentoo-dev] Non-free software in Gentoo
On 01/07/2010 01:19 AM, Vincent Launchbury wrote: All I'm asking for is that users who care about this will be shown an accurate license, I think that this really sums this whole thing up. Can you run a computer with ONLY FOSS on it (firmware to ROMs to hard drive controlers) - probably not, but maybe. I think that is really a separate matter. I think this really just boils down to this: If we have a piece of metadata on a package it should be accurate. The license should reflect the license of whatever ends up on a user's hard drive. Maybe knowing the license isn't that important - in that case maybe we shouldn't track licenses at all. However, if we're going to track the license, then it should be completely accurate (or at least we should aim for that even if Gentoo metadata can never be perfect). That's why I also support having GPL2 vs GPL2+ / etc in the license field. Sure, it won't be exactly right for a while, but it is worth shooting for. Ditto for other metadata - homepages should be official, maintainers should be active, and all that. QA will always have work to do as this will never be 100% right for everything in the tree, but there is value in being accurate anytime we can be. By all means the default install should have an ACCEPT_LICENSE that is both legal and fully functional - if people want to trim it down that is up to them. Maybe somebody wants to use Gentoo to build an appliance and they want to go pure non-copyleft - that's a major chore but we could still give them a great head-start on identifying where the issues with that are and at least getting them 80% of a functional system. I think this whole thread really boils down to - make the license accurate. What users do with it is up to them, and we don't need to support non-standard configurations just because we make them possible.
Re: [gentoo-dev] Some ideas on the licensing issue
On 01/07/2010 05:46 AM, Hanno Böck wrote: I think the GPL-compatible set makes barely sense. ++ Difference between OSI and FSF approved: ... I think the definitions of FSF and OSI are pretty much the same, ... So I'd like it much more to have one big This is free and open source software set. -- I think that we should make the license groups as objective as possible. EVERYBODY can agree that such a license is or isn't OSI approved or FSF approved - whether they hate or love the FSF/etc. By all means every gentoo dev is welcome to post on their blog if you want free and open source software put this in your ACCEPT_LICENSE - and everybody can post comments on the blog calling them the next saint of the Church of GNU, or the devil incarnate. Let's just keep the portage tree to the facts. Now groups that are fairly legally objective like redistributable-without-modification I think are useful. They could be useful in doing QA checks on RESTRICT=mirror, for example. However, let's try to stick with simple objective criteria that both people who hate a license and love it can agree on. What bites me is the man-pages issue. Is it really the case that there's no free (as in freedom) man-pages package? Maybe then we should provide an option to install the base system without man-pages? I guess strictly-speaking man-pages aren't essential as part of system, but they'd seem like a big omission to leave out. Unless we want a free-only profile (nobody seems to want to fully support this), I think that the better option is this: Write up instructions on how to have a free gentoo install and put it on your blog or whatever. If they've good enough maybe we can have the doc team make it official (gotta consider support issues here). You can always stick the man-pages in package_provided or whatever so that portage doesn't try to install it. You can also make your own profile, and post instructions for the world to see. Again, break it and you get to keep the pieces and all that...
Re: [gentoo-dev] Non-free software in Gentoo
On 01/08/2010 12:26 AM, Greg KH wrote: If the kernel loads a firmware file that is not free, or if the device itself has a firmware in it that you can not change so easily, has _nothing_ to do with the license of the kernel, I don't think anybody is concerned about the license of the kernel, but rather the license of sys-kernel/gentoo-sources. Gentoo-sources contains the kernel as well as a bunch of other stuff (documentation, firmware, etc). It can only have a single license if EVERYTHING installed by the package is usable under that single license. The LICENSE in an ebuild pertains to the package - not just to the largest component or majority of the package. Very few people install gentoo-sources mainly to read the docs or get a firmware blob, but they are still there, and the license should reflect this.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/11/2010 06:30 PM, Arnaud Launay wrote: As a newsmaster, I'm a bit concerned by this. Yeah, inn seems like a really high-profile package to mask for removal. It would be conspicuous in its absence. Would it make sense to post on -dev BEFORE masking packages like this? I'm sure there are lots of people who would chip in before something like this dies. Right now lots of users are going to get errors due to a masked package until somebody takes the initiative to fix it. I suspect that nobody wants to poke their head up and risk getting it shot off by doing something like that... Perhaps Gentoo needs a little more of Wikipedia's Be Bold attitude and a little less of their delete first and ask questions later attitude. Note - I'm not suggesting the problem shouldn't be fixed - I'm just suggesting that in this case the solution is worse than the original problem. Rich
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/11/2010 10:43 PM, Jeremy Olexa wrote: (A general reply, not targeted towards you, Rich) No prob - my post wasn't really directed personally at anybody. Speaking on behalf of the treecleaners: The fact is, some of us have never heard of inn and until Gentoo has some sort of popularity tracking software/tool, the treecleaners will continue to mask unmaintained software. Yikes - just goes to show how NNTP is starting to fade into the past. :) I'm not sure if it would cause undue overhead, but perhaps a solution would be to: 1. Open a bug stating that the package will be discarded - assign to the maintainer. This gives the maintainer a chance to wake up. You can even do this without having to try to contact them first which might save you a step if you're doing that now. 2. Periodically post a list of packages that have said bugs logged for more than two weeks on -dev-announce - reference the bug number. That gives the community at large a chance to pick up the package. 3. In another two weeks, if some dev hasn't stepped in to maintain, then mask as usual. Don't announce this since anybody who cares should have CC'ed themselves on the bug. 4. Of course, security issues / etc take priority and appropriate action is taken quickly (try to find a maintainer, but mask otherwise). I'd think that if you tagged bugs appropriately you could largely automate #2 and #3 - just query for bugs over a certain age with a given keyword or whatever. This would probably lengthen the time needed to get rid of a package, but it wouldn't really increase the work needed by too much. You already announce on the list that you're masking packages - now you'd announce two weeks earlier and skip the announcement when the mask is made. This is just a suggestion, but it does eliminate the need to try to make judgment calls about whether a given package is or isn't important. Rich
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/12/2010 01:30 PM, Markos Chandras wrote: IMHO ( this is not a treecleaners@ opinion, i m just talking for my self ), announcing and masking a package is a good way to inform and wake up everybody to take care of this package if they really really want to stay on portage. I agree with the announce part, and the THREAT of masking. I just don't think that the masking should happen at the same time as the announcement. Having open bugs for months isn't a way to let everybody know that this package is broken for long time, so it is a valid candidate for removal? Should we send that via e-mail as well? I don't think an open bug constitutes notice. It is valid notice to the maintainer of the package, but not to the larger community. I probably have 100-200 packages installed, and I'd probably be annoyed if any of them went away (I'm still missing kdirstat, but that isn't really the kde team's fault). If an important one was about to go away I might step in to maintain it, and I'm sure a lot of other people feel the same way. At the same time, I can't monitor the bugs on 100-200 packages - that is the reason for having a maintainer. I think the concern is that some maintainers don't respond in a timely manner. Now, I don't know that maintainers have an obligation to fix every bug within a certain timeframe - some packages are problematic and I'm not sure that we should discard a 98% solution in favor of a 0% one because we don't have a 100% one. However, serious issues should be in scope for treecleaners, but the first goal should be to find a maintainer, and only if that fails should we consider masking. Also - if a maintainer can't be found we might also try to coordinate with the Sunrise folks to see if they're willing to take it over. We should also solicit proxy-maintainers among the user community when we announce pending removals. That could be very helpful with something like inn: I use it VERY lightly and I'm not a news guru, but I am a dev. I bet we have users who are news gurus and who care about inn, but they aren't Gentoo devs. Together we could probably cover the gaps and I'm sure devs would be more willing to pick up a package if they knew they had some help with the nuances of the package itself. If that falls apart later, at least an active dev is assigned to the package, and they can always decide to try to find a new maintainer or kill the package (saving treecleaners the work of doing so). In short - treecleaners should be about getting packages back into the mainstream maintenance model, with removal being the fallback option if that doesn't work. They shouldn't have to go out of their way to do this, but an advance announcement and some coordination is probably a good idea. Rich
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/13/2010 09:24 AM, Mike Frysinger wrote: On Tuesday 12 January 2010 15:51:28 Tomáš Chvátal wrote: And since WE want to enable as-needed as default at some time we need to work on the bugs which isnt going to happen This isn't really intended to point fingers at anybody in particular - I haven't personally investigated the complexity of fixing the as-needed issue for this particular package. I think that logging as-needed bugs is certainly a value-add. I think that tracking a blocker for as-needed is a value-add. However, if we want to turn as-needed into a QA issue and try to enforce it, I think that this should really be run past the council and documented. It wouldn't hurt to also document tips for solving the problem and the proper way to mask as-needed if it just isn't going to work (even if we make as-needed the default that doesn't mean that we can't mask it if we have to). I think that devs should make good-faith efforts to fix as-needed issues, but if the problem is with the overall upstream design and major work is involved, that is an UPSTREAM problem. Sure, it is nice if somebody wants to be an upstream contributor and fix their problems for them, but I'm not sure that it is worth the Gentoo resources in every single case. Maybe for system packages or common dependencies we might push a little harder. In any case, when this kind of controversy exists the best solution is to make a proposal and ask the council to render a decision. It isn't productive to have battles on the mailing list about whether something should or shouldn't be policy. I don't mean to suggest that QA or treecleaners or whatever absolutely must run everything they do past the council. However, when we run into genuine disagreements between projects/herds/devs that is the ultimate escalation path. Package mask is not a very good way to try to hit devs with a cluestick anyway - the main victims of this sort of approach tend to be the users.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/13/2010 10:06 AM, Arnaud Launay wrote: which kind of explain what is a proxy maintainer (more or less), but does not explain how to become one... We don't really have any official process around this. Things like sunrise and proxy-maintainers are good ways to get new blood into the contributor pool, however, and I think they'd be good things to look into. Maybe I'll try to brainstorm some ideas of how to generate involvement (I'll post on -project if I come up with something). Le Tue, Jan 12, 2010 at 09:49:10PM +0200, Markos Chandras a écrit: If you feel like it, become a proxy-maintainer and poke a developer to put your ebuilds on tree. Have you ever heard of that ? :) No problem. Just tell me who I need to poke :) Would that be antarus, saying hey, I'm mostly in servers, how may I be of service ? Yup - some kind of clearinghouse and communications tool wouldn't hurt. You can always post in irc or a list and see if you get any takers. You can also post them in bugzilla under maintainer-wanted, but it doesn't get much visibility there.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/17/2010 03:20 PM, Thilo Bangert wrote: Ben de Grootyng...@gentoo.org said: I think we have a bigger problem with packages that have a maintainer, at least nominally, but said maintainer does not actually maintain the package anymore. full ack. i was thinking that maybe we need an 'easy-fix' team, which can do all the easy fixes, which have been laying around for way too long and which aparently are easy to fix (ie. only waiting for somebody to commit)... I think this is a good idea. Alternatively, perhaps if we just make a policy that it is acceptable for a dev to touch a package and leave it with QA problems, as long as it ends up with no more QA problems than it started with. Of course, devs are encouraged to fix QA problems whenever they can. This way devs will be more willing to make small fixes that generally improve the distro without being worried about being chewed out because they didn't go through the package with a fine-tooth comb looking for issues. That will at least get poorly-maintained packages trending in the right direction. Along with that I think we need to address the problem of packages that list a maintainer but which aren't maintained. Perhaps a solution would be to have some way to periodically ping maintainers to confirm they're still looking at a package. That could take many forms - a simple one would be to ask the maintainer to touch the metadata.xml file or something like that (obviously the manipulation has to be something that is noticed by CVS). On the other hand we don't want needless churn. Then an automated process can ping maintainers if they haven't done this, and after a delay the package would be set to maintainer-wanted. Actively-maintained projects would be allowed to use automation to keep packages they track marked fresh. However, the project does then become accountable for actually maintaining them. This would go along with an (unwritten but already in place) policy that anybody listed as a maintainer has to actually maintain the package, with consequences for not doing so to some defined standard. This standard would not be zero-bugs, but certainly anything real flagged by repoman or a violation of a written QA policy would be expected to be cleaned up in a timely manner. The goal is to make the maintainer field meaningful. Then we could figure out a policy for maintainer-wanted builds. My feeling is that as long as they build, don't have security issues, and don't have QA issues that genuinely get in the way of some Gentoo initiative, they can stay around. Once any of the above ceases to be the case they're announced on-list and then treecleaned. The bottom line though is that we can write all the rules we want - ultimately Gentoo needs warm bodies to fix bugs. No amount of process will get around that. What process can do for us, however, is to increase visibility of issues so that QA doesn't waste time hunting down inactive devs and so that people running servers or whatever can tell if a package is actively maintained.
Re: [gentoo-dev] Re: Last rites: net-nntp/inn
On 01/17/2010 08:23 PM, Ben de Groot wrote: What about something like: if a bug has been open for 2 months without any apparent maintainer activity, anyone can step in and commit a fix? How about - anybody at any time can at their discretion post a comment in a bug asking if there are objections to committing a fix. If there is no reply from the maintainer/project/etc in two days go ahead and do it. Do check devaway first to see if it makes sense to wait a little longer, and use discretion on the more critical packages.
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 01:20 PM, Ben de Groot wrote: 2010/1/24 Petteri Rätybetelge...@gentoo.org: On 01/24/2010 03:02 PM, Ben de Groot wrote: Why should we keep redundant information in the list? How is that redundant? Well, I doubt we'll get away from python in the system set anytime soon, but imagine the results of having a policy that anything that is a dependency of something in system needs to be in system. Now the system set is three times larger than it is now. There is also no easy way to tell whether something is in the set simply because it is a dependency. Then in the future if something is no longer a dependency it will be installed on every gentoo system unnecessarily. Sure, we can clean things up every once in a while, and maybe even automate that, but what would be the point. The whole reason we have dependency management in our package managers is so that you don't have to worry about details like what package requires what. Package managers shouldn't make it trivial to accidentally remove a dependency in an unsafe manner Rich
Re: [gentoo-dev] emerge -C eselect-python disaster
On 01/24/2010 07:02 PM, Dale wrote: Is there something that I am missing here? For me, system should include the things needed for booting and for the package manager to work. It should include the programs directly involved in booting, and the package manager. I'm not sure that it should contain their dependencies - since that information can be derived from the packages themselves. As I pointed out in another reply, portage won't let you unmerge itself but it will let you unmerge a package that will render portage useless. Well, it shouldn't allow you to unmerge anything that will render ANYTHING useless without some explicit instruction to do so. The documentation does warn of this behavior: --unmerge (-C) WARNING: This action can remove important packages! Removes all matching packages. This does no checking of dependencies, so it may remove packages necessary for the proper operation of your system. Its arguments can be atoms or ebuilds. For a dependency aware version of --unmerge, use --depclean or --prune. If you use --depclean to remove your package then you're safe. Note - the command line option names are not well-chosen here. -C should really be --unmerge-without-checking-dependencies-unsafe or some other obnoxious option, and --depclean should be the easy to type parameter.
Re: [gentoo-dev] News item: MySQL 5.1 bump
On 02/20/2010 09:23 PM, Robin H. Johnson wrote: The MySQL 5.1 news item with all updates is now commited, and 5.1.x have been unblocked in package.mask. It looks like that news item is visible to users running stable as well. When 5.1 eventually goes stable we might want to re-announce it since it may have been long forgotten by then...
Re: [gentoo-dev] Pending mask of Qt3 and MythTV
On 02/22/2010 12:25 AM, Ben de Groot wrote: If no action is taken soon, we see no other way than to protect the users by masking the complete mythtv package. We hope this won't be necessary. Agreed none of the options are nice. The mythtv wiki isn't a bad resource, how about this for a news item (I can commit if there are no objections - and be gentle as I just parsed the GLEP - also posted to the bug 299222): Title: MythTV 0.22 Upgrade Database Corruption Author: Richard Freeman ri...@gentoo.org Content-Type: text/plain Posted: date Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-tv/mythtv-0.22 Due to an incompatibility between MythTV 0.21 and the default Gentoo MySQL configuration, it is likely that long-time MythTV users will have databases with a mixture of locale encodings. If you upgrade to 0.22 without following these directions carefully, you could end up with a database that contains errors that are extremely difficult to fix. Please see the MythTV Upgrade Guide for instructions: http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding Be sure to save a database backup before upgrading. Also, be sure to upgrade any other clients/backends you are using to 0.22 at the same time. The upgrade instructions need to be followed once per database - individual client/backend upgrades do not require these steps.
Re: [gentoo-dev] Re: Pending mask of Qt3 and MythTV
On 02/24/2010 02:15 AM, Doug Goldstein wrote: My response was the arch teams haven't stabilized MythTV in years because none of them have a setup to test it, so please stabilize it. I'm running it on a stable machine. Well, to their credit, you CAN'T stabilize a package if you can't test it. I can test it and stabilize it on amd64, but that's it. If there is an arch that nobody has a mythtv setup for testing on then the solution is to drop the stable keyword entirely - not to just mark it stable. As far as the news item goes, as I've said before. Its completely unnecessary since MythTV will handle notifying you properly if you need to do anything to your database. I can count more than a dozen people on Gentoo that have successfully done the conversion without issue. Here is the problem I have with this: doing the migration takes time. Somebody who does an emerge -u world probably doesn't set aside an hour or two to manually fix databases. Anybody doing this for mythtv will at best have a mythtv install that refuses to start until they spend time doing database dumps, sed scripts, and reloads. If for some reason the mythbacked doesn't detect the problem and starts up anyway, then they'll end up with partial database corruptions. I think that if nothing else we should send out a news item warning users that a major mythtv upgrade is coming and that they should exercise care in upgrading it, setting aside time for database cleanup if they are long-time users. I'm completely open to revised wording, but I don't feel comfortable stabilizing this for amd64 without any news at all. I do appreciate all you've done for mythtv, and the time crunch you are in right now. However, if I commit a keyword stabilization I need to be accountable for the results. I suspect the other arch teams feel similarly - nobody wants to just commit something like this without testing and good documentation. How about this revised news item: Title: MythTV 0.22 Upgrade Database Corruption Author: Richard Freeman ri...@gentoo.org Content-Type: text/plain Posted: date Revision: 1 News-Item-Format: 1.0 Display-If-Installed: media-tv/mythtv-0.22 Due to an incompatibility between MythTV 0.21 and the default Gentoo MySQL configuration, it is likely that long-time MythTV users will have databases with a mixture of locale encodings. If you upgrade to 0.22 without following these directions carefully, you could end up with a database that contains errors that are extremely difficult to fix. Note that not all mythtv users need to modify their databases, and this should only be performed at the time of the upgrade. The guide below contains instructions that can be used to determine if this problem pertains to you. Please see the MythTV Upgrade Guide for instructions: http://wiki.mythtv.org/wiki/Fixing_Corrupt_Database_Encoding Be sure to save a database backup before upgrading. Also, be sure to upgrade any other clients/backends you are using to 0.22 at the same time. The upgrade instructions need to be followed once per database - individual client/backend upgrades do not require these steps. If you do run into problems with your upgrade, there is a forum thread where you may be able to find help: http://forums.gentoo.org/viewtopic-t-816566-highlight-.html
Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
On 02/26/2010 07:06 AM, Ben de Groot wrote: Is there a simple way for users to determine what client versions they may have? Forwarding my reply: Well, they can always just ask the package manager what version is installed. The news item is targeted only at users who do not already have mythtv 0.22 installed, so only potentially impacted users will get the announcement. The guide includes instructions for determining whether a particular database has problems. mythfrontend also has a --version option that returns some useful information. However, anybody getting the news item has a potential issue, and since mythtv isn't compatible across client versions if their gentoo install has a problem then all of their clients should need an upgrade. Rich
Re: [gentoo-dev] Re: [RFC] News item: 2010-03-01 MythTV 0.22 Upgrade Database Corruption
On 03/01/2010 09:24 AM, Ben de Groot wrote: The 72 hours have passed, so I take it we are ready to officially publish this. Richard, are you going to commit this? I will do so today.
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/03/2010 09:41 PM, Dale wrote: So in the situation above, removing cups doesn't help any? The user would still have to work around the dependency problem. Is there not a better way to handle this? Agreed that there should be better ways of handling things. However, at the very least if somebody follows the instructions in the Gentoo Handbook to the letter, they shouldn't end up staring at an error message. A completely scripted install using any non-experimental profile should just work. So, removing the use flag should probably be done at least in the interim. That said, I do agree that we need to try to avoid this circular dependency in the first place. It is kind of silly that you can't even do an emerge -u world right out of a stage3 using a fairly common set of use flags and get a working system.
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/04/2010 08:57 PM, Patrick Nagel wrote: Obviously, users who re-install Gentoo the way you do will have less difficulties resolving a circular dependency than those who are just following the guide and getting their first Gentoo experience. I think that the cups issue is probably worth mentioning in the Handbook. Whether it is there by default or not lots of people get burned by it. A little advanced warning would help. I think that at the very least following the handbooks to the letter should never lead to an error. I think that a good argument can be made for or against having cups in the desktop profile - this might actually be the sort of thing a survey would be useful to address. I think that is separate from the circular dependency issue. As long as we have an unresolved circular dependency I think cups should be off the list. However, I'd be the first to agree that this is a short-term solution. The problem is that we only have two long-term solutions so far: 1. A smarter package manager that can work through these dependencies automatically. 2. Splitting packages like poppler that have these issues. Both of these need effort to address. #1 requires PM work, and #2 requires an ongoing commitment to do more work to keep poppler working. Unless somebody can come up with a #3 at this point the most constructive thing anybody can do is help out. A good place to start would be to write up some patches to the handbook that clearly explain how to deal with this problem. I'm not sure I agree with the poppler maintainers but they may have reasons that aren't apparent to me and the fact is that it is a whole lot easier to tell somebody how to maintain a package when I'm not the one actually doing the work. Nothing gets results in FOSS like dirty hands... Rich
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/05/2010 08:06 AM, Ben de Groot wrote: On 5 March 2010 04:18, Graham Murraygra...@gmurray.org.uk wrote: 3. Include one or both of the packages in the stage tarball. None of the packages involved (gtk+, cups and poppler) is in any shape or form essential, so you will have a very hard time convincing people that this is the best solution. I tend to agree, but do consider this: 1. We wouldn't need to put all the packages in the dep list up to these packages in the tarball - you could just put one package in the tarball so that when emerge gets to this point it won't die. 2. You don't need to put that package in @system, so the first time the user cleans out their install it will be removed. For server users it will start out there but will eventually go away. It does increase the size of the tarball, which is of course undesirable. We might also need to modify the build scripts since I'm guessing those scripts look at @system to figure out what belongs in the tarball and these packages don't need to be there. I do agree that it isn't really an ideal solution, and probably not the first thing we should try... Rich
Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events
On 03/10/2010 04:42 PM, Duncan wrote: So a gmail account is now considered mandatory for Gentoo devs, at least if they want calendar access? What about those who might think that Google knows enough about them with search and the web crawling and database correlation Google does, and whatever ad serving might leak thru, and object to having a gmail account on principle? Honestly, Google calendar works well enough that I'm not sure that I like the idea of re-inventing the wheel. Maybe if somebody designed some kind of open calendar access protocol that was comparable. If you don't like Google tracking all that you do, create a gmail account and don't use it for ANYTHING but Google Calendar. That will greatly limit the amount of database correlation they can do. If somebody has a suggestion for a reasonable multi-user calendaring infrastructure that has reasonably close feature parity and isn't a bear to maintain I'm sure it would be considered. Rich
Re: [gentoo-dev] Re: Gentoo calendar for tracking Gentoo events
On 03/11/2010 03:53 PM, Alec Warner wrote: however if it becomes some kind of integral part of Gentoo (which I doubt it will) we will have to look at switching to something else (which is easy given the many export formats of Google Calendar :)) I think you hit the nail on the head. Right now it isn't really getting used at all, and as you pointed out we can always transition it later. Before we build out an uber-calendaring-application maybe we should just let the current calendar get some use, and then we can see how it goes. Plus, our experiences with Google Calendar may come in handy when defining requirements for a pure-FOSS solution. Of course, if somebody wants to setup something that is FOSS anyway, nobody is going to stop them. Rich
Re: [gentoo-dev] [RFC]: Proxy-maintainer project
On 03/18/2010 04:34 PM, Ben de Groot wrote: Recruitment being the bottleneck that it is (with candidates waiting many months), it is good to have another option for people who want to contribute. If we do have a list of people waiting to get in, could we maybe publish this list somewhere, or instruct these people to look for maintainer-wanted bugs and offer their services as proxy-maintainers? Can we have some way of communicating that one of these almost-devs has written some ebuilds so that devs can work with them to get them committed? This would get them a head-start and will give them VERY practical instruction. For the devs that work with them they'll know that they're working with somebody with a long-term interest. I'm not sure that we want a policy that states that when the recruits become devs that they will maintain these packages long-term, but it would be nice if they did so. Perhaps the devs could also provide feedback to the recruiters on the recruit's strong/weak points so that they could work on these. (NOTE - I'm not suggesting marking people for exclusion here - if somebody is fairly raw we want to work with them, but it doesn't hurt for the recruiters to know about that up-front.) I realized that some of these ideas are still half-baked, but I'm wondering if there isn't an opportunity here. Rich
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 03/24/2010 02:28 PM, Joshua Saddler wrote: On Wed, 24 Mar 2010 19:04:51 +0100 Arfrever Frehtes Taifersar Arahesisarfre...@gentoo.org wrote: People, don't want Python 3, probably have already masked it. There is no reason to waste Council's time for decision on what sentence should be included in the news item. Not the folks running the stable tree, because they don't know about it. They're not following the discussion here on -dev. They're going to get unpleasantly surprised when it shows up in their next world update. Include instructions on how to mask it if desired in the news item. Will not masking python-3 cause anything to break in any way? Do users need to do anything to make python-2.6 or whatever the default interpreter (instructions for using eselect python are not given in the news item)? If the only potential issue is that users might have a few extra files installed that they don't need but which won't cause them problems, then I don't know that we need to instruct users to create masks. If having python-3 will cause stable users problems, then we probably shouldn't be stabilizing it anyway. Compared to the KDE 3-4 migration this is probably going to be a fairly minor issue for most stable users, unless we're expecting breakage. Rich
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On 03/24/2010 11:47 PM, Joshua Saddler wrote: Even then, it'll likely get installed first, as users will probably learn about p.masking it only *after* they install it. I don't have strong feelings on whether having v3 installed by default is a big problem, but the last bit here probably should be addressed. The current news item only shows up for people with python 3.1 already installed. Would it make sense to have it show up for anybody with any version of python installed? Otherwise it is news after-the-fact. Rich
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On 03/28/2010 06:04 AM, Tomáš Chvátal wrote: Basically you are saying that NONE tested that package on the arch until the stablerequest. That's quite wrong and it should mean that the arch should be ~ only, since they are stabling packages that they first tested the day they stable them. Well, keep in mind that if a package is marked ~arch, it is getting used, but for the most part it isn't getting used with other packages that are stable. So, if your package is ~arch for a period of time that gives you strong evidence that it works with openrc, but no evidence as to whether it works with baselayout-1, which is what stable users have. So, I would argue that for any package to be stabilized on an arch it should be tested on that arch on a stable platform. amd64 has had the policy that any dev can stabilize if they've tested it on a stable amd64 system, and this hasn't really caused problems. Perhaps we should encourage understaffed arch teams to recruit more arch testers if possible? Then any dev could ask an arch tester to test on some platform that they don't have access to, and then stabilize accordingly? For arch-neutral packages a more liberal policy might be possible, but keep in mind that the set of stable packages is not the same across archs. So, unless you check carefully you might not be testing the same library dependency versions from one stable platform to another, and that could cause problems. Rich
Re: [gentoo-dev] Re: List of User projects
On 03/28/2010 10:27 AM, Duncan wrote: The point being, perhaps I'm wrong and openrc does have a broader distribution basis than I'm aware of, but in practice, it seems all of these tend to be used /almost/ exclusively with Gentoo and Gentoo based distributions. If openrc's usage is rather wider than I'm aware of, well then, I'm about to learn that. =:^) Well, I'm sure there is an openrc list somewhere that might be a better forum for these kinds of discussions, but I suspect that they need to walk before they run. Right now openrc isn't even the stable init system for Gentoo. I know that their goal was to be completely distro-neutral, and once it stabilizes we might see it happen. It certainly would be very useful - it would standardize a ton of stuff across distros. Rich
Re: [gentoo-dev] Is Gentoo a Phoenix?
On 04/03/2010 06:19 AM, Tobias Scherbaum wrote: And still, when someone tries to fix things in such an understaffed herd people go all territorial and are like omg u touched my package. Right now I'm quite confused what our project strategy seems to be, as far as I can tell there's one group aiming for an aesthetical optimum and the other group just wants to get things fixed. And they are not cooperating well ... I for one can't say I had any territorial problems when touching packages belonging to other devs or herds - it's just a problem if you screw up. Agreed - if you ping the herd in advance, and get an OK (or at least no reply for a few days), and then you make some simple fixes to their packages, it is very unlikely that you're going to have any complaints. If you send the the proposed patch in advance and let them review it, and you get no complaints, you're even more clearly in the right. If you don't notify them at all, or you notify them and do a cvs commit 3 minutes later, or if you completely redesign their ebuilds in addition to fixing a 1-line problem, then you're going to get complaints. Nobody minds help. People do mind when somebody drops by to help them for 5 minutes and they're stuck with the aftermath. We don't own our packages, but existing maintainers have at least shown a long-term commitment to them (however strong) and that should at least be respected. On other topics in this thread: I agree wholeheartedly that whenever possible just do it is a good approach - especially when you're talking about documentation and external websites/etc. Modifications to things that already exist are less amenable to just do it. I really think that the Gentoo recruitment process needs improvement. Right now it seems like a LOT of effort is required both to become a Gentoo dev and to help somebody become a Gentoo dev. That means we have great people, but not many of them. I think the problem is that our recruitment process uses the ability to answer complex technical and organizational questions as a way to assess maturity. I think that maturity is far more important than technical skill in a distro - a mature person will recognize their own limitations and exercise due diligence when stepping outside of them. Instead of playing 20 questions and going back and forth with recruits, maybe a better approach would be to cut down the questions dramatically (or more clearly put their answers in the documentation), and then use other approaches like references and interviews. A new recruit might be given the names of 5 devs that they will need to interview with for 30-60 minutes by phone or IRC (preference on phone), and they will need to submit references, who will be contacted. When we hire people at work we don't play trivial pursuit with them, we use an interview to get a feel for what they're like and how they handle situations, and we screen resumes and references to determine experience. I'm sure any of the professional linux distros would work in the same way, but perhaps somebody should ask around and see how it is done elsewhere. So, now instead of a recruiter having to spend hours helping somebody through quizzes without giving them answers, instead they just send them a list of interviewers, and collate the results. Any interviewer will just need to spend 30 minutes on an interview and 10 minutes on a writeup. Plus, the whole process will make Gentoo a bit more human. Rich
Re: [gentoo-dev] [Gentoo Phoenix] recruitment process
On 04/05/2010 03:48 AM, Ciaran McCreesh wrote: On Mon, 05 Apr 2010 03:33:52 +0200 Tobias Heinleinkeytoas...@gentoo.org wrote: 3) Questions that aren't that important at all and would just be nice to know. [snip] Examples for these: 5. What is wrong with using $(somecommand) or `somecommand` or $ARCH inside SRC_URI, DEPEND, etc? [Devmanual, Caching] How the heck is this not important? Anyone who doesn't immediately know the answer to this has absolutely no business touching any ebuild that might end up being given to someone else. My concern with these kinds of questions is that there really isn't any page where we have key gotchas consolidated like don't execute external programs in global scope. Sure, it is in the devmanual, and if you read the whole thing then maybe you might remember that one bit in particular. I agree that somebody who doesn't know this particular fact shouldn't be committing ebuilds. My concern is that we don't really have any way to make people aware of that particular fact. Honestly, I think it would be just as effective to simply write up a single webpage with thou shalt not's, and not make people go hunting all over the place to figure out the whys. By all means have a link on each thou shalt not to the reason. There are lots of people who would be perfectly capable of doing many developer activities who might not come in knowing about the metadata cache. They don't need to know the nuts and bolts of how it works, just what they need to do to avoid problems with it. In any case, giving hints as to the location of the answer in this kind of a question seems fine to me. The important thing is that the candidate dev learn about the potential problem - not that they figure it out 100% on their own. Still, the socratic method is a good approach to teaching, so I'm not opposed to the QA format of the quiz in general. We just need to let candidates know that we're there to help them succeed and the quiz is a tool - the goal isn't to eliminate any potential contributor who doesn't come to the table knowing as much about Gentoo as any seasoned dev. Rich
Re: [gentoo-dev] Is Gentoo a Phoenix?
On 04/04/2010 02:09 PM, Denis Dupeyron wrote: All ideas regarding improving recruitment are welcome, thanks. However if, during your review, you were not given the impression that your maturity and other social skills were being assessed then you were being blissfully naive. :o) That actually wasn't what I was trying to convey (guess I need to work on those communications skills :) ). I did recognize that you were looking to assess this, and that you felt that this was of critical importance. What I was getting at is trying to identify what aspects of the whole recruitment process added the most value and which added the least, and adjusting accordingly. I think that assessing attitude and maturity, and providing the tools and education needed are the most critical aspects of recruitment. That's why I'm all for changing the approach to quizzes - from my experience it wasn't the quizzes themselves that really added the most value for me. The interaction that they triggered and getting me to consider some of the more critical issues that come up in ebuild maintenance added far more value than getting every detail of the answers 100% correct. The quizzes are just a tool - not the ultimate validators of ability. Let's use every tool at our disposal in the best way possible. Rich
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 04/05/2010 10:13 PM, Nirbheek Chauhan wrote: * Proposed is to generate ChangeLogs from git commits on the rsync server side when metadata generation is done - Scripts to do this already exist[1] I haven't seen this discussed, so I'm going to toss this out there and duck: Why not just get rid of the in-tree Changelogs entirely? The scm logs already document this information, so why have it in a file? It seems like the main purpose for it is for end-users to have some idea what changed in an ebuild. However, in my experience the upstream changes are far more impactful than the ebuild changes, and those aren't in the Changelogs at all. Instead, why not just create a script that gets distributed with portage that will upon request tell a user what changed based on the scm logs? I can't imagine that the hit on the servers will be all that large, and since this is read-only traffic it might be manageable through replication. Rich
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 04/07/2010 05:58 AM, Angelo Arrifano wrote: 3*) With git, one would just branch (lets call it embedded branch) the package. Apply the patches there and let people using embedded profiles to emerge from that branch instead of master. Benefits? I think they are pretty obvious - people can start putting quick patches in the tree for specific arches while not breaking others. IMHO, the only bottleneck I see on Gentoo development is the massive policy (not saying it is not needed) a -dev has to follow just to commit a simple fix. Git my friends, will be our holly grail. I think that allowing for different levels of QA standards, and accomodating things like this are good reasons to use branches. HOWEVER, we do need to manage this so that it doesn't get out of hand. We really don't want users following 14 different branches and have 10 different variations on every package in the tree - which is how it could get after a year or two of branching without any effort to do pruning and get things merged into a main tree. Having branches to do development and facilitate access and testing seems fine, however we should always have the goal of getting these tested revisions merged back into the main tree. We really don't want divergent development to be the norm.
