Re: [gentoo-dev] New metadata fields
The equery 'meta' module in gentoolkit-0.3.0* can show all the upstream fields, though not many packages currently make use of it. Oh yeah, and there's a traceback in the upstream code that's been fixed but won't be in the tree until rc7, so you may want to wait to check it out. $ equery m --upstream lince * net-p2p/lince Remote ID: sourceforge: lincetorrent
Re: [gentoo-dev] Re: Issues regarding glep-55 (Was: [gentoo-council] Re: Preliminary Meeting-Topics for 12 February 2009)
On Mon, Feb 23, 2009 at 7:02 PM, Tiziano Müller wrote: > Am Montag, den 23.02.2009, 22:25 +1300 schrieb Alistair Bush: >> >> Tiziano Müller wrote: >> >> What is proposed in glep-55 seems to aim to solve both issues at the >> >> same time (it isn't stated) by switching file extension every time the >> >> eapi is changed. This is slightly against the principle of the least >> >> surprise and apparently is disliked by enough people to lead the >> >> situation to be discussed in the council. >> >> >> > >> > Instead of switching file extension every time the eapi is changed you >> > could also increment it only when a new EAPI breaks sourcing the ebuild >> > compared to the requirements of the prior EAPI. >> > (This way you'd in fact split EAPI into a major- and a minor-version.) >> > >> >> Doesn't that just add extra complexity for no gain. > Yes, sure. I was just looking for a solution for the "we have countless > .eapi-X after 10 years" problem. No one wants to be working with ebuild-29 or something like that in a few years and trying to figure out which feature came in which EAPI. Instead of bumping EAPI for each little change, save them up and bump no more than once a year or less, each bump bringing in some major new feature. With a little common sense and planning, we could make this a non-issue and give ebuild authors and PM devs alike a little time to get used to each change.
Re: [gentoo-dev] PR Project Activity Issues
On Tue, Jan 27, 2009 at 6:30 AM, AllenJB wrote: > My idea for a web-only setup would require more initial work, but I think > would make maintenance much easier once set up. The Gentoo Newsletter would > become a separate website, not based on GuideXML, but on a standard CMS. > Instead of having set release dates (weekly or monthly), articles would just > be released as soon as they are produced. > > The regular features like bug stats, GLSAs, developer changes could be > easily generated automatically (I suspect almost all of those are mostly > done automatically anyway - adapting such scripts for a CMS that can publish > from RSS feeds should be relatively trivial) and would appear on the website > without any intervention. Allan, firstly I really like and appreciate that you're interested in Gentoo PR. You're not the only one concerned about it :) I also tried to help out with the newsletter a few months ago... not the best experience. However. Besides bugstats and dev join/retires, gentoo.org/index2.xml has already implemented everything you're talking about. It gets news as soon as it's written, has GLSAs and package additions generated automatically (could add removals), plus the blog roll is such a great step toward showing the active side of gentoo. What would be _really_ cool is if the WYSISYG guideXML editor quantumsummers is (was?) working on allowed users and devs alike to submit news stories to the PR team. Anyway, It sounds like your idea is essentially getting rid of the newsletter and adding more automatic stats to the front page. No need to create a new page with a different CMS. Thoughts? -Doug
Re: [gentoo-dev] Re: Last Rites: app-portage/udept
On Tue, Dec 16, 2008 at 9:06 AM, Daniel Pielmeier wrote: >> Duncan schrieb am 16.12.2008 00:47: >> While I'm at it, is there anything useful to display metadata.xml? In >> particular, the long descriptions and use flags can be useful. With >> use.desc and especially the local version thereof going deprecated, and >> with additional info about global flags sometimes in the metadata... > > Regarding metadata.xml there is (besides querying Willikins on IRC) > emeta. Take a look at bug 248278 [1]. > > [1] http://bugs.gentoo.org/show_bug.cgi?id=248278 > emeta will likely become `equery meta' in the next release of gentoolkit, but feel free to use it from the overlay for now. Regarding equery, there's a "changes" option that is just waiting to be written. Considering udept's changleog function is about 30 lines, it should be trivial to do. If people are interested, I can handle that. It's something I would like to have, also. I hope to have the upgraded gentoolkit available for testing within a few weeks. -Doug
[gentoo-dev] Re: Digest of gentoo-dev@lists.gentoo.org issue 653 (33679-33728)
blah (switching emails, sorry for that) On Tue, Dec 9, 2008 at 7:14 PM, Douglas Anderson <[EMAIL PROTECTED] > wrote: > [EMAIL PROTECTED]<[EMAIL PROTECTED]> >
[gentoo-dev] Re: Digest of gentoo-dev@lists.gentoo.org issue 653 (33679-33728)
[EMAIL PROTECTED]<[EMAIL PROTECTED]>
