Re: [gentoo-dev] RFC: removal of
On Fri, Jun 03, 2011 at 08:40:26AM +0200, "Paweł Hajdan, Jr." wrote: > ... > We can't have a tarball, most of the files from the package are > non-redistributable. > ... Then why do ebuilds contain line LICENSE="GPL-2"?
Re: [gentoo-dev] Last rites: www-client/chromium-bin
On Fri, Mar 04, 2011 at 09:41:30PM -0500, Rich Freeman wrote: <...> > For kicks I tried to do better with distcc and EC2. That worked great > until it started running a bunch of python scripts in the makefile - > at -j15 or whatever I had it set to. Distcc really needs a solution > for the fact that you can't pick a single optimum value for -j when > gcc is only part of the build. <...> from 'man make': -l [load], --load-average[=load] Specifies that no new jobs (commands) should be started if there are others jobs running and the load average is at least load (a floating-point number). With no argument, removes a previous load limit.
Re: [gentoo-dev] making revdep-rebuild (partially) obsolete
> ... > Subsequent merges will update this that, > ... Subsequent merges may happen after a long while. Old, possibly vulunerable library will still be used, and most likely unseen by admin.
Re: [gentoo-dev] RFC Bugzilla interaction guide for devs & editbugs users
On Tue, Sep 07, 2010 at 09:30:34PM +, Robin H. Johnson wrote: > This implies that the upstream is alive enough to fix it. > > I feel it should mean that the bug has been reported to upstream, and > that state is documented in the bug. > > If we keep every upstream bug open instead of closed, we'd have probably > another 2500 open bugs (5312 RESO/UPSTREAM in the history of Gentoo, and > I'm ballparking that 50% aren't actually fixed yet upstream). Bug may be a blocker. And marking it as RESOLVED/UPSTREAM you may unblock another bug (e.g. stabilization request) which should be still blocked because there is no fixed package in tree.
[gentoo-dev] Re: FYI: Rules for distro-friendly packages
On Sun, Jun 27, 2010 at 08:48:25PM +0300, Nikos Chantziaras wrote: > ... > It is allowed. Section 7.1.1, Paragraphs 2 and 3 of the C++ standard: > ... Not in C. ISO/IEC 9899:1999 (aka C99), section 6.7.1, note 101: > The implementation may treat any register declaration simply as an auto > declaration. However, whether or not addressable storage is actually > used, the address of any part of an object declared with storage-class > specifier register cannot be computed, either explicitly (by use of the > unary & operator as discussed in 6.5.3.2) or implicitly (by converting > an array name to a pointer as discussed in 6.3.2.1). Thus, the only > operator that can be applied to an array declared with storage-class > specifier register is sizeof.
Re: [gentoo-dev] app-editors/vim and USE="vim-with-x" -> Rename to USE="X"?
On Mon, Jun 07, 2010 at 07:53:22PM +0100, Ciaran McCreesh wrote: > It's there because if you break your X you probably want a usable > editor to help you fix it. vim, compiled with "vim-with-x" works correctly when X is broken. It doesn't enable X11-based UI, like flag "X" suggests. It just enables optional connection to x-server to use its clipboard, and vim still works if that connection fails. X11-based UI is in separate package, "app-editors/gvim"
Re: [gentoo-dev] [Gentoo Phoenix] an official Gentoo wiki
Hm. Can you all just talk to the admin of gentoo-wiki and make it official?
Re: [gentoo-dev] [rfc] layman storage location (again)
On Sat, Jan 16, 2010 at 01:57:38PM +0100, Ben de Groot wrote:
> 2010/1/16 Peter Volkov :
> > layman cache is nfs distributable. Also it's good idea to have it close
> > to PORTDIR. Thus I'd like to keep it somewhere at /usr.
>
> I'd like both to be under /var/
>
I _use_ both under /var/. In my config PORTDIR_OVERLAY="/var/repos/{many
directories}" and PORTDIR="/var/repos/gentoo". /usr/ is too crazy place
for ebuilds. IMHO.
[gentoo-dev] Re: News item for Paludis kdebuild-1 removal
On Mon, Jan 04, 2010 at 04:24:32PM +0100, Christian Faulhammer wrote: > Hi, > > My proposal: > Too late. News item is already there. (/usr/portage/metadata/news/2009-12-21-kdebuild/2009-12-21-kdebuild.en.txt)
Re: [gentoo-dev] Re: QA last rites for x11-wm/ion
According to his website (AFAIR) that license is for _names_ "ion" and "ion3". License for code is still GPL. If you rename the project, you may ignore that terms. On Tue, Dec 15, 2009 at 09:27:29AM +0100, Rémi Cardona wrote: > Le 15/12/2009 08:09, Ulrich Mueller a écrit : > >> On Tue, 15 Dec 2009, Peter Hjalmarsson wrote: > > > >> On the other hand this may be something for treecleaners? A package > >> that has not been bumped for 7 years? With at least three releases > >> since, and a bumprequest open for at least one year? A link to a > >> webside that does not exist? > > > > And both its sucessors x11-wm/ion2 and x11-wm/ion3 already punted two > > years ago. > > > > Wasn't there some licence issue with this package, too? > > That was with ion3 IIRC. Something about the author changing the license > from GPL to "don't patch ion3 ever without telling me about it and > showing me your patches so I can approve them". > > Or something similar, wikipedia/google might know more than me. > > As far as the original ion is concerned, the masking seems perfectly in > order. If someone wants it, that person can step up and do the work > (directly or via proxy). > > Cheers, > > Rémi
Re: [gentoo-dev] [RFC] USE flags requirements (EAPI-4 ?)
On Mon, Aug 31, 2009 at 07:27:32PM +0100, Ciaran McCreesh wrote: > Then when the user turns on all three: > > * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled > * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled > * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled > * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled > * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled > * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled > > And in the general case, there's no way of translating the latter into > the former. > > Much easier for everyone if you just say what you mean rather than > converting it into some convoluted (but theoretically equivalent) less > expressive syntax. I suggest alternative syntax, less powerfull but more expressive: groups of use-flags. Guess we define the following flags in IUSE: 3d.nvidia 3d.ati 3d.intel or 3d+nvidia 3d+ati 3d+intel or 3d:nvidia 3d:ati 3d:intel In first case we may enable any number of those flags. In second case we must enable at least one of them. In third case we must enable exactly one of them. In all 3 cases, if (and only if) flag '3d' itself exist in IUSE, those flags are ignored when it is unset. For convenience, user may use '.' as middle-character in config in all 3 cases (or, perhaps, even omit it and everything before it), but in output of PM he will see proper character and understand dependencies between flags without any explanation in English. If we add flag which depends on nvidia (e.g. cg), we name it 3d.nvidia.cg, and it will be ignored (perhaps with warning) if flag 3d.nvidia is unset.
