Re: [gentoo-dev] Jeeves IRC replacement now alive - Willikins
Robin H. Johnson wrote: 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. #gentoo-python Thanks
[gentoo-dev] dev-python/setuptools as RDEPEND
Just a quick note here in case you work on Python packages. Recently repoman started warning that setuptools may be suspicious as an RDEPEND. A lot of Python packages use another namespace that setuptools provides, 'pkg_resources', for plugin systems so it may not appear obvious that setuptools is an RDEPEND. I've updated the Python Developer's Guide[1] with info on how you can easily determine if it's an RDEPEND or not. [1] http://www.gentoo.org/proj/en/Python/developersguide.xml -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] What to do when Python 2.5 is blocking your package from entering stable? (Agenda for next council meeting?)
Samuli Suominen wrote: I don't know about you, but when a package can't be stabled because it's depending on Python 2.5 and current stable is broken I'd like to start reverting stable keywords back to ~arch as noone wants to maintain broken junk. Latest being app-cdr/gtkcdlabel, and media-video/gaupol. Perhaps it should be a council agenda? Not much different from "slacking arches", it's simple, lack of active devs. What I would prefer, of course, is a list from one of python members to get it into stable but have no expetations, since I've asked it many times past 1-2 years. Unless there are any objections from the rest of the Python project, I'll try to get this done within the next 24 hours. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] GLEP 46: Allow upstream tags in metadata.xml
Santiago M. Mola wrote: The GLEP should be updated. "Motivation" section does not seem to justify the changes. IMO Meatoo [1] (and its hipothetical rewrite using Doapspace [2]) would be the right tool to detect version bumps. Maybe metadata.xml should contain a Freshmeat or DOAP entry so meatoo could get more automation. Anyway, I don't know how much would take the new version of meatoo. Pythonhead, could you give us some news about it? Or it's just planned for the long-term future? [1] http://meatoo.gentooexperimental.org/ [2] http://blog.doapspace.org/ Sorry, I missed this email, but I'll be at the council meeting to listen in on talk about GLEP 46. Having Freshmeat, SourceForge etc. project id's in metadata.xml sounds great. I would gladly write a tool to go through SourceForge and Freshmeat's metadata and match project names to ebuild package names using HOMEPAGE. I already have code to parse FLOSSMole's[1] metadata, so it'd be simple to whip up quickly. doapspace.org has an API that lets you give a SourceForge, Freshmeat, PyPI and RubyForge project name and get metadata back, so having a link to the DOAP's URL in metadata.xml isn't really needed for those. For self-hosted projects, we could either put a link to the DOAP in metadata.xml, or simply make sure the HOMEPAGE matches the homepage in the DOAP itself. The second is preferable because the URL to the DOAP could change. Meatoo will be much more accurate after I cross-reference metadata from FLOSSMole to map Gentoo package names to other forge/package index names. Once that's done, we'll have very accurate version bump info that can be looked up by herd/maintainer, from SourceForge, RubyForge, Freshmeat etc. Rob [1] http://ossmole.sourceforge.net -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Python setuptools/eggs
Dave Nebinger wrote: I may be a bit of-base, but since I don't know much about the ruby gems, I'm wondering how close of a situation this is with the perl cpan modules? They're integrated to operate using the distribution process of both cpan and portage... They are similar. There is a project called g-gem [1] that uses the gems.eclass to generate ebuilds. A few of us had a good talk on Eggs on yesterday on irc and came up with a few proposals. I've setup SVN/Trac[2] so we can get things organized. Theres a very quickly dished-out eggs.eclass and test ebuild on the Trac site. [1] http://rubyforge.org/projects/g-gem/ [2] http://eggs.gentooexperimental.org/ -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] python-2.4.2 marked stable x86
There is a memory leak in python-2.4.1 so 2.4.2 was marked stable on x86. There isn't much listed in the changelog[1] upstream such as a patch or bug#, but Mr_Bones_ encountered it when running repoman on the full tree causing python to consume >400 megs of memory. [1] http://python.org/2.4.2/NEWS.html -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Python setuptools/eggs
Anders Bruun Olsen wrote: But aren't eggs a bit against the Gentoo philosophy? I mean there are some eggs that contain precompiled C-extensions. Shouldn't it still be source builds that just somehow work with setuptools? We wouldn't use the precompiled C eggs. The main reason I'm looking at eggs so soon is because packages may start using them exclusively and we will have the choice of using them via portage or let people install them manually via easy_install. This happened with Rails. They have the source available but comes with no way to install it properly and they only support gems installations officially, so the gems eclass was born. Mail me off-list or join #gentoo-python if you're interested in working on the easy_install eclass, please. Should we move this off-list? I haven't worked with easy_install for about a month so I haven't got much to add, but I'm catching up on it tonight. Since nobody else on the Python team has spoken up, I think they may not be caught up either. I received a few mails from other interested people, and we're meeting on irc for now. Thanks, Rob -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Python setuptools/eggs
Anders Bruun Olsen wrote: It seems that alot of python projects are starting to use setuptools/easy_install/eggs, and granted, it is quite neat, but there needs to figured out a way to handle installing these things through Portage, or alot of new versions are going to be a pain to have installed. How should Portage handle this? I've been working on an eclass for these but its not ready. I was hoping it'd be as easy as the Ruby gems eclass, because they are similar, but eggs don't play nicely in a sandbox yet. You're probably best off using the straight source for TurboGears and its dependencies if you want to install via ebuild for now. Mail me off-list or join #gentoo-python if you're interested in working on the easy_install eclass, please. -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Gentoo Council meeting, Thursday 15th, 1900 UTC
Lance Albertson wrote: Ah, I see. To the best of my knowledge that just needs to be worked out w/ the GLEP 15 people and infra. I dropped into -infra and they said that there's space for it, but that bug # 98282 lists a couple of contentious points. (Also, the gentooexperimental scripts "about" page seems to suggest that their framework differs from the "official" version.) I did the temporary site on gentooexperimental. It'll happily die after port001 and his crew finish the official one. -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Looking for developers for a new 'Planet' web-app
Daniel Drake wrote: Examples of what people are requesting: - Ability to browse the 'archives' (i.e. the content which has dropped off the end of the page, which planet discards) - Ability to search the content and the archives - Ability to browse by Gentoo herd, i.e. view the weblogs of the apache maintainers. I patched the Planet source to add all the entries to an sql database then wrote a quick CherryPy demo [1] that uses the existing Planet's template system. The example just has the entries for a few random developers. You can search the titles or full text. Source code available [2] for the curious. You'll need dev-python/cherrypy and USE='sqlite' dev-python/sqlobject. If I can get ahold of the config.ini and template for the actual Planet Gentoo I'll be able to get the herd info from usernames (and make it look like the real deal). [1] http://gentooexperimental.org:9898/ [2] http://dev.gentoo.org/~pythonhead/planetdb.tbz2 -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] List of aging ebuilds?
Hasan Khalil wrote: If this is of any interest to anyone out there, let me know. As always, I'm open to discussion and suggestions. [1] http://charlies-server.no-ip.com/~gongloo/keywordlog Great, thats just about what I'm looking for. I wasn't as interested in the repoman top 10 stuff. Mainly I want to be able to search by the herds I'm in to get a quick glance at anything stuck at ~arch for >30 days. -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New GLEP draft: Status of forum moderators in the Gentoo project
Haas Wernfried wrote: Theoretically the trustees can decide to do whatever they want with the forums. They probably won't, but if anyone else who may be affected by their decisions is allowed to vote, why shouldn't we? The metastructure poll is affecting the forums in terms of us not even knowing where we fit into the metastructure even though f.g.o is in the offial domain gentoo.org. Becoming developer^wstaff should give us the right to vote. Since every other developer, infra staff, docs-writer or other person contributing time to gentoo as part of an official project, this should would be fair enough imho. Ok, I'll buy that. This part wasn't clear to me: "Recent events such as the election of trustees or the new metastructure poll are effectively affecting the forums" What you explained above is a lot clearer now, thanks. -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] New GLEP draft: Status of forum moderators in the Gentoo project
Christian Hartmann wrote: Feedback is highly appreciated. Feedback: I think the first sentence should say "staff" rather than "developer": "Global moderators and site admins should also go through the mentoring process and become official Gentoo developers." Overall it sounds like a good idea as far as QA goes. I think this will be your biggest obstacle: "Recent events such as the election of trustees or the new metastructure poll are effectively affecting the forums, so the wish to be part of the decision as an equal member is present among the moderators." How exactly did recent voting affect the forums and why should Foundation members vote to give you voting rights because of what is affecting the forums? (Assuming Foundation members would have to vote to change who can vote). Its arguable that moderators being non-staff is a good thing because its non-staff essentially censoring and deleting other non-staff in the forums, so make a good case ;) "Forums don't really seem to fit into one of the current categories as they are related to the infrastructure and the documentation project. We suggest putting it in the other category or making a separate one for the forums." Seems like you'd fit perfectly under User Relations, wherever they fall under the toplevel project structure. -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] List of aging ebuilds?
Anyone have the source for the package aging list? http://article.gmane.org/gmane.linux.gentoo.devel/23231 Maybe we can find a new server to run it on? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pinboard of outdated ports
Tom Martin wrote: Maybe it would be better to tell maintainers to just subscribe to projects on freshmeat? I whipped up this site because the herds I'm in have a gazillion packages: http://gentooexperimental.org/meatoo/ It needs some work but it'd be easy to send out mail to subscribers by herd or maintainer email instead of subscribing to dozens of individual freshmeat packages. Or when the command-line tool is done you can check whenever you want by herd name. -- Rob Cakebread Gentoo Linux Developer Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x96BA679B Key fingerprint = 5E1A 57A0 0FA6 939D 3258 8369 81C5 A17B 96BA 679B -- gentoo-dev@gentoo.org mailing list
