Re: [gentoo-dev] Re: Reverse use of Python/Ruby versions
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 ebuilds to build against any interpreter version listed in the appropriate *_TARGETS variable, even those the ebuild doesn't explicitly support. To help with keeping things reasonable, support for both ranges and negation could be added to *_COMPAT. This way, for example, an ebuild for a Python 2.7-only program, could specify PYTHON_COMPAT="2.7 ->=3.0", and the ebuild for a ruby app that's known to be broken in 2.2 but works fine in both 2.1 and 2.3 could specify RUBY_COMPAT="-2.2". Obviously, the *-compat-testing flags should not allow building against a known-incompatible TARGET if this is implemented. :) This keeps the benefits of *_COMPAT and *_TARGETS while allowing people to test a new python/php/ruby interpreter without having to manually edit dozens (potentially hundreds or thousands) of ebuilds. --James
Re: [gentoo-dev] RFC: USE flags in virtuals, to allow a specific provider to be determined
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 >>> would be to implement in the virtuals' ebuilds themselves, what >>> do people think of changing the virtuals so that they contain an >>> entry in IUSE for each provider that can satisfy it? >>> >>> The idea here is that the package satisfying a virtual could be >>> optionally explicitly-chosen through package.use (or USE= in >>> make.conf, perhaps) instead of having an entry in @world, that >>> way if nothing depends on the virtual then it and the provider >>> can be - --depclean'ed from the system. The idea is specifically >>> NOT to have rdeps depend on these flags, that would undermine the >>> whole purpose of the virtual; it would just be for end-users to >>> set if they so chose. >> >> I think I don't get this argument. >> >> If you really want to have a particular provider for the virtual >> for external purposes, it's fully purposeful to put it in @world >> or otherwise in a custom set. In this case, USE flags aren't >> helpful. > > The argument I was trying to make is that USE flags would allow > end-users to accomplish the same thing, while not having an entry in > @world and therefore allowing the package to be --depclean'ed if the > virtual is --depcleaned. > > I personally don't use sets so i've no idea if the exact same thing > could be accomplished in sets; for some reason i don't think so. > > >> >> If you only prefer a particular provider, you can tip portage >> easily to use it without resorting to USE flags. This also allows >> portage to semi-transparently switch to other provider if >> dependencies need it. In this case, USE flags only make this >> auto-switching harder. > > That is the other part of this idea, to make auto-switching harder, > because right now portage likes to auto-switch even when it seems like > it shouldn't. > > I figure this idea would also help with Ciaran's wishlist item of ||() > deps becoming more strictly-controlled and readily deterministic. > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iF4EAREIAAYFAlPWgi8ACgkQ2ugaI38ACPBfoQD/bZmCxCdLM9EyeJRrst5QmD9X > NS2Y0HCNhRnCfAuplUYA/2UHibYB6YHdKOi40RkWOUA0KMTRSwXYPR6dYsmByiQL > =njwB > -END PGP SIGNATURE- > Also, what about the case where multiple providers for the same virtual are installed but the first doesn't satisfy the dependency? Currently, portage only looks at the installed state of the providers, in order, and will use the first installed provider it finds even if it doesn't actually satisfy the dependency (e.g. due to use deps) and the dependency is already satisfied by a different installed provider. Paludis has an elegant solution for this situation (-F/-A), but afaik portage doesn't. Use flags in virtuals would solve this without having to hack around in portage and have it check all possible deps before choosing one. --James
Re: [gentoo-dev] The request to abolish games team policy
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 disagree with the policy games team has established and I > believe that their actions do not serve the best interest of Gentoo. > > I am therefore going to propose this request to the next Council. Since > this will likely require a fair amount of prior discussion, I would > like to start it already, hopefully reaching at least some point before > the appropriate Council meeting. > > > I would like to ask the Council to abolish the following policies that > have been established by the games team: > > 1. that the games team has authority over the actual maintainers > on every game ebuild, > > 2. that every ebuild has to inherit games.eclass as the last eclass > inherited [1], even if it actually increases the ebuild size rather > than helping, > > 3. that games must adhere to games team-specific install locations > and ownership rules, shortly listed in [2]. > > More specifically, I would like the games to be 'freed' from the games > team monopoly and treated like every other package. More specifically, > I believe that: > > i. games should be maintained by their respective maintainers, > and games team (if any) should help rather than overriding their > decisions, > > ii. that the games.eclass should be deprecated and likely disabled > in the next EAPI since wrapping phases and helper functions makes it > close to base.eclass in design, > > iii. that the games group along with the game-specific install tree > should be deprecated and phased out. Games should be installed alike > any other applications. > > > I feel like the games team is more focused on keeping the 'status > quo' than working on improving the experience of Gentoo users. > The problems with current game install design have been pointed out > multiple times, and the suggestions were either ignored by the team or > refused, sometimes with strong words. In fact, the team's own decisions > are creating further issues that they afterwards need to work around. > > The most notable issues with the specific use of games group include: > > a. nethack security issue [3] that is purely Gentoo-specific, and is > open with no action from games since 2006, > > b. multiple game ebuilds being unable to access files installed by > other game ebuilds that are worked around with dangerous > RESTRICT=userpriv [4,5,6]. > > Moreover, the eclass is purely suited for autotools-based ebuilds. > The policy enforced by the team makes it very hard to create proper > ebuilds for other build systems, often requiring redeclaration of all > phase functions (to restore the proper eclass) and heavy patching of > install locations. > > > The number of inconveniences, lack of replies (lack of time?) has > resulted in multiple games being spread throughout various overlays. > I think the gamerlay project [7] is most notable. Sadly, this results > in even worse quality of games in Gentoo. > > I believe that the policy needs to change. While I respect the members > of games team, I don't think they should be allowed to prevent other > developers from committing game ebuilds, and I don't agree with keeping > the 'status quo' of games.eclass for the sake of keeping it while > the issues outweigh the benefit (it is actually negotiable whether > there's any). > > I would like to ask the Community for their opinion on this issue. > When the new Council term starts, I will add the issue to the agenda. > Unless the games team decides to give up their policies and allow > developers to work on cleaning up games before that. > > > [1]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap3 > [2]:http://www.gentoo.org/proj/en/desktop/games/games-ebuild-howto.xml#doc_chap4 > [3]:https://bugs.gentoo.org/show_bug.cgi?id=125902 > [4]:https://bugs.gentoo.org/show_bug.cgi?id=112898 > [5]:https://bugs.gentoo.org/show_bug.cgi?id=419331 > [6]:https://bugs.gentoo.org/show_bug.cgi?id=516576 > [7]:https://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary > > -- > Best regards, > Michał Górny Here's my non-developer point-of-view: I agree with this - games are lagging way behind in gentoo compared to other distributions, and this heavy-handed super-maintainership by the games herd explains why. If a person wants his game to be co-maintained by the games herd, fine, they have to follow the rules of the games herd, but being in the games herd should be an option, not a requirement for a game to be in the tree. Lets let the people who want to maintain game ebuilds maintain them, governed by the same rules as all other ebuilds, regardless of herd status. I also agree that the games group needs to go, for the most part - users shouldn't have to be in it to play games (they shouldn
Re: [gentoo-dev] Is || ( Atom... ) broken?
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 want it to. Is it a bug? > > Well, more like unspecified behavior. PMS just says that the PM has > to accept any package in the list. It is silent on the matter of > which one is to be preferred, or to what degree. > > As we saw with upower portage will jump through quite a few hoops to > install the first dependency - it doesn't always figure out that > installing one of the others is easier. It is a bit hard to > algorithmically define "easier" - should portage favor fewer package > installs, fewer removals, fewer config file changes, avoiding changing > the init system (and what constitutes an init system), etc? Plus, > there are a lot of potential permutations to deal with. > > You'd probably need to be more specific as to what is going on to get further. > > I think most would agree that there is room for improvement here. > > Rich > In this case, it would be nice if Portage would see if one package of the set could be resolved without blocks or required config changes (i.e. if one package can be installed *now* choose it over earlier-listed not-installable packages). The problem with this is that it would take longer to resolve || () deps if the first one isn't installable. Not only that, but the workaround is easy: Either install the package you want first (upower-pm-utils, for example), or at the same time as your "target" package, so I also don't see this as high-priority. I also don't see this as something needing changed in PMS, as other PMs have different ways of handling the issue. --James
Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask
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 would also be helpful if this doesn't already happen. Not sure how much trouble this would be to add, tho, honestly. --James On Wed, Nov 13, 2013 at 12:56 PM, Daniel Campbell wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 11/13/2013 09:16 AM, Ian Stakenvicius wrote: > > On 13/11/13 09:55 AM, Thomas Kahle wrote: > >> On 11/13/2013 03:30 PM, Duncan wrote: > >>> Rich Freeman posted on Wed, 13 Nov 2013 08:37:51 -0500 as > >>> excerpted: > >>> > On Wed, Nov 13, 2013 at 8:25 AM, Thomas Kahle > wrote: > > On 11/13/2013 12:39 PM, Tom Wijsman wrote: > >> On Wed, 13 Nov 2013 10:28:02 + (UTC) Martin Vaeth > >> wrote: > >> > >>> Hello. > >>> > >>> The new "features" use.stable.mask and > >>> package.use.stable.mask have turned maintaining > >>> systems with mixed ARCH and ~ARCH keywords into a > >>> nightmare: > >> > >> They are considered unsupported by many; so, going down > >> that path you need to be acquainted with Portage enough > >> to keep a consistent system. > > > > This argument has come up several times, but is it valid? > > Honestly, opinions vary on this one and I don't think it is > a productive path to go down. I also feel that being able to > mix keywords is a big benefit of using Gentoo. I'd rather > focus on practical ways to make this easier rather than > whether it is desirable. > > That said, there are always going to be situations where > mixing keywords isn't practical. You're not going to run > stable chromium against ~arch v8, or mixed keywords between > kdelibs and kwin, etc. > >>> > >>> FWIW, I believe at least part of the confusion here is based > >>> on differing definitions of "supported". > > > >> I agree. Generally however, we should think Gentoo (or the open > >> source ecosystem) more bazaar, less cathedral. Libraries have > >> interfaces, and they are supposed to be mixed and matched > >> according to the interface definitions. We (Gentoo) should not > >> think of "Gentoo stable" as a fixed product like "iOS-7". It has > >> come a long way, but philosophically I still think of Gentoo as a > >> kind of automated Linux-from-scratch (where you also mix and > >> match whatever you find on the Internets). > > > >> In the end it boils down to what we mean by "supported". For me > >> "supported" does not mean "tested". As you point out, testing > >> every combination forbids itself. Supported for me means that > >> the argument "you mixed stable and unstable" is not per se valid. > >> There's a huge difference between > > > >> You mixed unstable firefox with stable gcc > > > >> and > > > >> You mixed unstable X server with stable protocols. > > > >> For me mixing the trees is supported in the sense that I would > >> apply rational judgement to bugs. If they are of the second > >> type, it can be said in a polite way that we as Gentoo can't do > >> anything about this combination not working. > > > > > > The term "supported" is a rather overloaded term which tends to > > mean different things in gentoo depending on the context that it is > > used (and who's using it), for sure. It's also not analogous to > > "working" or "expected to work", at all, imo. > > > > I wonder if it might be a good idea to have a discussion and reach > > consensus on what the Gentoo (Developer) definition of "Supported" > > should actually be, and document this somewhere so that ambiguity > > can be officially removed. > > > > > Not a developer, but when I see discussions about things that are > unsupported by the dev team, I think of it as "This is a special case > that's outside of our workflow and would add an exponential amount of > work for us if we tried to support it." Support, in this context, I > think refers to supporting bug reports and use cases. As mentioned > previously, it's impossible to account for every combination. If > developers stick to pure arch or pure ~arch, it's a hell of a lot > simpler to carry out the job, and I totally respect that. > > I've had minimal problems mixing ~arch and arch, but based on what > I've read and my understanding of FOSS culture in general... "If you > go off the beaten path and break something, you get to keep the pieces." > > Surely I'm not alone in that understanding. It's simple and closer to > pragmatism than any perceived malice or laziness that some may be > assuming about the developers. > > ~Daniel > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJSg8t0AAoJEJUrb08JgYgHr44H/RUC4AXvAX2n1GoaITV
Re: [gentoo-dev] Re: Versioning the tree
ppens in the case where somebody wants to use the Release tree, but also wants (or needs) one or more 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
Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]
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 is the case, couldn't GCJ be used in the place of Kaffe to build this app on platforms that aren't supported by Kaffe (or on all platforms, if that is desired)? Just some thoughts... --Arek On 8/17/06, Paul de Vrieze <[EMAIL PROTECTED]> wrote: On Thursday 17 August 2006 16:37, Enrico Weigelt wrote: > * Duncan <[EMAIL PROTECTED]> schrieb: > > > > > You ever seen the term "slaveryware"? You have now. > > We are still talking about the java *language* ? > I aggree that we shouldn't be bound to some certain proprietary > software. But the java language is not software, it is couple of > abstract concept for actually writing software. You forget the main part of a language is the library. Basically there is not yet a good complete open java standard library available. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
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. _Technically_ probably maybe, but please read what already has been said about it in this thread - there are big differences between those to projects, such as the sunrise being technically suspended as an official project and the java project not. Anyway, all of this (including my reply, sorry) already has been discussed in this thread before, no need to repeat history. ;-) Let me be clear on this: From what I understand, the rule as written prevents unofficial overlays from using certain fields in bugzilla. It says nothing about the status of the project(s) behind such overlays. So the argument that this should not apply to the java team because the project is still official, and sunrise is not, is bogus. This ruling applies to overlays, not projects. On 6/24/06, Simon Stelling <[EMAIL PROTECTED]> wrote: Question is, do we care about blindly following a policy that obviously was targetting at something completely different, or do we care about getting stuff done? There's nothing as unproductive as political correctness. Just my 0.02 SFr, I hate to put it to you this way, but if you give people an inch, they'll take a mile. Yes, political correctnes is unproductive. This is why decisions like the one made here need to be thought out better before being made. But once the decision is made, it should be applied equally, or not at all. As for the decision that led to this mess, I'd like to see it on the agenda for the next Council meeting. I really don't agree with it (or rather the way it was worded), and I can see others don't either. Unfortunately, I don't know if I have the authority to request this, since I'm not a dev. --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Bugzilla usage by gentoo-java's doing migration work
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 for the java team to use bugzilla for their migration-overlay. As for the fact that the migration overlay is in the process of being moved to o.g.o, "in the process of" doesn't mean it's already been done, and until it's finished, the above statement stands. Props *and* apologies to the java team for this, but it looks like you need to move the overlay *before* you finish the migration process now. As for java being a project and sunrise not being a project, if it was the intention of devrel to stop unofficial *projects* from using bugzilla, then that's how they should've worded their ruling. --Arek P.S. I do beleive that devrel may have been a little out of line in doing this. People need to think about the consequences of making (potentially far-reaching) rulings like the one made in this case. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Qt use flag recap - qt3 and qt4 as default?
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, Stefan Schweizer <[EMAIL PROTECTED]> wrote: Caleb Tennis wrote: > 2) Remove qt use flag, and create qt3 and qt4 global flags. It allows proper use.masking. Thanks. > people who are in favor of #2 have volunteered to do the work to implement > it as well as put qt3 into the use.defaults for 2006.1 so KDE will work > "out of the box". What should happen to qt4? I think it should be in make.defaults because qt is in make.defaults. So initially we need to do for make defaults: s/qt/qt qt3 qt4/ I would like this to happen retroactively for all current profiles so that no one gets broken when we migrate all ebuilds. After the conversion the qt use flag can be removed from the profiles. waiting for qt3 default flag to migrate my ebuilds :) Regards, Stefan -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Pending Removal of $KV
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 superb efforts of the kernel team and of linux-info eclass. As such I would like to deprecate $KV in favor of using linux-info eclass. I don't see the need for portage to export $KV into the environment for all packages. There are a few packages left that use this. There will be a tracker bug shortly. Mostly this mail is just a heads up ;) But any kind of checks against something in $KERNEL_DIR are just wrong, wrong, wrong. The only exception being when the ebuild is building something *against* those sources (kernel modules, and that's it). It's annoying to have virtual/linux-sources pulled as a dep of gnupg, iptables or any other package that can do fine without them. In many cases those packages are looking for a specific kernel feature to make sure support is enabled for it. You could argue that in the case where you aren't compiling against the kernel that support being enabled isn't critical, but that is a discussion you need to have with the package maintainers. HmmmI don't know about this, since I'm jusr a user without much programming experience, and haven't developed anything that makes use of kernel features, but If they don't actually build against the kernel, couldn't/shouldn't they look at either kernel-headers or the output of `uname -r` (possibly with a way to force the feature on if the user knows it's available but the build system isn't detecting it)? --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: using specific gcc-version in ebuild
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, but ... there is the possibility to have multiple gcc versions installed. So why not set CC and/or CXX variables inside the ebuild, and then compile the app with the "right" gcc-version? At this point, it just bugs me, that gentoo is staying below its potential. Well, hmmm, you might want to say, that there will be trouble because of applications/libraries linked to different libstdc++ versions - or something else. I'm always willing to learn, but this really bugs me, because gentoo really has potential for what's needed in this situation. Well, the problem here is that compiling some packages with one version of GCC and others with another version of GCC (on the same system) is asking for trouble. This means that ebuilds shouldn't change the GCC version in use. If the user wants to try it and see if it works, let them have at it, but don't do it automatically - it *will* eventually break someone's system (maybe not with 3.4+4.0/4.1, but who knows with future versions...remember the migration from GCC 3.3 to 3.4?). --Arek P.S. Who knows...eventually these incompatible packages might just make the move to GCC 4 (possibly on a major update). Until they do, tho, they'll just have to be broken (which is a shame...I like qemu). -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
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 shortcoming, I am starting to make a FAQ page in the trac wiki: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq We are adding new questions there, if you have some additions, please talk to me and I will add them for you. I do have a question: If you're allowing just anybody who asks to have commit access to the repo, what guarantees can you give me that they won't commit something deliberately malicious or which will break the entire overlay to the overlay? --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: Sunrise Project -- Sunrise FAQ
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 and answers easily get lost in a mailing > list. To solve this shortcoming, I am starting to make a FAQ page in the > trac wiki: > http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq > > We are adding new questions there, if you have some additions, please talk > to me and I will add them for you. I have one... What will it take for this project to go away? I have a counter-question to this: What modifications to the sunrise (not sunrice, btw) project would have to be made to get you to stop actively trying to shut it down? I really don't care if you think the team will be willing to make the changes, list them anyway, please. :) I'm asking because I think that this project is a Good Thing, if it gets handled correctly. I also agree that if it is not handled correctly it can and will be a Very Bad Thing. --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] virtual/x11-7* hides real bugs and breaks good ebuilds
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 great idea to fix the unported ebuilds. Would it be possible to mark virtual/x11-7 as deprecated (using enotice/ewarn or similar), in order to get people to port any build relying on it to modular X? The way I see it, once virtual/x11-7 has been deprecated for a while (6 months to a year) and most popular packages have been ported to modular X, virtual/x11-7 and any packages still relying on it could be given Last Rites. --Arek -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: automatically killing invalid CFLAGS/warning about bad CFLAGS
I find it a little annoying, but not that annoying. I have a few checks to make on libsdl, since it did fail with my CFLAGS settings. Perhaps it's not -fvisibility-inlines-hidden. As for KDE apps, didn't someone mention earlier that these ebuilds now filter -fvisibility-inlines-hidden? 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 wrote: > -fvisibility-inlines-hidden not only breaks a number of kde apps afaik (it's > filtered now), Again, probably -fvisibility=hidden. Many people have had success building KDE with both flags enabled lately, so maybe that's something that could be revisited when 4.1 goes ~arch. Getting off topic here, so see http://forums.gentoo.org/viewtopic-t-426814.html if you're interested. but it also seems to break SDL (using noflagstrip). -fvisibility-inlines-hidden affects C++ code. libsdl is written in C. ;) > It's not > broken enough that I'm going to remove it from my global CXXFLAGS, tho, > especially since if it breaks something I know about it right away (compile > error) and can remove the flag for that package. Right, so you don't find that `sleep 5` at the beginning of every single emerge just a little annoying? ;) --de. -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: automatically killing invalid CFLAGS/warning about bad CFLAGS
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 SDL (using noflagstrip). It's not broken enough that I'm going to remove it from my global CXXFLAGS, tho, especially since if it breaks something I know about it right away (compile error) and can remove the flag for that package. --James -- gentoo-dev@gentoo.org mailing list
