Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 2006-06-09 at 02:53 +0200, Stefan Schweizer wrote: Stefan Schweizer wrote: it is actually encouraged to update bugzilla when changes are made in the overlay. Encouraged? If you leave it at that, people will forget, and things will get out of sync. At the very least you should supply per-package rss feeds and email subscriptions. Otherwise this will be a downgrade in functionality from the current bugzilla system. (Which I think is perfectly fine as it is.) The ebuilds have a quality, repoman is required to be run. Also contributors should be knowing what they are doing - they are submitting an ebuild to the sunrise overlay, it needs to follow certain standards. And what if they do know what they're doing, and what they're doing is subverting Gentoo systems en masse? You're proposing to hand out commit access to anyone who makes a case on IRC; you have no way to tell that they aren't an attacker. Part of the reason becoming a dev is expensive is that it provides a barrier for attackers (and gives recruiters time to check that the candidate is who they claim to be). By using Gentoo resources for this project you're implying that the ebuilds can be trusted; hordes of users *will* sync with the sunrise overlay, giving an attractive target to attackers. (Or what if they're attacking overlays.gentoo.org itself? This stuff is shell code; some well-meaning person's going to source it at some point.) And similarly, Gentoo's reputation would be immeasurably damaged if an attacker succeeded in sneaking malicious code in. (Don't say you'll review it; can you review every line of a 20K gcc4-compatibility patch? Have you read the Underhanded C Contest?[1]) Ed [1] http://www.brainhz.com/underhanded/ -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Hi Kumba, In a similar vein, will this eselect tool eventually supplant the functionality of binutils-config as well (and thus need its own wrapper script)? Have a look at eselect binutils please, which is shipped with app-admin/eselect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Friday 09 June 2006 10:15, Danny van Dyk wrote: Have a look at eselect binutils please, which is shipped with app-admin/eselect. It's sub-optimal compared to eselect compiler, x86_64 ld does not work with i686. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppmkbojAU5g.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? just my point of view - bugzilla sucks. Ever had to download 10 attachments for one ebuild? It is a good tool for discussion, but I would prefer a simple tool (like layman) that can automatically update things. You obviously don't like overlays, but that shouldn't be a reason to stop us from using it. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Yes, now it is easier to check out the ebuilds. More users == better testing. ;-) No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. That differs from the 20 or so overlays maintained by users how? Honestly I'd prefer an overlay where I can marginally trust the content over a foreign repository maintained by people I don't know. And the quality of some of the overlays ... better have that supervised by devs, they should know how to handle b0rkage. Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) See mine. ;] Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ... Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) Having one overlay with a focus on not-in-portage ebuilds should not cause the scenario you described and will most likely cause less weird bugs because of intra-overlay dependencies. /opinion That is *exactly* what we get with the other overlays like php and vmware. I *know* that if I'm looking at a glibc bug and the user has php as an overlay, that it isn't going to be a concern. ... and if we control the overlay we can exclude things like system packages easily. Could be part of the policy to not touch existing ebuilds. This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) And again, one svn repo vs. 113 hard-to-find bugs ... Even better, if I am the proxy maintainer for a particular set of ebuilds for one or more user/maintainers, why do I need it in your big, bloated, and completely inappropriately-named sunshine overlay versus a developer overlay of my own? You don't. Please use your developer overlay. Please don't try to take away our more open overlay. After all, I am the *only* proxy maintainer. Why should there be the added *insecurity* of allowing any number of people that *I* might not trust complete access to the small number of packages where I am the proxy? It's your choice. Either you get mailbombed with each minor version update or you trust them to not screw up with the sunrise overlay. And the users could just create their own overlay, get it added to layman and we'd have the same without supervision. From where I'm standing it's better to have
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Alternative?
Hi again as written below I think it makes more sense for Project sunrise to redefine it a bit. It seems to be clear that currently noone is happy with the Sunrise Project. There is one huge disadvantage for end users like me: If we decide to use an overlay package (because we need / want the functionality) we have to make sure from time to time that this one is up to date. BTW: This is not only time consuming but also inefficient. Where is the difference to BMG? Two things: a) Official development support (note: not an official overlay). b) One overlay per development (team) project instead of an huge overlay with maybe breaking stuff. This is a different approach than the one of BMG: We want to provide unstable ebuilds, which have no chance to get into portage. How about this alternative: Use sunrise (as stated earlier) as an help me-mailing list or whatever for users who may want to become developers. Provide RSS feeds (as stated below - a good idea I think) for end users. How should it work (new dev view): - A user want to add application (x) to portage. He creates a overlay and uses bugzilla and so on. - He is interested in adding his ebuild (or program (x)) permanently to portage. - This user requests help and support from the sunrise developers. The guidelines say, that he should provide a RSS feed to inform users about new versions of program (x) for Gentoo. Why should he provide an overlay? Because it's easier for testing purposes than downloading maybe a whole bunch of files from bugzilla. How should it work (the sunrise project view): - Sunrise works like an planet site. It scans the RSS feeds in specific time intervals and add new entries to its own DB. - Sunrise contains a DB for locations of overlays and contact details. - Sunrise will provide functions for users to search on it (like packages.gentoo.org) and to find information where the overlay is located. How should it work (sunrise dev view): - The developer finds out that a new version of the ebuild exists. He reviews the ebuild and gives feedback to the developer. - He uses contact details that the taker used to register at sunrise. How should it work (end users view): - Load a RSS feed into your favorite RSS viewer and you're done. Of course you still have to use layman or whatever to update the overlays manually. Is there a way to integrate this functionality into emerge --sync? Advantages: - Easy to search and up to date DB for custom Gentoo overlays - Helpful information and feedback from Gentoo developers. - Learning by doing approach. Disadvantages: - Still different places all over the net for overlays. - Possibility that two teams create ebuilds for the same program. - Different development forms. Somehow there have to be a way that third parties provide improved ebuilds. - Maybe complicated rules: After x days inactivity, the project should be given to new takers and so on. What do you think? Best regards PS.: This is just an early idea. Maybe you will find some not logical points here or things that already exist in the www ... Edward Catmur writes: On Fri, 2006-06-09 at 02:53 +0200, Stefan Schweizer wrote: SNIP Encouraged? If you leave it at that, people will forget, and things will get out of sync. At the very least you should supply per-package rss feeds and email subscriptions. Otherwise this will be a downgrade in functionality from the current bugzilla system. (Which I think is perfectly fine as it is.) SNIP -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Hi Diego, It's sub-optimal compared to eselect compiler, x86_64 ld does not work with i686. eselect binutils should be as capable as binutils-config. AFAIK the stated behaviour is no regression. If it is a regression, please file a bug against it. If it isn't, file a bug for an enhancement request. I'm quite positive we can get it going. :-) Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? I agree that it would make sense for the the sunrise overlay to contain smaller package trees, with each package tree aimed at a particular type of ebuild. Layman supports automatically downloading each of these smaller trees as separate overlays. This would still allow Sunrise to maintain a social workspace, where Gentoo can encourage and train would-be developers (and hopefully recruit the good ones) . In fact, I believe that it will work better, because we'll be encouraging users to focus on particular problem areas rather than encouraging users to download a large and sprawling mass of packages. Having smaller, targetted trees would also help ensure that Sunrise doesn't become another BMG. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Patrick Lauer wrote: On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. This differs from a manually patched ebuild in /usr/portage by virtue of showing you that an overlay is used ... Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Ooooh, cool. Now I need about 75 overlays to get things done, and of course there will be no bad interaction between them ;-) Please, leave pam_skey alone. ;) It's a thing I'm using daily and the default system-auth config file installed by this ebuild allows for both system and S/KEY passwords to be used at the same time, you can pick whichever one you want. There's no way to get yourself locked out of system unless you've already forgotten your normal password and didn't yet set up OTP, in which case, it's not pam_skey problem at all. The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Nothing wrong w/ that. So, I can either keep on maintaining it in my local overlay or let other people use it if they find it useful. I prefer the latter. pam_abl and pam_mount is also stuff that I'm testing/using myself. The only thing I haven't tested beyond it compiles and installs is pam_pgsql, that one doesn't touch system-auth at all, comes w/ commented-out .conf and so has no effect until the user has configured it. There are about 3 other bugs requesting pam stuff, but since that stuff is essentially dead upstream, it won't be in the overlay. So, are you asking to have a separate overlay project for 4 pam ebuilds? Heh, really an overkill. Could be part of the policy to not touch existing ebuilds. IMHO the sunrice project is a good place for maintainer-wanted/needed bugs. Shouldn't be a dumpspace for whatever experimental patches for stuff that's actually being maintained in the main tree. This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) Erm, look at the vmware-server bug (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless for grabbing any ebuilds, there are ~350 comments and tons of obsolete, yet not marked as such ebuilds, that's why you switched to subversion, right? And it boosted the effectivity by a huge margin. Also comes w/ a nice side-effect of not bugspamming another 200 folks CCed on the bug when someone screws w/ attachments for a couple of times. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Friday 09 June 2006 11:06, Jakub Moc wrote: The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Or if somebody wants to help with PAM and related... considering right now Azarah is mostly away and I'm almost alone handling the rest. Yes it's offtopic, but a quick way to remember that we need more PAM maintainers :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyjpJZELOjq.pgp Description: PGP signature
[gentoo-dev] What is official?
Hi, One of the issues that the o.g.o project has brought to a head is the definition of what is official and what is not official when it comes to Gentoo. The term is already being thrown about in the Project Sunrise thread; I'm sure it'll come up again in future. It's an issue I think we should discuss and find an agreement on. Personally, I think what makes something official or not is 100% down to who does it. I think something is official if it is done by the project (where a project matches the definition in the metastructure project) responsible for whatever we're applying the label official to, then that's all that matters. So (picking something entirely at random for an example), if the Java project had an overlay somewhere (say, on gentooexperimental.org), because it's their overlay, the overlay is official. Doesn't matter where it is hosted - all that matters is that it is run by the Java project. Equally (because it is the hot topic of the moment), Project Sunrise's overlay would be official because they're a Gentoo project. The way to stop them being official is simply to have the Council pass a resolution to shut down the project. I think the other side of the term official is clarifying the scope of how far something can be official. Using the Java project as an example again (sorry guys :), the Java team can put in place official policies and procedures for what their team does, but that doesn't make them mandatory for the whole Gentoo project. Other developers remain free to form competitive projects, and put their own official policies and procedures in place if they wish. (I hope I explained that last bit properly. What I'm trying to do is keep in mind the terms of the metastructure document, which explicitly allow for two or more teams to be competing with each other). What are the alternatives? If a project's activities are not automatically official, then who gets to decide, and how is that decision made? How can that decision be made fairly, without contradicting the metastructure, and without giving rise to any accusations of 'cabals'? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] eselect-compiler updates and unmasking
Ah, you're right, there should be an env-update in there. Thanks for the report. As for sourcing /etc/profile, you don't need to do that with eselect- compiler because your $PATH doesn't change like it did with gcc- config-1.x. --Jeremy On Jun 8, 2006, at 11:27 , Donnie Berkholz wrote: Donnie Berkholz wrote: This aliases g77 to gfortran and gfortran to g77. They are entirely different compilers and do not accept all the same options. This is incredibly broken behavior, it masks issues in a number of packages and creates new issues in many others. Please fix it. It also doesn't run env-update, so the library paths aren't updated. In the past, all that was necessary was to source /etc/profile. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Shouldn't gcc-4.1-related bugs have some kind of priority as gcc-4.1 is now unmasked?
On Thu, Jun 08, 2006 at 07:00:33PM -0700, Drake Wyrm wrote: I just took a look at that. It's asking that you don't relay mail through dev.gentoo.org unless you can't send mail through your usual means of sending mail. For example, if your ISP blocks mail if the From: header indicates something other @myisp.com, then you need to relay through dev.gentoo.org. In any case, it's not telling you to avoid using your @gentoo.org account. Yupp. Of course, somebody flame me if I'm wrong. No flames from me - i send my from: [EMAIL PROTECTED] mails via my university's gateway as well. ;-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpesZDuc2ulD.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: Except that I can *look* at an ebuild without having to break out a subversion client currently. See my answer in 3) See mine. ;] Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 09/06/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. I don't agree with that semi-official term. We for example have an overlay for the Haskell project. Nevertheless, we consider it the official overlay for our group, but not for Gentoo. So that way we can use it as our sand-box, to play with it as much as we can, and giving commit access to even non-developers, the advantage The Haskell overlay isn't publically available (at least, layman doesn't know about it). That makes it quite different from the semi-official overlays I gave as examples. Whether something is semi-official or not is all about perception. If people see that a project is run by gentoo developers, possibly formed into a gentoo group, using gentoo resources (bugzilla, forums, mailing lists etc) to discuss and organise, then there will be a perception that the project has some semblance of officiality. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 09/06/06, Edward Catmur [EMAIL PROTECTED] wrote: And what if they do know what they're doing, and what they're doing is subverting Gentoo systems en masse? You're proposing to hand out commit access to anyone who makes a case on IRC; you have no way to tell that they aren't an attacker. This is the way the system currently works. I'm sure any decent motivated hacker would be able to fix a few ebuilds, hang out on irc, do the quiz, and gain cvs commit access. There are no identity checks when you become a gentoo developer; it's all about reputation. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On 09/06/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote: Yes, i agree, writting and maintaining ebuilds is a hard and *time-consuming* task. So if an user can't even take the time to fix a digest, why we should support him officially?. The point is that there are lots of users who are interested in niche packages that no developers use or are interested in. These users have the skills to write an ebuild, and other users of the package have the skills to fix and maintain that ebuild over time. These guys don't mind downloading ebuilds from bugzilla and fixing digests. But there are a larger class of users of niche packages that don't have the ebuild skills, and don't want the hassle of bugzilla and digest fixing. This larger group of users are the ones that would benefit from an overlay. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On 6/9/06, Edward Catmur [EMAIL PROTECTED] wrote: With an overlay: search sunrice.gentoo.org for the package If you want people to debate seriously with you, stop calling this project 'sunrice'. If you can't discuss this topic respectfully with others on this list, please stop using our lists. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Edward Catmur wrote: On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... Hmmm, I mostly notice a different scenario: - search for the bug, and file a dupe because you didn't find it :P - bug gets marked as a dupe - the guy who filed the dupe comments on how much bugzilla search sucks - download one of obsolete broken ebuilds attached to the bug - moan that it doesn't work - download another ebuild - moan that it doesn't work either - someone points to comment #27 that says you need to edit lines XX and YY for the ebuild to work - do it, post yet another redundant yay, that finally worked! comment - attach a fixed ebuild tarball - you get scream upon to not attach tarballs - you attach a plaintext ebuild now - notice that its MIME type is application/octet-stream - change the mime type - look at the ebuild in the browser now that you can and notice bunch of stupid typos you've done that ruin the whole fix (hello, Mr. Murphy) - try to edit the attachment in bugzilla, which produces one huge nonsense comment instead of actually editing the ebuild - attach a new one - oh noes, it's octet-stream again! argh! - fix it... - forgot to mark previous one as obsolete, do it now - produce sorry for the noise comment - someone notices that you've still left two typos there and attaches yet another ebuild By now, about 15 bugspams times the number of people CCed on the bug got sent, containing mostly useless crap. With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Yes, with an overlay you can prevent all the attachment screwups noted above and once you are really satisfied that it works, you post a link to bugzilla. You can fix your typos in VCS, even multiple times, without bugspamming the hell out of people, and you still have the history to go back if you screw up. Bugs with tens of attachments are essentially useless for most of newcomers and suck for effective development as well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=24247 http://bugs.gentoo.org/show_bug.cgi?id=70161 http://bugs.gentoo.org/show_bug.cgi?id=122500 -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thu, Jun 08, 2006 at 06:31:43PM -0400, Peter wrote: And, for me again as a user, using a gentoo-hosted overlay is preferable to a third party repository. This is a personal bias on my part -- and maybe unwarranted. This is actually my main concern with the Sunrice project. You say you would prefer a gentoo-hosted overlay to a third party repository. Why is that? I can only assume it's because you think hey, it's officially endorsed by Gentoo, the same people who maintain the other official ebuilds - so it must be ok. I suspect most users will think similar and will come yelling at us, or even worse - at upstream, when something in this overlay breaks and leaves their computer as expensive paper weight (at least until they've formattet and started over). Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpkuqZZtv2he.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Friday 09 June 2006 12:12, Chris Bainbridge wrote: This larger group of users are the ones that would benefit from an overlay. And this larger group of people is exactly the same one, that doesn't know to help itself, if necessary and will suffer the most, when something goes wrong. This group of people shouldn't use any overlay. I think the basic misconception is that some think we are supposed to provide a package just because it's requested. We need maintainers for every package. Without maintainers: Sorry, no. Period. Carsten pgpmveiBPApcq.pgp Description: PGP signature
Re: [gentoo-dev] What is official?
In my eyes only the main tree is official. The overlays are development niches (and as such perfectly fine), to speed up development without causing much trouble in the main tree. The problem is that overlay.g.o is seemingly official, because we host it. It should be made more clear that this isn't the case. Carsten pgp3UHsgOxWZ5.pgp Description: PGP signature
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Friday 09 June 2006 02:53, Stefan Schweizer wrote: It also doesn't answer the questions of security and maintenance. Are genstef and jokey going to be responsible for the security of every single package in the overlay? Yes, we will be acting upon all issues that we hear about. ... that is neither supported security wise, nor is ensured that the ebuilds have a minimal quality (do not fubar a users system). we do support it security wise, we will be reacting upon security issues. We do have package.mask support in the overlay and we are going to use it. The ebuilds have a quality, repoman is required to be run. Also contributors should be knowing what they are doing - they are submitting an ebuild to the sunrise overlay, it needs to follow certain standards. See, I don't go over this bridge, that an overlay of arbitrary packages, with varying skills and knowledge needed, can be decently controlled with very few people caring and not having a security team backing you up. Carsten pgpjJeyxOwK7k.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
This may work for Apache or PHP, but an overlay with arbitrary maintainer wanted ebuilds would need an extra bugzilla account. The problem is that this won't really help, since (some) users will see oh, an kde app crashed and file a bug at [EMAIL PROTECTED] Then /me looks at the tree, doesn't see the package and marks the bug as invalid. Even worse it is for bug wranglers. You hardly can expect that they look up every single overlay. You should at least make it visible in bold letters on the overlay.g.o front page, what the conditions of each overlay are and which [EMAIL PROTECTED] address bugs have to be assigned to. Also some warning that an overlay may break the tree or fubar the users system and that only the one who uses it, is responsible for using it, wouldn't be wrong. Carsten pgpbOuaBdZ6Hq.pgp Description: PGP signature
[gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 09 Jun 2006 13:08:01 +0200, Henrik Brix Andersen wrote: On Thu, Jun 08, 2006 at 06:31:43PM -0400, Peter wrote: And, for me again as a user, using a gentoo-hosted overlay is preferable to a third party repository. This is a personal bias on my part -- and maybe unwarranted. This is actually my main concern with the Sunrice project. You say you would prefer a gentoo-hosted overlay to a third party repository. Why is that? I can only assume it's because you think hey, it's officially endorsed by Gentoo, the same people who maintain the other official ebuilds - so it must be ok. I suspect most users will think similar and will come yelling at us, or even worse - at upstream, when something in this overlay breaks and leaves their computer as expensive paper weight (at least until they've formattet and started over). Regards, Brix I don't think so. I look forward to the sunrise (sorry I called it sunshine earlier, it was late) project because of two reasons. Firstly, I think it is very clear that anything in sunrise is experimental or not supported in the main gentoo tree. That's fine! I don't think any user who goes through the trouble to set up an overlay would miss that point. You can't go to o.g.o and not see the disclaimers. And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). Anyone who fetches the sunrise overlay would know exactly what he/she intends to do and why. Much different than emerge --sync with keyword x86. Secondly, my bias against a third party repository is perhaps unwarranted. I am sure the bmg site is excellent and the people running it are well-intentioned and experienced. However, that said, as a user, I have a higher comfort level staying in the gentoo.realm. Thirdly, the opportunity to be able to publish ebuilds that would otherwise languish in bugzilla is very exciting. I think it also gives the bugday people an opportunity to close out bugs. Despite what others have written, having multi-year old bugs is very counter productive. If something has not been fixed in so long, it probably either can't be fixed, or may not even apply anymore. I know this is a generalization, but if a bug was filed against gentoo 2004.3, who knows if it still applies with gentoo 2006.0. Especially if there has been little or no activity. Personally, I don't see the conflict, or the risk, or the additional work for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is a net positive. If that means the proposed ebuild lives in o.g.o that's fine. Just point users who see the bug over to it. And, if an ebuild proves to be useful, or popular, it's conceivable that it could ultimately find its way over to the main tree. As for the more sinister aspects of a rogue ebuild finding its way onto o.g.o, sure that's a possibility. However, any dev could do the same in portage because they have commit access (and the problem may not be caught right away). Moreover, it's possible that an ebuild may be fine, but a particular version of a package tarball could have outright malicious code or an undetected security hole in it that has not been caught yet. That could find its way onto portage too. IMHO, I don't see any more risk to security in o.g.o. Again, I think you need to consider your audience for o.g.o. The newbie won't be there or be syncing to o.g.o. The server admin probably would not be there either for updating a production machine. I think the main audience for o.g.o. would be the power user, or the wannabe power user or certain project teams, or people with a particular interest or need in a project not hosted on the main tree -- that is people who actively need sunrise's services. And, looking at this from a broader perspective, I see this as a real enhancement to gentoo. Offering an experimental tree for packages not intended or not wanted in the main tree. This is an added benefit, it demonstrates a policy of inclusion, not exclusion. It shows a willingness to push the envelope and give certain packages a home where they would not normally get one. -- Peter -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] What is official?
Keeping it simple... If it's hosted on gentoo infrastructure it's official. If it's hosted on gentooexp.org/SF/Non infra then it's not official. On Fri, 2006-06-09 at 10:32 +0100, Stuart Herbert wrote: Hi, One of the issues that the o.g.o project has brought to a head is the definition of what is official and what is not official when it comes to Gentoo. The term is already being thrown about in the Project Sunrise thread; I'm sure it'll come up again in future. It's an issue I think we should discuss and find an agreement on. Personally, I think what makes something official or not is 100% down to who does it. I think something is official if it is done by the project (where a project matches the definition in the metastructure project) responsible for whatever we're applying the label official to, then that's all that matters. So (picking something entirely at random for an example), if the Java project had an overlay somewhere (say, on gentooexperimental.org), because it's their overlay, the overlay is official. Doesn't matter where it is hosted - all that matters is that it is run by the Java project. Equally (because it is the hot topic of the moment), Project Sunrise's overlay would be official because they're a Gentoo project. The way to stop them being official is simply to have the Council pass a resolution to shut down the project. I think the other side of the term official is clarifying the scope of how far something can be official. Using the Java project as an example again (sorry guys :), the Java team can put in place official policies and procedures for what their team does, but that doesn't make them mandatory for the whole Gentoo project. Other developers remain free to form competitive projects, and put their own official policies and procedures in place if they wish. (I hope I explained that last bit properly. What I'm trying to do is keep in mind the terms of the metastructure document, which explicitly allow for two or more teams to be competing with each other). What are the alternatives? If a project's activities are not automatically official, then who gets to decide, and how is that decision made? How can that decision be made fairly, without contradicting the metastructure, and without giving rise to any accusations of 'cabals'? Best regards, Stu -- Ned Ludd [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Friday 09 June 2006 13:44, Peter wrote: And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). I had a bug from an users unable to build kdesktop with gcc 4.1. I built it fine I told him, and the line where the error was reported didn't contain anything of the extra qualification reported, so I asked him to check as he was probably using an overlay. He started ranting that we have a bad user support and so on... until he actually recognized he was using xgl overlay. That said, I wouldn't be surprised if especially with layman people ends up using overlays without knowing that. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpRMTwFZBiuu.pgp Description: PGP signature
[gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Carsten Lohrke wrote: You should at least make it visible in bold letters on the overlay.g.o front page, what the conditions of each overlay are and which [EMAIL PROTECTED] address bugs have to be assigned to. Please, do not assume our users being stupid. They know that they are using an ebuild from the sunrise overlay with zero support. They deliberately typed svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application; emerge application And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. Also some warning that an overlay may break the tree or fubar the users system That is not the intention of the overlay. Everyone can help fixing breakage, it is not like with the current tree, where you have apps broken for a few days, weeks or even months because the maintainer is unreachable. With fixes (by users) spread all over bugzilla. It is designed to be more open and more easily fixable. -Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. we want to encourage users to contribute and if they do good contributions in bugzilla they get commit access to the overlay. and then the workload is drastically reduced... You didn't answer anything I asked here. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. I'm sorry, but you're avoiding the question here. How will the bug-wranglers even *know* that this is related to a package in the overlay? They wouldn't. As I ststed *repeatedly* now. The user has not mentioned that they're using pam_skey, as is a common occurrence in bugs. Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. why would a pam dev get this bug? as far as I know bug wranglers work, a check whether the ebuild is in tree is one of the first ones... So the chance that it really hits the pam dev is damn small... Because the user has pam in USE and there's nothing else indiciating that they're using some pam packages from an overlay that has absolutely no hint as to its contents. Also, as I have said, while the bug wranlgers are wonderful and really do reduce our workload, they're *nowhere* near perfect. There are *tons* of bugs that go to the wrong people, or are simply invalid once the actual maintainers see it. The bug wranglers cannot be expected to be experts on every package. Your comments make it sound like they will be. We're not the first large overlay project, there are other ones out there already and these wrong bugs aren't a new thing arising here... No. You're the first large overlay project that is on official Gentoo infrastructure, even after it was agreed that there wouldn't be something like this. With the non-official projects, we simply don't support any bugs from anyone using them. It's that simple. With this project, you're vying for official status, meaning we cannot do that. This will be an *enormous* time sink for the entire ebuild developer pool. Wouldn't this process be *infinitely* easier if instead of sunrise there was a pam overlay with *only* the pam stuff? Then the pam devs are responsible for all the things with it. As it would surely be hosted on o.g.o then, we'll notice it and either shift all ebuilds we have in the sunrise tree over or do whatever is fine with pam devs. If they really dislike the m-w bugs out of their control, then a friendly note on irc, a friendly mail or whatever is enough and we won't touch things of them then... Excellent job of avoiding the issue. I asked how the pam developers would even *know* that there is pam crap in your aptly-named sunrise overlay, and you respond with a comment about how when the pam devs tell you to move the packages you will. I am honestly seeing that this is starting to go nowhere as the answers to my questions aren't being given, and instead the issues are being avoided. That is *exactly* what we get with the other overlays like php and vmware. I *know* that if I'm looking at a glibc bug and the user has php as an overlay, that it isn't going to be a concern. Well we don't keep ebuilds in there which have a maintainer in contrast to the php overlay. they may even keep newer versions of in-tree packages
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 9 Jun 2006 11:05:56 +0100 Chris Bainbridge [EMAIL PROTECTED] wrote: | On 09/06/06, Edward Catmur [EMAIL PROTECTED] wrote: | And what if they do know what they're doing, and what they're doing | is subverting Gentoo systems en masse? You're proposing to hand out | commit access to anyone who makes a case on IRC; you have no way to | tell that they aren't an attacker. | | This is the way the system currently works. I'm sure any decent | motivated hacker would be able to fix a few ebuilds, hang out on irc, | do the quiz, and gain cvs commit access. There are no identity checks | when you become a gentoo developer; it's all about reputation. And in theory, you have to build up quite a bit more of a reputation and talk to quite a few people and have your dev application seen and commented upon by existing developers who can have it cancelled if they deem it inappropriate, which is quite a bit harder to do than what is being proposed here. Of course, the practice is, uh, somewhat lacking of late... -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote: On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. I'm sorry, but you're avoiding the question here. How will the bug-wranglers even *know* that this is related to a package in the overlay? They wouldn't. As I ststed *repeatedly* now. The user has not mentioned that they're using pam_skey, as is a common occurrence in bugs. Curious, how will the wrangler know in general? *cough* they won't. You're using a generic arguement against a specific target- iow, apply it to overlays.g.o in general instead of singling sunrise out via it. Meanwhile, answer to that one is better bug data for reporting- dump of (random out of the ass example) first level deps, and where they came from (overlay/portdir). Downside to that data is that slackers will automatically punt the bug if they see non portdir in cases where it's obvious it's an issue in the pkg rather then the deps, but there always is a downside... We're not the first large overlay project, there are other ones out there already and these wrong bugs aren't a new thing arising here... No. You're the first large overlay project that is on official Gentoo infrastructure, even after it was agreed that there wouldn't be something like this. With the non-official projects, we simply don't support any bugs from anyone using them. It's that simple. With this project, you're vying for official status, meaning we cannot do that. This will be an *enormous* time sink for the entire ebuild developer pool. Same for above re: large overlay, realistically, like it or not the general case of N overlay/repo is coming down the pipe. Personally, I'd rather see this particular case be handled from the get go as an experiment- lay out from the start the exit conditions for it (if it becomes a dumping ground, out she goes). Reason? Devs/users have been after a true testing branch/repo from day one, if we're doing overlays and people are willing to try and supply that demand, lets get the question answered once and for all (instead of everyone and their mother shooting off about every potential they can think of for why it might fail). ~harring pgpcq5ihyOyf2.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, Jun 09, 2006 at 07:44:38AM -0400, Peter wrote: Firstly, I think it is very clear that anything in sunrise is experimental or not supported in the main gentoo tree. That's fine! I don't think any user who goes through the trouble to set up an overlay would miss that point. You can't go to o.g.o and not see the disclaimers. And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). Anyone who fetches the sunrise overlay would know exactly what he/she intends to do and why. Much different than emerge --sync with keyword x86. According to other mails in this thread, it will be possible to use the overlay through layman - no need for a complicated svn checkout process. Secondly, my bias against a third party repository is perhaps unwarranted. I am sure the bmg site is excellent and the people running it are well-intentioned and experienced. However, that said, as a user, I have a higher comfort level staying in the gentoo.realm. Care to explain why you have a higher comfort of staying in the gentoo realm? I ask since I'm afraid it's due to a false sense of security. Thirdly, the opportunity to be able to publish ebuilds that would otherwise languish in bugzilla is very exciting. I think it also gives the bugday people an opportunity to close out bugs. Despite what others have written, having multi-year old bugs is very counter productive. If something has not been fixed in so long, it probably either can't be fixed, or may not even apply anymore. I know this is a generalization, but if a bug was filed against gentoo 2004.3, who knows if it still applies with gentoo 2006.0. Especially if there has been little or no activity. We're not talking about bugs per se here - we're talking about enhancement request for new ebuilds. No bugs should be closed simply because an ebuild from the bug is included in the sunrise overlay. Until the ebuild is included in portage proper the enchancement request still stands. Personally, I don't see the conflict, or the risk, or the additional work for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is a net positive. If that means the proposed ebuild lives in o.g.o that's fine. Just point users who see the bug over to it. And, if an ebuild proves to be useful, or popular, it's conceivable that it could ultimately find its way over to the main tree. Again, the bugs wont be removed - the ebuilds will simply be mirrored in the sunrise project (please correct me if I am wrong here). As for the more sinister aspects of a rogue ebuild finding its way onto o.g.o, sure that's a possibility. However, any dev could do the same in portage because they have commit access (and the problem may not be caught right away). Moreover, it's possible that an ebuild may be fine, but a particular version of a package tarball could have outright malicious code or an undetected security hole in it that has not been caught yet. That could find its way onto portage too. IMHO, I don't see any more risk to security in o.g.o. Except that when a Gentoo developer intends to add a new package to the tree they're supposed to do QA on the package and the ebuild. Many herds also use peer review for this. As every Gentoo developer knows, this is a very time consuming task. A task for which we are already understaffed as it is. I fail to see how a new parallel portage tree with contributions from people inexperienced in writing ebuilds and reviewing packages can be reviewed and supported by only a handful of Gentoo developers, who also have no experience with the packages in question. Again, I think you need to consider your audience for o.g.o. The newbie won't be there or be syncing to o.g.o. The server admin probably would not be there either for updating a production machine. I think the main audience for o.g.o. would be the power user, or the wannabe power user or certain project teams, or people with a particular interest or need in a project not hosted on the main tree -- that is people who actively need sunrise's services. Perhaps. No one really knows how many newbies or experienced users will use the sunrise project, not you - not I. But I do fear that many of our end-users will use it, or at least, use parts of it. As previously stated, I fear that the quality of the parallel tree will not live up to the standards of the main tree, causing the reputaion of Gentoo as a whole to degrade to the reputation as a ricer distribution which we have worked so hard on eliminating in the past couple of years. Therefore I'd rather see the project hosted on third party servers (e.g. gentoo-sunrise.org) to avoid having it automatically seen as an officially endorsed Gentoo repository by end-users/upstream developers to begin with. If the Gentoo developers and contributors involved succeed in proving that this indeed is a good idea, and that it indeed
Re: [gentoo-dev] Project Sunrice: arch team perspective
On Thu, Jun 08, 2006 at 11:08:55PM -0400, Stephen P. Becker wrote: Starting a new thread here for a new angle... As Stuart mentioned, bugs for any ebuild on o.g.o would go through Gentoo bugzilla. It seems like genstef and jokey have completely ignored support from arch teams for this overlay. What are you proposing with respect to arch keywords and package.mask? Do you actually expect us to do anything but close assigned bugs for sunrice ebuilds as WONTFIX? Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? And while we're talking collateral damage, could the Sunrise folks please make sure it's abundantly clear that users shouldn't ask for support in #gentoo after installing any Sunrise ebuilds? Thanks, Jon Portnoy avenj/irc.freenode.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, Jun 09, 2006 at 05:42:01AM -0700, Brian Harring wrote: Curious, how will the wrangler know in general? *cough* they won't. You're using a generic arguement against a specific target- iow, apply it to overlays.g.o in general instead of singling sunrise out via it. Well, the other overlays at overlays.gentoo.org will primarily be team/herd specific overlays as I understand it - overlays maintained by the people managing the ebuilds. If a bug ticks in about, say, a KDE related ebuild it will be assigned to the KDE herd - who are in a much better position to know whether or not this bug might be caused by something available in their project overlay, since they're the ones who put it there in the first place. Sincerely, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] Gentoo Metadistribution | Mobile computing herd pgpyxOX8zX14r.pgp Description: PGP signature
[gentoo-dev] client+server packages - build which one?
Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. A good candidate is net-misc/dhcp as it installs a DHCP client and server. Which makes no sense really, so I'd like to put some USE flags here to show what I want, or not want to build. A quick scan through the use flags show no real consistency, so here's what I propose USE client server client - just build the client - duh server - just build the server - duh client and server OR neither then build both. Other packages to possably beneift udhcp mldonkey samhain bacula boxbackup Interestingly, many packages have a server USE flag but not a client one - maybe make both a global USE flag? Good idea? Bad idea? Thoughts? Thanks -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrice: arch team perspective
Stephen P. Becker wrote: Starting a new thread here for a new angle... As Stuart mentioned, bugs for any ebuild on o.g.o would go through Gentoo bugzilla. Yeah, as there is usually a bug report for maintainer-wanted and maintainer-needed bugs it wont hurt anyone. It seems like genstef and jokey have completely ignored support from arch teams for this overlay. What are you proposing with respect to arch keywords and package.mask? users are supported to do everything themselves in the sunrise overlay. We are not trying to add any additional workload to your current one. We are in fact trying to make life easier for everyone. Do you actually expect us to do anything but close assigned bugs for sunrice ebuilds as WONTFIX? It is more like, explain the users how to fix it themselves, because they can with the sunrise overlay. Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? These are not expected to be filed as bugs, they should be fixed by the users in question. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrice: arch team perspective
Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? These are not expected to be filed as bugs, they should be fixed by the users in question. Apparently, this is not the case. Policy for overlays.gentoo.org stipulates that all bugs in overlays must use our bugzilla. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] What is official?
Stuart Herbert wrote: Hi, One of the issues that the o.g.o project has brought to a head is the definition of what is official and what is not official when it comes to Gentoo. The term is already being thrown about in the Project Sunrise thread; I'm sure it'll come up again in future. It's an issue I think we should discuss and find an agreement on. Personally, I think what makes something official or not is 100% down to who does it. I think something is official if it is done by the project (where a project matches the definition in the metastructure project) responsible for whatever we're applying the label official to, then that's all that matters. Its a matter of PR in most cases. Infrastructure has been trying hard to make sure any project we host still provides Gentoo with decent PR. Its easy for us to say that if its not on Gentoo's servers, then we can't fully support it. Its the whole liability thing. (That's why we moved all the servers in the rsync.g.o rotation into our control). User X sees something on *.gentoo.org and assumes that its being properly taken care of and managed. If its non-*.gentoo.org, then they can be safe to assume its not entirely under the arms of Gentoo. Now, we can have experimental stuff on gentoo infra, but the key thing here is it needs to be properly maintained and managed. Say in the case with sunrise, I think a lot of people are concerned with the people managing that project won't be able to handle all the different types of issues people are worried about. Perhaps its also a trust issue also, I'm not sure. So (picking something entirely at random for an example), if the Java project had an overlay somewhere (say, on gentooexperimental.org), because it's their overlay, the overlay is official. Doesn't matter where it is hosted - all that matters is that it is run by the Java project. Right, and if ge.org gets hacked, its pretty obvious that it wasn't officially part of Gentoo anyways. To me official means that we (as a group of developers) agree to support something in some fashion and everyone is held accountable for it since its on Gentoo's central resources. Equally (because it is the hot topic of the moment), Project Sunrise's overlay would be official because they're a Gentoo project. The way to stop them being official is simply to have the Council pass a resolution to shut down the project. It would have helped if the project had discussed it on ML's *before* announcing it to the world and then ignoring all discussion about it. I'm pretty sure that the whole attitude they've shown thus far has degraded their trust among developers for the project. The discussion about overlays several months ago specifically was against these types of repos being included, yet it somehow got by? There was trust involved there that if o.g.o became to being, that it would try and keep such repos out. I think the other side of the term official is clarifying the scope of how far something can be official. Using the Java project as an example again (sorry guys :), the Java team can put in place official policies and procedures for what their team does, but that doesn't make them mandatory for the whole Gentoo project. Other developers remain free to form competitive projects, and put their own official policies and procedures in place if they wish. The trouble here is, those policies don't probably incur more bug traffic for *everyone*. There's lots of ways of doing this and most people want it done in such a manner to reduce bug traffic, bad PR, and an agreed upon policy. (I hope I explained that last bit properly. What I'm trying to do is keep in mind the terms of the metastructure document, which explicitly allow for two or more teams to be competing with each other). I don't think the real argument is a competing team. If it is, what teams is it? I'm not sure I understand your point here in relation to the current stuff going on. What are the alternatives? If a project's activities are not automatically official, then who gets to decide, and how is that decision made? How can that decision be made fairly, without contradicting the metastructure, and without giving rise to any accusations of 'cabals'? The decision should be made on our development list for the most part. If it seems that most people don't have a problem with it, then it should ok to assume that its 'more' official. Now if its discussed and several people point out issues with a project, and the project either denies or ignores the issues that are brought up, then I would question its official status. We're all peers in the same group and we should all respect each other's opinions. If such a project cannot work with their peers on resolving the issue then it to me the project doesn't belong in Gentoo nor be included as official. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key:
Re: [gentoo-dev] client+server packages - build which one?
п'ятниця, 9. червень 2006 15:10, Roy Marples Ви написали: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. [skip] USE client server client - just build the client - duh server - just build the server - duh client and server OR neither then build both. The problem with this approach is when you have dependencies on a particular client or server. Then you cannot sipy depend on a package (with present portage) and instead you need to do a hackery detection and bail out in pkg_setup. I think this is the reason why, for example, bind comes as two packages: bind (for everything) and bind-tools. Of course this multiplies the number of packages to support, if such situation is common. However the solution you describe can be considered clean only after #2272 is finally resolved.. https://bugs.gentoo.org/show_bug.cgi?id=2272 George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] client+server packages - build which one?
Roy Marples wrote: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. A good candidate is net-misc/dhcp as it installs a DHCP client and server. Which makes no sense really, so I'd like to put some USE flags here to show what I want, or not want to build. A quick scan through the use flags show no real consistency, so here's what I propose USE client server client - just build the client - duh server - just build the server - duh client and server OR neither then build both. Other packages to possably beneift udhcp mldonkey samhain bacula boxbackup Interestingly, many packages have a server USE flag but not a client one - maybe make both a global USE flag? Good idea? Bad idea? Thoughts? My thought is wait until portage-2.2_alpha where we will have default USE flags. Then I can see putting client/server flags up and having both be default, letting the user turn off clients and servers in /etc/portage/package.use. Thanks -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Sunrise Project -- Open questions post requirement
Hi, so as I was told that I avoid the questions regarding this project several times now, please repost all open issues you have with this project clearly, each in one or max two short sentences here. I'll answer them all the same way to keep out all non-belonging stuff. Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] client+server packages - build which one?
Roy Marples wrote: USE client server client - just build the client - duh server - just build the server - duh client and server OR neither then build both. Other packages to possably beneift udhcp mldonkey samhain bacula boxbackup finger, telnet and ssh are probably other candidates. (though not too many people set up boxes without a ssh server these days). ++ to this, I have always found it a little absurd having dhcpd installed on my laptop just for dhclient. George Shapovalov wrote: Of course this multiplies the number of packages to support, if such situation is common. However the solution you describe can be considered clean only after #2272 is finally resolved.. https://bugs.gentoo.org/show_bug.cgi?id=2272 I doubt whether any devs would argue against USE based dependencies. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrice: arch team perspective
On 6/9/06, Stephen P. Becker [EMAIL PROTECTED] wrote: Apparently, this is not the case. Policy for overlays.gentoo.org stipulates that all bugs in overlays must use our bugzilla. The intention of the policy is to prevent the use of third-party bug trackers for tracking problems w/ ebuilds in overlays. There's no requirement that developers and users must use bugzillla to track changes to ebuilds (which is what I believe Stefan was trying to say). Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Portage-2.1 released
Portage-2.1 final is released, RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4] [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup [3]http://bugs.gentoo.org/show_bug.cgi?id=115839 [4]http://bugs.gentoo.org/show_bug.cgi?id=136198 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Friday 09 June 2006 13:44, Peter wrote: Secondly, my bias against a third party repository is perhaps unwarranted. I am sure the bmg site is excellent and the people running it are well-intentioned and experienced. However, that said, as a user, I have a higher comfort level staying in the gentoo.realm. It's not. The problem is, that the assumption an overlays.g.o overlay of the sort we speak about would be better, is false. Carsten pgpbAFzd7YMoI.pgp Description: PGP signature
Re: [gentoo-dev] Portage-2.1 released
Alec Warner wrote: Portage-2.1 final is released, Is that the 4th horseman I see off in the distance? -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
On Friday 09 June 2006 14:04, Stefan Schweizer wrote: Please, do not assume our users being stupid. They know that they are using an ebuild from the sunrise overlay with zero support. They deliberately typed You have said stupid, not me. Some won't care enough, I'm quite sure about that. We had such invalid bug reports occasionally in the past and I expect this to happen more often, the easier and more common dealing with overlays becomes. Regarding zero support: Making this abslutely clear is what I miss looking at overlays.g.o. svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application; emerge application And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. maintainer-needed is imho not acceptable at all, as any dev trying to clean up bugs, won't know if a bug report comes from a user of the main tree ebuild or from your overlay. Also some warning that an overlay may break the tree or fubar the users system That is not the intention of the overlay. If it were intended, it would be malicious. Even if not intended, it doesn't mean tree breakages won't happen. Some dev may change an eclass, without taking overlay ebuilds into account (and he doesn't have to), but the change may break all ebuilds inheriting the eclass in an overlay, leaving all the users of the overlay with a broken tree. And to make that clear: Eclasses in overlays are only sort of acceptable, when the same team handles the eclass in the the main tree, as eclasses in overlays hide the main tree eclasses. Carsten pgpU7l3V10Wea.pgp Description: PGP signature
Re: [gentoo-dev] Portage-2.1 released
On Fri, Jun 09, 2006 at 12:12:31PM -0400, Alec Warner wrote: Portage-2.1 final is released, Congrats to the portage team! While i'm at it, may i ask which files are affected by these changes / which docs i missed to read? * config files as directories enabling more flexible settings management. Oh, and -U has finally been killed :-) cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpUo7w48Cw3G.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:28 +0200, Patrick Lauer wrote: On Thu, 2006-06-08 at 20:06 -0400, Chris Gianelloni wrote: You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? just my point of view - bugzilla sucks. Ever had to download 10 attachments for one ebuild? It is a good tool for discussion, but I would prefer a simple tool (like layman) that can automatically update things. You obviously don't like overlays, but that shouldn't be a reason to stop us from using it. Well, I thank you for your vast experience as an ebuild developer in this matter. You do realize that this isn't one of those things where you can say that if you don't like it you don't have to use it, right? This *will* affect *every* ebuild developer. This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Yes, now it is easier to check out the ebuilds. More users == better testing. Except that now the developer has to do much more work to get the same information, making it even less likely that he'll bother to pick up one of these maintainer-wanted bugs. You also completely gloss over the ability of a single rogue user to now compromise countless users with a single commit. Please come back once you've firmly grounded yourself in the reality that we're a pretty popular distribution, and that makes this project a prime target for malicious abuse. Perhaps if you were responsible for some ebuilds, you've be more cognizant of the implications that a bad commit can cause our users. No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. That differs from the 20 or so overlays maintained by users how? Let's see. They aren't on Gentoo infrastructure, which means they don't give off any immediate assumption of being official or supported in any way. Hell, go back and look at Peter's response about how he would use an overlay such as this only *because* it is on Gentoo infrastructure. So what exactly was your counter-point again? Honestly I'd prefer an overlay where I can marginally trust the content over a foreign repository maintained by people I don't know. Having an overlay such as this will tarnish Gentoo's reputation. We should not be providing *anything* that is only half-supported or half-tested. Anything less than being sully supported via the security team and QA is a failure on the part of Gentoo. We have enough *crap* in the *tree* that is unsupported, which makes us look bad, yet you want to insist on supporting a project that affects all of the ebuild developers, which you have not mentioned is a group which you are not a part of, so can gladly speak of increasing their workload with no consequences to yourself, and provides an avenue for low-quality or possibly malicious ebuilds to be distributed to our users, all under a Gentoo banner? I seriously question your motives towards the Gentoo project. Hmmm ... bugzilla. Instead of a simple cvs up; cd /usr/local/portage/category/package I need to search for ALL bugs with $name in it, look which one it is, curse bugzilla for falling asleep again, see which attachments are relevant, download them, curse bugzilla for falling asleep again, copy them to my overlay, read the bugcomments to see if any special renaming or directory structure is needed ... Hmmm. I think an overlay does have some advantages there ... Sure. Until I sneak in some obfuscated code as a fix to a bug and it gets executed on your machine because the actual *developers* that are used to maintaining this stuff and know what to look for aren't a part of the process. Making something easier does not make it better. I'm sorry, but you've yet to convince me on how your laziness is supposed to be an improvement for the development process of Gentoo. Again, read what I wrote. I said that the developer would see sunrise in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 11:06 +0200, Jakub Moc wrote: The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Nothing wrong w/ that. So, I can either keep on maintaining it in my local overlay or let other people use it if they find it useful. I prefer the latter. pam_abl and pam_mount is also stuff that I'm testing/using myself. The only thing I haven't tested beyond it compiles and installs is pam_pgsql, that one doesn't touch system-auth at all, comes w/ commented-out .conf and so has no effect until the user has configured it. Uhh... You're a developer. How about instead, you simply join the pam team with Flameeyes and add these packages and maintain them yourself? Do you really need an overlay with *countless* possibilities for other ebuilds to maintain 4 packages? There are about 3 other bugs requesting pam stuff, but since that stuff is essentially dead upstream, it won't be in the overlay. So, are you asking to have a separate overlay project for 4 pam ebuilds? Heh, really an overkill. No. It is called a repository that actually has an explicit purpose. I guess you've missed all of the other overlays out there that are limited to a specific scope. The funny thing is that I *know* that you use at least one of these external repositories, and I haven't heard you complaining that you need to move these packages to some free-for-all overlay such as this. I wonder why that is? Could be part of the policy to not touch existing ebuilds. IMHO the sunrice project is a good place for maintainer-wanted/needed bugs. Shouldn't be a dumpspace for whatever experimental patches for stuff that's actually being maintained in the main tree. It really is funny when you're arguing *for* something, yet you call it the sunrice project. Freudian slip, or an admission of truth? This is a prime example of totally glossing over any discussion to make it sound promising for you. If bugzilla wasn't so sucky people wouldn't try to use other methods of communication ;-) Erm, look at the vmware-server bug (http://bugs.gentoo.org/show_bug.cgi?id=122500) . It's vastly useless for grabbing any ebuilds, there are ~350 comments and tons of obsolete, yet not marked as such ebuilds, that's why you switched to subversion, right? And it boosted the effectivity by a huge margin. Also comes w/ a nice side-effect of not bugspamming another 200 folks CCed on the bug when someone screws w/ attachments for a couple of times. So you're going to try to use my own project as an example against me? Great. Bring it on. The vmware overlay is limited to only vmware products. When someone uses the overlay, they *know* that they are only getting ebuilds related to vmware. The project sunricer overlay is for any ebuilds of any kind. It is not focused on anything, what-so-ever, and has had many arguments against its use for many reasons. In the future, if you're going to try to use someone's project as an argument against them, at least try to come up with an argument that works. Using a focused overlay as an example of why a massive, bloated, free-for-all overlay should exist isn't exactly helping your argument, but instead helps mine. Thanks for making my work easier. =] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] client+server packages - build which one?
Patrick McLean wrote: finger, telnet and ssh are probably other candidates. (though not too many people set up boxes without a ssh server these days). ++ to this, I have always found it a little absurd having dhcpd installed on my laptop just for dhclient. dhcpcd could be a better temp solution =) lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: snipped lots and lots of valid points Well, I am going to do everything within my power to stop it. I will not back down until this project is dead. It really is that simple. *golf-clap* -- Andrew Gaffneyhttp://dev.gentoo.org/~agaffney/ Gentoo Linux Developer Installer Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 11:01 +0100, Edward Catmur wrote: Hmmm. I think an overlay does have some advantages there ... Advantages? With bugzilla I: search for the bug, cc myself on it, download the relevant files, look over them, note a style error, try to merge it, fix a compilation bug, re-upload the fixed ebuild and patch to bugzilla with a comment to the ebuild author on their mistake. When an update hits my inbox I can go directly to the bug... With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? This seems like *raising* the barrier to entry to me... Thank you. This explains my point about no longer having a definitive place to look for things much better than I did, and from a user point-of-view no less. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Portage-2.1 released
Wernfried Haas wrote: On Fri, Jun 09, 2006 at 12:12:31PM -0400, Alec Warner wrote: Portage-2.1 final is released, Congrats to the portage team! While i'm at it, may i ask which files are affected by these changes / which docs i missed to read? * config files as directories enabling more flexible settings management. /etc/portage/package.mask/* fex, assuming I am remembering correctly. Then you can maintain: /etc/portage/package.unmask/xorg /etc/portage/package.unmask/paludis /etc/portage/package.unmask/... you get the picture? Oh, and -U has finally been killed :-) cheers, Wernfried -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 12:33 +0200, Jakub Moc wrote: well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? A subversion repository was built for this. However, if you took the 3 seconds to *look* at the repository, you would see that it is actually an overlay for *all* of the vmware stuff. Then again, I guess it is just easier to ignore the facts and use things as you wish in an attempt to strengthen a weak argument. Of course, this is also an example of how a repository with an actual defined goal can bring on developers, since Mike is now a developer and a part of the VMware team. So again, I thank you for strengthening my position, while attempting to support your own. If you keep this up, I won't even have to reply anymore. ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? If the overlay were using a decent distributed SCM, you would get your fixes to users by posting your repository and requesting that it be merged in. I was under the impression that all ebuilds in this overlay would already have an associated bug for discussion. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
Markus Ullmann wrote: Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. The problem is that some questions and answers easily get lost in a mailing list. To solve this shortcoming, I am starting to make a FAQ page in the trac wiki: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq We are adding new questions there, if you have some additions, please talk to me and I will add them for you. Thanks, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer: And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. Only when you got FEATURES=collision-protect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer: And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. That is only true, if you have enabled FEATURES=collision-protect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 2006-06-09 at 13:28 +0200, Carsten Lohrke wrote: we do support it security wise, we will be reacting upon security issues. We do have package.mask support in the overlay and we are going to use it. The ebuilds have a quality, repoman is required to be run. Also contributors should be knowing what they are doing - they are submitting an ebuild to the sunrise overlay, it needs to follow certain standards. See, I don't go over this bridge, that an overlay of arbitrary packages, with varying skills and knowledge needed, can be decently controlled with very few people caring and not having a security team backing you up. I couldn't agree more. With the entire security team, plus arch teams, plus package maintainers, plus arch testers, it is *still* a complex job to maintain security in the tree. However, this group thinks that without any backup support whatsoever, that they'll be able to maintain the security of a project with countless contributors of varying degrees of skill and proficiency in writing ebuilds, as well as the security of the packages themselves. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
Am Freitag, 9. Juni 2006 14:04 schrieb Stefan Schweizer: And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. Only when you have FEATURES=collision-protect. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? I think it's an example of how user-friendly is bugzilla... -- Best Regards, Piotr Jaroszynski -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 02:08 +0100, Ciaran McCreesh wrote: On Fri, 09 Jun 2006 02:49:14 +0200 Markus Ullmann [EMAIL PROTECTED] wrote: | No. It clearly says that you would be doing the basic QA checks and | repoman checking on initial commit. You even said it right above | where I commented! | | You're doing some witch hunting here... I said we keep an eye on | non-devs commits. How much do you want to bet that I couldn't sneak malicious code past you? And if you accept that I could do it, you're also admitting that quite a few other random people, some of whom don't share my own ethical objections to such a stunt, could also pull it off given sufficient time and effort... I'd say that it's entirely possibly for some non-dev to sneak malicious code into the tree as is now, just as it will be possible to do in an overlay. It's not like it's particulary difficult to have someone proxy for you, and let's face it, if someone is willing to do so then they probably can't be arsed checking that what they are committing is clean and nice.. I mean, I trust you, right? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What is official?
Everything maintained by the Gentoo project, instead than for the Gentoo project. Stuart Herbert wrote: Hi, One of the issues that the o.g.o project has brought to a head is the definition of what is official and what is not official when it comes to Gentoo. The term is already being thrown about in the Project Sunrise thread; I'm sure it'll come up again in future. It's an issue I think we should discuss and find an agreement on. Personally, I think what makes something official or not is 100% down to who does it. I think something is official if it is done by the project (where a project matches the definition in the metastructure project) responsible for whatever we're applying the label official to, then that's all that matters. So (picking something entirely at random for an example), if the Java project had an overlay somewhere (say, on gentooexperimental.org), because it's their overlay, the overlay is official. Doesn't matter where it is hosted - all that matters is that it is run by the Java project. Equally (because it is the hot topic of the moment), Project Sunrise's overlay would be official because they're a Gentoo project. The way to stop them being official is simply to have the Council pass a resolution to shut down the project. I think the other side of the term official is clarifying the scope of how far something can be official. Using the Java project as an example again (sorry guys :), the Java team can put in place official policies and procedures for what their team does, but that doesn't make them mandatory for the whole Gentoo project. Other developers remain free to form competitive projects, and put their own official policies and procedures in place if they wish. (I hope I explained that last bit properly. What I'm trying to do is keep in mind the terms of the metastructure document, which explicitly allow for two or more teams to be competing with each other). What are the alternatives? If a project's activities are not automatically official, then who gets to decide, and how is that decision made? How can that decision be made fairly, without contradicting the metastructure, and without giving rise to any accusations of 'cabals'? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Peper wrote: well. A couple of examples: http://bugs.gentoo.org/show_bug.cgi?id=122500 And again, you use my project of an example. Perhaps you should try looking at something that actually supports your argument? I think it's an example of how user-friendly is bugzilla... Yeah, exactly... I don't understand where did this idea of me using someone else's own project against himself came from in the first place. *confused* I've merely posted a few examples illustrating that bugzilla and attachments suck big time for new ebuilds' development. Or, why did you switch vmware-server work to SVN if bugzilla is *the* place for all this? Apparently it's not all that great, otherwise you wouldn't have done that. -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=getsearch=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 2006-06-09 at 07:44 -0400, Peter wrote: Firstly, I think it is very clear that anything in sunrise is experimental or not supported in the main gentoo tree. That's fine! I don't think any user who goes through the trouble to set up an overlay would miss that point. You can't go to o.g.o and not see the disclaimers. And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). Anyone who fetches the sunrise overlay would know exactly what he/she intends to do and why. Much different than emerge --sync with keyword x86. Sorry, but if it isn't supported, it doesn't belong on Gentoo infrastructure. Secondly, my bias against a third party repository is perhaps unwarranted. I am sure the bmg site is excellent and the people running it are well-intentioned and experienced. However, that said, as a user, I have a higher comfort level staying in the gentoo.realm. Again, you are *proving* the point on why this would be bad. It would be not nearly as well maintained, yet users such as yourself will have this rose-colored perception that it's from Gentoo, so it must be good. This is the *exact* thing that I am trying to avoid. This will *not* be from Gentoo and it will *not* be good. Thirdly, the opportunity to be able to publish ebuilds that would otherwise languish in bugzilla is very exciting. I think it also gives the bugday people an opportunity to close out bugs. Despite what others have written, having multi-year old bugs is very counter productive. If something has not been fixed in so long, it probably either can't be fixed, or may not even apply anymore. I know this is a generalization, but if a bug was filed against gentoo 2004.3, who knows if it still applies with gentoo 2006.0. Especially if there has been little or no activity. Perhaps there is no activity because the interest is not there? Nobody seems to be taking this into account. If you really think your package should be added to the tree, then add yourself to CC, get your friends on CC, drum up some support in the forums, find yourself a developer to proxy maintain for you. We don't need a dumping ground for abandoned or little-use ebuilds. Personally, I don't see the conflict, or the risk, or the additional work for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is a net positive. If that means the proposed ebuild lives in o.g.o that's fine. Just point users who see the bug over to it. And, if an ebuild proves to be useful, or popular, it's conceivable that it could ultimately find its way over to the main tree. Well, I've done about as good as I can do to point out how it would be additional work and a major risk. If you cannot see it, there's not much else I can do. Luckily, a growing number of official developers *do* see the risks and are taking a stand against this egregious waste of time. As for the more sinister aspects of a rogue ebuild finding its way onto o.g.o, sure that's a possibility. However, any dev could do the same in portage because they have commit access (and the problem may not be caught right away). Moreover, it's possible that an ebuild may be fine, but a particular version of a package tarball could have outright malicious code or an undetected security hole in it that has not been caught yet. That could find its way onto portage too. IMHO, I don't see any more risk to security in o.g.o. Sure, a developer could be a risk, but they've gone through much more extensive checking and testing than some user who submitted an ebuild to a bug. Again, I think you need to consider your audience for o.g.o. The newbie won't be there or be syncing to o.g.o. The server admin probably would not be there either for updating a production machine. I think the main audience for o.g.o. would be the power user, or the wannabe power user or certain project teams, or people with a particular interest or need in a project not hosted on the main tree -- that is people who actively need sunrise's services. You're absolutely right. We need to think of the audience. The overlays.gentoo.org project was touted as a way to foster the community and to help *developers* develop things that might be intrusive to the portage tree, as well as allow for easier non-developer contributions. It was *never* touted as a place where we would allow dumping of half-correct, unsupported, and only marginally quality ebuilds for mass user consumption. And, looking at this from a broader perspective, I see this as a real enhancement to gentoo. Offering an experimental tree for packages not intended or not wanted in the main tree. This is an added benefit, it demonstrates a policy of inclusion, not exclusion. It shows a willingness to push the envelope and give certain packages a home where they would not normally get one. It also shows that we're not concerned with quality or providing
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:12 +0200, Jakub Moc wrote:
Peper wrote:
well. A couple of examples:
http://bugs.gentoo.org/show_bug.cgi?id=122500
And again, you use my project of an example. Perhaps you should try
looking at something that actually supports your argument?
I think it's an example of how user-friendly is bugzilla...
Yeah, exactly... I don't understand where did this idea of me using
someone else's own project against himself came from in the first place.
*confused*
I've merely posted a few examples illustrating that bugzilla and
attachments suck big time for new ebuilds' development. Or, why did you
switch vmware-server work to SVN if bugzilla is *the* place for all
this? Apparently it's not all that great, otherwise you wouldn't have
done that.
See you are just missing the point. He switched it to a VMware specific
SVN repo maintained by people who know VMware inside and out, otherwise
known as the VMware team. There is a HUGE difference between an overlay
with ${random_ebuilds} maintained by a small group who cannot possibly
know all of the ins and outs of every package and their impact on every
architecture and a targeted overlay for a very specific purpose which
only contains ebuilds for which the maintainers have 100% complete
understanding. Targeted overlays maintained by people who understand the
packages in question in totality == good, Catchall overlays maintained
by a few people who cannot possibly (and this isn't meant as a dig
against anyone it's just a fact) understand the implications and
interactions of *all* the packages in said overlay == BAD!
--Dan
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 14:04 +0200, Stefan Schweizer wrote: Carsten Lohrke wrote: You should at least make it visible in bold letters on the overlay.g.o front page, what the conditions of each overlay are and which [EMAIL PROTECTED] address bugs have to be assigned to. Please, do not assume our users being stupid. They know that they are using an ebuild from the sunrise overlay with zero support. They deliberately typed svn co http://overlays.gentoo.org/svn/proj/sunrise/category/application; emerge application Umm... and what if they checkout the entire repository and get something they weren't expecting? I love how you simply just dismiss this possibility as something that either can't happen, or something that won't happen because the users will know what they're doing when they use this overlay. And also there are only applications from maintainer-wanted or maintainer-needed allowed in the overlay. Because packages are not supposed to overwrite files from other ebuilds it is unlikely that they can cause any damage to applications that have not been directly installed from the overlay. Hahahahahahahahahahahaha!! Oh wait... Are you serious? What if it is a library? What if it is an alternative to a library already in the tree? Hrrrmn... plot thickens. Also some warning that an overlay may break the tree or fubar the users system That is not the intention of the overlay. Everyone can help fixing breakage, it is not like with the current tree, where you have apps broken for a few days, weeks or even months because the maintainer is unreachable. With fixes (by users) spread all over bugzilla. Everyone that you happen to include as allowed to actually commit, you mean. As opposed to everyone that can sign themselves up for bugzilla? It is designed to be more open and more easily fixable. Sure. More open then a self-registering system. Gotcha. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 09/06/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote: Chris Bainbridge wrote: There are already loads of semi-official overlays. Besides the stuff actually hosted by gentoo (random example http://dev.gentoo.org/~flameeyes/bzr/overlay/) there are official groups (again, not picking on anyone but exampes would be java, php, webapps...) with semi-official overlays. I don't know if the overlays are actually hosted on gentoo hardware, but when they're run by gentoo devs, publically available, and referred to in forums, bugzilla, mailing lists etc. then that at least makes them semi-official. I don't agree with that semi-official term. We for example have an overlay for the Haskell project. Nevertheless, we consider it the official overlay for our group, but not for Gentoo. So that way we can use it as our sand-box, to play with it as much as we can, and giving commit access to even non-developers, the advantage The Haskell overlay isn't publically available (at least, layman doesn't know about it). That makes it quite different from the semi-official overlays I gave as examples. I really don't know what semi-official means. And our overlay has always been publically available, http://haskell.org/~gentoo/gentoo-haskell/ But we don't have it as a way to offer extra ebuilds. We have it for testing, and experimental works and it has been used as playground for new developers too. Whether something is semi-official or not is all about perception. If people see that a project is run by gentoo developers, possibly formed into a gentoo group, using gentoo resources (bugzilla, forums, mailing lists etc) to discuss and organise, then there will be a perception that the project has some semblance of officiality. I am not against the overlay idea, i like it very much!, and we have been using it successfully in our team. I just don't see the point of having another official portage tree with maintainer-wanted packages as an overlay. Don't you see that what you are asking for is to have another portage tree, but now, with bunch of unmaintained and orphaned stuff, plus the extra sugar of *dangerous* consequences as some developers have already pointed out in this thread? I think we already have LOT of work with only one tree. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Chris Bainbridge wrote: On 09/06/06, Luis Francisco Araujo [EMAIL PROTECTED] wrote: Yes, i agree, writting and maintaining ebuilds is a hard and *time-consuming* task. So if an user can't even take the time to fix a digest, why we should support him officially?. The point is that there are lots of users who are interested in niche packages that no developers use or are interested in. These users have the skills to write an ebuild, and other users of the package have the skills to fix and maintain that ebuild over time. These guys don't mind downloading ebuilds from bugzilla and fixing digests. But there are a larger class of users of niche packages that don't have the ebuild skills, and don't want the hassle of bugzilla and digest fixing. This larger group of users are the ones that would benefit from an overlay. Fine. I highly agree on that, now my question is, why this needs to be officially supported? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 05:42 -0700, Brian Harring wrote: On Fri, Jun 09, 2006 at 08:16:32AM -0400, Chris Gianelloni wrote: On Fri, 2006-06-09 at 02:49 +0200, Markus Ullmann wrote: This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on new bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. I'm sorry, but you're avoiding the question here. How will the bug-wranglers even *know* that this is related to a package in the overlay? They wouldn't. As I ststed *repeatedly* now. The user has not mentioned that they're using pam_skey, as is a common occurrence in bugs. Curious, how will the wrangler know in general? *cough* they won't. I already covered this. If you're going to be a part of the conversation, try to keep up, will you? *grin* You're using a generic arguement against a specific target- iow, apply it to overlays.g.o in general instead of singling sunrise out via it. Except the other overlays are not designed as end-user overlays. They are designed to aid developers. Also, they are targeted at a specific task/goal, as opposed to being a dumping ground for the unwanted and unmaintained. Meanwhile, answer to that one is better bug data for reporting- dump of (random out of the ass example) first level deps, and where they came from (overlay/portdir). I definitely agree that better bug data would help the situation. However, it does not change the fact that this is still a dumping ground. Again, this was something that was *explicitly* stated that overlays.gentoo.org would *not* become, yet here we are. Downside to that data is that slackers will automatically punt the bug if they see non portdir in cases where it's obvious it's an issue in the pkg rather then the deps, but there always is a downside... Most people tend to not punt the bug so much as ask for proof that it isn't caused by the overlay. I know that we have done this in games and it has almost always ended up as something the user has done thanks to an overlay. In the cases where it truly is a bug, we fix it. We're not the first large overlay project, there are other ones out there already and these wrong bugs aren't a new thing arising here... No. You're the first large overlay project that is on official Gentoo infrastructure, even after it was agreed that there wouldn't be something like this. With the non-official projects, we simply don't support any bugs from anyone using them. It's that simple. With this project, you're vying for official status, meaning we cannot do that. This will be an *enormous* time sink for the entire ebuild developer pool. Same for above re: large overlay, realistically, like it or not the general case of N overlay/repo is coming down the pipe. Sure. Doesn't mean I have to support anything but the one and only official Gentoo package repository. Complain all you want, but I became a Gentoo developer, not a $random_repository developer for a reason. Personally, I'd rather see this particular case be handled from the get go as an experiment- lay out from the start the exit conditions for it (if it becomes a dumping ground, out she goes). I'd rather the things that were agreed upon when the overlays project was started were actually adhered to, instead. I guess it is just too much to ask from some people to keep their word. ...and people wonder why Gentoo developers don't trust each other anymore. Reason? Devs/users have been after a true testing branch/repo from day one, if we're doing overlays and people are willing to try and supply that demand, lets get the question answered once and for all (instead of everyone and their mother shooting off about every potential they can think of for why it might fail). Fine. Make a proposal to actually add it to the tree and do it properly. There's no need to have this sort of thing limited to a very small subset of developers who couldn't *possibly* keep up with the workload. Yes, there will only be a few developers and they'll be really busy, especially since they're going to be checking every commit to ensure that there's no malicious code.. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] client+server packages - build which one?
On Fri, 9 Jun 2006 14:10:51 +0100 Roy Marples [EMAIL PROTECTED] wrote: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. A good candidate is net-misc/dhcp as it installs a DHCP client and server. Which makes no sense really, so I'd like to put some USE flags here to show what I want, or not want to build. A quick scan through the use flags show no real consistency, so here's what I propose USE client server client - just build the client - duh server - just build the server - duh client and server OR neither then build both. Doing this by USE flag would cause problems I think; if other stuff depends on the server or the client, you get USE-flag problems with portage dependencies met but the actual dependency not met. We have some of this sort of thing already - which manifests with ebuilds aborting in pkg_setup if they detect that a dependency wasn't emerged with the necessary USE flags. A better approach in this case, IMO, is to split it into two ebuilds - well, three if you keep the existing package as a meta-package depending on both client and server. So you would have: net-misc/dhcp-client net-misc/dhcp-server net-misc/dhcp - empty but for RDEPEND on the above. A similar thing already happens with net-dns/bind and net-dns/bind-tools, which are both built from the same upstream tarball but one installs the server, the other installs just the client programs. Other packages to possably beneift udhcp mldonkey samhain bacula boxbackup Interestingly, many packages have a server USE flag but not a client one - maybe make both a global USE flag? Good idea? Bad idea? Thoughts? Thanks -- Kevin F. Quinn signature.asc Description: PGP signature
[gentoo-dev] Re: Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Fri, 09 Jun 2006 14:15:01 -0400, Chris Gianelloni wrote: Chris, I am not familiar enough about gentoo's hierarchy, politics, or team responsibilities to question your sincerity or authority to say something like: Sorry, but if it isn't supported, it doesn't belong on Gentoo infrastructure. I do think that is a pretty heavy-handed statement though. However, authority issues aside, I would like to respond to your comments. Secondly, my bias against a third party repository is perhaps unwarranted. I am sure the bmg site is excellent and the people running it are well-intentioned and experienced. However, that said, as a user, I have a higher comfort level staying in the gentoo.realm. Again, you are *proving* the point on why this would be bad. It would be not nearly as well maintained, yet users such as yourself will have this rose-colored perception that it's from Gentoo, so it must be good. This is the *exact* thing that I am trying to avoid. This will *not* be from Gentoo and it will *not* be good. I do not understand how ebuilds created by gentoo developers or interested users who may have contributed via bugzilla that are hosted on o.g.o would not be good? My perspective is primarily as a user. However, there are several ebuilds in portage, and one eclass with my name on it. So, I feel that I have the ability to discern between good and bad. I choose to contribute to gentoo because I want to. Some projects will never see the light of day. Others will. However, some bugs have a large following. And to keep those ebuilds in limbo is unfair to those users who are interested. Thirdly, the opportunity to be able to publish ebuilds that would otherwise languish in bugzilla is very exciting. I think it also gives the bugday people an opportunity to close out bugs. Despite what others have written, having multi-year old bugs is very counter productive. If something has not been fixed in so long, it probably either can't be fixed, or may not even apply anymore. I know this is a generalization, but if a bug was filed against gentoo 2004.3, who knows if it still applies with gentoo 2006.0. Especially if there has been little or no activity. Perhaps there is no activity because the interest is not there? Nobody seems to be taking this into account. That's a fair point. However, if there is no activity and no interest, then nuke the bug. Post an announcement like they do periodically on -devel saying Last rites for. and see who comes forward. If you really think your package should be added to the tree, then add yourself to CC, get your friends on CC, drum up some support in the forums, find yourself a developer to proxy maintain for you. We don't need a dumping ground for abandoned or little-use ebuilds. Done that. However, there are some packages that won't ever make it. Like some kernel sources, java and gcc hacks, etc. I don't think the process of committing and ebuild should be a popularity contest. I do not infer that sunrise would be a dumping ground at all. I think that it's a very low chance that every maintainer-wanted bug will get there, don't you? Personally, I don't see the conflict, or the risk, or the additional work for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is a net positive. If that means the proposed ebuild lives in o.g.o that's fine. Just point users who see the bug over to it. And, if an ebuild proves to be useful, or popular, it's conceivable that it could ultimately find its way over to the main tree. Well, I've done about as good as I can do to point out how it would be additional work and a major risk. If you cannot see it, there's not much else I can do. Luckily, a growing number of official developers *do* see the risks and are taking a stand against this egregious waste of time. I've had some conversations with devs personally and on irc. Most complain about how overworked they are or how little time they have. Something like this will remove a burden from their plates. The risk aspect has been covered in other posts far more eloquently than I could (see Christel's post for example). What WOULD be a risk is adding a profile to the main tree with this overlay. snip... Again, I think you need to consider your audience for o.g.o. The newbie won't be there or be syncing to o.g.o. The server admin probably would not be there either for updating a production machine. I think the main audience for o.g.o. would be the power user, or the wannabe power user or certain project teams, or people with a particular interest or need in a project not hosted on the main tree -- that is people who actively need sunrise's services. You're absolutely right. We need to think of the audience. The overlays.gentoo.org project was touted as a way to foster the community and to help *developers* develop things that might be intrusive to the portage tree, as well as allow for easier non-developer
Re: [gentoo-dev] client+server packages - build which one?
On Fri, 2006-06-09 at 14:10 +0100, Roy Marples wrote: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. A good candidate is net-misc/dhcp as it installs a DHCP client and server. Which makes no sense really, so I'd like to put some USE flags here to show what I want, or not want to build. A quick scan through the use flags show no real consistency, so here's what I propose USE client server client - just build the client - duh server - just build the server - duh client and server OR neither then build both. Other packages to possably beneift udhcp mldonkey samhain bacula boxbackup Interestingly, many packages have a server USE flag but not a client one - maybe make both a global USE flag? Good idea? Bad idea? Thoughts? (Yeah, I know, repeating our IRC conversation.) Bug #12499 The truth is that we don't ever want to become like the binary distributions. We don't want to have to have separate client/server/common/devel as it removes many of the advantages that Gentoo has. The default should *always* be to install the package as it was intended from upstream, completely intact. Now, it has started to become a practice to have a minimal USE flag on certain packages that reduces the functionality to the bare client portion. I see no real problem with this, so long as the default is to always build/install the full package. That's my $0.02 on the matter. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Project Sunrice: arch team perspective
On Fri, 2006-06-09 at 15:35 +0200, Stefan Schweizer wrote: It seems like genstef and jokey have completely ignored support from arch teams for this overlay. What are you proposing with respect to arch keywords and package.mask? users are supported to do everything themselves in the sunrise overlay. We are not trying to add any additional workload to your current one. We are in fact trying to make life easier for everyone. Except that you aren't accomplishing this. I have shown lots of points where this will increase workload on an already overworked group of volunteers, yet the proponents of this project are either overlooking them, avoiding them, or simply ignoring them. Do you actually expect us to do anything but close assigned bugs for sunrice ebuilds as WONTFIX? It is more like, explain the users how to fix it themselves, because they can with the sunrise overlay. ...or just mark it as WONTFIX because we won't fix it. It isn't our job to go around policing things that are not in the portage tree. If it was good enough or popular enough to be of concern to us, it would be *IN THE TREE* where it belongs. Why is this so hard to understand? Where else would these bugs go except for arch teams, seeing as we clearly can't assign them to end users who originally submitted the maintainer-wanted ebuilds? These are not expected to be filed as bugs, they should be fixed by the users in question. So now we will have random users also doing work of the architecture team? How about you guys start building the releases, too? I'm sure you'll have a wonderful time with the reiser4/broken-sources ricer crowd out there. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] client+server packages - build which one?
Chris Gianelloni wrote: The truth is that we don't ever want to become like the binary distributions. We don't want to have to have separate client/server/common/devel as it removes many of the advantages that Gentoo has. The default should *always* be to install the package as it was intended from upstream, completely intact. Now, it has started to become a practice to have a minimal USE flag on certain packages that reduces the functionality to the bare client portion. I see no real problem with this, so long as the default is to always build/install the full package. I suppose we should get the server flag on cvs changed to minimal, then. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Re: Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: Everyone that you happen to include as allowed to actually commit, you mean. As opposed to everyone that can sign themselves up for bugzilla? It is designed to be more open and more easily fixable. Sure. More open then a self-registering system. Gotcha. We actually have a FAQ entry about that. See But there is access controls? Why is there access controls? on http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage-2.1 released
On Fri, 2006-06-09 at 11:12 -0400, Alec Warner wrote: Portage-2.1 final is released, RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4] [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup [3]http://bugs.gentoo.org/show_bug.cgi?id=115839 [4]http://bugs.gentoo.org/show_bug.cgi?id=136198 So like... should we put up a news item about this? I think so. After all, it is good PR when something as major as this happens. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] client+server packages - build which one?
On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote: On Friday 09 June 2006 14:10, Roy Marples wrote: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. Thanks to wolf31o2 for pointing out that current policy dictates that we install both by default and the minimal USE flag should be used to stop server only compoment from installing. Not policy (I don't think) but current accepted practice. Should this become a policy? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] What is official?
On Fri, 09 Jun 2006 07:50:27 -0400 Ned Ludd [EMAIL PROTECTED] wrote: Keeping it simple... If it's hosted on gentoo infrastructure it's official. If it's hosted on gentooexp.org/SF/Non infra then it's not official. I think this is the best way to define it. Anything on Gentoo infrastructure has to have broad support from the Gentoo community. Anything elsewhere can do whatever it wants. We could take a leaf from the GNU book, and register nongentoo.org if infra wish to host stuff that is not official (c.f. savannah.gnu.org vs savannah.nongnu.org). Then sunrise could go on overlays.nongentoo.org Official means supported, however supported does not necessarily mean official. Just because some people support something doesn't make it official. For example, if a project is official, then it's not acceptable for devs to just ignore a problem related to the project in stuff that isn't part of the project (at the very least the problem should be referred to the project). What I'm getting at is that officialness can be thought of in terms of the effects it has, how does the way something official is dealt with differ from something unofficial?. My take is that official stuff is something that all devs accept some level of responsibility for. Thus official stuff is supported by the dev community as a whole. If something isn't supported by the dev community as a whole, in that a reasonable portion of the dev community actively discourage it, then it shouldn't be official. Works both ways, of course - official projects need to make reasonable efforts not to cause pain for everyone else. On Fri, 2006-06-09 at 10:32 +0100, Stuart Herbert wrote: Hi, One of the issues that the o.g.o project has brought to a head is the definition of what is official and what is not official when it comes to Gentoo. The term is already being thrown about in the Project Sunrise thread; I'm sure it'll come up again in future. It's an issue I think we should discuss and find an agreement on. Personally, I think what makes something official or not is 100% down to who does it. I think something is official if it is done by the project (where a project matches the definition in the metastructure project) responsible for whatever we're applying the label official to, then that's all that matters. I think this delegates officialness too much. I don't think a project should encourage something that directly contadicts what is official in a broader sense. So (picking something entirely at random for an example), if the Java project had an overlay somewhere (say, on gentooexperimental.org), because it's their overlay, the overlay is official. Doesn't matter where it is hosted - all that matters is that it is run by the Java project. My argument would be that the experimental overlay would not be official for Gentoo as a whole. For example, any problems caused by people using stuff from the experimental overlay (such that returning to the official tree would eliminate the problem) could be RESOLVED/INVALID. We come back to the same thing; how can anyone be expected to maintain stuff against a sea of unofficial overlays? Equally (because it is the hot topic of the moment), Project Sunrise's overlay would be official because they're a Gentoo project. The way to stop them being official is simply to have the Council pass a resolution to shut down the project. With regards sunrise, I think a good solution would be to start it as an unofficial project. If in the long term it proves acceptable to the community as a whole, it could become official. One thing that is a distasteful is the way sunrise is presented as a fait-accompli, when prior discussion on this list had clearly implied (to my mind at least) that overlays.g.o would not be used for such a thing. I think the other side of the term official is clarifying the scope of how far something can be official. Using the Java project as an example again (sorry guys :), the Java team can put in place official policies and procedures for what their team does, but that doesn't make them mandatory for the whole Gentoo project. Other developers remain free to form competitive projects, and put their own official policies and procedures in place if they wish. (I hope I explained that last bit properly. What I'm trying to do is keep in mind the terms of the metastructure document, which explicitly allow for two or more teams to be competing with each other). This is about delegation, which is fine - however I don't think it's a good idea to have two conflicting official positions. With regards Gentoo-wide policy What are the alternatives? If a project's activities are not automatically official, then who gets to decide, and how is that decision made? How can that decision be made fairly, without contradicting the metastructure, and without giving rise to any accusations of 'cabals'?
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 10:05 -0700, Donnie Berkholz wrote: Chris Gianelloni wrote: With an overlay: search sunrice.gentoo.org for the package (no, I don't know category/name), sync that directory (no, I'm not syncing the whole sunrice tree), check it over, note some mistakes, compile it if I feel OK with it, it fails, I fix it - and what then? Where do I discuss the problems? How do I get my fixes to other users, considering the package is devless and the b.g.o bug is out of date? If I open a b.g.o bug, will it be read? If the overlay were using a decent distributed SCM, you would get your fixes to users by posting your repository and requesting that it be merged in. I was under the impression that all ebuilds in this overlay would already have an associated bug for discussion. Initially, yes. What happens once the user gets complete access to the repository, though? Are we going to be keeping people from adding packages without bugs? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote: Markus Ullmann wrote: Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. The problem is that some questions and answers easily get lost in a mailing list. To solve this shortcoming, I am starting to make a FAQ page in the trac wiki: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq We are adding new questions there, if you have some additions, please talk to me and I will add them for you. I have one... What will it take for this project to go away? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] client+server packages - build which one?
Chris Gianelloni wrote: Not policy (I don't think) but current accepted practice. Should this become a policy? I'd say so, since this discussion regularly comes up again, and how we do it is really an expression of the Gentoo philosophy and our differences from a typical binary distribution. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Portage-2.1 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Fri, 2006-06-09 at 11:12 -0400, Alec Warner wrote: Portage-2.1 final is released, RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4] [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup [3]http://bugs.gentoo.org/show_bug.cgi?id=115839 [4]http://bugs.gentoo.org/show_bug.cgi?id=136198 So like... should we put up a news item about this? I think so. After all, it is good PR when something as major as this happens. indeed we should do this. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEiclUMXMsRNMHhmARAqquAKCDOj/tdftL6EvPsXplSGYhQwVPnwCg8Khr aZlG4knJs4fseveWBWispXM= =oJwv -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] client+server packages - build which one?
On Friday 09 June 2006 20:04, Chris Gianelloni wrote: On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote: On Friday 09 June 2006 14:10, Roy Marples wrote: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. Thanks to wolf31o2 for pointing out that current policy dictates that we install both by default and the minimal USE flag should be used to stop server only compoment from installing. Not policy (I don't think) but current accepted practice. Should this become a policy? I think so, as many packages provide such a split and it would make choosing flags a little easier :) -- Roy Marples [EMAIL PROTECTED] Gentoo/Linux Developer (baselayout, networking) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: Initially, yes. What happens once the user gets complete access to the repository, though? Are we going to be keeping people from adding packages without bugs? Absolutely. This is for maintainer-wanted stuff, so it should be documented in Bugzilla and assigned to maintainer-wanted with a special keyword to indicate it's in the overlay. The question is how to come up with some QA tool to enforce this. I don't find this overlay objectionable, assuming it's only used for maintainer-wanted packages. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 09 Jun 2006 20:06:04 +0100 Christel Dahlskjaer [EMAIL PROTECTED] wrote: | I'd say that it's entirely possibly for some non-dev to sneak | malicious code into the tree as is now, just as it will be possible | to do in an overlay. | | It's not like it's particulary difficult to have someone proxy for | you, and let's face it, if someone is willing to do so then they | probably can't be arsed checking that what they are committing is | clean and nice.. I mean, I trust you, right? Huge difference between committing a few things for a person you know, where you have time to review code, and bulk committing random stuff where you don't have time to check anything. That's the deal here -- if a large number of developers can't handle maintainer-wanted, what makes people think a far smaller number can without screwing up? -- Ciaran McCreesh Mail: ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Luis Francisco Araujo wrote: Fine. I highly agree on that, now my question is, why this needs to be officially supported? See Why does this have to be on official gentoo hardware? http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote: Markus Ullmann wrote: Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. The problem is that some questions and answers easily get lost in a mailing list. To solve this shortcoming, I am starting to make a FAQ page in the trac wiki: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq We are adding new questions there, if you have some additions, please talk to me and I will add them for you. I have one... What will it take for this project to go away? I have a counter-question to this: What modifications to the sunrise (not sunrice, btw) project would have to be made to get you to stop actively trying to shut it down? I really don't care if you think the team will be willing to make the changes, list them anyway, please. :) I'm asking because I think that this project is a Good Thing, if it gets handled correctly. I also agree that if it is not handled correctly it can and will be a Very Bad Thing. --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
On 6/9/06, Stefan Schweizer [EMAIL PROTECTED] wrote: Markus Ullmann wrote: Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. The problem is that some questions and answers easily get lost in a mailing list. To solve this shortcoming, I am starting to make a FAQ page in the trac wiki: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq We are adding new questions there, if you have some additions, please talk to me and I will add them for you. I do have a question: If you're allowing just anybody who asks to have commit access to the repo, what guarantees can you give me that they won't commit something deliberately malicious or which will break the entire overlay to the overlay? --Arek -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ
James Potts wrote: I do have a question: If you're allowing just anybody who asks to have commit access to the repo, what guarantees can you give me that they won't commit something deliberately malicious or which will break the entire overlay to the overlay? I have added this to the FAQ: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq#Howareyouensuringthatthereisnob0rken/maliciuscodegettingintotheoverlay -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] herds.xml
On Thursday 08 June 2006 21:08, Brian Harring wrote: One additional to this- the location for the file in the tree *should* be metadata/ - shoving it into profiles is the wrong location (it's not profile data, it's repo metadata). that is the correct location for it but we have no metadata tree tracked in cvs -mike pgpZtoLv6aiaF.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 19:41 +0200, Patrick Lauer wrote: This *will* affect *every* ebuild developer. Maybe you don't realize that taking ebuilds for packages that are _not in portage_ and providing them in a nice bundle does not affect every developer? I'm sorry for the language, but I call bullshit. It is painfully obvious by your response that you've never had a library that is an optional dependency (and one we don't --without durng configure, since it isn't in the tree) cause a problem in one of your packages. Allowing libraries means it can cause breakage. Period. Noone wants to push a new cvs-snapshot of glibc. That so not the point here. Nobody ever said that you have to push a new glibc to cause mass breakage. But having a controlled managed overlay with ebuilds that are now spread all across bugzilla ... that would be a good service to our users. Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. This means it *CANNOT* be left up to a small group of developers to decide without any discussion on the matter. So now we're a democracy where everything needs to be voted upon? Anything this abhorrently stupid doesn't need a vote. It should be cast out on its complete lack of merit, alone. Also, at no point did I ever ask for a vote. Don't put words in my mouth and I'll try to pretend like I care what you say, OK? *sigh* Let's leave that debate for another day ... You brought it up, not I. Feel free to debate it with yourself until you're blue in the face. Yes, now it is easier to check out the ebuilds. More users == better testing. Except that now the developer has to do much more work to get the same information, making it even less likely that he'll bother to pick up one of these maintainer-wanted bugs. s/the developer/I/ You're right... I had that wrong. s/the developer/the developers/ After all, there have been quite a number of people agreeing with me. there are some devs that would prefer this overlay environment. Please don't push your personal preferences as The Right Way (tm) Ehh. Were you an ebuild developer, your opinion might actually count for something when it comes to an ebuild development discussion. By the way, where's the GWN this week? You also completely gloss over the ability of a single rogue user to now compromise countless users with a single commit. And an ebuild on bugzilla has more security? Nope. However, I'm also not proposing that ebuilds from bugzilla automatically get pulled in over some magical overlay that is supposed to fix all of the problems Gentoo's ever had with unmaintained packages. We're just making it easier to use these ebuilds. Also I expect the maintainers to keep a reasonable quality standard. I'm glad your faith in them is so high. My faith in *any* group this small having the ability to watch over a large number of outside contributors simply isn't there. Please come back once you've firmly grounded yourself in the reality that we're a pretty popular distribution, and that makes this project a prime target for malicious abuse. Perhaps if you were responsible for some ebuilds, you've be more cognizant of the implications that a bad commit can cause our users. I am not responsible for ebuilds because I don't trust myself enough :-) That's great. I don't trust you enough, either. ;] That doesn't stop me from giving out access to my server to anyone who has a good reason ... like the Gentoo/HURD repository or the Java overlay. Well, we thank you for your immense self-sacrifice. What this has to do with the topic at hand, I have no idea. That differs from the 20 or so overlays maintained by users how? Let's see. They aren't on Gentoo infrastructure, which means they don't give off any immediate assumption of being official or supported in any way. Hell, go back and look at Peter's response about how he would use an overlay such as this only *because* it is on Gentoo infrastructure. So what exactly was your counter-point again? We have control over sunrise. And hey, if it sucks kill the project with silver bullets, a stake to the heart and two pounds of garlic. I'm locked and loaded. Just don't kill an idea before it is even tested ... Why not? What reason is there to stop me from aborting this brain-dead monstrosity before it claims a single user casualty, let alone our reputation? I would have thought that your involvement in PR would have you thinking better. A reputation is something that takes years to establish, and seconds to demolish. You, of all people, should know that. Having an overlay such as this will tarnish Gentoo's reputation. No :-) What reputation are we talking about? The distro that lags in updates behind others? Yes, we are *so*
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
On Fri, 2006-06-09 at 14:46 -0500, James Potts wrote: On 6/9/06, Chris Gianelloni [EMAIL PROTECTED] wrote: On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote: Markus Ullmann wrote: Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. The problem is that some questions and answers easily get lost in a mailing list. To solve this shortcoming, I am starting to make a FAQ page in the trac wiki: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq We are adding new questions there, if you have some additions, please talk to me and I will add them for you. I have one... What will it take for this project to go away? I have a counter-question to this: What modifications to the sunrise (not sunrice, btw) project would have to be made to get you to stop actively trying to shut it down? I really don't care if you think the team will be willing to make the changes, list them anyway, please. :) I'm asking because I think that this project is a Good Thing, if it gets handled correctly. I also agree that if it is not handled correctly it can and will be a Very Bad Thing. To start with (and mind you this is just my list): 1). At least one member of the project must be familiar enough with each of the officially supported architectures, x86, amd64, ppc, ppc64, hppa, alpha, mips, sparc and ia64, to support any bugs which arise due to arch specific issues. The level of knowledge must be on par with that which is required to join any of the aforementioned arch teams. This is the only way to ensure that arch teams do not experience a higher work load because of this overlay's existence. 2). For a package to be added to the overlay at least one member of the project must be familiar enough with the package that they would be accepted into the team that would maintain the package if it were in the mainline tree if they are not already a team member. This is the only way to ensure that non-arch teams do not experience a higher work load because of this overlay's existence. 3). Teams must have the option to opt-out of participation. What this would mean is if a team opts-out no packages may be placed in the overlay that would be maintained by said team if the package was added to the main tree. 4). Packages cannot be added that are version bumps or bug fixes of packages that are already in the tree. 5). The project must have an active security liaison who's job it would be to ensure that there are no packages in the overlay that have outstanding vulnerabilities. 6). The project must have an active QA liaison who's job it would be to ensure that *all* of the QA standards that are applied to the main tree are also applied to the projects overlay. And the above is just the tip of the iceberg...but satisfy those and I'll give you the rest. The next thing I'll hear is But this is really no different then hosting them on Bugzilla except it lowers the bar for their use... Which brings me to my next point...like it or not the lower the bar for their use the more generally accepted the idea that using the ebuilds in this overlay is officially supported. --Dan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Portage-2.1 released
On Fri, Jun 09, 2006 at 01:55:44PM -0400, Alec Warner wrote: Wernfried Haas wrote: * config files as directories enabling more flexible settings management. /etc/portage/package.mask/* fex, assuming I am remembering correctly. Then you can maintain: /etc/portage/package.unmask/xorg /etc/portage/package.unmask/paludis /etc/portage/package.unmask/... you get the picture? Ah, i see. Sorry for the probably stupid question, but i couldn't find any documentation on it (probably because most search engines don't make much of a difference between /etc/portage/package.unmask/ and /etc/portage/package.unmask - could someone give me a hint where to find it? cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgp6XYwVaeCp5.pgp Description: PGP signature
Re: [gentoo-dev] client+server packages - build which one?
On Friday 09 June 2006 15:04, Chris Gianelloni wrote: On Fri, 2006-06-09 at 17:43 +0100, Roy Marples wrote: On Friday 09 June 2006 14:10, Roy Marples wrote: Some packages provide both a client and a server. As such, users usually only want one or the other - and rarely both. Thanks to wolf31o2 for pointing out that current policy dictates that we install both by default and the minimal USE flag should be used to stop server only compoment from installing. Not policy (I don't think) but current accepted practice. Should this become a policy? i dont think it should ... minimal has a very floating definition and varies widely based on the package -mike pgp70xhe57Py6.pgp Description: PGP signature
Re: [gentoo-dev] last call for xml2 (#116346)
On Thursday 08 June 2006 08:35, Roy Marples wrote: On Thursday 08 June 2006 11:00, Mike Frysinger wrote: On Thursday 08 June 2006 02:58, Roy Marples wrote: On Wednesday 07 June 2006 12:03, Mike Frysinger wrote: you guys have had plenty of time to do this ... so last call before i scrub xml2 from use.desc and repoman starts complaining :P Stable samba-3.0.22 has both xml and xml2 still. tell it to the samba maintainers samba maintainers ^^ :P way to join the party after everyone is already passed out (translation: they already fixed announced it) -mike pgpSSSQgl3OUv.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: Since when was overlays.gentoo.org supposed to even be a service to our users? As I understand it, the goal was to ease development, not to provide an easy method for half-working ebuilds to make it to our user's machines. Our users are our biggest base of testers, and the point of overlays is to develop and test, so of course one of the goals is to get overlays onto users' (testers') machines. Making testing as easy as possible is important. But it should be clear that it is testing, and if the apps were ready for the real Portage tree, they'd be in it. Thanks, Donnie signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] client/server policy for ebuilds
This is the official (hehe) request for comments on making a policy of how to handle ebuilds than can be used for either client or server and how to allow for building client-only. The idea is quite simple. Gentoo's standard operating procedure is to build packages as they were intended and packaged from upstream. This means if the client and the server for a particular package is in a single package, we should build both by default. To facilitate building the client portions only, the use of the local minimal USE flag is allowed. This can be shown in the openldap and dhcp ebuilds. Each package which uses this flag should document what is built when the minimal USE flag is in use, via use.local.desc as it will remove any ambiguity into what is being done. Because of this, I would request that minimal not become a global USE flag, since its meaning would actually be different between some packages, for example, minimal in xorg-server, that causes it to only build the primary server, and not the secondary servers, such as DMX. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Portage-2.1 released
On Fri, 2006-06-09 at 21:17 +0200, Jochen Maes wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: On Fri, 2006-06-09 at 11:12 -0400, Alec Warner wrote: Portage-2.1 final is released, RELEASE-NOTES[1] NEWS[2] BUGS-FIXED[3] STABLIZING BUG[4] [1]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/RELEASE-NOTES?view=markup [2]http://sources.gentoo.org/viewcvs.py/portage/main/trunk/NEWS?view=markup [3]http://bugs.gentoo.org/show_bug.cgi?id=115839 [4]http://bugs.gentoo.org/show_bug.cgi?id=136198 So like... should we put up a news item about this? I think so. After all, it is good PR when something as major as this happens. indeed we should do this. CIA-14 wolf31o2 * gentoo/xml/htdocs/news/20060609-portage.xml: Announce portage 2.1's release. Done. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Fri, 2006-06-09 at 20:32 +0100, Ciaran McCreesh wrote: Huge difference between committing a few things for a person you know, where you have time to review code, and bulk committing random stuff where you don't have time to check anything. That's the deal here -- if a large number of developers can't handle maintainer-wanted, what makes people think a far smaller number can without screwing up? *ding* *ding* *ding* *ding* *ding* We have a winner! What do we have for our winner, today, Dianne? Isn't that nice, a turkey baster! ;] -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
