Re: [gentoo-dev] pkg_{pre,post}inst misusage
Well, you should know that those are because of portage bugs or some portage peculiarity, read the corresponding bugs for example for cups to find out more. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: hd_brummy
Welcome aboard and have a good time! -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Allow upstream tags in metadata.xml (GLEP 46)
That will increase the sync time for all of our users - can we please keep this info out of the sync-tree? I do not see why this is necessary to be in the tree - we can do fine with a webbased database for that. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozextension.eclass last call!
On 12/30/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: > On 12/29/05, Jory A. Pratt <[EMAIL PROTECTED]> wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > Unless there are any major objections tomorrow night I will commit > > mozextension.eclass to the tree. You can find mozextension.eclass at > > http://dev.gentoo.org/~anarchy/eclass . You can also find the firefox > > and firefox-bin ebuilds at http://dev.gentoo.org/~anarchy/ebuilds that > > are waiting to go to be added to the tree which inherit mozextension. > > > Do you mind addressing http://article.gmane.org/gmane.linux.gentoo.devel/34397 You are kidding? It had enough time now. And it was already addressed as the eclass was not added on monday. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] mozextension.eclass last call!
On 12/30/05, Dan Meltzer <[EMAIL PROTECTED]> wrote: > > > Do you mind addressing > > > http://article.gmane.org/gmane.linux.gentoo.devel/34397 > > > > > > You are kidding? > > It had enough time now. > > > > And it was already addressed as the eclass was not added on monday. > > My appologies, time off has been messing with my sense of what day it is :) > > Carry on! But you have a point anyway .. I think we should wait till after the holidays because some people only scan their mail at work. S my proposed merge date is 6th of january provided all comments are addressed till then. Thank you, - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Is the autotools mess solvable?
On 1/11/06, Diego 'Flameeyes' Pettenò <[EMAIL PROTECTED]> wrote: > It's a compromise, we trade perfectly stated deps for a lot of easyness for > devs.. It's not a perfect world, you all know. We do not have perfect depends in portage For example we are missing out all deps in "system" usually. And I do not see a problem with omitting autotools deps, because autotools is in system. Read "Implicit System Dependency" on http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/dependencies/ for reference. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Making the developer community more open
On 3/21/06, Bret Towe <[EMAIL PROTECTED]> wrote: > perhaps having some proxys of a sort that accept patchs and such > from trusted users that would commit fixes to portage would help. > similiar to the kernel format that way users can 'commit'/help out quickly > without having to go thru the long process of becoming a dev That is imo a key feature: Get contributions back to the users easily It doe snot need to be the portage-tree .. but an official user-overlay or contrib-overlay would definitely help to get a lot of people involved. Other projects are providing similar infrastructure with very good results, see the Arch User Repository for example: http://aur.archlinux.org It would be great to have something like that available for gentoo-users. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On 3/22/06, Donnie Berkholz <[EMAIL PROTECTED]> wrote: > This definitely sounds like a fun idea. It would be even cooler if we > were using a distributed SCM on both ends that allowed for easy merging. I think it should be all in a central place possibly saved with GPG-Keys that need to be signed by trusted persons so that someone can get access. Because security seems to be a big problem with a public overlay, but I think with gpg-key-based-access it could work. Also see http://aur.archlinux.org for how arch linux is already successfully doing it. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > Think about it this way, what if we had two competing products in the > tree that do the same thing, with the same file names? We would add a > blocker, no? So what mechanism is there to ensure that there's no > "blocking" issues between an official in-tree project, and these > external overlays that are not in the tree? With the tree, we have a > well-defined policy on this. What policy would we use for the overlays? What about if we just skip your "policies" and let the overlays be a free place where people can handle issues how they think it is right for the specific case and not how $super_dev said somewhere. That is what overlays are about, not? - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Official overlay support
On 3/23/06, Daniel Ostrow <[EMAIL PROTECTED]> wrote: > You can't have it both ways, either they are wholey Unofficial and do not get > tracked in bugzilla at all (something which would have to be made VERY clear > to our users, e.g. a you use it you get to keep the pieces policy, and the > developer or team in question is the *only* point of contact for fixing > things) -or- it is an Official overlay with official support which means it > needs to abide by the rules... I think we need both: An aggregation of unofficial and clearly stated unofficial overlays which are currently in place. And an official gentoo user and developer overlay, where ebuilds have to conform to policy. The difference between official and unofficial: bugs can be on bugs.gentoo.org or not. Then both goals would be met: Access to a gentoo-overlay for non-developers and an aggregation of all gentoo overlays out there. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Sandboxes
On 3/24/06, Alec Warner <[EMAIL PROTECTED]> wrote: > Thoughts on ideas on this somewhat more focussed idea? ( or at least I > think it's more focused :P ) IMO motivation b) is not taken into account enough. You are missing out a general-user-overlay, where the developer adding a user to the access list would be responsible for him. We really need a general user overlay for stuff that is abandoned in the treee ([EMAIL PROTECTED]) or stuff that has not even been added to the tree ([EMAIL PROTECTED]). Those are ebuilds that no developer is interested in, so a general way for users needs to be present to be able to take care of those in a policy-based-overlay instead of bugzilla. Also the overlay will be easier to access and more bug-free as every person who is trusted by gentoo-devs can just fix bugs that come up without spamming every CC: on the list as it would be in bugzilla. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] questionable usefulness of virtual/pdfviewer,psviewer
I think you are right, remove it. - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] who renamed adsl-start to pppoe-start and why
On 3/31/06, Jürgen Schinker <[EMAIL PROTECTED]> wrote: > > how ca i make sure that i am informed earlier about such changes? > when has it been renamed exactly, any specific versions? For rp-pppoe I can tell you that it has been deprecated in favour of ppp doing the same job. Have a look at /etc/conf.d/net: # ADSL # For ADSL support, emerge net-dialup/rp-pppoe # WARNING: This ADSL module is being deprecated in favour of the PPP module # above. I added gwn-feedback to CC Maybe gwn is interested in informing gentoo users about this change and the deprecation of rp-pppoe, which has already happened some itme ago? - Stefan -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Renewed security risk uhm Dev
On 4/4/06, Danny van Dyk <[EMAIL PROTECTED]> wrote: > It is a personal pleasure to announce that Stefan Cornelius, > one of the Operation Lead Developers of the Gentoo Security Project > has passed all necessary quizzes to fiddle with the tree. Congratulations! Now, finally I can tell the security guys to fix their bugs themselves. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: xorg-server 1.0.99/1.1 ABI break
Donnie Berkholz wrote: > The drivers cannot be upgraded until a newer server is installed. So > technically, this would allow things to work by forcing people to > unmerge all their drivers before upgrading, then remerge the new > versions. That's not a very desirable solution either, but do you think > it's the best one? just use a PDEPEND, it has been made for issues like that :) - Stefan pgpUl5K2895p7.pgp Description: PGP signature
[gentoo-dev] Re: nxserver-freenx-0.5.0 to be masked
Stuart Herbert wrote: > nxserver-freenx-0.5.0 is in the ~arch tree by mistake. It will be > masked just as soon as my DSL connection stays up long enough for me to > cvs up. What is the reason for the mask? Modular Xorg incompatibility in nx-x11? I guess "testing" does not really count after two months in ~x86 By the way masking something afterwards is bad habit because it will cause downgrades. Downgrades can be harmful because they can cause bugs to come up again that have been fixed in the latest version. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Maintainer wanted for app-text/pstotext
Do we really need this package? There is ghostscript: /usr/bin/ps2ascii as well as: /usr/bin/ps2pdf + poppler: /usr/bin/pdftotext Does that replace the functionality? - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] et_EE locale and language of error messages
Hi, there are at least two problems with how portage currently handles locales: - Firstly some packages fail to build with obscure LC_* settings The continuous stream of et_EE bugs is annoying: http://tinyurl.com/jsqzb - and secondly I get my gcc output in german when I have a german locale set. This makes it really hard to report bugs or the bugreports are useless for most developers that do not understand the language. Those problems cannot be easily workarounded since portage does not use LC_ALL and LANG settings from /etc/make.conf I propose to have the portage build environment set the language to English or LC_ALL=C by default. That would significantly reduce the bugs with unreadable error messages+ solve all the et_EE bugs at once. One problem could be that packages depend on LC_* to install the correct language. But that is a real bug then in my opinion, because ebuilds should only honour LINGUAS and not LC_* during build time. Those bugs should be detected and fixed. What do you think? LC_ALL=C in portage or not? - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: et_EE locale and language of error messages
Marc Hildebrand wrote: > Otoh LC_ALL=C could help if you intend to use a .utf-8 locale as root, > though. So if it does help solving bugs and causes no trouble, why not. ok, we have prepared a patch now, so everyone can have a look at it. http://dev.gentoo.org/~zmedico/tmp/portage_lc_all.patch the default LC_ALL=C will be overwriteable by PORTAGE_LC_ALL= in make.conf. Of course broken settings like et_EE will not be supported. If no other objections come up against patch will be added to portage within a day. So, if you have any problem with it, speak up now. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: et_EE locale and language of error messages
Harald van Dijk wrote: > [..] encourages broken packages. > et_EE breakage should be fixed, and slowly but surely is[..] That is your main problem here and I have discussed this in IRC with you and it is true in my opinion that it does not improve gentoo or make the distribution any better to close et_EE bugs as WONTFIX. But the default should be C to make sure everyone can compile their system without an error, and if people want locale output and help with bugfixing they can of course enable it in their make.conf and keep the bugs coming :) Also developers wont have to translate that often or ask for translations when the default locale is C. Developers are more likely to fix a bug quickly if they do not have to ask twice :) Kind regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: et_EE locale and language of error messages
Marius Mauch wrote: > Why does this have to be fast tracked all of a sudden? Because someone took care of it eventually and it will fix all the estonian bugs at once + allow other-LC-people like me to file bugs without having to run emerge again with LC_ALL=C. And I think it should go in as soon as possible to ensure it gets enough testing, when you do not like it you can always overwrite it :) Also I would want to have it in the stable branch anyway because of bugreports by first-time users who do not use the latest version of portage. It is better to add it now while in pre-release phase than after that when it is stable. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New darcs.eclass
There is also a darcs.eclass in the zugaina overlay (available through layman) if you need some more inspiration. I think this is cool and a darcs eclass should definitely live in the tree. Please add it, so that we can start using it :) - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC Maintainer-Wanted Bugs/Cleaning]
Alec Warner wrote: > So we created this awesome alias to put ebuilds that need a maintainer. > Good idea at the time, decent idea still. The problem? We have nearly > 2000 open bugs assigned to maintainer-wanted[1]. I would like to > discuss policy on these. Do we keep them, do we get a group of people > to slowly review and discard them? Do we mind having a ton of things > open like this (a quasi-ebuild db of sorts). Is bugs the right place > for this sort of thing, or can we improve somewhere/how? Discarding them seems not like a good idea to me. I think they are interesting for many users who want to use the software that lacks an ebuild. Also some contributors have invested a lot of time in it. I think those should all be available within an overlay: overlays.gentoo.org There they are downloadable, improveable and we do not turn contributors away by "WONTFIX". Additionally we will not get many dupes once we close an ebuild contribution. People who file ebuild requests have not contributed anything, so I think those can easily be marked as WONTFIX :) Probably it makes sense to have such an overlay on gentooexperimental.org for the time being. So that we can start reducing the 2000 bugs in bugzilla Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Hi, today I would like to propose a few default keywords for removal. They are outdated and no longer needed on current systems: -apm - only very old notebooks use apm -foomaticdb - foomaticdb is only used for development foomatic xml files. SInce most of our users do not develop printer drivers I suggest making "ppds" a default use flag instead. -fortran - Do we really need this outdated language as a default in gcc? -imlib - imlib depends on gtk-1, which imo should not be installed in a default gentoo installation - there should be no legacy depends for a plain emerge kde. -motif - is unmaintained in portage and rather outdated, does not look good. Should not be default for optional interfaces -oss - oss is a legacy audio interface that has been superseeded by alsa in most current installs, a default use flag is no longer needed -xmms - xmms depends on gtk-1 and has been superseeded by audacious/bmpx I would like to make the changes in a new 2006.1 profile, how do I go about that? I think the current profiles should not be touched, since some users may still be using the flags. Any comments/objections - any outdated useflags I forgot? Have a look at /usr/portage/profiles/default-linux/x86/2006.0/make.defaults for the list of current default use flags. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
Chris Gianelloni wrote: > On Mon, 2006-06-05 at 18:03 +0200, Stefan Schweizer wrote: >> -foomaticdb - foomaticdb is only used for development foomatic xml files. >> SInce most of our users do not develop printer drivers I suggest >> making "ppds" a default use flag instead. > > Should we have ppds in the 2006.1 profile, or 2006.1/desktop? printers are not only used on desktops, add it in "profile" please. > >> -oss - oss is a legacy audio interface that has been superseeded by alsa >> in most current installs, a default use flag is no longer needed > > There are *many* applications in the tree that do not use ALSA, but work > only via the OSS emulation. Removing this is a bad idea and it would > definitely be blocked by the games team. Probably half of the packages > that I maintain require OSS capabilities. but they do not require an oss use flag. The point of removing this flag is to remove "optional" oss support. Have a look at http://gentoo-portage.com/Search?search=&use=oss for the useage of this flag. And for your games argument. The games ebuilds from the above list I have looked at, provide both the "alsa" and the "oss" use flag, as do most really. It is not about removing OSS emulation, it is about removing duplicated backends. > > So does anyone have any objections to the others being removed? > (apm imlib mikmod motif xmms) foomaticdb is missing here, I hope you will not forget it -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Default useflag cleanups - discussion status
Hi, so the thread is getting a bit long, I will just summarize the status -apm -foomaticdb -imlib -motif -xmms Those are more or less without objections -fortran - I am dropping this request, seems fortran is meant to be default -oss - apparently people are fighting this one. Flameeyes also brought up in IRC that this can cause arts being selected as a backend instead of oss, which is certainly not desirable. Also some packages might not give sound at all without the oss useflag. All packages with IUSE=oss need to be checked for this and fixed properly. Although some people think it is USEflagspam I am voting for an ossemu use flag here. If you want to help with this effort, we need to create a tracker bug and check [1] 71 packages :) Also there came up a few more suggestions: -mikmod - This came from wolf31o2 and I do not like it. mikmod is used in many games and I think it gives people less hassle to have it as default. The intention of this request is to make use-setting easier, not harder. Please do not remove this flag. -gtk2 - This has been brought up by carlo. And it makes sense although not in the 2006.1 profile. This needs to happen in all profiles and can only happen once all those flags have been removed from ebuilds. So, sorry, but this needs more work and cannot be put in the same request. If you want to help for this, please have a look at [2] [1] http://gentoo-portage.com/Search?search=&use=oss [2] https://bugs.gentoo.org/show_bug.cgi?id=1065602 - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Hi, I have founded a new Gentoo Project for the Gentoo User Overlay. The intention is to give contributors a single place to put their ebuilds - a place where they can be downloaded, updated and be moved to portage more easily than through bugzilla. It is also a good place for users who would like to become developers to learn how to commit and how to not break the tree. You can find the project page as a subproject of the overlays project [1] The overlay is available on overlays.gentoo.org [2] Initially jokey and myself will be working on this. The current focus is to migrate ebuilds from bugzilla into the overlay and to get contributors to commit their changes to the overlay instead of updating the bugzilla every time. Anyone who wants to help, please stop by in #gentoo-overlays @ freenode [1] http://gentoo.org/proj/en/overlays/sunrise [2] http://overlays.gentoo.org/svn/proj/sunrise - Stefan PS: This is an announcement - No flamewars allowed -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Jon Portnoy wrote: > On Thu, Jun 08, 2006 at 09:32:13AM -0400, Thomas Cort wrote: >> On Thu, 08 Jun 2006 09:20:18 -0400 >> Chris Gianelloni <[EMAIL PROTECTED]> wrote: >> > Please keep the games bugs in bugzilla. Making this change is a direct >> > change in games team policy without any prior notice to the games team >> > and without our permission. We have good instructions on our trac wiki page[1] for how to work with the overlay. The bottom of the page, point 6) adresses your problem. > I do not object to the concept of ebuilds in overlays. > > I do very much object to using any gentoo.org infrastructure or > subdomains to do so. If someone is going to tackle that, it should be > done outside of Gentoo proper. We don't need to be stuck maintaining and > supporting a semiofficial overlay. This is a problem, that we are working on, see [2] It is obvioous to see if an ebuild comes from an overlay or not with that change. Due to the good metastructure and project support in gentoo it is possible to have most of the overlay-work done in the projects [3] and [4] [1] http://overlays.gentoo.org/proj/sunrise [2] http://bugs.gentoo.org/136031 [PATCH] Display a warning when an overlay-ebuild fails [3] http://www.gentoo.org/proj/en/overlays [4] http://www.gentoo.org/proj/en/overlays/sunrise I am still against the idea of turning this into a flamewar. Better no comments than flaming comments. Please - keep it constructive. Kind regards, - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
foser wrote: > I don't think the problem with maintainer-wanted ebuilds is that they > are crappy, but that there is no dev willing to maintain them and ensure > their quality over time. 'sunrise' (who came up with that name ? cheap > asian poetry attempt) doesn't change that by adding it to an 'official' > overlay. The sunrise name name from Patrick Lauer and I personally really like it :) > > Instead of tackling the real problem -the lack of maintainers to deal > with all requests- 'sunrise' is trying to create a backdoor for > unreliable maintained stuff to enter the tree. Please, you are confusing "overlay" and "tree" here. And yes - I do try to tackle the real problem with this project. I am hoping to teach quite a few people how to write ebuilds and contribute with the overlay. I am already beeing contacted by interested people and it will only help the situation come better. Eventually a few good recruits might be the result of this project Also the sunriose overlay is an attempt to solve the unreliable maintained problem. You see that for example today we are committing a bunch of gcc-4.1 fixes for ebuilds that are obviously "unreliable maintained" in gentoo. The sunrise overlay helps to fix stuff quicker and extends the basis of people that can do maintaining work. Please do not comment on this if you have no real improvements to make and just fell like commenting, "flaming" it. Kind regards, - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
Stefan Schweizer wrote: > ..commit their changes to the overlay instead of updating the bugzilla > every time. it is actually encouraged to update bugzilla when changes are made in the overlay. Here are some more things I found in the current thread: chris > 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. chris > How are > ebuilds going to get from this overlay into the official repository? The people who committed them to the overlay will move them to the tree eventually when they are developers - otherwise any developer can move them if he likes to. Of course taking full responsibility of it, it is also mentioned in the overlay project documentation, that automatic tools for committing to the tree are not allowed. antarus > The point of the > Sunrise project as I understand it is to aid in the development of > ebuilds in maintainer-wanted, such that they may improve and be added to > the tree; as well as to give frequent 'not quite a dev' and 'I don't > have a bunch of time but would like to help' people a place to commit to. Have to agree here :) chris > Why is there access controls? Because we are just following the overlays.g.o standards. There is no actual access controls, because we are not refusing valid requests currently. valid requests = come with a valid change they want to make. carlo > 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. peter > The sunshine overlay nice name :) > Warn users that ebuild in o.g.o come with no assurances whatsoever, and > let the market decide if this is a source worthy of use! That is the plan. g2boojum made some interesting suggestions about how bugzilla could be automatically connected with an overlay - unfortunately no one is working on that. flameeyes 21:38:17 > I would prefer if people would still comment on the bugs when they do some > changes on the overlay so that at least we know that. yeah that is already suggested by the current guide it is useful for maintainers to know about contributors. > eclasses The eclass/ subdirectory has been blocked in the overlay - It is not possible to commit there. If eclasses are needed they need to go through the usual gentoo-dev-review and need to be committed to the main portage tree. - Stefan -- gentoo-dev@gentoo.org mailing list
[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
[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
[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
[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
[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
[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
[gentoo-dev] Re: Re: Sunrise Project -- Sunrise FAQ
Wernfried Haas wrote: > - Ebuild development questions should for example be discussed in > #gentoo-dev-help and I have seen threads about it on > forums.gentoo.org and even helped there. There is no reason why > questions about ebuild writing for the Sunrise overlay should not be > treated equally. > --snip-- > > Maybe i wasn't clear enough in my previous mail (which may be the > reason why it was simply ignored), but while we were taken by surprise > of a new project being announced and no one talking to us about where > this may fit in on the forums, this FAQ entry completely ignores what > i explicitely asked for in the mail above. > If you want to use the forums, that's fine and they are here to help > with problems, but deciding things without approaching us to find a > solution that also fits into our forums structure makes me have > reasonable doubts how this project will integrate into Gentoo. I actually was trying to adress your issues with that FAQ entry, sorry if you feel like I have decided something. Please give me a reasonable rewording if you think my assumption is not correct that this will be treated equally by forums users (I count me in here, that is why I made the assumption). I will of course explicitly forbid any forums activity in the FAQ when you have a problem with that. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: Sunrise Project -- Sunrise FAQ
Anders Hellgren wrote: > What the faq entry didn't say, and what amne asked for in his previous > e-mail was that questions related to ebuilds not distributed as part of > the official tree should be posted to the Unsupported Software forum [1]. Yes > We have neither reason nor desire to treat sunrise ebuilds differently > from other user contributed ebuilds. Yeah, I was just taking ebuild related questions in account. Of course useage questions are only valid in an "Unsupported Software forum" I added: - For useage questions the "Unsupported Software forum" on forums.gentoo.org is the right place - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrise -- Proposal
Markus Ullmann wrote: > 2) Not one large tree but subdirs, one per herd > > to help herds better keeping track of which parts are alive in the > overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be > a netmon/ dir with net-analyzer/specialapp below it. A better solution is mentioned in the FAQ --snip-- I want to see all the ebuilds in sunrise that affect my herd, is that possible? Yes, we have hacked up a script in scripts/create-stats.sh for the moment, that will give you all packages, bugs and CC: sys-auth/pam_skey - bug 55279 - on CC: jakub pam-bugs taviso maintainer-wanted You might want to run it with your herd or maintainer as argument to get filtered output: scripts/create-stats.sh pam-bugs --snap-- If there is real interest in subdirs for other reasons than listing packages by herds I would like to hear them. For the moment we are still discussing everything as mentioned on the wiki: "WARNING: This is currently under creation and review - fundamental changes may still take place" Please work with us in IRC to make it please everyone. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrise -- Proposal
Marius Mauch wrote: > On Sat, 10 Jun 2006 13:37:15 +0200 > Markus Ullmann <[EMAIL PROTECTED]> wrote: > >> Okay, so after figuring out open problems (thanks to kloeri and >> various other people for help here), we now have a resolution that >> should satisfy all involved parties here. This should adress >> dostrow's demands as well. >> >> 1) m-w / m-n requirement >> >> Only ebuilds that are reported to bugzie (valid bug#) and set to >> maintainer-wanted are allowed here as well as maintainer-needed ones. >> >> maintainer-needed are only allowed if they're removed from the tree >> and moved over to sunrise (and thus end up as maintainer-wanted >> again). > >> 5) commit access to the overlay >> >> We implement two levels of commit rights: >> >> 1. As there are people out there who just want to maintain one app for >> start, the ebuild should reach a level that project devs are fine with >> it, then the user is given permission to commit on that single app. An >> automated check makes sure that he doesn't commit anywhere else. If >> violations arise, the access is revoked immediately. >> >> 2. People who contribute good ebuilds over a certain period of time >> are allowed upon decision by project devs to actively help >> maintaining the project. They'll be given commit rights for the >> project then. Same frome above applies here: If we notice any abuse, >> we revoke access immediately. > > One more rule I'd like to see (should be obvious, but better to write > it down): > > People who commit to a certain project/ebuild have to be on the CC > list of the relevant bug report(s) and any important commits should be > documented on the bugs (including the revision of/link to the commit). I have not made it a rule yet to prevent whitespacing and updates for minor changes, also I would like to leave things like that to the people to decide to prevent that too many rules lock us in. How far would you want to go? Update for "I have removed some quotes" for "I have made a version bump"? Currently it is written down as follows: http://overlays.gentoo.org/proj/sunrise/wiki/HowToCommit, point 6 --snip-- 6) For later updates to the package in the overlay it is still considered good style to update the bug and link to the changes, for exmaple: I added some sed calls, it should build with --as-needed now http://overlays.gentoo.org/svn/proj/sunrise/sys-apps/openguru/openguru-1.ebuild --snap-- I think it should be at least changed from a suggestion to a "you need to for updates of .." So,, my question, how far do you want them to go here? - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrise -- Proposal
Peter wrote: > Um, there are numerous "new" not-in-portage-tree ebuilds submitted to bz > which have been assigned to teams. However, they may still languish. They > were assigned by the wranglers, and not improperly. Yet, for many reasons, > the bugs wait. So, will there be a mechanism for a contributor to get an > ebuild uploaded to sunrise in this circumstance? You need to ask a team member then to move them to maintainer-wanted. Usually the teams have no problem with moving bugs over to maintainer-wanted because they know that they cannot maintain everything themselves. > I would also suggest having some sort of review process for inclusion of > m-n/m-w bugs. Some may not have any relevance (i.e. the program is no > longer supported, or the upstream project has been incorporated into a new > one, or the version of dated). Doing a blanket import of m-w bugs could > make quite a mess of things IMO. This is volunteers work and usually volunteers are only moving over the ebuilds they use themselves. We are not doing this in a general way, but on a per-user per-package basis. We do not plan to run any importing scripts. It will only be done if a user or developer is interested in it :) > One of the terrific benefits of sunrise will be the cleaning out of > bugzilla. Nuking open bugs is an especially satisfying experience! Sorry, we are not doing this. We are assigning a bug to every sunrise ebuild to make sure that it can be discussed there and is still easily searchable. > > Lastly, what about user contributions? Will users require some kind of > sponsorship in order to have their ebuilds posted? What will the procedure > be (or did I miss it in one of the hundreds of emails)? see 5) from Markus' email. You just need to have a good ebuild contribution that we can review with you, You will not gain full access but it is a start. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrise -- Proposal
Dan Meltzer wrote: > On 6/10/06, Markus Ullmann <[EMAIL PROTECTED]> wrote: >> 2) Not one large tree but subdirs, one per herd >> >> to help herds better keeping track of which parts are alive in the >> overlay, each herd's ebuilds are grouped in a subdir, e.g. there will be >> a netmon/ dir with net-analyzer/specialapp below it. >> > > If its unofficially part of a herd, then isn't it no longer a m-w/m-n > ebuild? I think you are right, see my answer to the threadstarter to find a solution that works without subdirs. > I think this is a much improved//thought out version of the proposal. > From the looks of things sunrise should never make it to layman > however, because as we all know, anything that makes things more > easily accessible to users is going to be (mis)used by more of them. > From what I understand, you see Sunrise as an overlay for users to > improve their ebuilds because they are insufficient quality to be in > the main tree. If they are of this poor quality, they should be no > where near users hands, this doesn't make sense. We will yet have to see if quality will be that bad. I want some more time to see how the ebuild quality works out before we make it more publically available. > If on the other hand you saw sunrise as a way for more packages to be > available to users due to there being a lack of maintainers, asking > herds to check out ebuilds as part of the proposal seems > counterproductive to the cause. They do not have to. It is just nice to let us know that they would like to see a package in sunrise. > Maybe you should expand on the goal of the sunrise project, what > exactly do you want it to do? The Sunrise Project goals may change, it is not yet running long enough to know about all the effects and the goals. Because of this, I cannot give you an "exact" definition now, sorry. our goals include for example: - encourage users to write ebuilds - get new recruits - make maintainer-wanted ebuild access and development easier - work with users on new ebuilds and explain them what they can do better I think these are working out quite well currently, I hope it helps you. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Project Sunrise -- Proposal
Thanks, I have worked in your ideas and made the +CC and bug-updates clear in the HOWTO. Kind regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrise -- Proposal
Henrik Brix Andersen wrote:
> On Sun, Jun 11, 2006 at 06:53:51PM +0100, Stuart Herbert wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Henrik Brix Andersen wrote:
>> | However, as has been pointed out several times in this thread already,
>> | back when the devloper community agreed to the overlays project it was
>> | also agreed that projects similar to what is now known as Project
>> | Sunrise was not be present on overlays.gentoo.org.
>>
>> Can you provide a reference to this, please? I've been through my -dev
>> M/L archive several times, and cannot find an email where I agreed to
>> this.
>
> Perhaps not in those exact words, I admit. But the general consensus
> in my eyes, and I'm not alone with this view according to other
> replies to this thread, was that the purpose of overlays.gentoo.org
> would be to provide a common place to host project and developer
> overlays - not a place to host Joe User's ebuild contributions (except
> for users regularly contributing to specific teams/herds and
> devs-in-spee). [1] [2] [3]
I think you misunderstand the Sunrise Project. I will tell you why the
Sunrise Project in fact complies to all these rules.
It only hosts ebuilds that have been reviewed by Gentoo developers or
directly committed by "regular contributors" that have taken the ebuild
quiz, we name them "trusted committers". We have not yet fleshed out how it
works, but believe me we are watching the quality of the overlay and we
certainly will not let it rot.
You believe we do not have the manpower for this as you have stated in many
other threads. But currently we are coping well with the ebuild submissions
we get. Additionally #gentoo-dev-help is of big help for us.
All current contributors to the Sunrise overlay take effort to improve their
ebuild skills and listen to our words closely. I would consider them all as
devs-in-spee, I am personally planning to recruit some of them when they
have reached a certain level of ebuild writing. They are all around in IRC
(as noted in the [1]-mail by stuart you referenced).
> You could argue that Project Sunrise *is* a specific project. Fact is
> that nobody at that time could predict that a small group of
> developers would go ahead and create a project with the single goal of
> providing Joe User's bugzilla-contributed ebuilds to end-users through
> overlays.gentoo.org.
The Sunrise overlay hosts many ebuilds that do not have a herd in CC. It
also hosts ebuilds for herds that do not have their own overlay or are not
interested in recruiting new contributors. Herds who wish to work with the
contributor in a different way are already doing that, and we encourage
people to use existing herd/team-specfic infrastructure if there is one.
Quote from the FAQ
--Can I commit everything I like to the overlay?--
Herds could also have a better official overlay for herd related packages.
For example you should not add packages from the PHP overlay or concerning
PHP to the Sunrise overlay, rather ask for access to the PHP or Webapps
overlay and talk to those herds first, depending on where you feel your
package should go.
---
The Sunrise project catches all ebuilds that a specific herd does not have
the resources or interest in catching. We make sure that contributions have
a certain level of QA and are not ignored. As soon as a specific herd/team
wants to work on the ebuilds themselves we remove the ebuild from the
Sunrise overlay.
Our single goal is not to provide Joe User's ebuilds, we have more goals:
- provide a central home for contributed ebuilds that do not (yet) find a
place in the portage tree
- encourage users to write ebuilds
- find new recruits
- make maintainer-wanted ebuild access and development easier
- work with users on new ebuilds and explain them what they can do better
Those are also mentioned on our Project Page[1]
> In my opinion, creating a new project with this purpose should not
> have been allowed.
In what other form should we do something like this in your opinion. Should
we be recruiters or mentors? I think creating a project and listening to
and working in the many comments on the mailing lists was a good idea.
> I fear that perhaps creating the project was just
> an attempt to circumvent the policy of overlays.gentoo.org, which
> states that only project teams and individual Gentoo developers can
> have an overlay on overlays.gentoo.org.
Sorry, how are we circumventing the policy? We want an overlay where more
than one person (me and jokey and the users) work together on improving
ebuilds. This is not sensible to do in a developer overlay. We need a
project overlay.
> It seems that the developers
> who started Project Sunrise already planed to use overlays.gentoo.org
> as a "free-for-all" overlay with no QA and policy checks back when the
> idea of an official overlays project was discussed. [4] [5]
You are making two assumptions("free-for-all" and no QA) that are no longer
true. Those may have been true wi
[gentoo-dev] Re: Project Sunrise -- Proposal
Daniel Ostrow wrote:
>> 3) a yes from herds required, keeping a timeout to avoid bugspam
>>
>> after a comment has been placed on a maintainer-wanted bug in bugzie,
>> there's a grace time of two weeks for herds to either leave a comment on
>> whether they're fine with take over or not. When this time is over and
>> it is assigned to maintainer-wanted, then and only then it is implied as
>> an OK to keep it also in the sunrise project.
>
> I'm 100% against implicit acceptance. If someone from the sunrise
> project wishes to add an ebuild to the overlay they should have to get
> an explicit OK from the team in question.
we are not doing this, because we do not want to put more work on teams that
are overworked anyway. Everything that is assigned to maintainer-wanted in
bugzilla means that it wants a maintainer and has no maintainer. If not, it
would not have been assigned to maintainer-wanted. We are allowed to
maintain packages that want a maintainer without asking anyone. Especially
since we are removing the packages if any other herd shows interest.
> The sunrise project could of
> course keep a list of teams that have given a blanket OK and of those
> that have totally opted out.
There are teams that have made very clear that they are not interested in
other people maintaining there packages. For example the games team does
not assign any bugs to maintainer-wanted. It is obvious to every
contributor that he cannot commit such packages, because they are not
assigned to maintainer-wanted. However it is still possible to ask the games
team to reassign the package to maintainer-wanted in order to get it into
the sunrise overlay. Alternatively we help the contirbutor then to get the
ebuild to quality so that the herd in question can commit it.
> For those teams in between an OK per
> package sought by the sunrise project's team members is needed.
Sorry, I think you are trying to kill our project with red tape. I do not
think it helps anyone to do more work.
> I'm
> sorry but the leg work to track this stuff and get acceptance has to be
> 100% on your projects head.
Yes, it is currently. We are not requiring anyone else to take any action!
You are proposing to ask, that would generate a huge bugspam and require
many people to take action. We do not want that, sorry.
> Your proposal adds a need for me to actually
> look at bugs for packages that I may have no interest in.
no, absolutely not. You do not need to look at any bugs, in fact you are not
required to do anything for sunrise. We are just proposing it might be good
to give us a hint when you have a package that should be added to the
sunrise overlay.
> I don't pay
> any attention to maintainer-wanted now I don't want to pay any attention
> to a subset of that ever.
That is good, and you do not need to. Why do you think that you would need
to do that?
>> 6) QA assurance
>>
>> Of course there are minor issues with the ebuilds, otherwise they could
>> be committed straight forward. Important thing is that it only finds the
>> way into overlaye if the trusted committers (project devs and users who
>> are given permission explicitely, see above) are fine with it.
>> Additional note on arch issues: initially, just ~x86 and ~amd64 may be
>> set. The rest would need successful test reports for other ~arch
>> keywords. Stable keywording isn't permitted at all, there will be some
>> automated check to make sure no one does it (by accident) here.
>>
>> Additional note: we won't start adding this to layman and making it
>> available easier until the QA checks have been implemented.
>
> Erm...no! See that is the thing about item #1 on my list...there is
> nothing preventing Joe User from checking out the overlay and adding say
> a ppc64 keyword or a mips keyword to ${random_ebuild} meaning that bugs
> *will* be generated for arch teams for packages that are not in the
> tree.
I still do not get why there will be bugs generated?
"Nevertheless the overlay ebuilds are mainly from users, thus being
_unsupported_ and _experimental_"
> Also note I'm not talking necessarily about the "Hey, I installed
> ${package} and it broke." bugs because if ${package} isn't in the tree
> bug-wranglers can catch it and off you go...the arch teams aren't
> involved. What I am talking about is "Hey, my ppc64 started doing weird
> things yesterday, ${daemons} are no longer working." having that bug
> assigned to the arch team, and then spending a long time only to track
> down that the user installed some random library from sunrise seven days
> ago and there just happened to be upgrades to programs that took
> advantage of said library in unexpected ways.
Sorry, I think you are drawing a very unlikely situation here. If such thing
ever happens (a library that can be used by in-tree ebuilds) we will of
course add that to the tree. It is not our nor anyone else's intention to
break the tree.
Also the same can happen for in-tree libraries that are not ppc64 and even
for
[gentoo-dev] Re: Re: Project Sunrise -- Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Gianelloni wrote: > On Mon, 2006-06-12 at 15:19 +0200, Stefan Schweizer wrote: > You've broken this one before, so I just want to point it out to you > again. The bug was of course discussed in IRC with the games team and the lead in advance. I wonder why no one of the recruiters insisted in this important step and added the team lead to CC. Anyway, I am sorry for not adding the team lead explicitly to CC, my excuses, this breach of policy was not intended. > Anyway, I'm just reminding you > to make sure that the team wants/needs help before you go recruiting > people for a team you're not even a member. It'll make things much > smoother and you'll get much less resistance. Thank you very much :) But imo contributors who aim to join a specific team are usually recruited within that team. Usually there are specific project overlays then. Currently it looks like sunrise-users would join without becoming part of a team. Very valuable comment indeed, thanks. I will take that into account when I file my next recruiting-bug. - - Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEjYdONJowsmZ/PzARAr01AKCE9DJPPfd65W4zCFjmXYUw1KGIqgCZATFg 5IoKFUahr3E+DHAyDGju9a0= =aN5C -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: A heretical thought? Blessing project sunrise as an almost-fork.
Grant Goodyear wrote: > Over the years we've had a fairly consistent stream of suggestions that > we should open up the e-build maintaining process to users instead of > just devs. The main arguments against it are the security issues and an > expectation that it would add to developer workloads. The former is > certainly a real problem, although signing (assuming a reasonable > web-of-trust) could mitigate that some (at least we'd know who to > blame). The latter, however, is conjecture, and the only good way to > verify it would be to actually try it and see what happens. Oh, and > there's also a very real fear that if things go horribly wrong, that > Gentoo's reputation would suffer quite badly. Perhaps I'm naive, but I > tend to think that if we were to advertise project sunrise as > experimental, temporary, use-at-your-own-risk, and > might-break-your-system, That is already done. > and even put it on hardware without a > gentoo.org address and add Sorry, we cannot do that. gentoo.org is an essential part of Sunrise and even the reason it came into existance. Looking at the project page [1] I can see multiple goals that would become hard if not impossible on non-gentoo hardware. "provide a central home for contributed ebuilds that do not (yet) find a place in the portage tree" It is hard to make it look like a central place if it is not on .gentoo.org "get users to contribute their ebuilds to "gentoo" instead of a third-party overlay" This is particularly important to me, because I have delt with users having problems with overlays. If the overlay-maintainer is unreachable and the overlay is broken it harms gentoos reputation even if the overlay is not on gentoo hardware. Overlays should be on gentoo as much as possible so that we are able to fix breakage. Users will not contribute or will be hard to persuade for a not gentoo.org overlay. > a portage hook that warns whenever the > project sunrise overlay is used, This came up already at the beginning of Sunrise and has of course been taken care of [2} > then our reputation isn't really likely > to suffer even if it's a complete disaster. Sorry, I cannot see how this could turn into a complete disaster. It is all controlled, controllable and access can be restricted, removed, it can be modified, .. because it is on .gentoo.org even infra has the ability to shut it down if things go bad. [1] http://www.gentoo.org/proj/en/sunrise [2] http://bugs.gentoo.org/136031 Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: Project Sunrise thread -- a try of clarification
Mike Frysinger wrote: > On Friday 09 June 2006 15:01, Stefan Schweizer wrote: >> 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 > > umm, that should of course read "are" instead of "is" ... > -mike I picked that up from wolf31o2, 08 Juni 2006 18:27:47: ".. Also, who is going to control access to this resource? Why is there access controls? .." Seems I was wrong in thinking the native knows the language better ;) Well, I will change it as soon as possible. Currently all the wiki and avn are locked until the council meeting. Thanks for the comment. -Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Sunrise: way forward, semi-official, review
To my fellow developers and users, with the council meeting not much has changed for Sunrise: "Sunrise is still suspended/closed in overlays until the details can be hashed out" And that is what we are doing now. We have moved the overlay to gentoo-sunrise.org to analyze, improve and hash out the details. So the Sunrise project is now "semi-official". While being an official Gentoo Project run by Gentoo developers it is not currently hosted on gentoo.org. We have also implemented review and added the overlay to layman. It works like follows: - users are only able to commit to sunrise/ - developers merge the commit to reviewed/ when they are happy with it review/ is what is available in layman. Adding ebuilds from bugzilla is regaining speed and we are looking for new developers and users to help this project grow. Just drop by in #gentoo-sunrise if you want to help reviewing or have comments and suggestions. Kind regards, Stefan Schweizer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] embedded overlay on overlays.gentoo.org
Hi, solar has requested an account on overlays.gentoo.org for the embedded overlay for you. Your password: DX7wnSe40Y Kind regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: embedded overlay on overlays.gentoo.org
Seemant Kulleen wrote: > On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote: >> Hi, >> solar has requested an account on overlays.gentoo.org for the embedded >> overlay for you. >> Your password: DX7wnSe40Y >> >> Kind regards, >> Stefan >> > > Was the list the intended recipient of this? > no, of course not. I wonder how it ended up there - the password is changed and mailed to the right recipient now :) Probably we should move to a key-based system for committers that are already developers? - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: embedded overlay on overlays.gentoo.org
Ned Ludd wrote: > On Sat, 2006-06-17 at 18:04 +0200, Stefan Schweizer wrote: >> Hi, >> solar has requested an account on overlays.gentoo.org for the embedded >> overlay for you. >> Your password: DX7wnSe40Y > think you can change my pw and lets do this offlist? lol, you have not read accurately. The account was requested by you, it is not your account :) - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
Hi, with kde4 approaching and the new Qt-4 being in the tree we suddenly see the same problems that gtk had with the gtk2 flag again. I am currently using the flags that way: [ebuild R ] app-text/poppler-bindings-0.5.3 USE="cairo gtk qt qt4" 0 kB so qt = qt3. Now that scheme will sure break when people start using the qt useflag for applications that only use qt4. Now cardoe thinks a qt3 useflag would make sense to disable qt3 support easily: sys-apps/dbus-0.62 USE="X gtk mono python -qt3 qt4 -debug -doc" 0 kB I do not think it there should be different useages of the qt, qt3 and qt4 useflag all over the tree, so there are a few options: 1) enable qt4 and qt3 by default when both are possible, and merge the qt4 and qt3 useflags currently in the tree into one qt useflag. What we lose here is use.masking qt4, I think this will only be an option when qt4 is marked for all architectures that qt3 is marked for. 2) use qt for qt3 only and a special qt4 for qt4. This is what I did originally and it makes sense if done right. However when paackages with qt4 start using the qt4 useflag you can no longer do USE="-qt" to disable qt3 and the concept breaks. 3) split the qt flag into a qt3 and a qt4 flag. This allows users to specifically pick qt3 or qt4 and the flag meanings are obvious - downsides are it is a lot of work. 4) do nothing and happyly use the qt useflag for qt3 or qt4 as well as sometimes a qt3 useflag or a qt4 useflag, just how the maintainer likes it :) This is also not that bad since we do not need to set any rules here. But it might be confusing and makes it impossible to disable all qt3 uses or all qt4 uses Currently we are at 4), should we change anything? Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis wrote: > I would personally like to stay with just the "qt" use flag. The use flag > will be for support of whichever version of Qt is supported (v3 or v4) for > the particular emerge. > > In the cases where more than one version is supported, it should be for > Qt4 only. The Qt3 version should be a separate emerge. For example, in > the case of the poppler bindings, there should be a poppler-bindings-qt3 > package. The problem here is that a user cannot just say at one point "I do not want any more qt3 packages on my system". He will need a big /etc/portage/package.use list to do it. That is the same problem I currently have with gtk1 - I would like to avoid it for qt. Considering we only have 36 packages [1] with a qt useflag it will be fairly easy to convert them to a qt3/qt4 version system that makes sense to everyone and allows easy enabling/disabling of only qt3 or qt4. [1] http://gentoo-portage.com/Search?search=&use=qt this scheme also allows some people to disable qt4 just with USE="-qt4" and mask it. Any optional qt4 interfaces wont be built then. With only a qt useflag this would require a package.use list again. Can we think about it again? 36 packages is less than half what currently still uses gtk1 in the tree. Doing it right for the users is better than doing it easy for the package maintainers. Thanks, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
Caleb Tennis wrote: > On Tuesday 20 June 2006 12:40, Stefan Schweizer wrote: >> Hi, >> >> with kde4 approaching and the new Qt-4 being in the tree we suddenly see >> the same problems that gtk had with the gtk2 flag again. > > I think there's a lot of good thoughts surrounding how to handle this. > There are 2 categories of packages we need to concern ourselves with: > > 1) A package can optionally add support for Qt3 or Qt4 (such as dbus). > qt3 and qt4 is being used there already and it is obvious > 2) A package requires either Qt3 or Qt4 (both not both?...such as > x11-libs/qwt-5). qt3 - enable optional qt3 support qt4 - enable optional qt4 support when both are possible its the maintainers decision, would look something like this: qt4? ( =x11-libs/qt-4* ) !qt4? ( qt3? ( =x11-libs/qt-3* ) Why you ask? Because a user does not care if packageX uses qt3 or qt4, he just wants to use it. But why do we have two useflags then? Because the user should be able to disable optional support for either qt3 or qt4 or both for every package. Disabling all optional qt4 support is only conveniently possible with a qt4 flag. Same for qt3. We need separate flags here, otherwise you can just use one flag for everything, it does not make sense to have two flags when one cannot be used because the other is ambiguous. > Solution: Build against qt4. If you want to provide the same package for > the qt3 version, add a new package to portage I suppose. This "add a new package to portage" is not really the gentoo spirit of following upstream tarballing, in my opinion. > In the end, this is just merely suggestion. I think each maintainer > should come up with the best way to handle the situation unless someone is > going to GLEP this. We have 36 qt-use-packages, so we could have 36 different flags in the end ;) Trying to reach a consensus on the mailing list is a better idea imo. > I think we should, however, do our best to avoid a situation where we have > some ugly combination of USE="qt -qt3" or USE="qt4 -qt qt3"... right you are. And since we already have a qt3 and a qt4 useflag in the tree it is a good move to do this right. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] documentation update: emake install instead of make install
Hi,
I am referring to this thread here, please make sure you read it in case you
have not already:
"parallel fun in src_install - going beyond the serial monotony of 'make
install'"
http://thread.gmane.org/gmane.linux.gentoo.devel/38901/focus=38901
Since nobody has objected there I would like to update the documentation to
reflect this change. I have attached a patch to do this for skel.ebuild and
sent a patch to plasmaroo for the devmanual. Is there any other
documentation that needs updating?
- Stefan Schweizer
--- /usr/portage/skel.ebuild2006-06-20 20:05:18.0 +0200
+++ skel.ebuild 2006-06-22 17:43:00.0 +0200
@@ -134,23 +134,27 @@
# anything outside of DESTDIR; do this by reading and
# understanding the install part of the Makefiles.
# This is the preferred way to install.
- make DESTDIR=${D} install || die
+ emake DESTDIR=${D} install || die "emake install failed"
+
+ # when you hit a failure with emake, dont just use make. It is
+ # better to fix the Makefiles to allow proper parallelization.
+ # If you fail with that, use "emake -j1", still better than make.
# For Makefiles that don't make proper use of DESTDIR, setting
# prefix is often an alternative. However if you do this, then
# you also need to specify mandir and infodir, since they were
# passed to ./configure as absolute paths (overriding the prefix
# setting).
- #make \
+ #emake \
# prefix=${D}/usr \
# mandir=${D}/usr/share/man \
# infodir=${D}/usr/share/info \
# libdir=${D}/usr/$(get_libdir) \
- # install || die
+ # install || die "emake install failed"
# Again, verify the Makefiles! We don't want anything falling
# outside of ${D}.
# The portage shortcut to the above command is simply:
#
- #einstall || die
+ #einstall || die "einstall failed"
}
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Qt use flag recap - qt3 and qt4 as default?
Caleb Tennis wrote: > 2) Remove qt use flag, and create qt3 and qt4 global flags. It allows proper use.masking. Thanks. > people who are in favor of #2 have volunteered to do the work to implement > it as well as put qt3 into the use.defaults for 2006.1 so KDE will work > "out of the box". What should happen to qt4? I think it should be in make.defaults because qt is in make.defaults. So initially we need to do for make defaults: s/qt/qt qt3 qt4/ I would like this to happen retroactively for all current profiles so that no one gets broken when we migrate all ebuilds. After the conversion the qt use flag can be removed from the profiles. waiting for qt3 default flag to migrate my ebuilds :) Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [experiment] Sunrise try 2
Luca Barbato wrote: > Edward Catmur wrote: >> On Sat, 2006-06-24 at 13:05 +0200, Luca Barbato wrote: >>> (from critics) >>> - What is wrong with the model (each point 2 lines at least, 4 at most) >>> - What you'd do as alternative as the criticized point ( 2 lines again) > > Let me reformat a bit >> > > Critic 1 >> * Simplicity: The FAQ claims that Sunrise is simpler than Bugzilla. It >> is - for users. Contributing is a lot more involved than with Bugzilla; >> Sunrise is supposed to be about making contributing easier. > > Reply 1 >> - Admit this in the FAQ. Where possible, write svn wrappers to make the >> contributing process easier. I have added something to the answer in question, if it does not go far enough I would appreciate a better rewording from you :) "But in contrast to that it requires more knowledge and tools to get something into sunrise - more work for contributors. Also contributors have to get their ebuilds reviewed before committing - bugzilla is easier here." For wrappers: I am working on a svncommit.sh to generate the digest and svn commit the ebuilds. This is certainly high on the TODO list :) > Critic 2 >> * Security (from malicious contributors): Glad to see layman will only >> track the reviewed/ tree; still, anyone who checks out the sunrise/ tree >> (and has it in PORTDIR_OVERLAY) is vulnerable. > > Reply 2a >> - Remove from the examples any suggestion that one should check out the >> whole tree when contributing. A contributor needs the whole tree, because of the scripts/ and the profiles/ directory as well as skel.ChangeLog. For 2b I have added an explicit warning, I think it covers this as well. > Reply 2b > - Point out that one should not svn up sunrise/ as part of updating > Portage. right, I added the following: "The copy of the sunrise you will checkout here is '''not reviewed'''. Handle with extreme care. Do not use this as your PORTDIR_OVERLAY! Keep using your reviewed layman copy for PORTDIR_OVERLAY." > > Reply 2c > - sunrise/playground won't let anonymous fetch. Yeah, this is certainly easy to do and increases safety. I have been bugging jokey about this already :) > Critic 3 >> * Conflicts between contributors (technical): Alice adds an ebuild; Bob >> makes a change; Alice makes another change and discovers it conflicts >> with Bob's change in the repo. Alice has not used subversion and doesn't >> know how to resolve conflicts. > > Reply 3a > - People are supposed to learn svn in order to contribute. since we use the IRC channel for contributing, I think this is a non-isssue because devs in the IRC channel know subversion and can help out. Learning by doing is preferred. > Reply 3b > - Tutorials will be provided about conflict resolution see #3a, I do not want to write too many docs that are not often needed and easily explained in IRC. > Critic 4 >> * Conflicts between contributors (social): Alice adds an ebuild; Bob >> makes a (maybe "obvious") change; Alice thinks the change is incorrect, >> and, feeling that the ebuild is her property, reverts the change. A >> revert war erupts. Many casualties. > > Reply 4a >> - Create a social structure to enable Alice and Bob to communicate and >> resolve their differences of opinion. Forums? Wiki? IRC? Bugzilla? I >> would argue there should be One True location for this to occur; not >> bugzilla (bugspam); not IRC (impermanence). IRC is certainly a good and direct way of doing this and it has worked in the past for us, when we already had a similar conflict. Now you say that IRC is impermanent, where do you see the problem, can you elaborate that a bit for me, please? We are open here. Currently there is no forced way of communication - everyone can chose how to communicate himself. > Reply 4b > - ban warmongers. this can always be done, but it is a last resort that is hopefully not needed. Of course when someone behaves badly action will be taken. > Critic 5 >> * More to keep track of: With bugzilla you have a single URL, from which >> you receive threaded email updates. Sunrise adds /two/ svn directories >> plus whatever is used for discussion. >> - Create a summary page that links to bugzilla and discussions, and >> tracks versions and changes, and all other relevant information. Allow >> (require?) contributors to subscribe to email updates from the summary >> page. Yeah, this is also on our TODO list, currently we have a script for that: scripts/create-stats.sh - it currently lists only bug entries and herds, devs on CC for packages in the overlay. A more extensive version of that needs to be put on a web page, right. For updates: Every ebuild-committer is required to CC to the bug, important ebuild updates need to be mentioned on the bug, I think a second update/notification system would be overkill here and leave out people that only use bugzilla. > Ed if you think this doesn't show your ideas please send another using > this format. I changed some things back where I wanted to answer Ed directly.
[gentoo-dev] Re: [experiment] Sunrise try 2
Mike Frysinger wrote: > after looking at some acl stuff i'm 99% sure this can be done ... so can > we get this setup ? > > in fact, gentoo-wiki.com has a section on doing apache2/svn/dav/acls > -mike anonymous checkout is already disabled for some time now: svn co http://gentoo-sunrise.org/svn/sunrise does not work whereas svn co http://gentoo-sunrise.org/svn/reviewed works. I do not know how jokey technically did it, but it was apparently easy :) The website listing the content of the overlay and referring to the bugs and herds probably has to wait after jokey's exams which will be next week. I have made a small svncommit.sh script to make committing easier. But it is probably not complete yet: http://gentoo-sunrise.org/svn/reviewed/scripts/svncommit.sh Need to work on that more with feedback from contributors. Do you have anything else I can do? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Monthly Gentoo Council Reminder for July
Hi, Can we have another Sunrise discussion please? I would love to have some feedback about Sunrise, about our progress and where we are still lacking. Thanks, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: [experiment] Sunrise try 2
Luca Barbato wrote: > Add support for QA checkers clientside and serverside (there are > precommit hooks you can use for that) > > That way we will avoid those smart problems as described in irc long ago. Yeah this is now supported, the script has been greatly improved by shillelagh, thanks go to him. It is now named sunrise-commit. We are always working on improving it, so comments are welcome :) Serverside checks are overkill imo since we check that later ourselves when reviewing. It is also harder to implement in general and especially now because the administrator of the server, jokey, has exams this week. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for July
Chris Gianelloni wrote: > What exactly is there to "discuss" about this? Evaluating our progress with hashing out the details etc. > It is not an official > project anymore, so the council really has no bearing on it. I'm > guessing you would like for it to become an official project. correct. > If I were > asked, some of the things I would bring up are: > What has the existence of Sunrise done for Gentoo? - We have formed a #gentoo-sunrise channel with an atmosphere of help and friendliness - We are teaching many people how to write ebuilds correctly and how to use repoman to check for QA problems, etc. > What new packages > are now in the tree because of it? For example I have added a fix for ftpd and libvc to the tree. I also bumped media-video/dvd-slideshow. Markus Ullman added net-analyzer/wireshark from a sunrise contributor, drchandra, to portage. > What new developers have been > recruited because of it? Recruiting is a long-term goal. We already have a two people that have done the ebuild quiz, one other is working on it. It is like release work: they will be released as developers when they are ready. I do not want "alpha-developers" on the tree. And no, we will not reveal the release date ;) > What packages that were previously without > maintainers in the tree have found maintainers due to Sunrise? I mentioned a few packages above where I fixed bugs because of sunrise people, that does not mean they found maintainers, but people care about it and I can commit their fixes if needed. > I think you fail to see that for something like Sunrise to prove itself > as a viable Gentoo project, it has to actually accomplish some of its > stated goals. Looking up the "stated goals" in the cvs log: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/sunrise/index.xml?hideattic=0&view=markup > encourage users to write ebuilds > find new recruits > make maintainer-wanted ebuild access and development easier > work with users on new ebuilds and explain them what they can do better We have only found potential recruits but at least those four have been reached. > That being said, if the council wants to discuss it, they're more than > welcome to. I just personally feel it wouldn't be time well spent. Not discussing is not a solution either. The last userrel-meeting about sunrise was very successfull. If you want we can make another meeting and talk about it together before the council meeting? I would love that, to hear some more about your ideas for the "stated goals" of Sunrise and get issues sorted out without (perceivedly) offensive mails on the developer mailing list. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Monthly Gentoo Council Reminder for July
Mike Frysinger wrote: > On Monday 03 July 2006 15:41, Henrik Brix Andersen wrote: >> On Mon, Jul 03, 2006 at 03:04:55PM -0400, Mike Frysinger wrote: >> > the entire point of these threads is to address developer concerns >> > to that sunrise can be folded back into Gentoo >> >> Really? According to who? > > presumably the Sunrise guys considering they started the thread > Yeah, this is right. Sunrise is meant to be Gentoo. >> We only just had the userrel + sunrise meeting where the people behind >> Project Sunrise said they would continue the project as an unofficial >> project. > > Stefan would have to comment on this then > Yeah, we got frequent problems with offical/unofficial/suspended or not so much suspended. Consequently to sort out this issue we came to the conclusion to make it fully unofficial in the meeting. It works this way but it is not how I wish Sunrise to operate. It needs to have approval and that is why we discuss Sunrise and improve it constantly. >> Even if they have changed their minds about this, I think it is too >> early to re-evaluate the project for inclusion. > > maybe, but ignoring constant requests for feedback isnt helping anyone > -mike Agreed, and waiting does not help Sunrise either. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007
Mike Frysinger wrote: > - only Gentoo devs may be nominated with that limitation in mind I want to propose some developers that are doing a lot of work to improve gentoo: AllanonJL for his gnome work nichoj for the outstanding java-2 move rl03 for his devdication to webapps antarus for his treecleaners work CHTEKK and sebastian for their php work Thanks, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New USE_EXPAND flag: FOO2ZJS_DEVICES
Hi, As proposed in http://bugs.gentoo.org/show_bug.cgi?id=139987 I would like to add a flag to the foo2zjs printer driver ebuild to select if everything is downloaded or only parts. This makes sense to be done in a special variable. I want to use FOO2ZJS_DEVICES because that seems to be common, I have not seen _DRIVERS somewhere yet and _CARDS does not fit. Any objections? Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: xpdf status
Sune Kloppenborg Jeppesen wrote: > On Wednesday 12 July 2006 16:43, [EMAIL PROTECTED] wrote: >> I really would like to see back the upstream version, what do you think? > The reason for this was security I believe. xpdf code is embedded in lots > of other packages (see http://glsa.gentoo.org for some examples). By > linking to poppler this is fixed in one place. Right you are, the reason is security. > > Though if someone is willing to maintain a vanilla xpdf ebuild I'd have no > complaints. Genstef? > I have no complaints either. If there is exg doing the security bumps and taking care of the upstream version I am supporting it. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
Hi,
This came up in Bug 138792 [dobin etc. should automatically die on failure]
It needs more discussion on the mailing lists.
Some excerpts from the bug: The proposal from Paul Bredbury:
"Hi, I propose that the following ebuild commands themselves *die* on
failure, because the vast majority of the time the emerge might as well be
considered a failure if such commands fail.
dobin, dosbin, doexe"
Jason Stubbs called for consistency .. i.e making doman and dodoc also die
when nothing the file does not exist. A simple workaround in case an ebuild
is broken: [ -f xxx ] && dodoc xxx
SpanKY complained that he cannot set a custom die message then. But this is
not needed here, since every do* command can be clearly identified by the
argument and the directory it will be installed to.
Also as Paul suggested something like that would be possible for a custom
die message:
if [[ -n "${DIE_MSG}" ]] ; then
echo "!!! ${DIE_MSG}"
fi
So, because we want no broken ebuilds and we want consistency I propose to
change this and fix possible problems. They are imo QA problems and should
be fixed.
So what do you think?
- Stefan
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Making dobin, doexe, doins, doman, dodoc die by default
Aron Griffis wrote:
> Stefan Schweizer wrote: [Wed Jul 12 2006, 01:37:44PM EDT]
>> This came up in Bug 138792 [dobin etc. should automatically die on
>> failure]
>
> Since do* would become functions in this case, you'll have to fix the
> few ebuilds that use them on the RHS of xargs.
>
> grep -r --include \*.ebuild -E 'xargs do(bin|exe|ins|man|doc)' .
./local/layman/hanno-xgl/media-libs/mesa/mesa-6.5.1_pre20060620.ebuild: find
${S}/lib* -name '*_dri.so' | xargs doexe
./local/layman/hanno-xgl/media-libs/mesa/mesa-6.5.1_pre20060627.ebuild: find
${S}/lib* -name '*_dri.so' | xargs doexe
./media-libs/mesa/mesa-6.5-r3.ebuild: find ${S}/lib* -name '*_dri.so' |
xargs doexe
./media-libs/mesa/mesa-6.4.2-r2.ebuild: find ${S}/lib* -name '*_dri.so' |
xargs doexe
./app-emulation/vmware-gsx-console/vmware-gsx-console-3.2.0.14497.ebuild:
find man -name \*.\?.gz | xargs doman
> Assuming the list is relatively short, it should be acceptable to
> convert these to something like:
>
> doman $(find man -name '*.?.gz')
I just pinged MattM about vmware-gsx-console, and the x11 guys about mesa
and some minutes ago fixed timidity-eawpatches and speedtouch.
Thanks :)
- Stefan
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo dev]suggestion to distutils eclass
Zhang Le wrote: > Some packages don't provide standard "setup.py". > Take a look at the attachment. > This is a new ebuld. > > So my suggestion is to add a new variable to distutils.eclass, e.g. > SETUP.PY, if it's set, then use it, otherwise let it defaults to > "setup.py". what about making a simple symlink then? This will avoid more code in a general eclass for only very few cases. You can also report this upstream and get them to rename the setup script. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: pybugz - python command line interface to bugzilla
Alastair Tse wrote: > I know there's gentoo-bugger, which is great, but it's in perl and I > couldn't figure out how to modify the output to suit my needs. yeah gentoo-bugger was interactive, this one is better :) I really like it, thank you. > Here's the README attached if you're interested in how it might work for > you to become more efficient when dealing with Gentoo's Bugzilla. I am sure it will make us all more productive! > You can get it either via my portage overlay in: > http://overlays.gentoo.org/svn/dev/liquidx/app-admin/pybugz > or as a python distutils compat tarball in > http://media.liquidx.net/static/pybugz/pybugz-0.5.tar.gz I would love to see this in the portage tree. If you need an ebuild maintainer just tell me :) Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] New category: net-voip
Hi, the herd of voip packages is constantly growing and according to "herdstat -p voip" we already have 60 packages in the voip herd. Those are currently in the categories net-misc, net-im, net-libs, dev-libs and media-libs. Most of them would fit perfectly into a new net-voip category. Those are enough packages to allow the creation of a new category. More important than the current packages I think it is to put new packages into the more precise net-voip instead of net-misc/net-im. For example some packages in my overlay [1] maintained by the fellow gentoo users peper and fuoco. Also there is a lot of stuff waiting in stkn's private voip overlay The 47 voip packages in net-misc and net-im should be moved over to the new category definitely, you can get the list with: herdstat -p voip | grep -e net-im -e net-misc >From the others I think dev-libs/ilbc-rfc3951 should be moved, too. Any objections, problems with the plan, comments? [1] http://overlays.gentoo.org/svn/dev/genstef/net-im -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: making the firefox USE flag a global one
Simon Stelling wrote: > I just noticed that the USE flag 'firefox' is a local one. I think it > should be global, though: Good plan. I think it should also be a default use flag on supported architectures in desktop profiles. Can we make it default at the same time? Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New category: net-voip
Ned Ludd wrote: > Creation of a new categories is fine. pkg moves are bad. > See the countless other posting on this subject of why pkg > moves are bad. yeah new packages is my primary concern. >> Any objections, problems with the plan, comments? > > Sure I'll step up and say I object to the part of your plan which > involves a shitton of pkgmoves. Moving pkgs from existing categories > into another category causes numerous problems that portage can't solve > as easy as the rest of us might think so please just don't do that > part. I've got no objection to the creation of a new category for *new* > packages. I talked with you in IRC about this more. We will do the package moves only when a bump occurs and will make sure that stable as well as ~arch get an updated ebuild. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Removal: net-im/gnomemeeting
Hi, net-im/gnomemeeting is obsoleted by net-im/ekiga and if no objections come up I will remove the old gnomemeeting in 30 days. I package.masked the package for now. see bug 136615 [1] for the removal request. alpha and pcc64 are asked to add their keywords to ekiga. Also the ppc64 keyword is needed to readd the gnomemeeting/ekiga depend to kopete that I have commented out for the time being. Regards, Stefan [1] http://bugs.gentoo.org/136615 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Proposal for a global xinetd USE flag
Matthew Kennedy wrote: > The following ebuilds installed xinetd configuration on my machine > even though I don't have xinetd installed. > > [EMAIL PROTECTED]:~$ equery belongs /etc/xinetd.d > [ Searching for file(s) /etc/xinetd.d in *... ] > dev-util/subversion-1.3.2-r1 (/etc/xinetd.d) > dev-util/cvs-1.12.12-r3 (/etc/xinetd.d) > net-misc/netkit-fingerd-0.17-r2 (/etc/xinetd.d) > net-print/cups-1.2.1-r2 (/etc/xinetd.d) more: # qfile /etc/xinetd.d/ net-fs/samba (/etc/xinetd.d) net-misc/telnet-bsd (/etc/xinetd.d) net-dialup/capi4k-utils (/etc/xinetd.d) Yes, please go ahead and make xinetd a global use flag. It is incorrect to have several local use flags for the same purpose. In /etc/xinetd.d only a small file is installed, so probably making that file optional is not obligatory. Nevertheless it would be cool to use the useflag whereever possible. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: aging ebuilds with unstable keywords - how can we help?
Richard Fish wrote: > On 7/2/06, Daniel Ahlberg <[EMAIL PROTECTED]> wrote: >> Hi, >> >> This is an automatically created email message. >> http://gentoo.tamperd.net/stable has just been updated with 15968 >> ebuilds. > > A question [1] has come up on -user about why some ebuilds take so > long to become stable for an arch. This isn't the old "when will we > have KDE yesterday.3am" type question. In reviewing the above > database, and the OP, it looks like a fair number of ebuilds that > could/should be stable are not. > > Of particular concern to me are packages that: > > a) have no open bugs. > b) are marked stable on some archs, but not others. > c) may have only a single version available in portage. > > As an example, consider net-analyzer/etherape, which is "~amd64 ppc > sparc x86", and has no open bugs (other than a version bump request), > and only a single version available in portage to begin with. > > So my question is: is there anything that interested users can do to > help here? I know we can file stabilization bugs, but I agree with > Robert [1] that this should not be necessary in the normal case. > Besides, do you _really_ want 16,000 new bug reports that say nothing > more than "blah/foo works for me, please stabilize"! Is the problem a > lack of time, devs, arch testers, or interested users? The problem is in the system. Unless you are a developer _and_ part of the arch team you cannot do anything but file a bug and wait and wait and wait until a member of the arch team decides to test the package again for his own and mark it stable. So with the current system the arch teams cannot cover all the packages. I would say for your litle pet package to get stable you have little chances. And you would not want it stable anyway, because stable marking usually lacks behind the bugs of the package. That means you most certainly will hit the bugs and a month later when someone has filed a bug _and_ the package herd or developer has said yes _and_ a developer from the arch team has tested it the bug will be stable, too. As a better system I would like to see packages stable automatically after 30 days and no bugs. But this is probably not going to happen with gentoo so I just stay away from stable and put ACCEPT_KEYWORDS in my make.conf Things you can do for stabilization to go better: - file a lot of bugs and wait - become an arch tester and test packages to recommend them for stabilization. Of course they still need testing by a developer in the team then. - look for developers and ask them to comment on stale bugs to get them solved To get involved the best way is maybe to show up in IRC in the arch team channel like #gentoo-x86. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Project Sunrise resumed
To my fellow Gentoo developers and users, Sunrise is about contributing ebuilds and getting feedback and review while doing so. The main resource this currently happens for is the Gentoo User Overlay of Sunrise and second come ebuilds that get into portage afterwards In last weeks council meeting [1] it was decided that the Sunrise project is no longer suspended. I can give a short overview of the current status of the overlay: - we currently have 154 ebuilds in 58 categories in the overlay not counting the ebuilds that got into portage and were removed again - we have 8 developers, 4 trusted committers who have taken the ebuild quiz and 26 users committing to the overlay The basic project concept of creating a social workspace has been reached. #gentoo-sunrise is an active IRC channel where users usually find help quickly and it also forms a friendly community. Best regards, Stefan [1] http://www.gentoo.org/proj/en/council/meeting-logs/20060720-summary.txt http://www.gentoo.org/proj/en/council/meeting-logs/20060720.txt Other useful resources: Project page http://www.gentoo.org/proj/en/sunrise/ svn reviewed http://www.gentoo-sunrise.org/svn/reviewed/ cia page http://cia.navi.cx/stats/project/sunrise/ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Project Sunrise resumed
Stephen P. Becker wrote: > Eso since when did we have the discussion where you actually > addressed all of the numerous concerns brought forth right before this > project was initially suspended? Do you have any concrete concerns that have not been dealt with yet? I would like to hear about them in that case. I have so far as good as possible implemented suggestions and answered concerns. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] webdav global use flag and default
Hi we currently have both webdav and nowebdav ueflags, this is confusing: # grep webdav /usr/portage/profiles/use.local.desc dev-util/git:webdav - Adds support for push'ing to HTTP repositories via DAV dev-util/subversion:nowebdav - Disables WebDAV support via neon library net-misc/sitecopy:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. This system allows users to collaborate on websites using a web based interface. See the ebuild for an FAQ page. Enables neon as well to handle webdav support. www-apps/open-xchange:webdav - Enable WebDav (Web-based Distributed Authoring and Versioning) support. www-servers/lighttpd:webdav - Enables webdev properties The proposed solution is to make webdav a global useflag and set it as a default use flag to have the same effect as the current nowebdav use flag in subversion. Comments? Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: proxy-dev (an alternative to sunrise?)
Luis Francisco Araujo wrote: > 3 - Users ask on this mailing list if there exist any developer > interested to include X, or Y ebuild into the tree. (Probably we could > create a template for this?) The user should send the ebuild changes together with the mail. Make it look like on LKML including diffstat and the actual diff. This way you can quote and give review comments on the mailing list - visible for everyone. Of course diffing needs a good script so that the user does not have to generate the diff and the stat manually > The user _has_ to compromise to take care of those previous commented > three points that some of us might be afraid of, besides of giving us a > centralized way of keeping informed about new ebuilds. > > The users explicitly compromise to (just to make it clear)[1,2,3,4]: How are we going to reach this? Currently the bugs for ebuilds which have both developer and user in metadata get assigned to the developer and then the developer puts the user on CC. The proposed solution is to put in metadata: maintainer-needed as herd and the user as maintainer. Thus the user can take care of the package but when he leaves or is unavailable it is still considered maintainer-neeeded which means that every developer can take it over or fix bugs. In my opinion it does not matter which developer reviews a specific version bug for a package - so the developer should not be noted in metadata.xml. Of course developers can personally commit themselves to take care of the package and add themselves to metadata too. > This evidently brings some developers responsibilities too, we will need > to review, and test the ebuilds. we sometimes will have to check with > upstream, and comment on the ebuild, or fixing some details. But it > should be a far minimimal effort than the developer taking care of the > package(s) by his own, in the better of the cases, he even shouldn't do > anything but to test, review and commit, from there on, the ebuild will > be under the standard procedures of maintenance (arch testing to > stabilize, bug reports to notify problems, etc). The developer should > also take care of any internal developer communication if needed. "internal developer communication" turns out to be CCing arches on stable bugs. Giving ok to stabilize some new version. This should be done by the maintaining user since he knows the package best. What exactly do you mean with internal developer communication? - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: webdav global use flag and default
Paul de Vrieze wrote: > I'd like to explain why subversion has a nowebdav useflag. Basically one > of the features of subversion is its ability to work over the http > protocol. Many subversion installations use the apache module to serve > subversion (even our own overlay project does). To disable webdav support > would cripple the subversion client. It is something one should only do > when aware of the consequences. right you are. Putting the default useflag into base/make.defaults has the same effect as a nowebdav useflag without being a no* useflag and confusing with other useflags that do not have the no* bit. If there are no objections and you agree with the solution I will make webdav global and default after a week from now and you can remove the old nowebdav useflag. If there are any problems with putting it in base/ for example neon does not work on hardened, embedded or anything else I would like to know about it. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: webdav global use flag and default
Danny van Dyk wrote: > 5 packages, and only one has nowebdav, and you want to make it a default > USE flag? I strongly disagree here. Make it a plain useflag and notify > users of subversion that the behaviour changed. Much better than > informing users of the other 4 packages that the behaviour changed. We have no statistics on this so I cannot prove but I can argue that subversion is used most of all 4 packages. And I can also argue that having webdav on by default will not cause any harm for the other packages, because it just adds and does not remove functionality. It does no harm. Thus having users informed is not crucial here However doing the change in subversion will break current useage cases by reducing functionality. Most users do not read elog messages and just will get broken. I see your problem and maybe there are ways of solving the problem: - change all other 4 useflags to nowebdav, then make the webdav useflag default, then change them all back to webdav. Maybe you are more happy with such a gradual change. - leave everything as is: it does work but I do not particularly like the nowebdav useflag tho it is better than having subversion broken. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: new svncache.eclass
Mark Stier wrote: > See http://bugs.gentoo.org/show_bug.cgi?id=141806 > > Provides caching and release tag support for SVN. sorry - I do not see the need for a new eclass here. Can you please instead modify the subversion eclass and add support for what you want to do? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] repoman: check for deprecated eclasses
Hi, Repoman needs to check for deprecated eclasses, see http://bugs.gentoo.org/141677 As a result of the discussion in the bug, we would like to add $PORTDIR/qa-data/eclass.deprecated to allow to deprecate eclasses properly and make repoman fail. This will allow us to avoid problems with new ebuilds for deprecated eclasses which result in bugs like Bug 141629 dev-util/systemtap-20060325.ebuild uses deprecated kernel-mod.eclass I believe the developer has not known anything about that kernel-mod is deprecated when making that ebuild. Now he ignores the bug and we have that old eclass used again :( Best regards, - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: repoman: check for deprecated eclasses
Carsten Lohrke wrote: > What about revdep-rebuild and > emerge regarding installed stuff and overlays? what do you mean? Please elaborate I have only repoman in mind for now. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: packages going into the tree with non-gentoo maintainers
Kevin F. Quinn wrote: > I don't think it's a good idea for devs to be putting stuff into the > tree without taking responsibility for it. sure I can put myself in there but it will help no one because I cannot test the thing. Furthermore I am actually part of maintainer-needed and commit fixes there. I am also on the maintainer-needed email alias. Also maintainer-needed makes obvious to everyone that they do not have to ask me to fix sth. or take over the package -> less communication overhead. > I would expect that either > the herd is set appropriately (which means either the committer be a > member of the herd, or the herd explicitly agree to be proxy), which is the case here. > or the > committer be listed as a maintainer email address along with whoever is > being proxied. the committer in this case has no interest in maintaining the thing. And for proxying it does not matter who is proxying. > Further I believe bugs against such packages should be > assigned to the @gentoo.org address (proxy maintainer if there is one, > herd otherwise), and CC'ed to the proxied maintainer address. this does not allow the actual maintainer to close the bug and causes a lot of bugspam for a person who does not care about it and should be only contacted in the end to commit fixes/patches/bumps. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Kevin F. Quinn wrote: > Then you should not have committed it - as a dev it is your > responsibility to test any ebuilds your commit. There's nothing > stopping you doing the normal checks on the ebuild, even if you can't > read Hebrew. For example you should verify whether the '-j1' is really > necessary on emake. yeah, I do those tests of course. Had not thought of -j1 though. You are right - it is not needed. Sorry :( >> Furthermore I am actually part of >> maintainer-needed and commit fixes there. I am also on the >> maintainer-needed email alias. > > The point of a herd is to provide a contact for maintenance of the > member packages - and maintainer-needed by definition does not do > maintenance. yup. This is just so I can keep track of bugs filed against it while clearly separating them from bugs for packages which I judge more important and maintain directly. Support is provided by upstream and the user, build-testing/committing/ebuildfixes is provided by maintainer-needed (which is most likely me) >> Also maintainer-needed makes obvious to everyone that they do not >> have to ask me to fix sth. or take over the package -> less >> communication overhead. > > You can put notes into metadata.xml - see other instances for > examples; the easiest way is to have two maintainer entries, and in > the description field describe the maintenance arrangement. Give jeeves and herdstat support for reading notes and I might consider it. What annoys me most when putting myself in is that arch teams will ask me if I would want that stable. I honestly do not care. The annoying thing about it is that I get more than one bugmailspam about it and it also happens regularly for new versions :/ Such things the user should be able to decide himself. > Putting > "maintainer-needed" as the herd just means the package is essentially > unmaintained, and is a candidate for removal. that is what I want to imply by putting it in, you got me correctly. > We should not be putting > stuff into the official tree if no dev has taken responsibility for it. we are not putting new stuff in there, we are just fixing existing stuff so that it does not need to be removed. >> And for proxying it does not matter who is proxying. > > Proxying is more than just "doing whatever the non-dev says". By > committing to the tree, you take full responsibility for those > commits. I do. And if it breaks anyone I will fix it of course. > Whoever does the commit takes formal responsibility for those commits. > Therefore they should take note of bug activity relating to those > commits. If they don't care about that then they should not be acting > as proxy in that case. I do take note of all maintainer-needed bug activity. I do not put in myself to clearly separate those from the other bugs where I am directly maintaining stuff myself. > Surely this is what the Sunrise overlay was for; user-supplied ebuilds > that don't have a a Gentoo dev to take responsibility for maintenance. true. Sunrise is only for new ebuilds however. It is not designed as a place to dump ebuilds from portage to and force users of them to use Sunrise. If you or antarus or someone else wants to remove it from the tree feel free to do so, I am not in metadata, I do not care. I just fixed the bug. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Bryan Ãstergaard wrote: > Ok, let me see if I can get this straight.. You're saying that > maintainer-needed requires less communication overhead compared to > ebuilds with maintainers assigned? And that maintainer-needed is > therefore better than ebuilds having maintainers. agreed. I prefer to fix ebuilds in maintainer-needed than maintained ebuilds because communication takes eternally compared to fixing simple things quickly. >> the committer in this case has no interest in maintaining the thing. And >> for proxying it does not matter who is proxying. > Of course it matters. There's a big difference between a proxy > maintainer having to ask a *specific* dev that's proxying his ebuild > updates/changes or trying to find a random dev willing to help. I will of course commit all fixes when anyone asks me to. But it does not matter if I commit them or anyone else who cares and has access levels. >> this does not allow the actual maintainer to close the bug and causes a >> lot of bugspam for a person who does not care about it and should be only >> contacted in the end to commit fixes/patches/bumps. > Shouldn't matter too much as a gentoo dev is still responsible for the > package? of course he is still responsible. Does not mean he likes to get 10 mails about people asking for stable keywords and arches stabilizing every month. > Nobody shoud be adding stuff to portage without taking > responsibility for it. I am not adding stuff. I am fixing existing packages. And I am taking responsibility. The maintainer can always assign me bugs if he thinks I should take care of them and I read and take care of them anyway because I am on maintainer-needed. - Stefan PS: mailing lists are a bit broken. 3 people answer me and ask almost the same and I answer almost the same again .. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
Paul de Vrieze wrote: > For this stuff, add a comment to the metadata.xml file. Don't do it in > this less than obvious way. arch teams for example will still contact me then for stabilizing, I do not want that. jeeves and herdstat do not support comments and the metadata is not often read directly. > The maintainer must still be someone with a > gentoo email. is that written down somewhere? I was under the impression that it is allowed and have seen it used for example in /usr/portage/www-client/links/metadata.xml - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [GLEP] Bugzilla access for contributors
Hi, as requested by multiple devrel members I have written a GLEP to standardize bugzilla access for contributors. It has already been discussed on the devrel mailing list before but I am looking for a wider opinion now. This is also a submission for the new council when it meets. Best regards, StefanGLEP: 52 Title: Bugzilla access for contributors Version: $Revision: 1.1 $ Last-Modified: $Date: 2006/08/16 19:25:14 $ Author: Stefen Schweizer <[EMAIL PROTECTED]>, Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 01-Sep-2006 Post-History: 01-Sep-2006 Abstract To improve the development flux in Gentoo, we should allow more people to manage bugs in our large bugzilla database. Current situation Currently there are specific deals with arch testers and devrel/infra to allow arch testers to edit bugs. This GLEP is written to standardize the process and make it available for all aspects of Gentoo where work is being done by people who are no full developers. Requirements Bugzilla permissions It is needed that contributors who work on bugs can edit them on their own and do not have to rely on their mentoring or supervising developers to reassign or modify bugs. An example for this has been obvious since the overlays project was established. Bugs for overlays should be filed on bugs.gentoo.org and will most likely get assigned to the developer/herd. This does allow a contributor to fix the bug but only to mark it as fixed in bugzilla when he is also an arch tester. Security - To ensure that not everyone who asks for it can get access to edit bugs it is required to complete the ebuild quiz prior to requesting access Management --- This cannot be managed by recruiters, because they lack the resources to do it. Instead a developer who mentors more people gets access to edit bugzilla permissions and can add people there where he has checked the ebuild quiz. The developer will also take care of removing them again if needed. This reflects current arch tester practice. Copyright = This document has been placed in the public domain.
[gentoo-dev] Re: [GLEP] Bugzilla access for contributors
Elfyn McBratney wrote: > thus that developer can request > write access for them. It's worked like that for at least two > years... I did that and devrel asked me to write a GLEP. If you can show me another way to do it, I would like to hear about it! I have two contributors with ebuild quiz here. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [GLEP] Bugzilla access for contributors
Josh Saddler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Stefan Schweizer wrote: > [. . .] > > Define "contributors" -- is this a special status? If it is, how does one > *become* a "contributor" to get these rights? > > This is potentially a big problem, the way I see it. As the word might tell a contributor is someone who is contributing. No special status involved. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [GLEP] Bugzilla access for contributors
Alec Warner wrote: > C. No real standard on any other fora. I don't need a GLEP to add > someone to my project overlay, or grant them voice or ops in my > project's IRC channel. I don't need a GLEP to get them subscribed to my > mailing list and I don't need a GLEP to add them to (most) project > aliases. Why does this require one? devrel, plasmaroo, asked me to send this here. And hparker wanted me to send it in, too. Cannot really answer that myself, but obviously there is no working solution without a GLEP. I have two users on queue with their ebuild quiz ready. Show me a way to get access for them if you think that this is unneeded! Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: [GLEP] Bugzilla access for contributors
Josh Saddler wrote: > Stefan Schweizer wrote: >> Josh Saddler wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Stefan Schweizer wrote: >>> [. . .] >>> >>> Define "contributors" -- is this a special status? If it is, how does >>> one *become* a "contributor" to get these rights? >>> >>> This is potentially a big problem, the way I see it. >> >> As the word might tell a contributor is someone who is contributing. No >> special status involved. >> >> - Stefan > > Contributing what? Contributing how much? Contributing how long? How is > quality measured? Is there a minimum level somewhere? X amount of ebuilds? > X amount of patches for docs/packages, or donating hardware, or adminning > a webnode somewhere? It does not matter. The real requirement is not to be defined as a "contributor" but to take the ebuild quiz: "To ensure that not everyone who asks for it can get access to edit bugs it is required to complete the ebuild quiz prior to requesting access" -Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: [GLEP] Bugzilla access for contributors
Mike Frysinger wrote: > On Monday 04 September 2006 02:45, Stefan Schweizer wrote: >> Josh Saddler wrote: >> > Stefan Schweizer wrote: >> > [. . .] >> > >> > Define "contributors" -- is this a special status? If it is, how does >> > one *become* a "contributor" to get these rights? >> > >> > This is potentially a big problem, the way I see it. >> >> As the word might tell a contributor is someone who is contributing. No >> special status involved. > > huh ? if contributors dont require special status, why are you proposing > a GLEP ? > -mike they are not defined by their status. I wonder why this word is causing problems .. The status is maybe being an arch tester. This GLEP is not about status, only about giving some people bugzilla access when needed. -stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: [GLEP] Bugzilla access for contributors
Josh Saddler wrote: > Because as much as possible, we need to see something concrete, not "maybe > an arch tester." We need to have a better definition of what "when needed > is" and who these "some people" are -- think about it. Do we want a system > that works like devship, but only halfway -- like you suggested, just > passing the ebuild quiz -- or is something more needed? If it needs to be extended a new GLEP like this one can be written or this one extended. This is only about bugzilla access, nothing more. So no, it is meant to be as non-concrete as possible to allow usage in as many cases as possible. -Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: I'm concerned about a bug (#121142, imagemagick)
Roy Marples wrote: > On Tuesday 05 September 2006 15:18, Sven Köhler wrote: >> There's no comment by the maintainer for a while. I wrote the patches >> that are needed to fix the problem. They work fine as far as i can tell. > > Don't feel too bad - I frequently post patches to bugs reported on the > same day and ask for feedback. Some of which are now over a year old > without any feedback from the reporter. that is why I try to close a bug when commenting something on it. NEEDINFO usually works on those and allows you to clean up your list of inactive bugs. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Re: Re: packages going into the tree with non-gentoo maintainers
Luca Barbato wrote: > Carsten Lohrke wrote: >> On Sunday 03 September 2006 16:36, Stefan Schweizer wrote: >>> I am not adding stuff. I am fixing existing packages. And I am taking >>> responsibility. >> >> How wonderful this sort of "maintenance" is you can read here: >> >> https://bugs.gentoo.org/show_bug.cgi?id=146626 >> >> Am I the only one who has a problem with this? >> > > Genstef PLEASE always contact the related herd before adding stuff. I am part of the kde herd, thanks. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [GLEP] Bugzilla access for contributors
Bryan Østergaard wrote: [..] Adding a bit of structure to it seemed like a good > thing and I'd argue that the small bit of structure have helped keep > the discussion on track. I talked with kloeri in private about this and a GLEP that allows giving out bugzilla access permissions by non-recruiters is not wanted. Because of this we concluded to apply the AT/HT procedure on overlays: "Projects operating on overlays can also recruit herd testers and call them trusted committer. This explicitly includes sunrise which operates on a random mumbo-jumbo of ebuilds." thanks kloeri and request for discussion :) best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Sunrise trusted committers with bugzilla access
To my fellow Gentoo developers, in the Sunrise project we have some users who are ambitious and cotribute more than a few ebuilds. Those regulars have the possibility to take the ebuild quiz and acquire the title "Sunrise trusted committer". Those sunrise committers can use extended bugzilla permissions to edit keywords EBUILD and REQUEST for example in the maintainer-wanted@ and maintainer-needed@ bugzilla region where usually developers clean up litle or have no interest in spending time on. Now I tried to get this done with the "[GLEP] Bugzilla access for contributors" and I was told it is to undefined and misses out the point of removing access levels again. Also I was told that a GLEP for this is overkill. All this is addressed and working with the current arch testers procedure. The plan is to just treat Sunrise trusted committers the same as arch or herd testers. The difference is that they operate on ebuilds of all flavours that interest themself in the sunrise overlay and not on a certain herd of packages. Neither do they focus on testing for a specific architecture. Just coding is their work, not testing - which explains the difference in the name. Now how do people feel about this approach? -Stefan -- gentoo-dev@gentoo.org mailing list
