[gentoo-dev] how to become a package maintainer
I am a gentoo user and software developer for a quite a little while. I found out that I have some spare time and I like to prepare myself to become a package maintainer. Are there any links that provide volunteers with the neccessary know how of how to maintain a project? I have some money to buy a dedicated machine, preferrably an AMD 64. Projects could be something in C++ combined with networking or PHP/Perl stuff. Just in case I decide not to volunteer for private reasons these papers may be beneficial for others, too. Robert
[gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
Petteri Räty wrote: I wrote a script to check which ebuilds use built_with_use and have keywords in never versions making the ebuild unused. This means that neither arch or ~arch users are likely to install the ebuild. The script and the list of ebuilds is attached. I plan on removing all these ebuilds two weeks from now unless a reason is given why not to. If you see an ebuild on the list that should be kept, please migrate it to EAPI 2. If you need assistance in migrating, I can help. With these gone built_with_use usage will be down to about 600: betelge...@pena /usr/portage $ grep --include *.ebuild built_with_use -r . | wc -l; 923 betelge...@pena ~/bin $ wc -l ebuilds_to_nuke.txt 317 ebuilds_to_nuke.txt Regards, Petteri It's over two weeks now so I will start the cleanup when I have time. I will leave packages that I think are used widely to be last so maintainers of those still have time to do things on their own. I have exams coming next week so it will probably take a while for me to process the list. Here's the people/packages that wanted to be excluded from the list: GNOME gstreamer gnuplot hkBst If I forgot someone, please slap me around a bit with a large trout. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: how to become a package maintainer
Robert Welz posted on Sat, 24 Oct 2009 10:42:48 +0200 as excerpted: I am a gentoo user and software developer for a quite a little while. I found out that I have some spare time and I like to prepare myself to become a package maintainer. Are there any links that provide volunteers with the neccessary know how of how to maintain a project? I have some money to buy a dedicated machine, preferrably an AMD 64. Projects could be something in C++ combined with networking or PHP/Perl stuff. Just in case I decide not to volunteer for private reasons these papers may be beneficial for others, too. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml That's the Gentoo developer handbook, which is a good place to get a feel for what's involved at that level. Note that there's both the formal Gentoo dev political process documented and Gentoo technology (ebuilds, eclasses, metadata, common mistakes, etc) guides. Generally, the idea is to start on something small and work with the current devs. Once they know you, the rest more or less comes naturally over time. Know that there are many who ultimately don't make /that/ big a commitment, but who have time to help with the smaller stuff that's the first steps toward full developership anyway. The bug-day Saturdays are a great way to get started. Or choose an area (Gentoo project) you're interested in, hang out here and/or on the IRC dev channel and/or the the individual project lists and/or channels, follow the bugs for that project, help comeup with and test patches, etc. Many of the projects have testing overlays where stuff that's not ready for the main tree is worked on. Java has a big one, as does KDE, both with a lot of help from non-(gentoo-)dev project testers, many of which have commit rights to they project overlays. There's also the experimental projects, or projects that started that way, that are headed toward merging into the Gentoo mainstream now. Gentoo-prefix, devoted to making it possible to install Gentoo packages in a user's home dir or the like, on Linux or other platforms, is a big one that's headed toward merge at this point. Another way to start if you have specific applications you are interested in is with proxy maintainership if a package is in the tree, or the Sunrise overlay, for packages not yet in the tree. A proxy maintained package has a non-(gentoo-)dev doing much or all of the real work, bug fixing, etc, working closely with a full Gentoo dev (or project/herd if it's herd maintained) doing the final commits to the tree but often little else, at least once the relationship has been established. The Sunrise overlay is for packages not yet in the tree, but that have various Gentoo community users maintaining them. There's a few Gentoo devs that work with them, helping them get the packages into full Gentoo shape, so ultimately, if a dev finds the package useful, they can bring it into the main Gentoo tree where it may continue to be proxy maintained by the same community user. Of course, there's more packages than devs to maintain them, so not all packages ultimately make it into the tree, but Sunrise is there for them as long as there's someone in the community interested in doing the maintaining at that level. The various arch teams have arch-testers (ATs) as well. These guys help the devs on the arch teams test packages for keyword stabilization, etc. Don't forget the Gentoo Documentation Documentation project as well. They could certainly use some help from someone willing to learn the way Gentoo handles its docs and get their hands dirty helping to maintain them. There's always documentation updates that could be done! =:^) Many, probably most Gentoo devs come in thru one of these paths, starting out working with a project in an overlay or with a proxy maintained or sunrise package, or as an AT. Other quite active users at that level are content to stay active at that level without ever becoming full Gentoo devs for whatever reason (time, politics, whatever). Either way, they can rest well, knowing they're filling a vital role in the Gentoo community, and thru it, the larger free/libre and open source software community. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Hi there! Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. It's been proposed to: - keep 'desktop' profile but strip it from any desktop specific features and settings, making it default recommended choice for anyone using non-KDE and non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is free to join and create own DE-specific subprofile if needed. - create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 'desktop' profile and move any desktop specific things there. This should in theory allow us to not add 'recommended' IUSE defaults to desktop specific packages, but keep those settings in profile - making profile effectively 'out of the box' solution for those who need it. If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. Thanks -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
2009/10/24 Maciej Mrozowski reave...@gmail.com: If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. What about people who like to install both gnome and kde on their systems? (Perhaps different users on the computer use different DEs) It probably won't be a problem in the short term (people can just select one profile and add the missing USE-flags to make.conf). But it /might/ get unwieldy in the future if more USE-flags and USE_EXPAND-ed variables make their way into the DE-specific profiles. Since multiple inheritance is not worth the work, I would suggest each project team maintain some minimal documentation in their doc space about the USE-flags and USE_EXPAND-ed variables enabled in each profile. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Maciej Mrozowski wrote: Hi there! Resulting from discussion during last Gentoo KDE team meeting taking place 22 Oct 2009 at #gentoo-meetings (summary fill be available soon), having Gentoo GNOME team representative, it's been decided to go ahead with splitting desktop profile to DE-specific subprofiles, to avoid bloat and provide desktop specific separation which should result in desktop subprofiles being actually practical. It's been proposed to: - keep 'desktop' profile but strip it from any desktop specific features and settings, making it default recommended choice for anyone using non-KDE and non-GNOME desktop environment, yet avoiding USE flags bloat. Any other DE is free to join and create own DE-specific subprofile if needed. Hi, Just so it is clear and there aren't any questions in the future. The XFCE team maintains a set of recommended global use flags in our docs[1] (maintained by Josh (nightmorph)). So, whatever direction this ends up, xfce will not be going down that same road. Additionally, One cool thing about Gentoo is that you *can* have more than one DE installed. We don't have things like KGentoo =P I hope this profile thing doesn't make it harder for end users to use GNOME and KDE at the same time. -Jeremy [1]: http://www.gentoo.org/doc/en/xfce-config.xml - create 'KDE' (or 'kde') and 'GNOME' (or 'gnome') subprofiles within 'desktop' profile and move any desktop specific things there. This should in theory allow us to not add 'recommended' IUSE defaults to desktop specific packages, but keep those settings in profile - making profile effectively 'out of the box' solution for those who need it. If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. Thanks
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
On Saturday 24 of October 2009 16:00:03 Jeremy Olexa wrote: Just so it is clear and there aren't any questions in the future. The XFCE team maintains a set of recommended global use flags in our docs[1] (maintained by Josh (nightmorph)). So, whatever direction this ends up, xfce will not be going down that same road. Well, if XFCE 'satisfying use deps' USE flags are not excessive, I think they could stay in desktop (parent) profile of course as desktop profile is meant for general use desktop. This would address some parts of Nirbheek's concern. Additionally, One cool thing about Gentoo is that you *can* have more than one DE installed. We don't have things like KGentoo =P I hope this profile thing doesn't make it harder for end users to use GNOME and KDE at the same time. That's the 'edge' case we encounter. Of course splitting desktop profile *will* make it harder for them to have GNOME and KDE at the same time. But, to be clear, we're talking here mainly about default USE flags (not gnome-base/* entries in package.mask in KDE subprofile... hmm, jmbsvicetto? worth considering... ;) ) Splitting profiles is to provide out of the box desktop specific solutions (because that's what majority uses afaik, though I don't have any poll to back my words), not to prevent anyone from mixing things - those may just need the same package.use/make.conf effort to set it up (mainly to satisfy USE deps, as one can put recommended USE flags in +EAPI-1 IUSE in desktop environment ebuilds after all). -- regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Splitting desktop profile to KDE and GNOME
Nirbheek Chauhan wrote: 2009/10/24 Maciej Mrozowski reave...@gmail.com: If you have any comments, suggestions, important notices regarding this change, please keep discussion in gentoo-desktop mailing list. What about people who like to install both gnome and kde on their systems? (Perhaps different users on the computer use different DEs) It probably won't be a problem in the short term (people can just select one profile and add the missing USE-flags to make.conf). But it /might/ get unwieldy in the future if more USE-flags and USE_EXPAND-ed variables make their way into the DE-specific profiles. Since multiple inheritance is not worth the work, I would suggest each project team maintain some minimal documentation in their doc space about the USE-flags and USE_EXPAND-ed variables enabled in each profile. You can make your /etc/profile a real profile instead of symlink and using multiple inheritance inherit both GNOME and KDE. The instructions are in man 5 portage. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Amount of useflags enabled by default
El vie, 23-10-2009 a las 22:54 +0300, Petteri Räty escribió: Thomas Sachau wrote: In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? One possible reason is that our packages should follow upstream policy and maybe upstreams usually like to keep things enabled rather than disabled. Regards, Petteri I don't see any problem in enabling some USE flags by default but, maybe, would be interesting to have a place where people could consult why some USEs are enabled and, specially, disabled by default. The problem is where to write that information :-/ (into the ebuild, into metadata file...) Best regards
Re: [gentoo-dev] Amount of useflags enabled by default
Sebastian Pipping schrieb: Thomas Sachau wrote: In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). I'm not sure for how much of the IUSE=+foo cases this applies but I can explain one of them: In xfce-base/xfce4-session-4.6.1-r1 there is +fortune in IUSE because otherwise previous users of 4.6.1 would be missing the feature enabled by it. If you worry that +foo is becoming a trend _without_ strong reason you could try enforcing documentation for in metadata.xml (through new tags) maybe. Sebastian This is a nice example for a default enabled USE flag, where i see no strong reason to enable it. Now i dont know that package nor do i know how many users actually use that feature. If the majority uses that feature, it seems ok to me to enable it by default (either by a specific xfce profile or default enabled USE flag). If its on the other hand a minority, which just complains louder, i would still request the useflag to stay offline by default. Together with this, i am glad to see the move of KDE/GNOME specific USE flags from normal desktop profile to KDE/GNOME subprofiles. In most cases, users will either use one of those or none of them. With this change, it will give a better situation for the majority of our users. And for those, who want to use both profiles, they can have a look at portage manpage, as betelgeuse suggested. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Amount of useflags enabled by default
Petteri Räty schrieb: Thomas Sachau wrote: In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? One possible reason is that our packages should follow upstream policy and maybe upstreams usually like to keep things enabled rather than disabled. Regards, Petteri With that argument you could request to enable all useflags by default. Its ok in my eyes, if you follow upstream the way tarballs are created (e.g. qt move to splitted qt packages or the other way round). Something else would make maintainence part much harder. But i disagree on the part for follow upstream policy for default enabled USE flags. Gentoo is about choice and i would like to have the choice to disable most USE flags by default and with an easy way, e.g. by choising a profile with less default enabled USE flags. Forcing every user to disable many or almost all flags independent of his profile would make Gentoo less userfriendly in general without a good reason. If upstream does not want to support a disabled USE flag, they should not offer the choice to disable it in the first place. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Amount of useflags enabled by default
Alistair Bush schrieb: Hi, i would like to start a discussion about reducing the amount of default-enabled USE flags in profiles, especially in inherited basic profiles. Sounds like a reasonable idea to me, for the base profiles at least. Sure. If we have a desktop/kde subprofile, noone should complain, if that profile enables kde specific USE flags. On the other hand, if i just want a desktop without kde, i dont want to be forced to either choose a none-desktop profile and enable many USE flags by hand or using the desktop profile and disabling many USE flags by hand. In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? who complain about a enabled feature and are not able to think and disable a USE flag for that feature? What a couple of changes make I dont mind, if a flag is really usefull and requested by a big majority of the users. But as Gentoo is about choice, the minority should be able to easily choose something else, e.g. by a less heavyweight profile. If a majority of mplayer users want to be able to play audio files, i dont mind to disable it for myself, if i dont want it. But on the other hand shouldnt a handfull of users be able to dictate the enabled and disabled USE flags for many other users, which might have a different interest. It would be nice if we actually documented why they were enabled. Does the use flag enable significant functionality that would otherwise make the software less useful. Documentation is always usefull. One should also check the additional overhead of the USE flag. I believe we should be trying to find a nice 'middle of the road' balance. DE related use flags should be enabled in profiles ( unless of coarse they package is already DE related e.g if a kde package has a use flag for kde's sound system, this could be enabled at a package level while a package with a kde use flag should not default enable it.). I aggree. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
Fabian Groffen wrote: On 18-10-2009 14:31:15 +0200, Fabian Groffen wrote: On 18-10-2009 13:57:10 +0200, Tomáš Chvátal wrote: Hi, You know i am totaly supporting prefix but i have one point. Why on earth portage simply does not detect the prefix enviroment is being run and then INTERNALY switch D-ED and other variables. It would be much easier that way to migrate all stuff in portage instead of doing this || shebang. Mostly when it is done by eclasses its quite cool, but when you get into changing lots of ebuilds its quite hard for maintaining. Even the multilib overlay guys rather modify the portage than changing a load of ebuilds. Of course we would like to do that, but that was rejected for EAPI=3, so it will at least take until EAPI=4 is implemented, which is not the forseeable future, given that EAPI=3 isn't a fact yet either. I was just informed that it is also a possibility to do an EAPI bump just for these variables, which would mean we can avoid replicating setting ED and EROOT in ebuilds. It's possible. The suggestion was to just introduce EAPI=3 with these variables, and making everything which is scheduled for current EAPI=3 just EAPI=4. I was told we could quite quickly have a Portage in the tree that would set ED and EROOT for EAPI=3 that way. Maybe 2+prefix is a more describing name? This would avoid changing what EAPI 3 means. Are there any objections to this? If not, I'd like to put this on the agenda for the next council meeting. As the council decided to add new stuff in the last meeting if zac is starting to implement new EAPIs this could go into EAPI 3 too. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Amount of useflags enabled by default
On Sat, Oct 24, 2009 at 06:24:51PM +0200, Thomas Sachau wrote: Petteri R??ty schrieb: Thomas Sachau wrote: In addition, i see a trend to enabled more more more USE flags (either over profiles or via IUSE +flag). Whats the reason for forcing a big load of default enabled USE flags on every user including more dependencies, more compile time, more wasted disk space and more possible vulnerabilities except some users, who complain about a missing feature and are not able to think and enable a USE flag for that feature? One possible reason is that our packages should follow upstream policy and maybe upstreams usually like to keep things enabled rather than disabled. Regards, Petteri With that argument you could request to enable all useflags by default. Its ok in my eyes, if you follow upstream the way tarballs are created (e.g. qt move to splitted qt packages or the other way round). Something else would make maintainence part much harder. But i disagree on the part for follow upstream policy for default enabled USE flags. Gentoo is about choice and i would like to have the choice to disable most USE flags by default and with an easy way, e.g. by choising a profile with less default enabled USE flags. Forcing every user to disable many or almost all flags independent of his profile would make Gentoo less userfriendly in general without a good reason. If upstream does not want to support a disabled USE flag, they should not offer the choice to disable it in the first place. I think there are two issues being put together here. One is the issue of profiles enabling use flags by default, and the other is packages enabling use flags by default in IUSE. At the package level, I do think that we should follow the upstream policy. Upstream giving you the option to disable something doesn't mean that they don't support disabling it, it just means that they are giving you the choice to disable it. If it is enabled by default, it could mean that upstream has found that most of their users prefer to enable it, so they set it up that way. To me, the question really is at the profile level since enabling use flags there has the potential to affect entire systems. I don't think flags should be enabled at the profile level unless we are sure that most users who use that profile will want the flags enabled. -- William Hubbs gentoo accessibility team lead willi...@gentoo.org pgpUJsk1ua8xf.pgp Description: PGP signature
Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds
On 24-10-2009 22:37:30 +0300, Petteri Räty wrote: The suggestion was to just introduce EAPI=3 with these variables, and making everything which is scheduled for current EAPI=3 just EAPI=4. I was told we could quite quickly have a Portage in the tree that would set ED and EROOT for EAPI=3 that way. Maybe 2+prefix is a more describing name? This would avoid changing what EAPI 3 means. Naming is up to others, from my point of view. Are there any objections to this? If not, I'd like to put this on the agenda for the next council meeting. As the council decided to add new stuff in the last meeting if zac is starting to implement new EAPIs this could go into EAPI 3 too. Yes, this was implicit, the next EAPI should contain the same support too. -- Fabian Groffen Gentoo on a different level
Re: [gentoo-dev] Re: [gentoo-dev-announce] Unused ebuild built_with_use cleanup
When you first psoted this list I noticed some (or several?) live ebuilds. Git- is the one I remember. Those should not get nuked during global cleanups, as they are likely to be in active use notwithstanding their keywording or masking. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Lastrite: KDE3 applications with bugs and KDE4 replacements.
# Samuli Suominen ssuomi...@gentoo.org (25 Oct 2009) # Replaced by: # # =media-gfx/digikam-0.10 # kde-base/gwenview # =media-gfx/kphotoalbum-4 # =media-plugins/kipi-plugins-0.6 # # Masked for removal in 30 days. media-libs/libkdcraw =media-gfx/digikam-0.9* =media-gfx/kphotoalbum-3* media-gfx/gwenview =media-plugins/kipi-plugins-0.1* media-libs/libkipi media-libs/libkexiv2 # Samuli Suominen ssuomi...@gentoo.org (25 Oct 2009) # Replaced by kde-base/dragonplayer. # http://www.dragonplayer.net/ # Masked for removal in 30 days. media-video/codeine # Samuli Suominen ssuomi...@gentoo.org (24 Oct 2009) # Replaced by =kde-misc/filelight-1.9_rc3. # Masked for removal in 30 days. kde-misc/filelight-i18n =kde-misc/filelight-1.0* # Samuli Suominen ssuomi...@gentoo.org (24 Oct 2009) # Deprecated aRts support wrt bug #270575 # Masked for removal in 30 days. kde-base/noatun kde-base/noatun-plugins media-plugins/hayes media-plugins/jefferson # Samuli Suominen ssuomi...@gentoo.org (24 Oct 2009) # KDE3-only packages with QA issues. # # sci-calculators/fung-calc, bug #248340 # kde-misc/krd, bug #276266 # kde-misc/kadslwatch, bug #276809 # x11-themes/thinkeramik, bug #276898 # app-admin/klogview, bug #277182 # app-admin/kiosktool, bug #277411 # net-ftp/kcmpureftpd, bug #277581 # x11-themes/lipstik, bug #277737 # kde-misc/styleclock, bug #277767 # net-im/kpopup, bug #278425 # # Masked for removal in 30 days. sci-calculators/fung-calc kde-misc/krd kde-misc/kadslwatch x11-themes/thinkeramik app-admin/klogview app-admin/kiosktool net-ftp/kcmpureftpd x11-themes/lipstik kde-misc/styleclock net-im/kpopup # Samuli Suominen ssuomi...@gentoo.org (24 Oct 2009) # KDE3-only. Doesn't work with stable mplayer wrt bug #208786. # Masked for removal in 30 days. =media-video/kplayer-0.6* # Samuli Suominen ssuomi...@gentoo.org (24 Oct 2009) # KDE3-only. Doesn't compile wrt bug #262318. # Masked for removal in 30 days. kde-misc/kio-locate # Samuli Suominen ssuomi...@gentoo.org (23 Oct 2009) # KDE3-only. Doesn't work with stable sqlite, wrt bug #224503. # Masked for removal in 30 days. kde-misc/krecipes-1. # Samuli Suominen ssuomi...@gentoo.org (23 Oct 2009) # KDE3-only. Doesn't work with unicode, which is Gentoo # default. Masked for removal in 30 days. Bug #221115. app-mobilephone/kmobiletools # Samuli Suominen ssuomi...@gentoo.org (23 Oct 2009) # KDE3-only. Doesn't compile with KDE4 installed, bugs # 245543, 258791, 248508, 275733 and security bug 282891. # Masked for removal in 30 days. =net-irc/kvirc-3* # Samuli Suominen ssuomi...@gentoo.org (23 Oct 2009) # KDE3-only. Doesn't compile wrt bug #237966. # Masked for removal in 30 days. games-board/knights
