Re: [gentoo-dev] Lastrite app-pda/*synce*
On Thu, Nov 04, 2010 at 09:03:13PM +0200, Samuli Suominen wrote: # Samuli Suominen ssuomi...@gentoo.org (04 Nov 2010) # Over 20 open bugs, http://tinyurl.com/2wurbtz # Bugs assigned to a proxy maintainer without CVS access # Every package outdated, bug 340007 # Removal in 30 days The bug 340007 you're citing shows that people are working on adding the next version but are not done yet. What's the point of this masking/removal besides fucking up the installation of people who use the software? OG.
Re: [gentoo-dev] SDLMame maintainer with Gnome setup wanted
On Sat, Jul 26, 2008 at 03:13:36PM +0200, Luca Barbato wrote: Christian Birchinger wrote: But no matter how wrong i think it is, i usualy respect the upstreams wishes. If upstream is wrong I think we should help them... Upstream thinks it's a bad idea not to give the user any possibility of changing the font. Upstream does not want to handle questions about that if the gentoo ebuild is crippled by default in that aspect. OG.
Re: [gentoo-dev] Re: GLEP 55
On Wed, Jun 11, 2008 at 04:14:58AM +0100, Ciaran McCreesh wrote: On Tue, 10 Jun 2008 19:14:11 +0200 Olivier Galibert [EMAIL PROTECTED] wrote: On Tue, Jun 10, 2008 at 03:02:28PM +0100, Ciaran McCreesh wrote: Except that currently, the ebuild file isn't opened for read. So it's not in memory at all. Why would you need the EAPI before the time when you actually want to interpret the contents? You need the EAPI before you use the metadata. But you don't need the ebuild to get the metadata in the common case. The metadata should carry its version indicator too. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 03:14:47PM +0100, Ciaran McCreesh wrote: !-- EAPI=3 -- *Then* would be the time to change the extension. As long as the ebuild is bash-parseable with an appropriate environment, it doesn't make sense to change the extension because a env-variable set or a comment are more natural methods. If/when the format changes to something not parseable by bash, then it will be time to change the extension. And then how to mark (sub-)version will depend on the chosen new format, in case of xml that would be the dtd information. I suspect the rejection of the extension change will be there as long as the fundamental format (bash script) doesn't change. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: GLEP 55
On Tue, Jun 10, 2008 at 12:01:00PM +0200, Rémi Cardona wrote: Ciaran McCreesh a écrit : Kills the upgrade path completely. No good. Lemme sum this up in layman's terms : 1) EAPI _has_ to be known before sourcing an ebuild. There's no way to avoid that for various reasons, all 100% valid. sourcing != reading the first line/n first lines/first block and grepping. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: Concerns about WIPE_TMP change
On Sat, Jan 19, 2008 at 10:18:35PM +, Duncan wrote: Richard Freeman [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Sat, 19 Jan 2008 07:55:53 -0500: I think that this would probably warrant an elog. Sure, anybody who knows the correct way to admin unix doesn't put anything important in /tmp - but educating our users before blowing away their data isn't a bad thing. We shouldn't assume our users are idiots, but this is an obscure enough piece of admin knowledge that I think that users will be impacted by the change. Obscure? It's the directory name (says another with both /tmp and /var/ tmp on tmpfs). How much less obscure can you get than announcing it every time the path is referenced or specified? Who could reasonably argue that tmp doesn't mean tmp? Tmp has never meant erase at restart, because restarts are often not predictable. Tmp has sometimes meant things like erased after a week, or erased when space gets low, but never erased after restart which is just unusable. Frankly, if I'm writing a long email (which mutt stores in /tmp) and a powerloss makes it gone even if I was saving it from time to time while I was writing it, I'll get annoyed. Severely annoyed. It's just another bug of the FHS that shoule be ignored. OG. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Smoother moderation scheme? (was: ML changes)
On Fri, Jul 13, 2007 at 03:46:56PM -0400, Thomas Tuttle wrote: Questions? Comments? You're going to have a hell of a fun time to answer the question of how a post is judged good or spam. OG. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] ML changes
On Thu, Jul 12, 2007 at 01:24:32PM -0700, Mike Doty wrote: We're voting on this next council meeting so if you have input, now would be the time. Any dev can moderate is an illusion. Most non-dev messages are perfectly reasonable ones and I'm pretty sure the smart devs know how to handle filters when they get bored with the flamefests. So either the devs get a message when there is something to be moderated, and it's going to annoy them to see all these messages twice, or they don't, and I don't see anybody checking a web site or something on a regular basis to see if there are messages to let go through. At least not long term. OG. -- [EMAIL PROTECTED] mailing list
[gentoo-dev] How to help an ebuild move along
I've had decided to do an ebuild for praat[1] as my first contribution. I checked in bugzilla just in case there was one added recently, and I found out there was one since two years and half[2], regularly kept up to date even. So my question is, what could I do to help having it end up in the official package database? OG. [1] A speech analysis tool, the reference in the domain. [2] http://bugs.gentoo.org/show_bug.cgi?id=78392 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-dev] Re: SCM choices
On Mon, Jun 04, 2007 at 03:30:37AM +0300, Stratos Psomadakis wrote: but i think linus is too biased against other scms... He is biased against technical choices done in other SCMs, which is not exactly the main thing. Specifically, from what I can see, he hates: - centralization (cvs, svn...) - file ids (cvs, svn, hg, ...) - hiding what is really going on on the pretext that it's easier (lots of interfaces out there, or people who want commit -a as default for git) - lack of ways to be sure we're talking about the same code in the end (quilt) - anything slow (almost every other scm out there) I very probably have missed some. It's obvious why git doesn't have properties Linus hates. OG. -- [EMAIL PROTECTED] mailing list
