Real Name: David G
Real Name: David Gümbel Email: david.guembel@gmx.de Mentor: lanius IRC Nick: ganymede Location: Germany Reason for joining: Help out with wine, which is currently unmaintained. Begin of recruiting period: 31. Oct 2004
what's the status on this one?
I'm working on a wine-config tool (like java-config and the like), and will submit a testing version tomorrow (sunday). I'm a little busy at the moment, as I have put much effort into helping with organizing Wineconf 2005[4] so what I have done for Gentoo yet is * started taking care of the wine-config issue [1] * spoke my mind on crossover office source ebuilds [2]. I agree with vapier that if someone provides a working one, I'll test it, but personally I won't (and he won't) create one, for reasons to be found in the related bugzilla page. * got into nwwine ebuild [3]. This can't be fixed without a wine-config tool, so I moved that to top of my agenda. However, the latest nwwine version is from 2003, so this software doesn't actually seem vividly maintained to me. * in totally unrelated news, I helped a little with FreeNX problems[5]. I have yet to return the Quiz's anwers to lanius, something that is also on my agenda for tommorrow. Sorry for the delays. If there are any questions open, please don't hesistate to ask. Bye, David [1] http://bugs.gentoo.org/show_bug.cgi?id=9842 [2] http://bugs.gentoo.org/show_bug.cgi?id=66843 [3] http://bugs.gentoo.org/show_bug.cgi?id=44654 [4] I am with WRS, who has offered to host Wineconf, the Wine developers conference, and I am part of the "Wineconf Committee": http://www.winehq.org/hypermail/wine-devel/2004/11/0647.html [5] http://bugs.gentoo.org/show_bug.cgi?id=71522
OK, here are my answers to the ebuild development quiz: > Ebuild development quiz > Revision 1.10 - 05 August 2004 > Answer in whatever length necessary for completeness. > Review documentation. Consult your mentor if you're unable to locate > answers. > > *** Organizational structure questions > > 1. When is it appropriate to post to gentoo-core rather than gentoo-dev? When discussing issues not directly related to Gentoo development issues, but nevertheless only of the interest of core Gentoo developers. Security issues that are not yet verified or schould not yet be disclosed to the general public also are to be discussed on gentoo-core. > 2. Who should be contacted with complaints about specific developers or > projects? ombudsman@gentoo.org or devrel@gentoo.org > 3. What is the proper method for suggesting a wide-ranging feature or > enhancement to Gentoo? Creating a GLEP (Gentoo Linux Enhancement Proposal). > 4. What is the purpose of the Gentoo management team? It manages the Gentoo top-level projects, which comprises several tasks, a very iportant of which is decision making. Every top-level project manager is accountable for the project(s) he/she manages, and responsible for communicatin its stauts to the rest of the top-level managers + the chief architect. Additionally, the managers have a bunch of responsibilities, which are explained in detail on the Gentoo Top-Level Management Structure webpage (http://www.gentoo.org/doc/en/management-structure.xml). Basically, these are rules how to manage projects and how to deal with the associated tasks such as roadmap definition, communication, meetings etc. > 5. What is the purpose of the Gentoo Top Level Project (TLP) structure? To keep track of the Gentoo top-level projects, that is projects that are crucial to Gentoo development, like security, portage, etc. as well as important enhancements like gentoo-hardened. > 6. What is the purpose of herds? With the number of ebuilds rising, the need for grouping developers (i.e. ebuild committers) together that work on related ebuilds, such as x11-related, wine-related, mozilla-related etc. ebuilds became obvious. These groups are called herds. > *** Ebuild technical/policy questions > > 1. You change a package's ebuild to install an init script. Previously, > the package had no init script at all. > Is a revision bump necessary? Why? What about when adding a patch? Yes, because the ebuild policy says: ----- Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade. Typically, this is the case when fixes are made to an ebuild that affect the resultant installed files, but the ebuild uses the same source tarball as the previous release. ----- If adding a patch doesn't affect many users and only comprises a stylistic change rather than a functional one, no revision bump is needed. If that's not the case, revision has to be bumped. > 2. A user submits a "live" CVS ebuild. What would be a preferable > alternative to such an ebuild? A snapshot cvs ebuild, i.e. an ebuild that builds a previously created snapshot of the cvs tree rather than downloading the source from cvs at build time. > 3. (a) What is repoman? How would you check for QA problems with > repoman? repoman is a QA tool that checks for common problems in ebuilds and helps developers make sure their commits don't break the portage tree. The manpage says it all: cd $MY_EBUILD_DIR and run "repoman scan" in order to run a QA check. Always use repoman for CVS commits rather cvs directly. > (b) A user submits a brand-new ebuild for a new package. What are the > proper steps (including repoman/cvs commands) to take to add > this ebuild to the tree? * cd (e.g.) app-emulation/ && cvs update * create the directory for the ebuild, e.g. app-emulation/myemu * cvs add myemu * create the ebuild file + digests * Create a ChangeLog entry (like: $date; D.G
OK, here are my answers to the ebuild development quiz: > Ebuild development quiz > Revision 1.10 - 05 August 2004 > Answer in whatever length necessary for completeness. > Review documentation. Consult your mentor if you're unable to locate > answers. > > *** Organizational structure questions > > 1. When is it appropriate to post to gentoo-core rather than gentoo-dev? When discussing issues not directly related to Gentoo development issues, but nevertheless only of the interest of core Gentoo developers. Security issues that are not yet verified or schould not yet be disclosed to the general public also are to be discussed on gentoo-core. > 2. Who should be contacted with complaints about specific developers or > projects? ombudsman@gentoo.org or devrel@gentoo.org > 3. What is the proper method for suggesting a wide-ranging feature or > enhancement to Gentoo? Creating a GLEP (Gentoo Linux Enhancement Proposal). > 4. What is the purpose of the Gentoo management team? It manages the Gentoo top-level projects, which comprises several tasks, a very iportant of which is decision making. Every top-level project manager is accountable for the project(s) he/she manages, and responsible for communicatin its stauts to the rest of the top-level managers + the chief architect. Additionally, the managers have a bunch of responsibilities, which are explained in detail on the Gentoo Top-Level Management Structure webpage (http://www.gentoo.org/doc/en/management-structure.xml). Basically, these are rules how to manage projects and how to deal with the associated tasks such as roadmap definition, communication, meetings etc. > 5. What is the purpose of the Gentoo Top Level Project (TLP) structure? To keep track of the Gentoo top-level projects, that is projects that are crucial to Gentoo development, like security, portage, etc. as well as important enhancements like gentoo-hardened. > 6. What is the purpose of herds? With the number of ebuilds rising, the need for grouping developers (i.e. ebuild committers) together that work on related ebuilds, such as x11-related, wine-related, mozilla-related etc. ebuilds became obvious. These groups are called herds. > *** Ebuild technical/policy questions > > 1. You change a package's ebuild to install an init script. Previously, > the package had no init script at all. > Is a revision bump necessary? Why? What about when adding a patch? Yes, because the ebuild policy says: ----- Package revision numbers should be incremented by Gentoo Linux developers when the ebuild has changed to the point where users would want to upgrade. Typically, this is the case when fixes are made to an ebuild that affect the resultant installed files, but the ebuild uses the same source tarball as the previous release. ----- If adding a patch doesn't affect many users and only comprises a stylistic change rather than a functional one, no revision bump is needed. If that's not the case, revision has to be bumped. > 2. A user submits a "live" CVS ebuild. What would be a preferable > alternative to such an ebuild? A snapshot cvs ebuild, i.e. an ebuild that builds a previously created snapshot of the cvs tree rather than downloading the source from cvs at build time. > 3. (a) What is repoman? How would you check for QA problems with > repoman? repoman is a QA tool that checks for common problems in ebuilds and helps developers make sure their commits don't break the portage tree. The manpage says it all: cd $MY_EBUILD_DIR and run "repoman scan" in order to run a QA check. Always use repoman for CVS commits rather cvs directly. > (b) A user submits a brand-new ebuild for a new package. What are the > proper steps (including repoman/cvs commands) to take to add > this ebuild to the tree? * cd (e.g.) app-emulation/ && cvs update * create the directory for the ebuild, e.g. app-emulation/myemu * cvs add myemu * create the ebuild file + digests * Create a ChangeLog entry (like: $date; D.Gümbel <ganymede@gentoo.org> ChangeLog: Added ebuild, thanks to joe@user.com) * cvs add foo-1.0.ebuild ChangeLog files ; cvs add files/digest-myemu-1.0 * in the ebuild's directory (in PORTAGE_OVERLAY usually), do a repoman scan; repoman fix; repoman commit; > 4. A user submits an ebuild that has numerous technical problems and > violates policy. How would you handle that situation? Explain the problems and ask him to fix it, keeping track of the progress in the associated bug report. Provide assistance to him if neccessary. If I have a lot of spare time, I might even fix it myself ;) but that's not going to be the usual procedure. > 5. You have a set of new ebuilds that could potentially benefit > from a global USE flag. What steps should be taken before > a new USE flag is implemented? What should be done if the > USE flag only applies to a single package? Before implementing that USE flag, it should be asked for review/agreement on gentoo-dev. A USE flag that only affects one package is potentially not a good idea. If I chose to create a USE flag anyway, goes into use.local.desc instead of use.desc > 6. You're creating an ebuild. Unfortunately, the ebuild's 'make install' > target causes numerous access violations. What is the best > course of action to take to have a clean, straightforward > ebuild? Don't use "make install", use dobin, doman, dolib etc. > 7. You're creating an ebuild that needs a patch. The patch is > nontrivially large - bigger than 20kbytes. Where should > the patch be kept? The same location as the distfiles, i.e. the source of the package itself. > 8. You're creating an ebuild that has its own license - one that > doesn't exist in /usr/portage/licenses/. What is the proper > course of action? Add the license text in an appropriately named file to CVS, in the same commit as ebuild and ChangeLog. Licenses are inside /usr/portage/licenses/. > 9. (a) You wish to mark an ebuild "stable," taking it out of ~ARCH > KEYWORDS. It's a library. What steps should > be taken to do so? Test it on all arches I have access to, and only mark it stable there. For all other arches, file a bug with the corresponding arch team. As it is a library, It would make sense to use upstream provided tests (sometimes available via "make test"), or a (stable) application that makes use of the library for testing purposes. > (b) You wish to mark an ebuild "testing," putting it into ~ARCH > KEYWORDS. It was previously hard-masked in package.mask. > What should be done prior to doing so? Resolve the reason why this package was hard masked ;) Change package.mask and commit it prior to committing the ebuild. > (c) You wish to mark an ebuild "stable." It is a popular > application, but no other ebuilds depend on it. > What should be done first? Test the application before committing the changed ebuild. > 10. You're committing a user-submitted ebuild. What should be in the > initial ChangeLog? In addition th the usual "What? When? Who? Why?", a line crediting the user who supplied the ebuild. > 11. What is the difference between DEPEND and RDEPEND? DEPEND are build-time dependencies, while RDEPEND are run-time dependencies. > 12. You wish to make a change to an ebuild, but you checked > ChangeLogs and metadata.xml and it appears to be maintained by > someone else. How should you proceed? Contact the maintainers, and if desired supply them with a patch. > 13. You find a situation in which an eclass may be useful. What should > you do before implementing such an eclass? Ask on gentoo-dev for any objections or anybody maybe working on the same thing. Before that, ask yourself if the complexity added by a new eclass really gives enough added usefulness to justify its creation and maintenance ;) > 14. You find a package that will not build on some architectures without > PIC (-fPIC) code in the shared libraries. What is the proper way > to handle this situation? Patching the Makefile (only for the libraries) to build with -fPIC. > 15. What do you do when you'd like to have a package you maintain > tested or marked stable on other architectures? Call for testers on gentoo-dev or in the appropriate herd (sparc, ppc,..). If testing is successful, it will be marked stable for that arch by the corresponding herd. > 16. How can you verify an ebuild has correct run time dependencies > (RDEPEND) for all installed binaries? Use ldd to determine its binaries' dynamic linking, and look for the packages the dynamically linked libs belong to. > 17. How do you deal with a situation in which an ebuild wishes to > install a file already installed by another package? Either let the packages block each other, or (mabye better) find a solution for coexistence, i.e. remove the file from one of the packages. > 18. Most configure scripts attempt to automatically determine > settings based on the host system. When should the ebuild > specifically override settings? When the local configuration provides more accurate information. That applies to CFLAGS (of course) as well as to the --enable-xy/--disable-xy options of configure, which should be set according to the USE flags for the package, and of course to installation into non-standard locations for Gentoo. > *** Please also submit the following information: > > * GPG public key ID (if you do not have one, please create one) 0x85E4FEEC > * Date of birth January 16, 1980. > * What are your programming/scripting skills, if applicable? Fluent in Java, Perl, Scheme. Not bad in bash, C++. Can read and write C, but I don't like that language at all :) > * What other areas are you experienced in? Cryptography, security, operating systems, networking, WINE. > * What other projects have you contributed to, if any? Code: * My own projects, to be found on http://www.david-guembel.de/os.html * KDE (see kdialog --author ;) Non-Code, i.e. bug reports, helping users, helping developers hunt down bugs etc: * KDE (See http://www.kde.org/people/credits/ ) * loop-AES (See e.g. http://www.spinics.net/lists/crypto/msg02889.html) * Wine (Helping organizing Wineconf 2005, the Wine developers conference. Helping users on wine-users. And other stuff ;) * Tuxmobil.org: Documentation on how to run Gentoo linux on my laptop > * Tell us about yourself. This doesn't need to be strictly > computer-relevant; things like where you're from, > hobbies, job, family, interests... Born in Munich (Germany), I moved to Tübingen in 1999 to start studying informatics. I am just about to finish my studies, and am a co-founder of a small enterprise (itomig.de) that sells services based on a research result I made when working on my Master's thesis. That thesis happened to be on efficient application migration to Linux using Wine :-) I am using Linux since 1997, and switched to full-time use (no windows installed anymore) about four years ago. Apart from that, I enjoy reading in almost all its varieties, be it fiction or non-fiction books, newspapers, blogs, usenet, or www stuff. I am fluent in German, English and French, and on perfect days[tm] I manage to spend several hours consuming information from news sources all around the globe. I have a brother and a sister, both still located in the Munich area.
David, please email the end-quiz to recruiters@gentoo.org when you're done rather than posting it here, thanks.
lanius, what's the status here. Please go over the end quiz with David when you can, and when you're satisfied that he's ready, let me know, and I'll review everything and set him up.
lanius went over the quizzes, so I'll look at them and send feedback. David told me he'll be on vacation until the first week of January
feedback sent for end quiz
David, can you please ping me on IRC.
I talked to David on IRC today, and we're going to take care of his account creation after he gets back from a trip at the end of th emonth.
Hey David, everything looks good... Please come talk to me so we can finish setting up your access.
welcome aboard.
Retiring due to inactivity. No cvs commits and last bugs activity 2005-03-19.
Infra: please retire ganymede.
Done
Retired on the forums.
All done.
