As another user, I have an interesting thought: Keep *_TARGETS and
*_COMPAT, but add useflags called "[python|php|ruby]-compat-testing",
which is at least use.stable.mask'ed (possibly straight-up
use.mask'ed), to any ebuild that uses *_COMPAT. Setting the
appropriate useflag would allow such ebui
On Mon, Jul 28, 2014 at 12:02 PM, Ian Stakenvicius wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 28/07/14 07:21 AM, Michał Górny wrote:
>> Dnia 2014-07-25, o godz. 14:49:44 Ian Stakenvicius
>> napisał(a):
>>
>>> Hey all.. So, putting aside for now how much of a mess this
>>>
On Mon, Jul 7, 2014 at 4:45 PM, Michał Górny wrote:
> Dear Community,
>
> First of all, please do not take this personally. I don't want to
> attack any member of the games team or the team in general. I respect
> their experience and long-term contribution to Gentoo. However,
> I strongly disagre
On Mon, Jul 7, 2014 at 6:14 AM, Rich Freeman wrote:
>
> On Mon, Jul 7, 2014 at 6:14 AM, Greg Turner wrote:
> > WTF is up with it? Why does it love the first Atom so much more than the
> > others?
> >
> > It could be such a useful feature, but, in practice, it just never seems to
> > do what I wa
To be honest, I think that printing a summary of masked useflags which
contradict a user's settings in USE= at the end of the pretend/ask portion
of an emerge would be a step in the right direction. Making it so that
portage bails with an error if package.use conflicts with
use.(package.)mask woul
packages from the Live tree, and doesn't want to
switch completely over to the live tree? If I understand what you
want to do correctly, the Release tree would include only stable
packages. Other packages wouldn't just be masked, they would be
completely unavailable to anybody using that tree.
I like the idea of having a stable p.mask much better, which says
"profile" to me. Any thoughts on a special profile just for releases?
--Arek (James Potts)
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
hmmmdoesn't the GNU ClassPath implement enough of Java's runtimes
to handle a command-line app like this (the app needs, basically, to
be able to read files, communicate via the http protocol, print to
stdout, and accept input from stdin)? And doesn't Kaffe use the GNU
ClassPath? And if this
On 6/24/06, Wernfried Haas <[EMAIL PROTECTED]> wrote:
On Sat, Jun 24, 2006 at 12:07:52AM -0500, James Potts wrote:
> There is a problem here for the java folks...Technically, their
> migration-overlay is an overlay, and technically, that overlay is
> currently unofficial.
_Techni
There is a problem here for the java folks...Technically, their
migration-overlay is an overlay, and technically, that overlay is
currently unofficial. Therefore, technically, if it is against the
rules for projects and/or devs to use bugzilla for unofficial
overlays, then it is against the rules
Hmm...Are thre any packages out there which *must* be built against
the same qt as (the rest of) kde? If so, I don't think qt4 should be
in the default use flags until KDE4 hits arch. This keeps people from
reporting issues with KDE apps built against the wrong version of QT.
--Arek
On 6/23/06
Alec Warner wrote:
Georgi Georgiev wrote:
maillog: 19/06/2006-11:13:33(+): Alec Warner types
Portage currently exports $KV as the current kernel version. We
detect this by attempting to mess around with the things in
/usr/src/linux (.config, make files, etc...)
This is duplicating the
Sven Köhler wrote:
some software, like qemu and others, are simply not compatible with gcc
4.x and they will not become compatible due to severe conceptional issues.
then they stay broken ... add a warning to the ebuild if `gcc-major-version`
is "4" (see toolchain-funcs.eclass)
Hmm
On 6/9/06, Stefan Schweizer <[EMAIL PROTECTED]> wrote:
Markus Ullmann wrote:
> Maybe that way we avoid any misunderstandings, nearly doubled posts and
> repeating ourselves over and over again.
The problem is that some questions and answers easily get lost in a mailing
list. To solve this shortc
On 6/9/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote:
On Fri, 2006-06-09 at 19:10 +0200, Stefan Schweizer wrote:
> Markus Ullmann wrote:
> > Maybe that way we avoid any misunderstandings, nearly doubled posts and
> > repeating ourselves over and over again.
>
> The problem is that some questions
Donnie Berkholz wrote:
Jakub Moc wrote:
=virtual/x11-7 is hiding breakage in ebuilds that are not ported for
modular X.
I couldn't agree more, but I was forced to add this rather than allow
unported ebuilds to break.
Thanks,
Donnie
Hmmm...Looks to me like it would be a gre
den? This doesn't fix the problem with the
flag, it just covers it up. In any case, it's a possible problem that
I will put up with. btw, I'm not using visibility=hidden (dev-only
flag, not for users).
--James Potts
On 4/27/06, R Hill <[EMAIL PROTECTED]> wrote:
James Potts
R Hill gmail.com> writes:
> I've yet to hear of _anything_ that's broken because of
> -fvisibility-inlines-hidden. (course someone will undoubtedly point
> one out now ;))
>
-fvisibility-inlines-hidden not only breaks a number of kde apps afaik (it's
filtered now), but it also seems to break SD
17 matches
Mail list logo
