[gentoo-dev] list masked for removal
# Stefan Schweizer [EMAIL PROTECTED] (19 Jan 2008) # Project abandoned. Masked for removal, bug 206105 sys-apps/list -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] last-rite bpalogin for mark_alec
someone should get him a cvs account ;) # Stefan Schweizer [EMAIL PROTECTED] (02 Sep 2007) # last-rite bpalogin for mark_alec, as the package is useless now (ISP # no longer needs it) and the initscript is broken with baselayout2 net-dialup/bpalogin -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: ML changes
Mike Doty wrote: We're going to change the -dev mailing list from completely open to where only devs can post, Restricting freedom to post is like setting up surveilance and censorship against terrorism. I hate it when the rulers think they can impose such decisions upon the people and do not see how they obviously impact their freedom. If it is only against a single User who has done something bad, but against all users in general, you are crazy .. -Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Last rites: media-tv/freevo
Hi, # unmaintained, masked for removal, bug 156497 # You can find a new version in the sunrise overlay media-tv/freevo-1.7.2 Best regards, Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] should we do an EAPI bump now with features that are already implemented?
Can you please also list #138792 as implemented? It has a patch attached. -Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [gentoo-council] Nominations open for the Gentoo Council 2007/08
A good time for a fresh wind in the Gentoo world :) nominating: betelgeuse dberkholz jokey Best regards, Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree
Steve Long wrote: Dunno what the procedure might end up becoming, but my understanding is commit right to the sunrise overlay, from where a dev has to commit it to the main tree. It seems like a logical extension of sunrise, and i am sure there are stats on who has submitted what to sunrise in the past. So there is a baseline for whom to invite to become insertNameOfNewPosts. Snrise already has such an extension. A portage-review/ subdirectory, where ebuilds from the gentoo-x86 + changes can be posted. A dev then takes those and reviews them to the main tree and removes them again from the dir The process has worked really good so far. I suggest you to read up on how this is currently being done on overlays.gentoo.org/proj/sunrise and if you are interested I invite you to join #gentoo-sunrise to see how it is done. The current log: http://overlays.gentoo.org/proj/sunrise/log/portage-review You will notice the regular in portage, now reviewed, in cvs messages Best regards, Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: invalid herd in metadata.xml
Thilo Bangert wrote: All packages with herdmaintainer-needed/herd will be moved to herdno-herd/herd. I think that is not quite right, and since maintainer-needed is not a maintainer but multiple people listening to the alias and users I would like to suggest the following addition to herds.xml to make it legal: herd namemaintainer-needed/name email[EMAIL PROTECTED]/email descriptionOrphaned packages. Every developer is encouraged to fix bugs here, proxy-maintain or take over maintainance/description maintainer email[EMAIL PROTECTED]/email nameMaintainer Needed/name /maintainer /herd Best regards, Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: OT: was 2007.0 release
Rumen Yotov wrote: Somebody might want to know (for a new install) for how long (eventually) he/she will have to wait. You do not have to wait for the gentoo release engineering team. You will get an up to date install after running emerge -uvaD system in your fresh system. If the livecd is not up-to-date enough for you you can use any liecd in the linux world. The only thing you need is chroot support. Do not wait - Go ahead and start installing Gentoo now :) best regards, Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)
Christian Heim wrote: Tobias is joining us from Hamm, Germany where he's currently finishing the junior high school. Wow he must be really young then. But I cannot find the adequate german translation for junior high school. What is it? Welcome to the devs! -Stefan -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Last rites: app-misc/gfontview
»Q« wrote: In news:[EMAIL PROTECTED], Philip Webb [EMAIL PROTECTED] wrote: 070407 Stefan Schweizer wrote: # masked for removal: no release since 2001, build broken, bug 154671 app-misc/gfontview I have added a comment to the bug. If you want to remove this package, please provide a better explanation. The bug is now marked invalid, but I'm not clear on what's happening, because the last comment also justifies removal. Is gfontview still scheduled for removal? no Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: app-misc/gfontview
# Stefan Schweizer [EMAIL PROTECTED] (07 Apr 2007) # masked for removal: no release since 2001, build broken, bug 154671 app-misc/gfontview -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Last rites: app-misc/gfontview
Philip Webb wrote: 070407 Stefan Schweizer wrote: # masked for removal: no release since 2001, build broken, bug 154671 app-misc/gfontview I have added a comment to the bug. If you want to remove this package, please provide a better explanation. right you are. The bug is invalid - it was because he unmerged some libraries he used earlier in depends and did not rebuild those depends. Have unmasked it again for you :) best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] [last rites] virtual/x11
Hi, virtual/x11 has been deprecated for some time and now that all packages that only use it have been removed it is time to mask and remove it. I have put it in package.mask now - please fix your overlays in case you still use virtual/x11 somewhere. It will be removed in 30 days as per the usual schedule. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Package removals: libzvt+deps: gnomesu, xsu2, root-portal
# Stefan Schweizer [EMAIL PROTECTED] (24 Mar 2007) # as-needed broken, unmaintained, for removal, bug 147550 x11-libs/libzvt # use gksu now app-admin/gnomesu app-admin/xsu2 # use root-tail now x11-misc/root-portal -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New developer: Bernard Cafarelli (voyageur)
Christian Heim wrote: Please welcome Bernard as a new fellow developer among us ! Thanks Bernhard - it is awesome to have up to date NX packages again! Thank you also Christian for taking the time to set him up. Your work is really appreciated. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] media-libs/libhydrogen masked for removal
libhydrogen is now masked for removal, modular X broken and unused. Bug 153202 -Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Masked for removal: app-i18n/skkinput, media-video/xiron
# Stefan Schweizer [EMAIL PROTECTED] (27 Feb 2007) # Masked for removal, modular X incompatible # bug 153202, upstream dead media-libs/libhydrogen # bug 139792, upstream dead app-i18n/skkinput # bug 116233, upstream dead media-video/xiron -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Global ebuild variables and pkg_setup
Some time ago the development version of portage used to source the ebuild only once. I very much liked this and in the process fixed some ebuilds like you described it. Sadly this feature was removed from portage again - nice to see it coming up again. Please fix or point out ebuilds that are broken. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] RFC: reduce conflicts, separate keywording from ebuilds
To my fellow arguing Gentoo developers, due to the recent conflict concerning keywording I want to propose to separate keywording completely from ebuilds. The keywords would reside in a special file in profiles/, maybe even in more than one file to allow more granular permissions. For example only mips developers can access the mips keywording file then. The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. Also currently kde keywording/stabling needs ~300 commits. The problem being that all changes files also get transferred in a rsync. A separate keywording file would be the only one changed thus greatly reducing the sync time. comments? Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
Bryan Østergaard wrote: A. ~arch keywords are supposed to be carried over to new versions unless we're talking about big rewrites or similar (so old versions doesn't have to linger around in portage tree at all). right, we all agree :) B. If we're complaining about MIPS team not being able to ~mips kde-meta on time we need to remove all the arch teams that falls behind from time. I think that leaves us with maybe x86, amd64, sparc as *the only* arch teams allowed to keyword kde-meta which is completely insane and an insult to our users. every arch team is allowed to keyword kde-meta, just they should not complain about their keywords not being on bumps when they are late. Keyword-ebuild separation allows to clearly show the arch teams that they are responsible and allows the developers not to get into conflict here. It clearly would have avoided the recent conflict. The problem is with ebuild developers like me having no means to get arch teams to keyword stuff yet we are responsible if something fails and we get bugs assigned. [remove kde-meta talk] Besides that splitting keywords out from ebuilds doesn't solve *anything* at all related to this as the ebuilds *still* have to stay around as long as they have keywords. Just like current policy says. Moving metadata to another place doesn't change that at all. yeah. A script for removing all ebuilds that are allowed to be removed by policy would be cool. Sadly I don't have one currently :( We can for example also offer x86-only sync trees without all the ebuilds that are only relevant to the other arches. Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
Alexander Færøy schrieb: It was discussed at the last council meeting... Proposed by jokey. Thanks. Sorry I did not know about it because there was no summary for the last council meeting. From the log that I read now I cannot clearly define an outcome. I would appreciate to see summaries again for the council. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: RFC: reduce conflicts, separate keywording from ebuilds
George Shapovalov schrieb: a) move all the keywording into profiles (that is remove all KEYWORDS fields from all the ebuild) and disallow package maintainers and other devs (other than arch teams) to touch keywords or b) leave ebuilds with simple ~arch/arch/-arch (literally) keywords and move granular per-arch settings to profiles the first one + maintainer arch is what I like to have. Other arches can then go up to maintainer arch automatically(with a bot) for ~arch and manually for arch or define their own policies like they want. or something else? Even then I am not sure how either of these is going to work, especially this: The arch team can then decide themselves which ebuild they want to mark ~arch and they can take care of possible new dependencies themselves. normally new versions/packages go directly into ~arch unless they are transiently masked by developer (waiting for release, etc) or are permanently masked live-cvs/svn ones. The particular case is about having new depends in new versions. For example in ghostscript-esp-8.15.3-r1 there is a new dependency on app-text/djvu and mips, arm, s390 and sh do not keyword it. See bug 148945 too. moving keywording only in the arch teams responsibility is the way to go imo because I hate having keywording bugs assigned to my herd where I can do nothing about it. I am not sure how a) is going to work at all in this respect. Are we going to get tons of ebuilds just sitting there never made visible to any arch now (since even x86 would have a large backlog)? it can be automated to do this from the maintainer arch if the arch team wants it. -Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Package removals: net-misc/kssh, sys-fs/captive, net-print/hpoj
# Stefan Schweizer [EMAIL PROTECTED] (19 Feb 2007) # bug 152513 broken on gcc4 and no release since 2002, masked for removal net-misc/kssh # Stefan Schweizer [EMAIL PROTECTED] (07 Nov 2006) # Please use ntfs3g now - it is better. Will be removed someday sys-fs/captive # Stefan Schweizer [EMAIL PROTECTED] (06 Feb 2006) # deprecated - please use net-print/hplip now net-print/hpoj Will remove in one month Best regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: GPL-2 vs GPL-2+
Diego 'Flameeyes' Pettenò wrote: Comments, ideas, proposals? currently we have all those under GPL-2. Now when GPL-3 becomes available people have the option to use GPL-3. However that will still allow people to use GPL-2 if their patents, etc need it. SO it is not much difference. The big difference that actually matters is when applications start to get distributed only for the GPL-3 and actually then I would also like to see the LICENSE change to GPL-3. I see little benifit in having GPL-2+ but a lot of potential confusion and a lot of work for developers to check all pkges. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: eclass cvs should not use -z4 by default
[EMAIL PROTECTED] wrote: and the reply by Mike Frysinger (vapier), maintainer of this eclass: i would use -z1 or -z2 as the default and allow people to override it via make.conf ... but you should send your proposal to the gentoo-dev mailing list to see how people feel why not use -z0? No compression at all should put less load on the servers. And people that have less bandwidth can adjust it if they need. Regards, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New developer: Charlie Shepherd (masterdriverz)
Petteri Räty wrote: It's my pleasure to introduce to you Charlie masterdriverz Shepherd. He is joining us to help with the multiple kernel sources we have in the tree. Maybe we will have master-sources soon? Previously he has been helping in the sunrise overlay and he is also looking to join other herds than kernel. He hails from London, UK. This is how he describes himself in his own words: Apathetic KDE user, die hard vim user, relutanct irssi user, lived in London all my life, currently learning the bass (guitar). congrats! Enjoy your time with Gentoo. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New developer: Cédric Krier
Petteri Räty wrote: It's my pleasure to introduce to you Cédric cedk Krier. He is joining us to help with the netmon herd. Previously he has been filling the bugzilla with new ebuilds and participating in the sunrise overlay. Welcome! Finally some of those many many ebuilds you made will get into portage. Best regards, - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] mirroring distfiles/patches on patches.gentoo.org
To my fellow Gentoo Devlopers and Users, The Gentoo Infrastructure team proposed this idea in june 2006 * Reduce mirror time for Gentoo specific patches/tarballs * Offer an official location for Gentoo specific patches/tarballs (Instead of using dev.g.o, this would be the official place) * Offer a distributed (3+ servers) mirror rotation for this This would be the official location for those distfiles when infra makes it available. I am asking them for status reports on this you will maybe see some here :) But for the meantime I am using http://gentooexperimental.org/~genstef/dist for this purpose. The reason is that I can remove and add stuff there myself and can keep control of what gets deleted. I can use my favourite scripts to create distfiles and keep them ordered. For example I am using this for firefox-2.0. This workaround I initially had to use when I discovered a bug in the mirroring script that was annoying me regularly. The mirroring script does ignore all RESTRICT=mirror SRC_URIs even those at mirror://gentoo/. Bug 121332 ppp patch missing from distfiles Bug 100260 The File foo2zjs-20050319.tar.gz missed on Gentoo-Mirrors Those get uploaded and look fine but after 6 months they are suddenly being removed by the script. Initially of course I needed a solution of that bug badly and because the mirrors kept dropping it I have just uploaded it to dev.gentoo.org in lack of any other proper place to put it. But using dev.gentoo.org is deprecated by our infra because the server may not be able to cope with the traffic. Fortunately later I was able to get an account on Patrick Lauers development server http://gentooexperimental.org/~genstef/dist to upload my distfiles there. So this is my current practice and I am eagerly waiting for infra to allow me to use an official service instead of my bandaid. Unfortunately some people are really afraid of what I am doing and want to harass me into using the mirror://gentoo that I do not want to use. This mail is dedicated to explain the issue to those people. Please, dont argue such discussions that only give you personal satisfaction of being correct or an excuse to annoy other people. Useless yelling at each other because of a minority where opinions differ is misplaced in a project that is driven by volunteers. That is also why I have stopped and written this mail. But I can see that you are a bit frustrated because you did not get your way through. So here is a guide of what you can do. I will gladly stop using workarounds when I am allowed to have an equally bugfree and fast workflow as currently. What you can do: 1) write a patch for portage to allow granular mirror restrictions for the SRC_URI and work with infra on improving the mirroring script to not ignore mirror://gentoo in mirror-restricted ebuilds. Also for this solution the time for a distfile in /space/distfiles-local to hit the first mirror should be equal to the time for ebuilds to get into the rsync rotation so that problems for users who are too early. 2) get infra to provide patches.gentoo.org as a permanent solution that I have asked for since march 2005 and it sometimes even looked close to getting it on bug 85098. Thanks for understanding Stefan Schweizer -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: mirroring distfiles/patches on patches.gentoo.org
Alec Warner wrote: Those get uploaded and look fine but after 6 months they are suddenly being removed by the script. There is a distfiles whitelist[1] for this exact purpose...isn't there? [1] http://www.gentoo.org/proj/en/infrastructure/mirrors/overview-distfile.xml Thanks for the heads up. I was not aware of this when I was looking for a solution badly back then. Must be a rather recent development. Looks easy and straightforward - even deleting is possible. Good job, guys :) Still the developer needs to know about it and think of it in the moment of adding mirror restrictions to an ebuild with mirror://gentoo sources. A risk that is not going to be taken in any of my ebuilds. I hope the people that prefer mirror://gentoo know about the issue and the solution :) Thanks, Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: mirroring distfiles/patches on patches.gentoo.org
Grant Goodyear wrote: Truly, the sarcasm doesn't help. It takes a potentially reasonable grievance and reduces it to just the author appearing to be a jerk. Sorry, I have no intention to cause any ill fate. Is meant explanatory. - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New Developer: David Shakaryan (omp)
Christian Heim wrote: So please welcome David as a new fellow developer among us! You are welcome, David! It is nice to see another of the sunrise people join Gentoo. Also thanks to Christian - you are doing an awesome job these days handling new developers. Delays are no longer an issue. You are one of the people that make working on Gentoo fun again! - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New Developer: Alon Bar-Lev (alonbl)
Hi, it has been a pleasure to work with you through bugzilla. I am really glad you are a developer now - I will not have to commit anything for you anymore now ;) Best regards, - Stefan -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Sunrise trusted committers with bugzilla access
Bryan Østergaard wrote: As there's been very little, if any, interest from anybody besides Stefan and Recruiters / Developer Relations I'm going to deny the contributor access idea. Recruiters and Developer Relations feels that this is a bad idea, especially seeing how hard it has been to reach any kind of resolution regarding who should get access and how we should solve the problems that I've outlined earlier. thanks for the clear no. I should have realized that before writing the GLEP and everything. Sorry :( -- 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
[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] 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: 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: [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: 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] [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] 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-portage-dev] Re: default postsync
Hi,
I think this is a good idea. Now that we have the file installed by
portage-utils there are ideas spreading about using it in layman and eix.
Depending on portage-utils does not seem to be a good way to make sure that
the bin/post_sync file exists. Installing it on ou one neither, because of
collissions. So the best solution is to allow portage to provide this file.
Please add it
Best regards,
Stefan
Ned Ludd wrote:
Jason and myself had talked about briefly but not in any depth about
post sync actions. Quickly after the basic idea was accepted it
started to become clear that a set of default triggered may be
desired.
So I was thinking like if portage installed something like the
following or if we changed the behavior now in emerge.py before the
existing become to widely adopted to do more or less the same thing
that this bash script does.
#!/bin/sh
# Copyright 2006 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $
if [ -d /etc/portage/postsync.d/ ]; then
for f in /etc/portage/postsync.d/* ; do
if [ -x ${f} ] ; then
${f}
fi
done
else
:
fi
##
How do you think we should handle it?
Should we install a post_sync in a postinst phase outside of portage's
handling if and only if not post_sync already exists?
Should we change it to handled a postsync.d by default?
Should we do both? I'm open as heck but would like to start to
finalize then document it's behavior. I feel it could be one of the
next untapped really useful features of portage. glsa-checking, news
handling, search db updating, and stuff etc..
--
gentoo-portage-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] 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] 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] 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] 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: [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] 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] 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: 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] 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: 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=0view=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: 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: [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: [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. Sorry to differ a bit from the format, but I think it is important to explain and get things sorted here.
[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: [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] [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] 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] 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] 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] 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 with the initial announcement but we have seen that the
[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 libraries that are from a third party overlay not controlled by gentoo.
It
[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: 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: 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 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: [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
