[gentoo-dev] Re: [RFC] DIGESTS metadata variable for cache validation
Zac Medico schrieb: The primary reason to use a digest for cache validation instead of a timestamp is that it allows the cache validation mechanism to work even if the tree is distributed with a protocol that does not preserve timestamps, such as git or subversion. This would make it possible to distribute metadata cache directly from git and subversion repositories (among others). So just to make sure I understand what you're after... You want to add some checksum to the cache file to make sure that all its other vars (line 1-17) are still the same even though there are timestamp issues? Or is that checksum for the ebuild file (which is in the Manifest file in the ebuild dir)? Greetz -Jokey
[gentoo-dev] OpenLDAP 2.4 unmask is coming
This is way overdue for us but uni work kept me busy, so I just didn't have the time yet. Please test all your apps against 2.4 series (desktop profiles have a dep on that by default, so likely a large part of our users will be affected) I filed a Tracker bug [1] if you have issues, please report and mark it a blocker of that. https://bugs.gentoo.org/show_bug.cgi?id=257867
[gentoo-dev] Re: [gentoo-dev-announce] Last Rites: games-puzzle/ksudoku
Richard Freeman schrieb: > Tobias Scherbaum wrote: >> >> Wouldn't it make much more sense to package move ksudoku then? >> > > I was thinking the same thing - this is a stable package, so ideally it > shouldn't be "replaced" with an unstable one. Why not keep -0.4 in the > tree for stable users? > > Package moved instead now. Although the kde version is much improved, we can keep it. Greetz -Jokey
[gentoo-dev] Re: [RFC] EAPI 2 Draft
Alec Warner schrieb: > I think the question isn't 'why is this functionality being made > available'; I think to me it is useful piece of code. > > I question its inclusion in the PM though; I would rather see it in > eutils or something similar. > > Arguably you could inherit a function from eutils that does SRC_URI > transformation for you. > > SRC_URI="foo bar baz;sf=tbz2" > src_uri_gitize > > would transform "baz;sf=tbz2" into "baz;sf=tbz2 -> baz.tar.bz2" Same applies to files that are fetched from trac so I also would question hard-coding a single use case into PM... Greetz -Jokey
[gentoo-dev] Re: Jeeves IRC replacement now alive - Willikins
Robin H. Johnson schrieb: Hi folks, Getting the bot out there - If you would like to have the new bot in your #gentoo-* channel, would each channel founder/leader please respond to this thread, stating the channel name, and that they are the contact for any problems/troubles. Please add to #gentoo-sunrise as well, thanks. I'll be contact for it. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Agenda [WAS: One-Day Gentoo Council Reminder for June]
Donnie Berkholz schrieb: >Status of PMS >- >ferringb said: > I'd like the council to please discuss the current status of PMS, if > the running of it satisfys the councils requirements of a *neutral* > standard, if the proposed spec actually meets said standards, and if > said spec is actually going to be approved sometimes this side of'09. > >Preparation: Post your opinion to the -dev thread "One-Day Gentoo >Council Reminder for June" 2+ hours before the meeting. After investing more than two hours to just read the Mails that popped up yesterday regarding this stuff, I'd say we can't really take this serious. The PMS maintainers were withholding information on compatibility issues they've seen. As such we can't be sure this will pop up again in the future and so I strongly suggest dismissing this as something official for gentoo. Best Regards Markus Ullmann Gentoo Council Member signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2008/2009
Josh Saddler schrieb: Now that nominations are officially open, I nominate the current council members (again): amne betelgeuse dberkholz flameeyes jokey lu_zero vapier Thanks, I accept the nomination :) Greetz -Jokey -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: Bug wrangling
Denis Dupeyron schrieb: That he comes back or not is of no importance to bug wrangling. Or at least it should be. It is a mistake to solely rely on a developer for such a task. Developers come and go without warning, he just proved it, so ideally we need a team of 2 or 3 to handle bug wrangling. Also, one single developer handling this puts him/her in such a prominent position that it is bad for him/her, our users, other developers and the entire project. We had too many examples of this. Fully with you, yet the other people who do bug wrangling occasionally didn't do it as good as him mainly because he followed all major mailinglists and knew the common issues around. I have nowhere an idea how much time he put into his bugwrangling but I bet that reaches at least 5-6 hours a day. Replacing that is simply hard work and nothing else and I'd love to see people stepping up to help with that task. -Jokey -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: New developer: Michael Hammer (mueli)
Petteri Räty schrieb: Joinin us from Graz, Austria is Michael "mueli" Hammer. He will be joining us to maintain kerberos related packages. Michael is responsible for the infrastructure at the Graz University of Technology and they run Gentoo of course. So no longer do you have to think about moving to other distros as this corner hopefully stays maintained. If he does a poor job on it it's time for the hammer and sickle. On his free time Michael restores and old Mini from 1975. So now you finally made it :) Let's see how our new kerberos conspiracy works out... Oh wait, that used to be sekrit, right? ;) Welcome ! -Jokey -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Last Rites: sys-fs/python-fuse
+# Markus Ullmann <[EMAIL PROTECTED]> (21 Apr 2008) +# Masked for removal in 30 days. +# unmaintained, broken and not used anywhere +# use dev-python/fuse-python instead +sys-fs/python-fuse -Jokey -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-apps/iproute2: ChangeLog iproute2-2.6.24.20080108.ebuild
Mark Loeser schrieb: Mike Frysinger <[EMAIL PROTECTED]> said: that's actually exactly what i'm encouraging. i'm not worried about such issues as they're easily resolved by people posting the full build log. Which is great, but I think this is something we should discuss and figure out if this is something we want to introduce into the tree (too late now, but better late than never). If it is something we want to move forward with, it should be introduced at the package manager level instead of being an in-tree package manager specific feature. I'm coming at this from a QA perspective and if we want to do it for one package, it should be introduced for all. We should document it and know how to support it as well. +1 on that, quite a bunch of overlayed ebuilds won't be needed if additional patches could be applied this way. we should just find a way to enable/disable this and make it visible on support requests. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Help offered - Portage tree
René 'Necoro' Neumann schrieb: I'm not a gentoo-dev - and I did not read the whole thread, because it was too political for me (do I really have to read all these IRC quotes?). +1, this stuff belongs to the -project mailinglist But I just had an idea for this topic (don't know if anyone had this already - or if it is not applicable here), that I want to share: Why not try to find someone, who does all the bug filing? - So lxnay can find and fix the bugs - and someone else files the bugs and does the discussing with the gentoo-devs. Then both sides have what they want. Of course, it still takes time to get things into the tree, but this shouldn't be a problem :) (I think). maybe finding someone who works with a bunch of people would do the trick ;) Just an idea - please don't eat me, if it's a silly one ^^ /me eats portatoes today ;) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New keyword monkey: Kenneth Prug (ken69267)
Welcome on board! Don't break my stable servers though :D Make your self at home. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Monthly Gentoo Council Reminder for March
Zhang Le schrieb: IMO giving proxy-maintainer due credit and publicity, meaning make it a formal position, could solve the very problem Anant's proposal intended to solve. we had that in the past already yet it didn't solve one problem at hand: users getting distacted and devs getting nervous b/c the process is a) undocumented and b) a bit complex as you have to keep $repo and gentoo-x86 in sync So giving both (devs and users) an automated way of working with that would help a lot IMHO. like the user submits using echangelog "My cool change" repoman submit then the dev gets a diff or whatever against current state and then just does repoman accept or repoman reject note: just brainstorm idea but we definitely could use some scripts for this kind of work. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: rgb file specification
Steve Long schrieb: Ferris McCormick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is random musing based based on perhaps my own problems. I need a local color.file to see well what I have going on, and current xorg ignores that. Thus, at every build, there is in oscolor.c a "constant" I must change from 1 to 0. I don't understand why this is an issue for "every build"; surely a patched ebuild in local overlay is trivial? It's only a quick sed -i line added. And with the gentoo-x86 follow script grobian uses for prefix syncing, it should even be doable to always have an up-to-date current ebuild. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer : Ingmar Vanhassel (ingmar)
Denis Dupeyron schrieb: Please everybody, give a very warm welcome to Ingmar. Oh noes, you made it ;) *welcome* :=) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Council meeting summary 20080110
Hi all, here is the summary from last week's council meeting. The complete log can be found at http://www.gentoo.org/proj/en/council/ Thanks, Markus Roll call - (here, proxy [by whom] or slacker?) amnehere betelgeuse here dberkholz proxy [musikc] flameeyes here lu_zero here vapier here jokey here Agenda -- GLEP 54: scm package version suffix http://www.gentoo.org/proj/en/glep/glep-0054.html GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI) http://www.gentoo.org/proj/en/glep/glep-0055.html Code of Conduct enforcement http://thread.gmane.org/gmane.linux.gentoo.council/82 http://www.gentoo.org/proj/en/council/meeting-logs/20071108-summary.txt http://www.gentoo.org/proj/en/council/meeting-logs/20071213-summary.txt - What needs to happen for us to make a decision? Last week, we agreed to just add moderators to #gentoo-dev and the gentoo-dev list. Other places with their own moderation should enforce the CoC themselves. We also agreed that moderation must be handed over to devrel or userrel after 2 days. Ferris asked some questions: 1) Do we have an implementation schedule? ; 2) Have we identified some warm bodies for it?; 3) Most devrel requests seem really to relate to CoC violations. Would you like us to bounce those to the CoC people, process them using CoC rules, or keep doing what we are doing now (generally, close them with a note explaining why or mediate them)? (I'm talking about the "He's being rude/sarcastic/disrespectful" sorts of things which really need to be processed immediately and merit a warning or brief suspension if anything.) Slacker arches See Caleb's post on -dev and subsequent thread Calebs post: http://article.gmane.org/gmane.linux.gentoo.devel/53933 Kumba's comment on mips status: http://article.gmane.org/gmane.linux.gentoo.devel/54168 Rich0's proposal: http://article.gmane.org/gmane.linux.gentoo.devel/54103 Document of being an active developer Araujo raised that he needs some kind of written document of being an active developer. Argument being that mentioning in CV in his environment is only accepted if there is some kind of proof. Our trustee grant deferred it back to council+infra as Foundation only handles IP, but suggested it could be some kind of generated document. === GLEP 54 : Postponed to -dev ML --- Comment from portage maintainer: - no statement about compatibility/implementation plans - more subjective: - while a distinction between CPV and atom may not be technically required, I might be useful to have - (minor) if the version part is optionl there could be some complications So is this something we'd like to have? Other ideas that came up during discussion: - -scm or _scm ? - handling as (-|_pre)) versions per definition - implement as dynamic package sets Related bugs: - bug #9202 - Better support for CVS Ebuilds... Pushed back to -dev ML as there are too many unresolved questions at the moment. peper is given the task to repost it and expand on usefulness / use cases as well as compatibility issues. GLEP 55 : Postponed to -dev ML --- - Agreement on eapi subdirectories are not feasible Ideas during discussion: - moving from EAPI= to eapi function and using repository bashrc for compatibility Pushed back to -dev ML as there are too many unresolved questions at the moment. Slacker arches -- vapier will work on rich0's suggestion and repost it for discussion on -dev ML Code of Conduct enforcement --- Council members agreed on the direction, dberkholz will provide additional details on -council ML Document of being an active developer - Suggested options: - Log in to dev.g.o and automatically generate there signed by infra-maintained key, put userinfo.xml website in the doc as reference. dberkholz and araujo will look into a scribus based template. devrel will have to generate a signing key for these purposes. signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: scm eclasses/ebuilds and revision logging
Bernd Steinhauser schrieb: http://en.wiktionary.org/wiki/something Sorry, thought that was common. ;) It seems so from german-schools' english teaching books. ;) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Of Mips and Devs [Was: Monthly Gentoo Council Reminder for January]
Thanks for your input on this, really made it look by 200% better from what we have so far on this list and gives a much better point of view to judge from. Kumba++ Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Projects and subproject status
Luca Barbato schrieb: Are we fine? lcd : G15 in good shape, no major issues anywhere ldap: openldap works good, nss_ldap has some issues here and there net-irc : some minor issues with dead-upstream apps or apps breaking their own configs but nothing too serious net-mon : behind on some packages due to only 3 people taking care, could use more hands to help maintaining What are we going to do: lcd : nothing major atm ldap: openldap 2.4 in the queue, yet needs more work to be safe net-irc : nothing big, just some minor bumps here and there net-mon : just working through bugs, some are hard to reproduce so may take a bit to be resolved finally Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Last rites: =dev-lang/python-2.3*
Ali Polatel schrieb: P.S: I plan to add a junk overlay like java's to put old python stuff. I'll keep you posted. Just make sure to copy anything that has mirror://gentoo as it would be gone automatically 14 after you remove the ebuild from gentoo-x86 (and thus the reference to it). Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last Rites: net-analyzer/driftnet
+# Markus Ullmann <[EMAIL PROTECTED]> (06 Jan 2008) +# Broken on compilation, pending removal +# see bug 192627 for details +net-analyzer/driftnet + Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Bug Day Saturday January 5th, 2008
Roy Bamford schrieb: It's that time of the month again, time for another Bug Day on Saturday 5th January. Yep, that's the first bug day of 2008. Join us in #gentoo-bugs on irc.freenode.net to help squash some bugs and meet up with fellow users and developers. Read all about it http://bugday.gentoo.org/ Friendly reminder, bugday is tomorrow :) signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Improving use.desc
Santiago M. Mola schrieb: > -ffmpeg - Enable ffmpeg support > +ffmpeg - Enable ffmpeg support --FIXME ffmpeg - Enable ffmpeg-based audio/video codec support > -junit - Adds junit awareness -- useful for developers. > +junit - Adds junit testframework awareness -- useful for developers junit - Adds junit test framework awareness -- useful for developers > -libnotify - Enable notification support > +libnotify - Enable notification support -- FIXME libnotify - Enable desktop notification support Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer : Richard Freeman (rich0)
Denis Dupeyron schrieb: > I would like to thank Markus Ullmann (jokey) for taking over the > mentoring of Richard after his original mentor left us. > > So please everybody, give a warm welcome to Richard. > > Denis. Now that you did your first commmits, welcome to the crowd of evil tree breakers^Wcommitters :) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Old ebuilds in bugzilla
Raised that a month or two ago here, conclusion: If you find something dead, just ping someone with appropriate rights to wontfix it. When you care about that pkg, either find a maintainer for it or take it up to sunrise overlay yourself. :) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: EAPI definition Was: [GLEP] Use EAPI-suffixed ebuilds (.ebuild-EAPI)
Santiago M. Mola wrote: > On Dec 20, 2007 8:01 PM, Zhang Le <[EMAIL PROTECTED]> wrote: >> Where is the detailed definition of those EAPI's? > > "0", "1" and any further official EAPI are defined in PMS. There's a > svn repository at http://svn.repogirl.net/pms Erm no, PMS isn't officially until council made a decision on it (and I'm not aware of one yet). Currently "official" EAPIs are 0 and 1. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: EAPI placement
Doug Klima schrieb: > zmedico: what if I have EAPI=2 above the inherit but an eclass > has EAPI=1 if an eclass sets EAPI, then the ebuild shouldn't... make it two eclasses if needed or plain bump them if really really needed. Greetz Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: maintainer-wanted bugcount
K, to sum it up then, everything stays like it is atm. Thanks for your comments :) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: maintainer-wanted bugcount
Robin H. Johnson schrieb: > On Mon, Nov 26, 2007 at 10:46:12AM +0100, Markus Ullmann wrote: > d) In addition to c), keep them open, flagged with sunrise in the status >board, so that when a developer does want some package not in the >tree, they can search first. That's done already > e) Encourage existing developers to review and commit this stuff more >often. That would be the best option > I really would not want to see them closed unless there is a good reason > for them to not be committed to the tree. See the reason's I've given here: http://article.gmane.org/gmane.linux.gentoo.project/179 Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] maintainer-wanted bugcount
Hi fellows, when taking a look at the open bug count for bugs assigned to maintainer-wanted (2450 at the time of writing), it seems pretty obvious that we really can't handle all of them, at least not without growing at least two dozen devs to maintain it properly. As I highly doubt this will happen within a week, we have to make a decision how to proceed with this stuff. So what options do we have? These come to mind: a) WONTFIX them within 4 or 8 weeks without picking them up b) reassign them to herds (some herds are on CC) and have them respond withing 4-8 weeks and give a yey or boo. c) let interested users move it to sunrise (some of them are there) so that the ebuilds are at least at our QA level we maintain for gentoo-x86 and are there to be picked up by devs if they're interested If you have more options or comments, I'd like to hear about them, as we definitely have to do something there. F'up is set to gentoo-project as this is more a political thing. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Automated Package Removal and Addition Tracker, for the week ending 2007-11-18 23h59 UTC
Robin H. Johnson schrieb: > The attached list notes all of the packages that were added or removed > from the tree, for the week ending 2007-11-18 23h59 UTC. Just thinking, as we send package fadeouts to both dev-announce, I think this should be sent there as well as it contains actual removes. Thoughts? Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: packages.gentoo.org lives!
Joe Peterson schrieb: > Robin H. Johnson wrote: > One idea for improvement, however, might be to spell the archs > veritcally, thereby easily letting all archs be viewable across one page > (even perhaps by default). It would help to boast our many arch support. Heh, well I think the devs are used to this view as that's what you get when you want to see keywords of packages. also try your suggestion with packages like wine... Though I like the spirit of new ideas. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: eselect_zenity: alpha eselect GUI
Doug Klima schrieb: > While I haven't had much time to work on the bits, Gentopia does contain > PolicyKit (though the 0.7 snapshots that appear do have some issues and > you should stick to the 0.6 series). It's hopefully going to be the way > forward for Gentoo to use PolicyKit. As many may know, Fedora has made > this commitment and Ubuntu is starting to contribute more back and be > involved a bit more. The gui project peoples along with two contributors and upstream already looked into that and at best we could use this notify feature for glsa. Gentoo is just too different to sanely work with it for full updates. Stuff like selecting useflags, outputting important changes, needed configuration updates afterwards and some more issues are plain not doable with packagekit. Though there is some work going on to get an abstraction layer for all three known package managers that work with the tree to make sure such a notify can be done. Greetz Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: Place of EAPI variable in ebuild
> What if I want to use EAPI=1 features in an eclass? So if we for example > we have an ebuild using EAPI=2 and then it inherits and eclass that sets > EAPI=1 for slot deps. shouldn't be an issue as eapi 1 and 2 would have slot deps though for other things like src functions defined in the eclass this might become really interesting, especially if we get src_configure in eapi2 Greetz Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer : Dawid Węgliński (cla)
Denis Dupeyron schrieb: > He will now be a full developer and work with > the net-irc and x86 arch teams. cool, net-irc made it to an arch team already? *fg*scnr* Anyway, cla, use repoman || die and welcome (again) among the dev crowd :) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Guys, I need your assistance here
Dawid Węgliński schrieb: > I'm curious, because i'm working with jokey to make p.g.o > up. Right, he contributed a modified template, I wrote a new db generator already and now working on some genshi/cherrypy frontend to avoid this shtml stuff. So anyone who wants to join: http://orion7.digital-server.de/cgi-bin/gitweb.cgi?p=packages.git;a=summary git://orion7.digital-server.de/packages.git If someone wants to see source being worked on, there it is, patches and contributions welcome ;) Note: normally I'd go public after the thing is at least partially working on both parts but as people start kicking heads this imho makes sense now... Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Pre-Last Rites (again): net-irc/bitchx
So there we are again... Open security bug and dead upstream. Please either anyone picks it up or we mask it next week. https://bugs.gentoo.org/show_bug.cgi?id=190667 Greetz -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New sparc Arch Tester --- tcunha
Ferris McCormick schrieb: > I am pleased to announce that Tiago Conha (tcunha) has joined the sparc > project as an architecture tester. Tiago is already an AT for amd64, so > now two architectures will keep him busy. > > Regards, Wheee more people :D Take over the. errr nvm ;) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Gentoo Graphical User Interfaces Project
>Hello, > >I take it you intend to use GTK. May I suggest you also provide ncurses >interfaces to your programs? I'm not sure how much additional work that >would be, as I don't program UIs. But an additional ncurses interface >would provide users with the comfort of having the same tools available >in case their Xorg fails for some reason, and on their X-less servers. Erm, there is a big hint: patches welcome. Ncurses has the disadvantage of being a bit "underdocumented". So programming isn't that much fun, although when someone is willing to start, help will be there for sure :) Though we don't limit ourselves to one GUI. From what I've heard on IRC, nobody declined a request for other toolkit(s) if other people help with it. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Markus Meier (maekke)
Petteri Räty schrieb: > It's my usual pleasure to announce our newest keywording monkey. Markus > "maekke" Meier is joining the x86 arch team to deal with the constant > flow of bugs. Yey for more minions :D Welcome :=) /me notes another namesake signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: On my way out....
José Luis Rivero (yoswink) schrieb: > Gustavo Zacarias escribió: >> I resign as gentoo developer. >> Infra: please remove my accounts. Short and without reason even :x Gustavo, was a pleasure to work with you whenever our roads crossed. Good luck with your future plans whatever they might be. It's just that your commit stats look like this happened in rush :x > P.D: this is just to wait the return of gustavoz (or Weeve) to Gentoo, > which will happen sooner or later. I'm sure. I second this... /me started helping out today as well to keep the thing alive, knowing that there is a big gap to fill. Greetz -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New Developer: Christian Hoffmann (hoffie)
Welcome ... and the german conspiracy grows... Enjoy though use repoman || die ;) Greetz -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New Developer: Jason Smathers (jsin)
Welcome Jason :) Good to see you joining us. Greetz -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Nominations Update
Christina Fullam schrieb: > Just a reminder about nominations and voting... > If anyone is still interested in running, you have one week left for > nominations. > Most who have accepted havent told us why we should vote for them. While > that information is not required perhaps it should be if we are to make > intelligent votes - sorry this isnt a popularity contest so give us some > content to review. Agreeing with previous posters to this thread here, it is a bit of popularity contest ;) > 1) What you will do > 2) Why you will do it While being all for finally documented EAPI stuff (we really need use and slot deps), I also want to keep an eye on user involvement. After all I wouldn't be a dev myself if some other dev would have been willing to help me with this stuff. I think we have quite a bunch of powerusers who either hide a bit in the corner or hit some devs they can't work along with. Actually makes me sad when I see such stuff when userrel@ gets involved. Besides that, some Distributions that base their work on gentoo already have hit some technical issues with the system they want to work around (There will be a binary merger some time soonish)... We should see if we can pick up some stuff from the communities that are even not directly gentoo related to see if we can merge work instead of duplicating it. I second a recent planet post about NotInventedHere problems sometimes. That should bring us back on track and at the technical top of (meta)distributions :) > 3) How you will do it For the technical part, well, you can't force someone to do things if he works just for fun. Though I want to get people motivated to work towards the new features mentioned in previous questions. On many ends we have proven that we can handle even huge evolutions soonish, so we should go on with it. > 4) What is the timescale for doing it Some of my ideas take some weeks, some may last longer. Depends on motivation of all involved, though I'm willing to set a point on that. > 5) What experience do you have with this or a similar role As being part of userrel, overlays lead and sunrise co-lead I already have a fair share at users front I think ;) > 6) Why do you think you are qualified I'm quite active in the opensource community (member of two LUGs), gentoo user since 1.4rc days and dev for more than one and a half year now. I think I know more a bit about how the stuff works around here. > 7) How you plan to balance a council role with your current Gentoo role I mentored / co-mentored a good handful of devs who keep up the work when I'm not in (Uni exams mainly) ;) > 8) How much time can you dedicate to the council role Should be something around 1-2 hours a day, sometimes more, sometimes a bit less. After all I still maintain some mystic thing called real-life ;) Though if you have something important, I am on irc, reachable via email and if there is really scary stuff going on, some devs have my cell phone number to send me a text about it. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Packages up for grab
Christian Heim schrieb: > - net-analyzer/mwcollect (net-mon herd ?) Herd-absorbage ;) -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: ML changes
Vieri Di Paola schrieb: > I already contacted jokey (Markus) several months ago > via e-mail and we agreed that he would have setup > "proxy maintenance" for the shorewall ebuilds so that > I could contribute patches and learn from his > suggestions. We never got to do anything because we > simply stopped e-mailing. I think we can reinstatiate this, I was busy with another round of exams at uni though as they're finished since yesterday, we should get your ebuilds in ;) Though we should continue this off this list ;) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: ML changes
Hey ;) As an extension of it. What about this: _All_ posts from -dev go in CC to -project. Even if the posts are moderated, they always appear there. That way you can have a (moderated) subset as -dev and people who want to get their words and fights out, can do that on -project? Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Davide Cendron schrieb: >> jokey Thanks for your nomination :) I'm accepting, too. greetings with nightvision goggles -jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Non-new developer: Tobias Heinlein (keytoaster)
Denis Dupeyron schrieb: > So please, everybody, give a warm non-welcome to Tobias. /me adds him to the dark lords list, also known as the evil german conspiracy Congrats to your upgrade :) -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Pre-Last Rites: net-irc/bitchx
As we know from previous bugs and mails here on -dev, bitchx is pretty much unmaintained and now has an open security bug. https://bugs.gentoo.org/show_bug.cgi?id=183149 So if no-one wants to take it, p.masking it in a week from now and remove it regular 30 days after. -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
Markus Ullmann schrieb: > nominating: > others are nominated already ;) d'oh, forgot fellow dertobi123 -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Nominations open for the Gentoo Council 2007/08
nominating: welp taviso others are nominated already ;) -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Are you guys for real?
Some numbers to back Vlastimil up > Yep there's still development going on, devs commit ebuilds and stuff. http://cia.vc/stats/project/gentoo > Also, as said many times, number of devs participating in flamewars here > is pretty low compared to number of all devs... considering http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml and http://archives.gentoo.org/stats/gentoo-dev-per-month.xml I really agree that most people are quiet ;) Greetz -jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Do not modify ebuilds which are already in the tree... even if masked
Luca Barbato schrieb: > Another solution could be provide a nice script that does that for you... Prefix project uses one already ;) Worth trying Greetz -jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New Developer: Gilles Dartiguelongue (eva)
Christian Heim schrieb: > So please welcome Gilles as a new fellow developer among us ! Good to see you around now, FOSDEM was inspiring you, right? ;) Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New Developer: Christoph Mende (angelos)
Christian Heim schrieb: > It's my pleasure to introduce to you Christoph Mende (also known as angelos > on > IRC), our latest addition joining the AMD64 and XFCE herd. > > Christoph is joining us from Flensburg, Germany, were he just finished a > internship to improve his GPA for his upcoming study at a specialised > engineering high school. W00T A gentoo dev around the corner and never seen him at a LUGFL event... How's that possible??? Anyway welcome to gentoo and to the mystic german conspiracy ;) Greetz -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: irregular metdata.xml check
Chris Gianelloni schrieb: > The point is that in cases where the herd > name doesn't equal the email address used for that herd, the maintainer > tag should probably be filled in with the proper email address. I think we have herds.xml for a good reason ;) -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: stabilizing expat 2.0.0
Rémi Cardona schrieb: > The profile idea looks ideal. Yup, +1 on that one -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] DWS for 2007-05-07 - 2007-05-13
Hi, this is the -dev weekly summary, actually the first one ;)
Announcements / Important stuff
===
Announcing GLI ("the installer") 0.5 (by agaffney)
--
http://article.gmane.org/gmane.linux.gentoo.installer/594
--
The Gentoo Linux Installer team would like to announce version 0.5[.4]
(we've found a few bugs since the initial 0.5 release) of the installer.
This release, which is available on the 2007.0 x86 and amd64
LiveCD/DVDs, has a lot of changes from the previous one (so many that it
really should have been a new major version, but we haven't even reached
1.0 yet, so it's a bit hard to jump to 2.0).
Release BitTorrent seeding (by robbat2)
---
http://article.gmane.org/gmane.linux.gentoo.devel/48936
---
Could the ~80 people that are still seeding the 2006.1 release on
BitTorrent please move to seeding the 2007.0 release instead?
The 6 torrents below are the most popular (in order), and account for
98% of the BitTorrent traffic since the 2007.0 release yesterday.
1. livedvd-i686-installer-2007.0
2. livecd-i686-installer-2007.0
3. livedvd-amd64-installer-2007.0
4. livecd-amd64-installer-2007.0
5. install-x86-minimal-2007.0-r1
6. install-amd64-minimal-2007.0
I will be retiring the 2006.1 torrents on June 1st, until then, they are
available at http://torrents.gentoo.org/?category=2006.1
Active threads last week:
=
Announcing GLI ("the installer") 0.5
dev-db/firebird needs an active maintainer
Eigen and GPL-2 exception - is a new licence required?
Increasing contributions and interest via personal project aggregation
invalid in metadata.xml
Last rites sys-apps/855resolution
Linux 2.6.21 plans
mail-mta/courier needs a maintainer
media-sound/DBMix removed from tree
missing metadata.xml
net-www/apache-1* masked.
New herd: kernel-misc
Optional Package Dependencies for netscape-flash -> libflashsupport
Release BitTorrent seeding
RFC: ion license
Suitable USE flag name for stuff that requires non volatile memory
Virtuals and Java
www-client/pybugz needs a maintainer
[RFC - Moving categories around]
[RFC] missing tag in metadata.xml
One sentence summaries on more active threads:
==
RFC: ion license
ion's upstream license prohibits keeping "ion" name if the package is
patched
Eigen and GPL-2 exception - is a new licence required?
Do we have to add a new license for base license + exception or use base
license plus exception?
Suitable USE flag name for stuff that requires non volatile memory
dhcpcd wants to store non-volatile stuff now in some cases
[RFC] missing tag in metadata.xml
no-herd in some cases but not everywhere
Optional Package Dependencies for netscape-flash -> libflashsupport
libflashsupport option with one use flag or multiple ones
Increasing contributions and interest via personal project aggregation
many +1s, antarus has preview working
Last rites sys-apps/855resolution
915resolution is still needed
Last Rites:
===
Last rites: dev-java/jswat
Last rites: app-vim/sudo
Last rites: app-emacs/preview-latex
Last rites: sys-apps/855resolution
So, that's it for this week, happy about suggestions/improvements for
next week ;)
-Jokey
--
[EMAIL PROTECTED] mailing list
[gentoo-dev] Re: Last rites sys-apps/855resolution
> Because it looks like the 2.x intel driver might still need this type of > hack to work properly for some types of machines (my laptop being a good > example of this...) Also 2.x breaks on my notebook when using xinerama and dual monitor atm so nothing rock solid yet ;) Greetz -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Nagios needs a new home err maintainer
There are quite some issues open about nagios stuff and they're piling up... So we need a new maintainer for it. Tracker bug is at https://bugs.gentoo.org/show_bug.cgi?id=172480 Would be sad if we had to drop support for it. If you want to help out and are not a dev (yet), I can commit patches as needed. Greetz -Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: $Header:$ and ebuilds
Vlastimil Babka schrieb: > Thilo Bangert wrote: >> i have never understood why repoman doesn't automatically put the >> commit message into the ChangeLog (share your use case!) > > Yeah I would like at least a switch that would call echangelog first and > then do its stuff, sunrise-commit which I use for overlays has -c for > this. Hm well I can make myself a wrapper but if it was already there, > it would be better :) I do it with a tweak in my .zshrc (attaching it as textfile to prevent weird linebreaks)... Run echangelog, then just do "rc" and all is set (yes, I do it with "erc") ;) Greetz -Jokey rc.sh Description: application/shellscript signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: New developer: Ulrich Müller (ulm)
Petteri Räty schrieb: > Ulrich joins the German conspiracy from Mainz. Okay, who recruited all those german people recently? :D Welcome aboard Ulrich and make yourself at home :) -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New Developer: Tobias Heinlein (keytoaster)
Christian Heim schrieb: > Tobias is joining us from Hamm, Germany where he's currently finishing the > junior high school. Meh, and I overlooked that Welcome aboard and to the mystic german conspiracy :D -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: New developer: Thomas Scharl (think4urs11)
Christian Heim schrieb: > Please welcome Thomas as a new, fellow developer among us ! Wheeheee :D German conspiracy growing again :) Welcome aboard Thomas -Jokey -- [EMAIL PROTECTED] mailing list
[gentoo-dev] Re: genlop-0.30.6 released
Mike Frysinger schrieb: > doubt it'll be possible to convince the developers to merge here ... genlop > is > written in perl and qlop is written in C ... > -mike Maybe we can do this as another 99bottle ;) For those who don't know what it is about, look it up here ... http://99-bottles-of-beer.net/ -Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Manifest2 Transition -- remaining packages
So after peper and myself have been on fixing most stuff related to this topic yesterday, here now is a list with remaining packages and their respective maintainers. http://dev.gentoo.org/~jokey/manifest2/manifest2-20070222.txt Greetz Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Google Summer of Code 2007
Grant Goodyear schrieb: > It's against the rules to have two students working on exactly the same > project, or at least it was last year. Also about last year, are there known improvements other mentoring organizations had out of SoC? (Like KDE, GNOME,...) Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last Rites: net-analyzer/netwatch
Broken with recent kernels and no newer version available on upstream page Bug #167125 Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Another council topic for Feb
Mike Doty schrieb: > Speakup now to get your input in. Why opening up the keywording like that? Most times a friendly ping on irc to get permissions to keyword x packages on own hardware succeedes and you're done. communication++ Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites:net-analyzer/prelude-nagios
Depends on much outdated libprelude and has 404 upstream. Removal on 2nd of March Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New developer: Martin Jackson (mjolnir)
Christian Heim schrieb: > It's my pleasure to introduce to you Martin Jackson (also known as > mjolnir40k - on IRC at least) our latest addition joining the netmon herd. > Please welcome Martin as a new fellow developer among us ! Really looking forward to work with you :) btw in german we have a nice expansion of team... "Toll ein anderer macht's" -> "good that someone else does the work" ;) Welcome in the dev crowd! Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites: net-analyzer/prelude-nids
Package is outdated, dead upstream and snort as frontend is favoured ;) Removal on 1st March Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: GIT vs? SVN (was: Re: Re: [RFC] Some sync control)
Ned Ludd schrieb: > On Thu, 2007-01-25 at 23:37 +0100, Markus Ullmann wrote: >> So to avoid thread hijacking, starting a new one. > > What exactly is this thread you are starting about? Just letting us know > you did some random testing? > More doing a test for a daily workflow and I'll continue it to see how it works out. I also hope to get some input on it from others. Maybe there are users / devs out there with more experience and are willing to share it. Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] GIT vs? SVN (was: Re: Re: [RFC] Some sync control)
So to avoid thread hijacking, starting a new one. I did some tests today and took sunrise overlay as testing ground. It has roughly 2850 revisions. As a blog recommended, I fetched the raw repo first to do the initial conversion to git. Then all I did was a git-svn init file:///home/jokey/sunrise-svn && git-svn fetch It took 5 minutes and 12 secs for me on a not-so fast box. Then I had a git repo that could do all the branching, file merging and stuff and it sends it back to repo nicely. Even a reversion of a commit worked perfectly. git log gave this output: commit a8c35b8efe130fca7e2c3bb0d589a2d251f381c3 Author: ndansmith <[EMAIL PROTECTED]> Date: Thu Jan 25 03:35:02 2007 + Removing old turl files in favor of surl git-svn-id: file:///home/jokey/test/[EMAIL PROTECTED] 12608f7e-a915-0410-b2f3-ce240db1b126 So judging from this, I'd say we could use advantages of both. Those who wish git can go for it (the git repo, as pointed out on this list, can initially be fetched via rsync or tarballs or whatever comes in handy) and those who dislike git can just go with svn and be happy with it. Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Overlay commit messages
James Cloos schrieb:
> Since there are no lists receiving commit messgaes, trac's timeline
> rss feed is the only way to keep track (no pun intended) of updates
> to the various svn-managed overlays, such as on overlays.gentoo.org,
> sunrise, etc. AFAICT, trac's rss only supports the commit messages
> and URLs to the diffs.
Partly, CIA comes in handy sometimes.
> We users would appreciate it greatly were you devs to be more diligent
> in mentioning the ${CATEGORY}/${PN} in the commit messages.
For Sunrise we use a tool called sunrise-commit (works on any other svn
repo as well) that automatically injects the path into the commit message.
an example can be seen here:
http://cia.navi.cx/stats/project/sunrise/.message/2baac3
Maybe we could improve it a bit for git support as well and then
recommend it as tool to use with overlays. Thoughts?
Jokey
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: [RFC] Some sync control
Donnie Berkholz schrieb: Greg KH wrote: What was the reasons he cited? Given that ports is pretty similar to our gentoo-x86, I'd guess about the same ones mentioned at http://dev.gentoo.org/~antarus/projects/gleps/glep-0666.txt -- I quote from there: 1. Git currently requires you to check out the whole repository. This includes *all of the history*. 2. Git cannot update portions of the repository, it can only update the entire thing. This was one of the big reasons. They (and we maybe as well) have people there with 56k/64k dialup connections. Checking out the whole thing would take ages. Second thing was that absolutely none of the scripts would be able to handle it and they would have to be rewritten from ground up whereas most of them would work with svn if you just change the binary path (or symlink it even) > The conversion to GIT from CVS was also lengthy > (approximately two weeks) althought many projects attempted a switch > this summer and tools have improved in speed. This one was the third. At the time they tried, the conversion could not be suspended, so cvs would have to be taken offline for a really long time. And the last thing was the idea about distribution. There is one "centrally" maintained tree and people commit to it all day. So the chance of getting conflicts in pushes if one is on tour for three days would be very likely and so the distributed part of the VCs wouldn't be helpful. Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Some sync control
Steve Long schrieb: I'm looking for a distributed SCM atm, and have come down to git, bzr, svn or arch. svn is centralized ;) I'm leaning to git simply because it's used for the kernel, which seems > like a project that would really stretch a VCS. Well the kernel is quite large but doesn't use that many different things, so it heavily depends on what you do. > Robin H. Johnson wrote: > My personal view (not infra) on it, is that I'm mostly negative about > changing VCS at all - I would prefer not to change, because the status > quo works very well as it is. Well it works, no question on that. But there's still room for enhancements ;) > If a change is going to be made, it should be taken as a chance to > resolve as many different issues at one time as possible, and for > that reason I favour GIT over SVN. I've talked to a friend of mine recently. He's a FreeBSD dev and he said they tried git for their ports tree (which is basically the same what we're talking about) and it was more or less a big pain for multiple reasons. He said he'd personally take svn after that experience. Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Ideas for projects...
Thilo Bangert schrieb: > and also the list of aging ebuilds with unstable keywords could be another > project that perhaps could be revitalised through the council's action... Right, well don't need to work on it asap as http://gentoo.tamperd.net/stable/ still works (made by aliz originally) Greetz Jokey -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New developer: Miroslav Šulc (fordfrog)
Jakub Moc schrieb: > Yay, the Czech beer conspiracy is growing! Welcome! You'd share your beer? :D Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [rfc] transition system loggers to 'adm' user/group
Diego 'Flameeyes' Pettenò wrote: > It would be really nice, especially if the adm group could be used to be able > to read the logs without using root login :) ++ on that :) Greetz Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Proposal of new global useflag: avahi
% cat /usr/portage/profiles/use.local.desc | grep -i ":avahi" gnome-base/gnome-vfs:avahi - Support for avahi mdns daemon. gnome-extra/gnome-games:avahi - Support for avahi mdns daemon. kde-base/kdelibs:avahi - Support for avahi mdns daemon. media-sound/mt-daapd:avahi - Use avahi instead of howl as mdns daemon media-sound/pulseaudio:avahi - Use avahi instead of howl as mdns daemon media-sound/rhythmbox:avahi - support for avahi mdns daemon media-video/vlc:avahi - Support for avahi mdns daemon. net-im/ekiga:avahi - Support for the avahi mdns daemon net-im/gaim:avahi - Enable using avahi howl libraries. net-misc/vino:avahi - Build with avahi support sys-auth/nss-mdns:avahi - enable support for Avahi this may reside as local flag description: sec-policy/selinux-desktop:avahi - Add avahi SELinux policy. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] The long story behind our new developer: Peter Weller (welp)
So it's here a bit late due to some mail issues but never the less Once upon a time there were some devs and a welp and they had a potentially crazy idea. welp: "I have an amd64 box sitting around here and just doing nonsense. Can I help you with doing something useful?" dev1: "Heh, look there, another arch tester for us :)" dev2: "Yup. See the URL in the topic, you can help us by testing packages on amd64" welp read through the page carefully and started working. Some days passed by and welp did a good job. But he definitely wanted more welp: "Is there something special required to work on this overlay?" dev3: "Nothing except some ebuilds you worked on and a password ;)" welp nopasted some ebuilds he wrote and after some improvements he committed them. He got familiar with it and advanced to a trusted committer and well-respected commenter pretty fast. So quite some weeks later the devs wanted him to take the end of mentoring quiz so that he could work on all the packages he provided in the tree. And if he doesn't sleep already, he still cares about all the open bugs. END Now you know the story behind our new amd64/bugday/xfce dev from UK. I think he deserves the usual happy welcome :) Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last Rites: net-analyzer/zodiac
Broken with GCC 4 and dead upstream related bug #153257 Greetz Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: New developer: Cédric Krier
Petteri Räty schrieb: > So please give cedk the usual warm welcome. Welcome and make yourself at home :D Jokey -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: mirroring distfiles/patches on patches.gentoo.org
Francesco Riosa schrieb: > Also I'm offering again, some space and bandwidth in germany Maybe we could also set up the box from bug #108379 (as mirror?) for patches. It has plenty of bandwith sitting around and not doing that much currently ;) Greetz Jokey -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Future developer
Paul de Vrieze wrote: > I'm proud to announce the arival of a future developer. His name is "Tom". He > arived last monday on 10:22 am (UTC+02). I and my wife will take care of > mentoring him to full developership ;-). Congrats... So how does it feel to fork(); ? ;) Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Security Dev : Falco
Shyam Mani wrote: > Please extend a warm welcome to Raphael Marichez aka Falco, our newest > addition to the Security team. Welcome on board Falco :) Have a nice warm home here Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Project Sunrise -- Proposal
Ryan Hill wrote: >> 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. > > Would they be considered Gentoo staff, with everything that involves (quiz, > etc)? No, they are only given permission for the project. Becoming a gentoo developer is a separate step and involves a full recruiting. However, they need to do the normal ebuild quiz with one of the project devs to be allowed to commit to the project overlay on their own. >> 7) tag on bugs >> >> All ebuilds that are made available on sunrise get an InOverlay KEYWORDS >> entry on bugs.g.o so that everyone, who looks at the bug, knows about it. > > Would it also be useful to also have a keyword to indicate that the Sunrise > ebuild has reached the point where it could be migrated to the gentoo repo if > a > maintainer for it steps up? I'm thinking that would make it easy to get a > list > of all m-w ebuilds that are ready for the tree. Maybe a page listing these > packages would also be a good idea. Okay so leave a comment on the bug for now and later on we can follow your idea here and provide a "ready to move over list" as well, which seems quite a good idea :) Greetz, Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Project Sunrise -- Proposal
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). 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. 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. 4) work needed by herds - take a look at the homepage of the new program - take a look at the ebuild If you're at least partly happy with the new app, drop a note on the bug or just ping sunrise that you're ok with it. Then sunrise takes it over and improves the ebuild together with the contributor so that it reaches a level where it could theoretically be committed to the tree. Herds are more than welcome to help here if they feel like it but basic checks whether the app should ever be on gentoo will be sufficient. 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. 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. 7) tag on bugs All ebuilds that are made available on sunrise get an InOverlay KEYWORDS entry on bugs.g.o so that everyone, who looks at the bug, knows about it. 8) Grace time also given from the go point on. When we see that this gets a bit fine-tuning / acceptance among devs, we will explicitely call out a two weeks notice for ebuilds currently assigned to maintainer-wanted so that herds can keep an eye on them and either comment as given, reject take over permission completely, close as WONTFIX in case they're against the app for the tree in futures or just drop a note that they're fine with the take over and the development can be started on the ebuild. Remember the way they need to be reviewed as said in 4). The ebuild is subject to development, the sunrise devs do help with it in case your herd lacks time to completely take care of it. 9) Security In this early stage we have no security liaison on board yet. If one is willing to help out here, we'd be more than glad on welcoming him :) Greetz, Jokey signature.asc Description: OpenPGP digital signature
[gentoo-dev] Sunrise Project -- Open questions post requirement
Hi, so as I was told that I avoid the questions regarding this project several times now, please repost all open issues you have with this project clearly, each in one or max two short sentences here. I'll answer them all the same way to keep out all non-belonging stuff. Maybe that way we avoid any misunderstandings, nearly doubled posts and repeating ourselves over and over again. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Chris Gianelloni wrote: > On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: >>> I know that when I spoke of security, I was not only talking about the >>> security of letting non-developers commit to an overlay that is, by >>> design, for end users, but also of the implications of ensuring that any >>> packages in these overlays are not vulnerable to exploits. >> You're right here, there is a chance that your system gets vulnerable. >> But this isn't limited to this one overlay. All overlays are affected here. > > Not like you think that they are. Let me try to make this clearer. > > The php overlay is maintained by the php developers. They are > intimately aware of the issues with their package, and are probably > aware of any security bugs before the rest of us. > > You are talking about a random collection of ebuilds with absolutely no > cohesiveness other than they were submitted to bugzilla. How are you > going to maintain any form of security on this project? > The approach is to get them maintained... But there is a chance that there'll be security bugs in it, I admit that. Once we know about it, we p.mask it as we have support for it in the overlay. I'm following most common vuln lists and run some automated scripts already on installed packages, should be easy to adapt them to search one other dir as well. >>>> 2) responsibility >>>> > > No. It clearly says that you would be doing the basic QA checks and > repoman checking on initial commit. You even said it right above where > I commented! You're doing some witch hunting here... I said we keep an eye on non-devs commits. > >>> Honestly, having to break out a subversion client to check a fix >>> immediately sounds like extra work. It is usually much easier to simply >>> look at the attachment online and make a decision immediately. >> You don't need a subversion client, you perhaps notice the http in front >> of the url.. just open it up in your browser and you get the source >> immediately. > > Umm... so now I need to go and instead of clicking a nice link in > bugzilla, trawl through the subversion repository and find what I'm > looking for? How exactly is downloading things via http any different > than downloading them from bugzilla, which is also http? the key difference is that you only need one wget command to get a completely prepared dir to work on, no ebuild renaming manual files/ population needed. > Now, I know that you're not an idiot, so please don't treat me like one. Was really not the intention.. You keeped the svn requirement which is simply wrong. Needed to make that clear. >> Or, if you want some history like sources.g.o, you can do so as well here: >> http://overlays.gentoo.org/proj/sunrise/browser/ > > Excellent. So we're moving the history from being in a single location > (the bug) to being in multiple locations. That will definitely improve > the development process. Another thing that people tend to miss is that > not all improved versions of ebuilds submitted to bugzilla are done byt > he original authors. There are many cases where an initial ebuild is > done, a developer makes comments on what needs to be changed, and > *another* contributor gives a fixed ebuild. How exactly will this > streamline that process? No offense, but everything I have seen looks > as if it will add even *more* overhead to actually getting packages into > the tree. The only thing this seems to provide is a half-baked > repository for the users to get marginally-tested ebuilds for software > that wasn't interesting enough for inclusion in the tree. we want to encourage users to contribute and if they do good contributions in bugzilla they get commit access to the overlay. and then the workload is drastically reduced... >>> How exactly are they >>> supposed to know that this user has pam_skey even *available* to them >>> when all they see as an overlay is "sunrise" and not the >>> project-specific overlays that overlays.gentoo.org was designed for? >> Well as the ebuilds in there already have open bugs, comments can be >> attached there. > > This is a bug for an ebuild that the user does not think is related to > the pam_skey. Go back and read what I wrote. > it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on "new" bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. >> Secondly, the portage team already integr
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
First let me state this one really important thing: The sunrise project is a project on its own. We're about to convert it to a TLP to make clear that it shares nothing with the overlay project except the hardware ressources and the overlay feature of portage. Chris Gianelloni wrote: > On Thu, 2006-06-08 at 20:58 +0200, Markus Ullmann wrote: >> To clarify things a bit (hopefully): >> >> 1) security >> > I know that when I spoke of security, I was not only talking about the > security of letting non-developers commit to an overlay that is, by > design, for end users, but also of the implications of ensuring that any > packages in these overlays are not vulnerable to exploits. You're right here, there is a chance that your system gets vulnerable. But this isn't limited to this one overlay. All overlays are affected here. >> 2) responsibility >> >> As already mentioned at 1), it is an overlay. The devs on sunrise do >> keep an eye on it and all ebuilds do have to pass at least repoman and >> some basic QA checks (currently done when porting them from bugs.g.o) so >> that they don't do some rm -rf / thing. They should be improved by the >> contributors then so that we have two things here: a) a contributor who >> can contribute good-quality ebuils and b) a good ebuild to be picked up >> by a dev and ported to the tree > > The problem is that you are only checking on the initial commit. Go > back to point #1 (security). You just assume this, no real reason/example for it. > Again, the entire concept of overlays.gentoo.org was stated again and > again that this would *not* be the result of the project. Many of the > maintainer-wanted ebuilds are quite good, many need to be completely > rewritten to even work properly. First let me say this. We don't blindly commit things here nor do we commit everything from m-w bugs. There is this interface inbetween called human intelligence. So I can convince you that I do look at things that are committed. > This also completely missing the point that most of the things in > maintainer-wanted are there because there is not a developer interested > in them. How will this change by moving the ebuild into an overlay, I > have yet to hear. Well if you can look / test a bit easier, that helps a lot... Some (won't exclude myself here) are just a bit lazy if they see a bunch of things to download, rename and move instead of a single checkout command ;) >> 3) replacement for bugs.g.o >> >> This project isn't a try to replace the contributions to bugs. It should >> just help to fetch and update things. We have help from bug-wranglers >> here (well, at least from jakub) to keep the overlay in sync with it so >> that one can say "Yeah, my-example/myapp r158 has this and this issue, >> here is a fix for it" and then either the sunrise-devs or one of the >> project-contributors commits it to the overlay. > > Honestly, having to break out a subversion client to check a fix > immediately sounds like extra work. It is usually much easier to simply > look at the attachment online and make a decision immediately. You don't need a subversion client, you perhaps notice the http in front of the url.. just open it up in your browser and you get the source immediately. Or, if you want some history like sources.g.o, you can do so as well here: http://overlays.gentoo.org/proj/sunrise/browser/ >> 4) workload on devs >> >> Well I really have problems to see increased workload on devs here who >> don't actively support the project. They can scour bugzie for >> interesting ebuilds and instead of fetching files, renaming them, moving >> them to a local overlay dir, just do a svn co >> http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an >> example here) and you have all needed files already prepared to look at >> them or to give them a try. > > Except that I can *look* at an ebuild without having to break out a > subversion client currently. See my answer in 3) Also, you completely gloss over the fact > that this is a overlay designed for end-user usage. This means that > anything in this overlay is *very* likely to be on user's machines and > cause any number of possible problems. Let's use your pam_skey as an > example. Now, let's say that someone has this installed, and has > configured it improperly. They file a bug because they are unable to > login, and the pam maintainers receive the bug. > How exactly are they > supposed to know that this user has pam_skey even *available* to them > when all they see as an overlay is "sunrise" and not the > project-specific overlays that overlays.gentoo.org was desig
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
My intention was to solve some parts with him directly and then send out some solutions but he wants to do everything on list, so I'm sending it out for you to know. -- LOGPOST -- [22:09:15] so after reading your posts I get the impression you fear that this project will end up in some BMG overlay just with an official gentoo stamp on it. Am I right here? [22:10:22] please read what I said in #-releng [22:11:45] Yes I want to do it public, maybe just attach a log of this to a mail sent to -dev afterwards. just want to avoid having that much emails just for seeking the issues instead of finding solutions for them [22:11:52] I think it is a bad idea [22:12:21] quite simply, when the overlays project was formed, this was something that was specifically said would never happen [22:12:41] I'm going to fight it tooth and nail, because I never would have accepted a project such as overlays if it was going to be abused like this [22:13:02] and please don't even say it won't be abused when there's already examples of it being done so [22:13:07] and the overlay just began [22:13:16] and that's really all I have to say about it [22:13:39] (sorry, I prefer my discussions on things that affect *everyone* be done completely in public) [22:14:31] okay, I'll attach this then to a mail just that everybody knows about it then -- LOGPOST -- Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
Henrik Brix Andersen wrote: > > It's not a "normal" overlay as I see it. You've promoted it to be an > > official overlay. The difference is huge in my opinion. Well partly you're right. As it is promoted that way it is a bit more official but anyway still an overlay. > > Will you also review the code each and every ebuild pull down over the > > internet? Well at least briefly. We decided to maintain it in an official way and thus keep an eye on the quality of the checkins. As said, at least a briefly view at it and also a repoman scan. We're going to have some contributors at it so it wouldn't be an easy job but I think we can get some more of them that way. Searched my inbox and found a mail saying this: --- Paste --- "He was trying to recruit me as a Gentoo developer. Unfortunately, I turned him down, the main reason being time. Also, I don't really need/want the status/powers/responsibilities that come with being a developer, so that was another reason. He then suggested that I become an arch-tester, or maybe contribute to this public overlay that you have in mind. The arch-tester position didn't seem that appealing to me. The public overlay on the other hand is more suitable for me. I like to write the occasional ebuild and there are some ebuilds writen by me in Bugzilla that are currently assigned to maintainer-wanted so getting these in an overlay would be nice. Also, I would assume that the barrier of entry and time requirements are lower than the developer position. --- Paste --- Sounds he likes to contribute / maintain some apps, just not the whole thing you have to do when being a full dev. But he expressed his interest in this as a possible entry point. So I guess we can keep an eye on him... But one thing is important: As the project has some overlay nature, there _may_ be the one or other small issue with it. On the other hand what ebuild is 100% bugfree? ;) QA would have nothing todo then... And here we don't break the (stable) tree if some really nasty issue ever slips through our fingers. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
To clarify things a bit (hopefully): 1) security This is not the main tree, just a normal overlay. Okay, some non-devs contribute here but doesn't change the fact that it is just an overlay as any other out there in the world. Well, it is a bit different. Here are some devs keeping an eye on the evolution and can help people with doing it right and thus get better contributions in the end. 2) responsibility As already mentioned at 1), it is an overlay. The devs on sunrise do keep an eye on it and all ebuilds do have to pass at least repoman and some basic QA checks (currently done when porting them from bugs.g.o) so that they don't do some rm -rf / thing. They should be improved by the contributors then so that we have two things here: a) a contributor who can contribute good-quality ebuils and b) a good ebuild to be picked up by a dev and ported to the tree 3) replacement for bugs.g.o This project isn't a try to replace the contributions to bugs. It should just help to fetch and update things. We have help from bug-wranglers here (well, at least from jakub) to keep the overlay in sync with it so that one can say "Yeah, my-example/myapp r158 has this and this issue, here is a fix for it" and then either the sunrise-devs or one of the project-contributors commits it to the overlay. 4) workload on devs Well I really have problems to see increased workload on devs here who don't actively support the project. They can scour bugzie for interesting ebuilds and instead of fetching files, renaming them, moving them to a local overlay dir, just do a svn co http://overlays.gentoo.org/svn/proj/sunrise/sys-auth/pam_skey/ (as an example here) and you have all needed files already prepared to look at them or to give them a try. 5) the tarball problem On some bugs we also notice that people contribute tarballs instead of ebuilds and the files as such. Some apps need a change on a bunch of files with every version bump. Take MailScanner as an example ( http://bugs.gentoo.org/show_bug.cgi?id=36060 ). Many devs cry out loud when they come across a tarball on bugzie. It is not the best way of contribution, I know that myself. But take it the otherway around. Someone out there took time (on some apps it is really much time) and provided an ebuild. Maybe he is new to it and doesn't know much about bugzie (no usability talk required here, done every 3 months on bugzie devel ml) then they post their hard work there. Then a dev comes along and says "never ever do attach tarballs blah blubb", the contributor feels scared as it was his first contribution and the dev was crying out loud and would surely think twice if the work done is worth it. 6) problems on infra hardware Well Lance arised that, so if infra has that big concerns about this project (I personally see no hard reason for it, but let the infra guys handle it how they want), then feel free to drop me a note and we host it elsewhere. I really see a great chance for contributors here as they can improve themselves here and if they contribute good quality, even commit themselves and learn how to handle maintainership. You all know we also have some people out there that would like to maintain just one or two packages. Now we call it proxy maintainership but why not giving them commit access to sunrise then? They can maintain it here without the whole workload as dev, but maybe they get encouraged by doing so and then become a dev later. Lots of options are possible here. 7) non maintainer-wanted things Some ebuilds found their way into the overlay, we talked about that internally and I'll remove them after this mail is sent out, so that we stick to maintainer-wanted things here. Greetz, Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Developer: Chris Parrott
Mike Doty wrote: > All- > > Chris has move from various AT projects to a developer. cparrot was > fist on the amd64 AT project, then he moved on to other arches and some > other hards. It's my great pleasure to have him as a gentoo developer. > > --Mike Congrats and welcome to t3h team ;) Jokey signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New Developer: bangert
Hopefully he signs some contracts to never leave again... Re-Welcome on board :) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] New ebuild Developer: Christian Hartmann (ian!)
YaY, b0rkage will go away :) Welcome ian -- gentoo-dev@gentoo.org mailing list
