[gentoo-dev] Last rites: app-misc/sleepyhead
# Rich Freeman (2020-02-16) # Dead upstream, obsolete deps. app-misc/sleepyhead
Re: [gentoo-dev] [Volunteers needed] Communicating use (and existence) of USE_PYTHON
On 12/03/2010 07:05 AM, Michał Górny wrote: On Fri, 03 Dec 2010 11:35:14 +0100 Sebastian Pipping sp...@gentoo.org wrote: to better communicate USE_PYTHON we could use: The first question that comes into my mind is -- why do we need to communicate that? I think that USE_PYTHON is a pretty specific variable which should be used only if specially required (i.e. to keep multiple Python versions ready for use). I tend to agree. For a user who doesn't actually USE python, but just has it installed because half of the rest of the system doesn't work without it, python is just another dependency. If a package only works with python v1.2, then it should depend on the appropriate slot/etc. If a user actually USES python, then they should have a mechanism to tell the system what versions of python to keep around. If you could put slots in the world file that might do the trick, but this variable seems like a reasonable way to do it as well. What needs to be fixed IMO is the default value of that variable. If you already disabled switching the active Python version by default, you should also make the Python eclass base its' USE_PYTHON defaults on the active Python version. I tend to agree here as well. The distro should manage the version used for distro packages. Maybe a user wants to do cutting-edge development work in python-v12. The system should still use a sane version of python to run portage/etc, unless the user specifically tells it to do otherwise. Rather than hard-coding this in every package a distro-wide default probably makes sense. When new versions of python are deemed acceptable for distro-wide use the default can be updated. Gentoo has to work reasonably well without having to micro-manage python versions. Users shouldn't have to figure out what version of python they want to run to do an install. Rich
Re: [gentoo-dev] Re: Re: Maintainer notes in metadata.xml?
On 12/01/2010 01:16 PM, Diego Elio Pettenò wrote: Il giorno mer, 01/12/2010 alle 19.05 +0100, Thomas Kahle ha scritto: I agree, comments within the ebuild are practically invisible to archteams (at least to me for x86). But also running repoman is usually the final step, right before committing. The place for comments that need to be considered during archtesting would be right in the stable request bug. This is where I usually start. This is where I usually try to provide them; it's a bit more complex when users require the stable themselves, or when new developers are replacing the old ones. Agreed on all points. Ideal behavior is to provide comments in the bug. However, if that doesn't happen then this comment will give a warning to the arch team before they inadvertently shoot themselves in the foot. If I do normal build tests first and then find they have been in vain when running repoman, then I wasted cycles for the build tests. I'm unsure if this would apply to your original example, though. I sincerely expect(ed) a repoman scan of the ebuild to be done after tweaking keywords to ensure all the deps are stable already, thus why I asked it to be printed on scan. So, my typical stable workflow is: Install package, after overriding keywords/etc in /etc/portage. Test package and satisfy myself that it is OK. From CVS tree, cvs update, ekeyword, echangelog, repoman manifest, repoman scan, repoman commit. All the testing typically takes place well before I've touched an ebuild or run repoman. However, I don't see this as a big deal. Right now I shoot myself in the foot and make a bunch of users upset if I don't know about something when I stable a package. The enhancement causes me to potentially waste some of my time, but less than if I have a big mess to clean up. The ideal solution as all agree is to have the package maintainer point things out in the STABLEREQ. Rich
Re: [gentoo-dev] Changes in server profiles
On 10/30/2010 05:09 AM, Markos Chandras wrote: On Sat, Oct 30, 2010 at 10:05:17AM +0400, Peter Volkov wrote: В Птн, 29/10/2010 в 09:11 -0700, Alec Warner пишет: On Fri, Oct 29, 2010 at 5:21 AM, Markos Chandras hwoar...@gentoo.org wrote: Can I install a machine with the server profile and USE=-ldap, but still get ldap + pam working? Can I install a machine with the server profile and USE=-apache, but still get apache + php working? apache + rails? How many packages support each USE flag? How many of those packages have IUSE defaults for +ldap or +apache already? Having lxc/openvz/vserver technologies at hand it's not rare to split LAMP server into a number of virtual servers (containers): mysql / backend with php / frontend / smtp - everything sits in its own container. And USE=apache will be used only in _one_ container. Also not all servers are web servers. So IMO server profile should be just minimal profile that hints users that this profile will stay minimal and usable for all kinds of servers. That said I think server profile is useless and for servers I maintain my own profiles. -- Peter. Exactly! How about the warning message. Should the statement about gcc+glibc be removed and keep the one about hardened but make it a bit different?Like This profile is making use of a minimal set of use flag. You may find it useful in a server environment. However, If you are seeking for extra security, please check the Hardened project (http://hardened.gentoo.org). What exactly is the intended use of the server flag? When I want a minimal image, I usually just use the default profile. That is pretty-much a bare-bones gentoo install. I can see the use of desktop, and I can see the use of hardened. Right now server just looks like default with random stuff for various kinds of servers added. I could see if server had a different set of keywords and QA policy (like debian stable), or if there were a set of use flags that would be universally useful on a server and not on a desktop. Right now it just seems like the server profile exists since lots of other distros have server editions, so we should too. If that is the case, why not just point users to the default profile, or hardened?' I'd be curious what the users of the server profile say. If anything they are the ones we should be listening to since they've found a use for it. Rich
Re: [gentoo-dev] Reminder: please use the latest Portage/repoman version to commit to tree
On 10/04/2010 03:50 AM, Michael Haubenwallner wrote: So - would it make sense to split repoman into its own ebuild? ++ I always did wonder why the two have been part of the same project. Repoman updates could probably be stabilized more quickly with so much worry about impact on users at large. Rich
Re: [gentoo-dev] Re: .la files and their future on Gentoo
On 10/03/2010 09:26 PM, Duncan wrote: The problem is that in-tree is a reasonably bounded set of builds, while out-of-tree is unlimited. Practically speaking, I simply don't see how Gentoo can be concerned with out-of-tree in general. If any other distro had that attitude Gentoo (and other source-based distros) would be the only ones that provided packages for GCC, since no other distro requires a functioning toolchain to install packages. Libraries don't exist just to run packaged programs - they're also needed to build new programs. So, this is a use case that needs to be considered. Probably one of the reasons that Gentoo is popular among developers is that it provides a very complete toolchain and libraries/etc. That said, supporting this use case should not interfere with more mainstream use of the distro. I like the USE flag proposal because it lets us have our cake and eat it too. Those who don't need .la files don't get them except where absolutely essential, and those who need and are willing to live with tons of them can have it their way. Gentoo is about choice... Rich
Re: [gentoo-dev] .la files and their future on Gentoo
On 10/03/2010 07:53 AM, David Leverton wrote: Would it be too much trouble to have a standardised variable that means .la files should be kept? It maybe /shouldn't/ be exposed as a USE flag because very few people will need it, but if it's easy to implement (maybe by having an eutils function to do the removal, checking the variable first) it would remove any objections I could imagine. Such a solution would also have the virtue of allowing the use of USE dependencies. So, you would only install the .la files from a particular library if another package actually needed them. Packages could also have USE defaults as seems logical to their maintainers and distro policy. Where this would get complex is if we want more than all-or-nothing resolution. The simplest USE approach would be to have it toggle all the .la files in the package. However, if you have 5 files that are essential, and 5 that are likely nothing but trouble it will be harder to manage that while still allowing full control. I guess careful use of local flags might work, in combination with some sane policy. I'm not sure if this is a use case that is even worth worrying about... Rich
Re: [gentoo-dev] openrc stabilization update
On 09/20/2010 07:06 AM, Michał Górny wrote: I guess quite a good solution for now might be enabling newnet through an USE flag, being masked in the profile by default. That would satisfy the oldnet compatibility requirement for users, while the small group preferring newnet could still benefit from it. This pretty-much guarantees that arch testers/etc will end up testing it one way or the other, and not both. That could lead to QA issues when packages work fine for some users and not for others. Granted, this is mainly a concern for lower-level network-config related apps. I'd hate to be the maintainer of an ebuild that needs to take into account multiple network configuration options. I still haven't heard a good reason as to why we need two. I'm running oldnet (baselayout-1), and changing to newnet would be a pain, but I don't expect the distro to take this into account for my sake when making decisions like this. I'm sure people running newnet feel similarly. The only argument I've heard for newnet is that it is more DHCP-friendly or something like that (not that DHCP is required). However, I've never found getting DHCP to work particularly difficult - it practically comes like that by default (just emerge dhcpcd and add the interface to your init.d). I imagine wireless might be more complex. One argument I've heard against newnet is that you can't bring individual interfaces up and down. That sounds like a potential drawback. Granted, most of the sorts of things that I'd like to conditionally bring up (vpn, ipv6 tunnel, etc) probably won't use the network scripts anyway. Rich
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 08/25/2010 08:29 PM, Duncan wrote: But that was pretty much decided some time ago, based on my following of the relevant discussions here and elsewhere, so why are you arguing a point that's not being argued any more? I believe that's what Mike's WTFing about. It's not that you're wrong, you're not, it's that you're debating a question that's no longer being asked. See: http://thread.gmane.org/gmane.linux.gentoo.devel/67098 and http://thread.gmane.org/gmane.linux.gentoo.devel/67098 The post I replied to cited upstream issues as a reason not to adopt OpenRC. My point is that upstream issues are not a distinguishing factor between OpenRC and baselayout-1. It isn't like I'm re-opening a thread from months ago. I'm replying directly to a point others have raised. If there is no debate about whether OpenRC should be adopting it, then why is it even being discussed in this way? Let's just do it... Rich
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 08/24/2010 11:57 PM, Nathan Zachary wrote: If we are going to endorse using OpenRC, the more relevant issues are the ones regarding its future development. Is the future development of OpenRC more problematic than the future development of baselayout-1? As far as I can tell, baselayout-1 never had an upstream, and never will have one. It seems like the debate is around openrc vs systemd or whatever. I think the debate we need to settle first is openrc vs baselayout-1. Otherwise we're going to end up maintaining TWO different legacy init.d systems while we spend the next few years aiming for yet another target. Wouldn't it make more sense to clean up openrc and get it deployed, even if in the long-term we decide to get rid of it? Alternatively, we drop support for openrc entirely, and tell everybody running ~arch to move to our next target or back to baselayout-1. I don't think we want to have three targets to maintain. Rich
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 08/25/2010 03:06 PM, Mike Frysinger wrote: On Wednesday, August 25, 2010 12:37:34 Richard Freeman wrote: On 08/24/2010 11:57 PM, Nathan Zachary wrote: If we are going to endorse using OpenRC, the more relevant issues are the ones regarding its future development. Is the future development of OpenRC more problematic than the future development of baselayout-1? As far as I can tell, baselayout-1 never had an upstream, and never will have one. wtf are you talking about ? Gentoo was always been the upstream of it. Uh, that was essentially my point... :) Clearly upstream support is not an issue that distinguishes openrc from baselayout-1. Wouldn't it make more sense to clean up openrc and get it deployed, even if in the long-term we decide to get rid of it? it's already cleaned up. this is the squash regressions from baselayout-1 and make sure all stable packages are happy with it phase. And my point was essentially that we should finish doing that, and not bag the whole project because of the OpenRC upstream issues. Sure, we can think about the next great thing that is coming along, but let's not abandon the work done so far, because doing so means living with baselayout-1 for another few more years. I was just being a bit subtle in my argument... Rich
Re: [gentoo-dev] Re: The future of sys-apps/openrc in Gentoo
On 08/24/2010 08:57 AM, Thilo Bangert wrote: given how long, so far, it has taken openrc to reach stable, it is no wonder people start lobbying for systemd today. ;-) Perhaps, but if we want to move in that direction perhaps we should consider at least getting openrc stable first. That doesn't mean making it perfect, or feature-complete. However, right now we have two different baselayouts, and if we start talking about systemd then we'll have three. Do we really want to start on seriously supporting a third one, without first getting rid of one of the other two? Alternatively we could dump openrc and move everybody back to baselayout-1, but I don't see that happening anytime soon. Looking at the tracker bug, I see all of three issues blocking openrc from going stable. One is documentation, one is getting an evms upgrade stable on a few minor archs, and one is some kind of mdadm upgrade with a few issues. It seems like we should just make the next bugday OpenRC Cleanup Day or something like that. Everybody can take 15 minutes to contribute to a wiki on getting started with openrc, or blog about it, or whatever. the docs team can glean the best of that and get the docs in order. The evms/mdadm/arch maintainers could make a push to finish up, and others can help them with patches. If we made a real push to get OpenRC stable I'm sure that those bugs would get taken care of quickly. Right now I'm guessing that it just isn't on anybody's radar. Or, is the situation with OpenRC less stable than is apparent in the tracker? Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On 08/14/2010 10:29 AM, Markos Chandras wrote: So do I. Fixing your package and you don't even bother to send a *ready to go* patch upstream seems like a bit rude to me as well. Perhaps, we do have a complete different point of view in this one. Recent example is Chí-Thanh Christopher Nguyễn who thanked me for fixing his package, asked me to attach the patch so *he* can send it upstream. I thought that was the *default* policy. Anyway. I should talk to each maintainer separately when I fix his package. Seems to me is the best approach My two cents. In my opinion, whether a commit is good or not depends on whether it left Gentoo as a whole in better or worse shape than before it was made. Here it sounds like we had QA problems before the commit, and no QA problems after the commit. Maybe the maintainer has some work to do now, but he had it to do anyway, and the maintainers have less work to do now than they did before the patches were made. Now, if he had broken something due to a sloppy commit I'd be more concerned. Many hands make for lighter work. The best way to have many hands is to make individual tasks easier. 1+1+1+1+1 is going to happen faster than 3+2, since nobody ever gets around to doing 3. If we give devs an ultimatum like fix it all or don't fix anything guess which one they'll pick? Rich
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in media-libs/mlt: ChangeLog mlt-0.5.4-r1.ebuild
On 08/14/2010 02:35 PM, Duncan wrote: User perspective here... For LDFLAGS, given the new --as-needed default, I'd prefer the rev-bump. Yes, it requires a rebuild, but the rebuilds will occur as the bugs are fixed so it's a few at a time for people who keep reasonably updated (every month or more frequently). The alternative is triggering a several- hundred-package rebuild when some base library package updates, because all those LDFLAGS respecting changes weren't rev-bumped and the user's installed set is still ignoring them, and thus --as-needed. Interesting - I was looking at it in the opposite way. Not having as-needed means that I /might/ have to rebuild that one package unnecessarily at some point in the future - if it isn't upgraded first for some other reason. Rev-bumping the build means that I /will/ have to rebuild that one package for certain - right now. I think we can all at least agree that this is a gray area as far as the INTENT of the (apparently unwritten) policy goes. I would like to echo Markos's comment that having policies written down, if only to point stubborn maintainers to them, would be helpful. The other reason to have them written is so that they go through some kind of review, and there is some way of challenging them if they no longer make sense. In any case, I think we're making a pretty big deal about a pretty small issue - we can probably all afford to think about this a little more and move on... Rich
Re: [gentoo-dev] Git Commit Procedures
On 07/26/2010 12:32 AM, Jeremy Olexa wrote: On 07/24/2010 10:10 AM, Richard Freeman wrote: I'm trying to make a correction to the devmanual (assuming this is supposed to be general access) for bug 293629. However, I can't seem to find where to clone the repository from. See Git Repositories on http://sources.gentoo.org or http://sources.gentoo.org/gitweb/?p=devmanual.git;a=summary Would this work for commits? Assuming of course that I had rights to commit? If this isn't supposed to be edited by devs at large, then somebody can feel free to close that bug. It had been open for ages so I figured I might just see if I could take care of it. Attach a patch to bug. That repo is not open for anyone to commit to, you have to be a member of the QA team, (or approval from Halcy0n or Betelguese) Makes sense. That would be the issue in this case. My general point was that documentation in general around git is very vague, except for the overlays (which is still lacking, but there is enough info to at least be dangerous there). Maybe a worked example with full command lines might be helpful - starting from scratch check out repository, change a file, and commit it to the official repository. The info out there does require filling in a lot of blanks, and since git itself has no concept of a central repository there aren't a lot of examples of how to do this. Such an example should of course factor in any Gentoo-isms as well (changelogs (if applicable), commit messages, etc - anything we ought to be doing). Rich
[gentoo-dev] Git Commit Procedures
Are the procedures for using git with anything but an overlay on gentoo documented anywhere? I'm trying to make a correction to the devmanual (assuming this is supposed to be general access) for bug 293629. However, I can't seem to find where to clone the repository from. If this isn't supposed to be edited by devs at large, then somebody can feel free to close that bug. It had been open for ages so I figured I might just see if I could take care of it. In general I think that before we can really consider any kind of migration to git we need to actually publish at least a little documentation around how it is to be used. Sure, devs can read the various tutorials online, but what will Gentoo's policy be on putting branches in the official repository, and where should sources be checked out from, and what if anything do devs need to do besides a git push so that everybody doesn't get upset, etc. It need not be 40 pages of documentation, but for something we're already using in an official capacity there should probably be at least a little documentation. It exists for the overlays, although barely (just a bunch of commands without much explanation, and they are commands that would not be covered in any normal git tutorial). Rich
Re: [gentoo-dev] Updated handbooks for autobuilds
On 07/20/2010 04:34 PM, Joshua Saddler wrote: x86 and AMD64 have not had new stages or LiveCDs in months. jmbsvicetto just started working on 'em, but we need LOTS of eyes and fixers for our two biggest arches. Right now there's no one else. Most of the breakages seem to come from toolchain and Python 3.x build failures (because *someone* wanted it stable), but it needs troubleshooting. Is the process for creating these documented somewhere? I did some googling and couldn't really find any documentation on how our stages and liveCDs are built in the first place. There are some generic catalyst docs, but no real docs on how to generate an official build - that is one that would be identical (not necessarily bitwise) to what you'd find on the mirrors if they were up to date. Rich
Re: [gentoo-dev] rfc: amateur radio applications should not be in media-radio
On 07/14/2010 03:16 PM, William Hubbs wrote: I am an amateur radio operator as well, and that is why putting the ham radio apps inmedia-radio bothers me. Ham radio is not part of the media. Most of the stuff in the media-* doesn't have anything to do with the media - whatever that is. Media likely stands for multimedia - generally referring to anything that has to do with sound, graphics, video, etc. I doubt that the jsmath font has anything to do with the media, but it is a font, and fonts have to do with graphics, and graphics are part of multimedia. If we REALLY want to move I guess we can do so, but I don't think that the category was supposed to be suggestive of the news or entertainment industries. Rich
Re: [gentoo-dev] Gentoo Council 14/7 introductory meeting
On 07/12/2010 10:18 PM, Paweł Hajdan, Jr. wrote: Rationale: Meeting summary for 20091012 is to be completed. Meeting summary for 20100419 is also to be completed, and all following council meetings lack summaries. This makes it hard to follow the council's work. I've seen this at work quite a bit. I've also seen an elegant solution that works moderately well. The minutes of the meeting are taken in realtime during the meeting by whoever will take it, and this is shared with the participants in realtime. This way errors in the minutes are instantly corrected. When the meeting is done you just save and publish the minutes and you are done. Realtime collaboration could involve any number of mechanisms. I don't know if google docs supports it, but I imagine Wave would. There might be other mechanisms as well. Webex/GotoMeeting/etc are usually the methods employed in the business world. There might be an FOSS equivalent. I think this should be purely up to the council's discretion, but I wanted to offer this as a suggestion. I'm not a fan of slacker marks in the first place - but, if you have to have them then I'd do it in a way so as to avoid creating a negative incentive for volunteering to do the work in the first place. Rich
Re: [gentoo-dev] FYI: Rules for distro-friendly packages
On 06/27/2010 06:52 AM, Enrico Weigelt wrote: remark #981: operands are evaluated in unspecified order (tons of them) return strcmp( left.c_str(), right.c_str() ) 0; I'm not sure if this really qualifies an warning, since - AFAIK - C spec never said, that there is an evaluation order for function parameters. I could see how somebody might make that assumption (incorrectly), and get burned by this. However, creating local variables just to hold intermediate results so as to not embed them in function calls seems to be a lot of overhead - certainly in terms of readability, and I can't think of a situation where the compiler would have to do it on its own. I guess religiously doing this might make the code less likely to contain very subtle bugs, but perhaps it is a bit over the top for anybody who wouldn't be otherwise developing in ADA. Rich
Re: [gentoo-dev] Tone in Gentoo
On 06/19/2010 03:10 PM, Jorge Manuel B. S. Vicetto wrote: I can assure you that if someone goes to #gentoo-forums and tries to tell the forums team what tone should be used in that channel, we'll kindly ask the person to stop or to leave. This is one of the public and exposed channels and thus we have a tone with that in mind, but we're not going to set our tone according to the demands of a developer that is not even part of the team. I was not suggesting that tone in Gentoo was up to the discretion of any individual developer - neither myself, nor you, nor the head of infra/forums/etc. The tone in Gentoo is up to Gentoo. Fortunately we have a forum for deciding what Gentoo wants - we elect them annually. What would grant any non-member of a team the right to demand how the members of the team should act amongst themselves in their private room? Simple - the room belongs to Gentoo as a whole. You're certainly free not to listen to me, but I and others are free to point out that this isn't good for Gentoo. I certainly wouldn't take it upon myself to enforce the CofC, but I certainly would urge those responsible for governing the distro to do so. About the legal right, that isn't true. There are a few misconceptions in your statement. Even though the Foundation is the body which holds the Gentoo brand, trademarks and logo, it's not the Foundation that sets the rules for joining and be part of the Gentoo Developers Community. Furthermore, being a Gentoo developer doesn't mean you can join any team you want or that you have a right to go to any #gentoo-* channel. In case you have any doubt, I can give you a list of quite a few channels most developers don't have access to. Your statement is partially correct - obviously if I am a stockholder in Google I can't choose to just waltz onto the corporate campus and go around as I please, merely by virtue of being a shareholder. However, a shareholder of Google certainly is able to speak out about actions within the company that they feel damage it, and their elected representatives (the board) can give power to anybody (including themselves) to waltz around and put things in order. This starts with their authority to hire and fire the CEO at whim. Ultimately, if anything contains the name Gentoo and represents itself as being associated with a linux distribution, then it is using a trademark owned by the Gentoo Foundation. In the end, any use of Gentoo trademarks is completely at the discretion of the Foundation. If you insist, to address the question that access lists for #gentoo-* channels can be set by Freenode (our main IRC network), you should know that the only people Freenode will listen to regarding that are the members of the Freenode Gentoo Group Contacts. The people in that group were not chosen by the Foundation nor do they respond to it. Well, this is getting a bit silly, but they'd certainly answer to a cease and desist, or those hosting their servers certainly would. It would obviously never come to that. Go ahead and try to register #microsoft-press-releases and see if being named the official contact gets you anywhere. Also, please never forget that being part of Gentoo is a privilege and not a right. On that we certainly agree. It really wasn't my intention to suggest that somehow anybody was personally beholden to me. I really am just stating my opinion, as are you. As an example, even though I use my gentoo cloak online, you don't have any right to impose a behaviour into me in my private channel. Sure, I cannot, personally. However, Gentoo certainly can. At the very least I'd expect devs to generally conduct themselves in a manner where such things aren't necessary to even bring up. We have a loosely-knit community that is able to provide a reasonable product Gentoo Linux. Let's try to avoid killing it by wanting to impose a certain mentality or behaviour into others and let's try to respect each other and learn to live in a community. Well, the whole principle of the CofC is that it imposes behaviors on those who wish to use Gentoo media, or be Gentoo staff. That said, I really don't suggest that anybody need be heavy-handed. Nor do I suggest that my personal opinion should be the one that rules Gentoo (I would say the same regarding your opinion as well). In the end that's all we're doing - you say that infra decides what happens on #gentoo-infra, and I say that they don't (well, not ultimately - certainly I'd suggest that the trustees/council should of course delegate channel moderation to the team that uses the channel, and only intervene if necessary). What I would say is that I encourage those who are in the trustees and council to recognize the importance of this issue, and I ask that they consider that tone really does matter. We elect these bodies to speak for Gentoo, and I think that this is an issue where Gentoo could stand to be heard.
Re: [gentoo-dev] Tone in Gentoo
On 06/19/2010 01:06 PM, Jorge Manuel B. S. Vicetto wrote: On 19-06-2010 16:15, Sebastian Pipping wrote: #gentoo-infra is a channel on infra matters. The fact that it's developers only doesn't make it a private channel in a sense of tone doesn't matter. you've failed to notice an important point that others have already tried to convey to you - #gentoo-infra is the home of the Gentoo infra team. Yes, developers go there to address infra issues on Gentoo, but it is the infra team channel and not the channel of every Gentoo developer. Perhaps he didn't fail to notice this point, but rather he just disagrees with it? The fact is that #gentoo-infra is part of the Gentoo linux distribution. It belongs to every Gentoo developer, or at least legally to every Gentoo foundation member. Conduct on this channel reflects on all Gentoo developers. It really does bother me that everybody is lining up to defend this kind of behavior. If the response had been - sorry, I guess the joking got out of hand I'd say, ok, well, let's try to do better but let's all move on. I don't see offensive behavior using Gentoo IDs/IRC Cloaks/media as a trivial matter. It sets the overall tone of the distro, which is what this thread is all about. I've heard several devs over the years comment that they love contributing to Gentoo, but they'd never put it on their resume. Who can blame them? I know that if I ever were hiring somebody and they pointed out that they were a Gentoo dev, I'd tend to assume that their technical knowledge was pretty good but you can be assured I'd do quite a bit of digging around to figure out if they're somebody I'd want working on my team. Unless somebody is so good that you'd be fine if they were the only person working for you, then they're not too good to pass over. Rest assured that if you hire and keep certain people, sooner or later they WILL be the only ones working for you... I don't think that most Gentoo devs behave in this way. I think a lot of people care about trying to fix this. I don't think it is asking too much for Gentoo devs to try to keep their behavior reasonably professional when using Gentoo media, or Gentoo emails/cloaks/etc. No need to start burning people at the stake for slip-ups, but let's at least try to agree that we'd like to be associated with a somewhat professional-acting distribution? Rich
Re: [gentoo-dev] Tone in Gentoo
On 06/19/2010 06:54 AM, Ben de Groot wrote: This is a point that deserves more consideration. One of the top reasons (as witnessed in forum discussions) many people are not getting more involved and volunteering to become developers is the level of in-fighting and the ineffective way that bullies and other poisonous people are being dealt with. Does Gentoo really prefer to keep more sensitive people out instead of effectively getting rid of repeat offenders? ++ http://www.mefeedia.com/watch/30301159 http://opensourcebridge.org/sessions/216 We don't need one-strike-and-you're-out, but tone does matter. Rich
Re: [gentoo-dev] Proposing fundamental changes to DevRel
On 06/16/2010 08:33 PM, Jorge Manuel B. S. Vicetto wrote: On 17-06-2010 00:00, Sebastian Pipping wrote: 3) Let Gentoo developers vote on who's in the conflict resolution team just like we do with the council. AFAIK this never happened before and in my opinion choosing conflict resolution members by popularity is a very bad idea. Well, as long as the council remains the board of appeals and it is elected, I don't have a problem. I'd also go a step further and say that devrel members serve at the pleasure of the council. Some might debate that. Rich
Re: [gentoo-dev] gentoo embedded reference accounts?
On 05/29/2010 01:54 PM, Joshua Saddler wrote: D-Link routers, for example, run (or used to run) Gentoo. SRI's solar probe, RAISE, ran Gentoo. The Misa Digital Guitar, just entering mass production, runs Gentoo. There are many more places where Gentoo's been used in various devices and production environments, so the PR, GMN, and GWN archives are your friends, as well as searching Google for Gentoo success stories. When I think about pros/cons for Gentoo vs something else here are a few thoughts (some of which you may have already had): Linux in general isn't the only OS used in embedded apps - there are other options like vxware/etc, which probably should be at least considered as well. Advantages of linux in general would be familiarity and a very wide range of features. A more purpose-driven OS might have the advantage of better realtime support and stability, as well as better vendor support (embedded is all that they do). If you're going to run linux, then I'd consider Gentoo well up there - granted I'd strip out a lot of it before deploying it. Gentoo has most of the flexibility of linux from scratch, but is FAR more maintainable if you plan to keep it updated. The fact that you can mix and match just about any version of any library/etc is a big plus - it gives you more control over what you put on your device. On the other hand, some other distros might give you better long-term-support if you're willing to live with the library versions they pick and how they build everything. If your device goes on a network then it may need security patching, and that is generally safer if you have a vendor who will backport security fixes for 5+ years. Something like RHEL has certifications/etc and more formal support, so you can hire people who probably know what they're doing. Like anything you have to consider all the pros/cons. If I were building something on my own dime in an embedded space I'd probably strongly consider Gentoo. Of course, if you do use Gentoo unless you have a ton of storage you're going to want to strip out the toolchain, portage, etc. You would use gentoo to maintain a development image, and then any time you want to you could copy that and then trim it way down (you could probably script this). Just some random thoughts. Rich
Re: [gentoo-dev] bug wrangler queue is large...
On 05/25/2010 02:24 PM, Mike Frysinger wrote:
On Tuesday 18 May 2010 02:02:01 Andreas K. Huettel wrote:
could you please help the poor bug wranglers a bit?! The queue has reached
170 unassigned bugs...
people dont seem to realize that bug-wranglers isnt just for re-assigning to
the proper maintainer. they are supposed to be doing basic triage, user
feedback, as well as cleaning up the bug. i shouldnt be seeing bugs assigned
to maintainers that have ${PN}-1.ebuild as their subject, nor bugs that lack
basic things like `emerge --info` or build logs.
As long as the status quo works I don't think we need to change it.
However if we are running into issues with keeping up it might make
sense to just have wranglers do assignments to maintainers and let the
maintainers deal with the rest.
The reason is that the maintainer might be able to spot dups much more
readily, or spot obvious solutions to bugs, where a wrangler might be
hunting around.
By all means wranglers should do what they can when they can, but keep
in mind that if you yell at a wrangler any time they do it wrong a
natural response of devs will be to not bother with bug wrangling or
just looking for their own bugs in the list.
I'm not necessarily proposing any changes here, but in general we need
to be careful about barriers to entry in projects that are undermanned.
Rich
Re: [gentoo-dev] Re: [gentoo-core] (infra) rsync updates and distfile fetching offline for next 12-18 hours.
On 05/20/2010 01:46 PM, Arun Raghavan wrote: Why is gentoo-core is not enough? I thought all devs were expected to follow -core, no exceptions made. Well, unless something is sensitive it probably doesn't belong on -core. In the spirit of openness we really should have very little traffic on -core (which happily is the case). Now, if the announcement included somebody in infra's cell phone number of something as a contact then of course that would be -core material. If you want all devs to get something -dev-announce is the right forum, unless it is sensitive. Rich
Re: [gentoo-dev] Does anyone use the VERIFIED status in bugzilla?
On 05/14/2010 09:34 AM, Samuli Suominen wrote: I'd like to see the whole thing go away. It's this one user I've pretty much ever seen using it. And he's using it to change RESOLVED status to VERIFIED on e.g. removal bugs, stabilization bugs, keywording bugs... I think that VERIFIED could have a place in a serious quality management system that closes the loop on every change. If we had a test branch and a release branch the VERIFIED might be the glue that moves patches from one to the other. However, we don't have anything like this in place right now, and so this is really just spam. Having the extra state does no good without all the processes that go with it. Would Gentoo have a higher level of quality if we did some CMM-5 practices like these? Absolutely! Would it struggle to keep up with Debian Stable? Absolutely! I don't think we really have the resources to pull off something like this. As it is we struggle with the current ~arch/arch system. I'd get rid of it...
Re: [gentoo-dev] Re: Requiring two sets of eyes for all eclass commits
On 04/25/2010 07:36 AM, Ryan Hill wrote: People make mistakes. Agreed - at work I've often found a quality mindset that is 100% focused on preventing mistakes, and I've found that these kinds of systems are almost equally as focused on preventing them from being fixed (three minutes to fix a bug, three weeks to document and release the fix - then we wonder why the system has hundreds of trivial open bugs with no ROI for fixing them). A good quality system isn't just about preventing mistakes - it needs to be about fixing them too. The system that prevents typos from getting into the tree shouldn't get in the way of those typos being fixed. There needs to be a balance. Scripts running on repository servers don't have a sense of balance, so they aren't the answer. Nor is cutting off hands any time a dev messes up unless it becomes a pattern or there is malicious intent. However, a systematic review process is probably a good thing most of the time, and published policies supporting this are a good thing. Rich
Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
On 04/13/2010 12:33 PM, Matti Bickel wrote: Alec Warner wrote: Its not possible in perforce once your change has been submitted. Oh, missed that one. Maybe that makes perforce more auditble or whatnot. I suspect that is the gist of it. I work with numerous systems that have audit trails that are subject to regulation, and it is pretty typical that the way to correct an audit trail entry is to add an additional audit trail entry (with the old entry still being there - perhaps with a pointer to the new entry). There is no shame in admitting that you made a mistake - the kinds of people who audit these systems look at a lack of mistakes as evidence that something is being hidden. Rich
Re: [gentoo-dev] Who is willing to be lead?
On 04/10/2010 07:44 PM, Ben de Groot wrote: On 11 April 2010 00:54, Denis Dupeyroncalc...@gentoo.org wrote: I know it hurts the eyes a bit, but calling problems by their name is part of fixing them. Except when someone else does it, then calling the problem of lack of leadership suddenly becomes immature political ranting. Nice try. You know, leadership can be as much about NOT replying to an email as replying to one... :) You don't need to be elected to the council to be a leader. I'd say that with very few exceptions those who have been on the council were elected because a majority of devs recognize that they have been leaders. I can certainly say that they have put in a lot more time than most reading this list, and it really isn't anybody's place to lecture them on being leaders as a result. If somebody really thinks they have constructive advice then make it constructive, or at least send it in private to coun...@g.o. If there is ANYBODY here who actually intends to lift a finger to actually do work to rectify these problems, by all means contact the appropriate project lead or the council or something and ask how to pitch in and help. Based on Patteri's post it sounds like you can feel free to ping him on irc/email if you're looking for something to do. And let's try to remember that we're all in it together - infighting isn't going to inspire more people to join the cause... 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.
Re: [gentoo-dev] Council meeting 19 April 2010
On 04/07/2010 11:00 AM, Denis Dupeyron wrote: 5. centralize developer documentation = This is an interesting idea which I believe I have seen discussed on irc at some point. Feel free to work on a GLEP to address that. To be honest, this doesn't even need a GLEP so much as a website or something. If somebody consolidated all this stuff into a reasonable format, I bet that half the devs would pitch in and make their contributions. The only thing that might warrant a GLEP is a policy decision that all development policies must be documented or linked from that site to be binding, or something like that. I don't think that for the council to make a policy decision that there needs to be a GLEP. Sure, it is the best way to make big changes, or changes that require some level of formality. However, the council can still show leadership in affirming their agreement on issues even if it isn't a formal affair. I'm sure every other town government in the Western World has taken a vote in support of their troops or something like that without going through the official lawmaking process and all that - it is just a gesture. I don't have the time to create such a website although I would agree that it is sorely needed. Hence, I will try to be careful in throwing around criticism - it is much easier to bring problems to the table than solutions... 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] [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] 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] [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] 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] 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] [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] 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] 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] [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] [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/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] 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] 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: 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] 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] 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] 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] 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] 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/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/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] 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] 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] 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 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] 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] 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.
[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] 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.
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] 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] 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... :)
[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] 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.
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] [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: [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] 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] 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] 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] 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] 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] 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] 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] 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: 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] 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.
