Re: [gentoo-dev] FEATURES use or misuse?
On Wednesday 04 November 2009 01:33:23 Sebastian Pipping wrote: Patrick Lauer wrote: Calling EAPI is ... well ... I can't even think of a place to start to explain how wrong it is. How on earth are you going to parse an eclass that supports multiple EAPIs where one EAPI were to support features of bash 4? The only way to do it would be to force bash 4 on all lower EAPIs, or make per-EAPI eclasses, or forbid use of new bash features in eclasses. All horrible ways to avoid fixing the problem. I find restricting the eclass to Bash 3 is a natural, maintainable approach to this. How would fixing he problem work from your perspective? It doesn't :) You can't use the new features in the old eclass, even with conditionals separating the execution paths. Which means you'd have to either not use them (which makes me wonder why we allow features when they can't be used). Or you clone the eclass and now maintain the code in two places (wheee, bad engineering!) So we end up with a bad solution either way. There are some clean options, but they tend to be a bit more complex. For example globally forcing minimum versions (which makes upgrade paths a bit more interesting). All workaroundable by just accepting things as they are. What do you mean by accepting things as they are? People have been doing things (in this case using bash 3.2 features) for a long time (about a year now). Even when some people warned about the impact noone cared. So more and more these illegal features get used, and as there are no sanctions for it (not even from QA!) they are accepted as allowed. Fast forward and you have an informal standard (using += in ebuilds is ok) that is agreed on by everyone. Yes, everyone, because when people pointed out that it was a Bad Thing there was no reaction, no opposition, nothing. So the Gentoo developer community agreed on it. The only thing not reflecting that agreement is PMS. So we fix it. Same with FEATURES variable. Been used for the last few years. Works. Most reliable way to do a few things if you assume that users don't actively try to break things. And instead of properly documenting it we pretend it never happened? You have been talking of accepting reality repeatedly and I'm left wondering what you actually mean by that. I especially fail to see who is trying to conceal(?) reality and reality about what. Ok, from stable portage ebuilds: RDEPEND= [snip] =app-shells/bash-3.2_p17 from KDE eclass: RESTRICT+= test gentoo-x86/app-shells/bash $ ls -1 *.ebuild bash-3.1_p17.ebuild bash-3.2_p39.ebuild bash-3.2_p48-r1.ebuild bash-3.2_p48.ebuild bash-4.0_p28.ebuild bash-4.0_p33.ebuild bash-4.0_p35.ebuild So we can either dance around all day and pretend bash 3.0 still has any relevance, or we stop the nonsense and tolerate reality as it is. We can also pretend FEATURES never served a purpose and doesn't fix any issues, then spend lots of time workarounding around working solutions because we just declared them illegal. I don't know how much time you have and what your priorities are, but I'm not going to care about such a waste of time, and it goes very low on my list of priorities. If there's a decision on this I doubt most devs will care much, so anyone wanting to have the FEATURES use removed will end up having to do it himself, against the resistance of package maintainers (don't touch my package etc. etc.) Have fun, Patrick
Re: [gentoo-dev] Re: FEATURES use or misuse?
On Wednesday 04 November 2009 01:11:39 Ryan Hill wrote: On Tue, 3 Nov 2009 23:28:57 +0100 Patrick Lauer patr...@gentoo.org wrote: And then why bother when the tree doesn't reflect PMS. Maybe if some people would stop ignoring PMS on whim because they don't agree with something in it this wouldn't be the case. Well, we have at least one prior discussion and a year of precedent on the bash 3.0 / 3.2 thing. Since there were no sanctions for doing it, there's no way to break things with it (because you have a recent enough bash guaranteed) and it is very convenient people started using it. After a year of use (and getting used more and more) I just don't see how any sane person can think about forbidding it NOW. It's too late. We've moved on. You missed your chance. FEATURES has been used in ebuilds for a lng time. People were happy with it. The only reason it was not properly documented in PMS was because the authors didn't agree with it. That's not how you do a standard, but then it never was about documenting reality. Now PMS has this hole in it, and instead of (1) documenting current behaviour and (2) agreeing on a standard behaviour while (3) keeping the historical errata documented ... well, it's kinda, look over there ... *runs away* Not a way to discuss or write a standard, also making things complicated when there are known easy ways to fix it. Like, when does this end? Whenever there's a policy you don't agree with, you do whatever you want? And it's the policy that's the problem? Well, if everyone else freely ignores it and pointing out that people violating the policy has no response I'll consider that policy inactive. If the Gentoo developers vote with their feet I'm not going to pretend they didn't. What you can do then is document what just happened ... maybe ... optionally? Anyways, this has nothing to do with PMS. Using FEATURES in the tree was frowned upon long before it even existed. The fact that it wasn't documented as such outside of mailing lists and bug reports is the real bug. And that usage was tolerated for 2 years. I still don't see what's bad about using things as they are, but if people now decide that we need to do complex dances instead of fixing things I'll just grab a camera and tape it instead of complaining. Life is too short to get worked up about such things :)
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
2009/11/3 Jörg Schaible joerg.schai...@gmx.de # Samuli Suominen ssuomi...@gentoo.org (16 Oct 2009) # Fails to build with KDE4 installed wrt bug #277427. # Masked for removal in 30 days. net-news/eventwatcher kde-misc/kisdnwatch ... http://bugs.gentoo.org/show_bug.cgi?id=279823 Does kde team changed their plans to move kde3 together with all kde3 applications to dedicated overlay? If not, then why we just drop this applications? No, the plan hasn't changed. These won't build with _stable_ KDE4 installed, and has no reverse deps. As such, they will be killed. Only the functional KDE3 programs will be moved to overlay. Sorry, I cannot follow this argumentation. In the office I need Exchange integration and all I can hope is, that it is ready for KDE 4.5. Unless this time, I have to stick with KDE3. However, with you removing all those apps, you also remove quite some that I use and need also. If you do not move them to the KDE3 overlay, my KDE3 setup is quite similar useless as KDE4 and the KDE3 overlay is simply a farce. If I use KDE3 only, I do *not* have KDE4 on my machine i.e. those apps *will* build without problems. You would have better add some build dependency with kdelibs-4 to effectively block those ebuilds when KDE4 is installed. You should join the kde-sunset (aka kde3) overlay team and maintain those packages, with the proper kde4 blocks, in that overlay. It expressly exists for people who need legacy applications. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
What about ppc64? They are MONTHS behind on stabilization, even for security bugs (see bug 281821 for example). The Qt team feels this is no longer acceptable. We propose that any arch that can't keep up will be demoted to experimental status. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Ben de Groot wrote: 2009/11/3 Jörg Schaible joerg.schai...@gmx.de # Samuli Suominen ssuomi...@gentoo.org (16 Oct 2009) # Fails to build with KDE4 installed wrt bug #277427. # Masked for removal in 30 days. net-news/eventwatcher kde-misc/kisdnwatch ... http://bugs.gentoo.org/show_bug.cgi?id=279823 Does kde team changed their plans to move kde3 together with all kde3 applications to dedicated overlay? If not, then why we just drop this applications? No, the plan hasn't changed. These won't build with _stable_ KDE4 installed, and has no reverse deps. As such, they will be killed. Only the functional KDE3 programs will be moved to overlay. Sorry, I cannot follow this argumentation. In the office I need Exchange integration and all I can hope is, that it is ready for KDE 4.5. Unless this time, I have to stick with KDE3. However, with you removing all those apps, you also remove quite some that I use and need also. If you do not move them to the KDE3 overlay, my KDE3 setup is quite similar useless as KDE4 and the KDE3 overlay is simply a farce. If I use KDE3 only, I do *not* have KDE4 on my machine i.e. those apps *will* build without problems. You would have better add some build dependency with kdelibs-4 to effectively block those ebuilds when KDE4 is installed. You should join the kde-sunset (aka kde3) overlay team and maintain those packages, with the proper kde4 blocks, in that overlay. It expressly exists for people who need legacy applications. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __ lowly user here We have been having a discussion on the KDE mailing list over the last few days and a couple of us Gentoo users have issues. KDE 4 is just not ready quite yet. I firmly believe it will be in the next few months and with each upgrade it gets better. As I wrote on the KDE list a short time ago, some of us feel that we are having KDE 4 forced on us when it is not ready just because KDE 3.5 is not being maintained. I'm not pointing at Gentoo here because this appears to be coming from upstream. Gentoo can't provide packages when upstream is not updating. What my point, and the point from others is, we need KDE 3.5 to be in the tree until at least KDE 4.4 or even better KDE 4.5 is released. I have faith that KDE 4 will be ready and fully usable by that point. Surely this can be done somehow. If not, KDE needs to rethink how they do this next time so that it can. It's not like KDE is new on the block. Just to be clear, I don't think this is a Gentoo problem but a problem with how KDE is handling the releases. It sounds like KDE has dropped the ball on KDE 3.5 a little bit early. I'm not a dev so I could be wrong here. end lowly user Dale P. S. Going back to my hole now.
[gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi, Ben de Groot yng...@gentoo.org: What about ppc64? They are MONTHS behind on stabilization, even for security bugs (see bug 281821 for example). The Qt team feels this is no longer acceptable. We propose that any arch that can't keep up will be demoted to experimental status. I surely subscribe to that. At the moment Brent (ranger) is definitely alone on that arch. V-Li -- Christian Faulhammer, Gentoo Lisp project URL:http://www.gentoo.org/proj/en/lisp/, #gentoo-lisp on FreeNode URL:http://gentoo.faulhammer.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
2009/11/4 Dale rdalek1...@gmail.com: We have been having a discussion on the KDE mailing list over the last few days and a couple of us Gentoo users have issues. KDE 4 is just not ready quite yet. I firmly believe it will be in the next few months and with each upgrade it gets better. As I wrote on the KDE list a short time ago, some of us feel that we are having KDE 4 forced on us when it is not ready just because KDE 3.5 is not being maintained. I'm not pointing at Gentoo here because this appears to be coming from upstream. Gentoo can't provide packages when upstream is not updating. What my point, and the point from others is, we need KDE 3.5 to be in the tree until at least KDE 4.4 or even better KDE 4.5 is released. I have faith that KDE 4 will be ready and fully usable by that point. Surely this can be done somehow. If not, KDE needs to rethink how they do this next time so that it can. It's not like KDE is new on the block. Just to be clear, I don't think this is a Gentoo problem but a problem with how KDE is handling the releases. It sounds like KDE has dropped the ball on KDE 3.5 a little bit early. I'm not a dev so I could be wrong here. I agree with you that KDE4 is not yet up to the standards of stability and usability we are used to in KDE3. However, both KDE and Qt upstream have de facto dropped support for their respective version 3. This means nobody is looking at security issues for those old versions. We cannot be expected to do that job for them, and do not want to maintain versions no longer supported upstream with possibly unknown security bugs. As you say, it is indeed an upstream problem, which forces our hand. But to extend a hand to those users who want to stick with the old versions and are willing to take possible security risks, we have started the kde3 overlay. And we are happy to help lowly users like you to get the skills to co-maintain those packages in the overlay. As it is now, we have no Gentoo developer who is committed to maintain both Qt3 and KDE3, and we feel it is irresponsible to leave those unmaintained in the tree. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Ben de Groot wrote: 2009/11/4 Dale rdalek1...@gmail.com: We have been having a discussion on the KDE mailing list over the last few days and a couple of us Gentoo users have issues. KDE 4 is just not ready quite yet. I firmly believe it will be in the next few months and with each upgrade it gets better. As I wrote on the KDE list a short time ago, some of us feel that we are having KDE 4 forced on us when it is not ready just because KDE 3.5 is not being maintained. I'm not pointing at Gentoo here because this appears to be coming from upstream. Gentoo can't provide packages when upstream is not updating. What my point, and the point from others is, we need KDE 3.5 to be in the tree until at least KDE 4.4 or even better KDE 4.5 is released. I have faith that KDE 4 will be ready and fully usable by that point. Surely this can be done somehow. If not, KDE needs to rethink how they do this next time so that it can. It's not like KDE is new on the block. Just to be clear, I don't think this is a Gentoo problem but a problem with how KDE is handling the releases. It sounds like KDE has dropped the ball on KDE 3.5 a little bit early. I'm not a dev so I could be wrong here. I agree with you that KDE4 is not yet up to the standards of stability and usability we are used to in KDE3. However, both KDE and Qt upstream have de facto dropped support for their respective version 3. This means nobody is looking at security issues for those old versions. We cannot be expected to do that job for them, and do not want to maintain versions no longer supported upstream with possibly unknown security bugs. As you say, it is indeed an upstream problem, which forces our hand. But to extend a hand to those users who want to stick with the old versions and are willing to take possible security risks, we have started the kde3 overlay. And we are happy to help lowly users like you to get the skills to co-maintain those packages in the overlay. As it is now, we have no Gentoo developer who is committed to maintain both Qt3 and KDE3, and we feel it is irresponsible to leave those unmaintained in the tree. Cheers, lowly user again Is it possible to just mask and maybe keyword KDE 3? Maybe do a news item as to why it is being done? That way people like me that don't use overlays can still keep KDE 3.5 but it requires us to unmask them. It would be just like we have to do to use a new program that may have security issues or bugs but just in reverse. I mention because I have already downloaded Mandriva and plan to install it as a temporary fix if needed. I think I can suffer through Mandriva for a couple months while this gets sorted out. I'm planning to install the same for my brother. I would like to install Gentoo but he's not as geeky as me. back to my hole again Dale :-) :-)
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
El mié, 04-11-2009 a las 07:55 -0600, Dale escribió: I mention because I have already downloaded Mandriva and plan to install it as a temporary fix if needed. I think I can suffer through Mandriva for a couple months while this gets sorted out. I'm planning to install the same for my brother. I would like to install Gentoo but he's not as geeky as me. back to my hole again Dale :-) :-) Mandriva already dropped KDE3 in 2010 and cooker and it's not being supported in older versions, since it's in contrib (for 2009.1) and 2009.0 (and previous) support ended for desktops. Then, it's the same situation (or even worse since, *if I don't misremember*, there is no external repository still providing kde3) Regards
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Pacho Ramos wrote: El mié, 04-11-2009 a las 07:55 -0600, Dale escribió: I mention because I have already downloaded Mandriva and plan to install it as a temporary fix if needed. I think I can suffer through Mandriva for a couple months while this gets sorted out. I'm planning to install the same for my brother. I would like to install Gentoo but he's not as geeky as me. back to my hole again Dale :-) :-) Mandriva already dropped KDE3 in 2010 and cooker and it's not being supported in older versions, since it's in contrib (for 2009.1) and 2009.0 (and previous) support ended for desktops. Then, it's the same situation (or even worse since, *if I don't misremember*, there is no external repository still providing kde3) Regards I have the 2009 version which still has KDE 3.5 available. I think KDE 4 is there to but I don't plan to install it anyway. It may not be as secure but at least it still works. ;-) Dale :-) :-)
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Dale wrote: lowly user again Is it possible to just mask and maybe keyword KDE 3? Maybe do a news item as to why it is being done? That way people like me that don't use overlays can still keep KDE 3.5 but it requires us to unmask them. It would be just like we have to do to use a new program that may have security issues or bugs but just in reverse. I mention because I have already downloaded Mandriva and plan to install it as a temporary fix if needed. I think I can suffer through Mandriva for a couple months while this gets sorted out. I'm planning to install the same for my brother. I would like to install Gentoo but he's not as geeky as me. back to my hole again Dale :-) :-) Give the developers a _good_ reason why overlays shouldn't be used in this case and I'm sure they'll consider it. But I don't think I refuse to use a standard tool of my chosen distro (for no good reason) is going to change their minds here. Overlays allow for a clear separation of fully supported and partially / unsupported packages in a manner that's clear, easy to use and maintain for both users and developers, with the added bonus of reducing disk usage and sync time for those who don't wish to use that set of packages. I fully welcome the way the sunsetting of KDE 3.5 is being done. It's clear and easy to follow. AllenJB
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
2009/11/4 Dale rdalek1...@gmail.com: Is it possible to just mask and maybe keyword KDE 3? This has already been decided. We are moving it to an overlay. I can't think of a valid reason why you would not use that overlay. Maybe do a news item as to why it is being done? There *is* a news item: /usr/portage/metadata/news/2009-11-02-kde-3/2009-11-02-kde-3.en.txt Which references http://archives.gentoo.org/gentoo-desktop/msg_a3e260bd0545cb4e763c81bc60f81de2.xml And for Qt3 there is http://archives.gentoo.org/gentoo-dev/msg_e81a66259e844162ef7f2db2a358d440.xml Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
[gentoo-dev] client/server consistency: USE flags / split packages
Hi. How do we handle packages that provide client, server, and possibly extra tools/libraries? Do we split packages like binary distros do or do we use USE flags? What USE flags? Currently some packages are split other use client, server or minimal USE flag(s). Back in 2006 similar problem was discussed many times with no final resolution - it was hard to ban split packages since portage had no support for USE deps. Also some packages started to utilize 'minimal' USE flag to force users read USE flag description and thus reduce its usage and lower number of bugs due to not-installed parts of package. With EAPI=2 both use deps and USE defaults (if necessary) are here so it's possible to introduce some guidelines: 1. do not split packages; use USE flags and USE deps. 2. stop using minimal USE flag to build client or sever only. So are there any good reasons to split packages? https://bugs.gentoo.org/12499 but many similar disscussions were on this list... -- Peter.
Re: [gentoo-dev] client/server consistency: USE flags / split packages
Peter Volkov wrote: Hi. How do we handle packages that provide client, server, and possibly extra tools/libraries? Do we split packages like binary distros do or do we use USE flags? What USE flags? Currently some packages are split other use client, server or minimal USE flag(s). Back in 2006 similar problem was discussed many times with no final resolution - it was hard to ban split packages since portage had no support for USE deps. Also some packages started to utilize 'minimal' USE flag to force users read USE flag description and thus reduce its usage and lower number of bugs due to not-installed parts of package. With EAPI=2 both use deps and USE defaults (if necessary) are here so it's possible to introduce some guidelines: 1. do not split packages; use USE flags and USE deps. 2. stop using minimal USE flag to build client or sever only. So are there any good reasons to split packages? https://bugs.gentoo.org/12499 but many similar disscussions were on this list... I think a good guideline is: 1. Use a single pkg when upstream releases server and client in one bundle 2. Use separate packages when upstream releases client and server separately I think the minimal use flag should not be used for this purpose any more. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] client/server consistency: USE flags / split packages
Am Mittwoch, den 04.11.2009, 18:44 +0300 schrieb Peter Volkov: Hi. How do we handle packages that provide client, server, and possibly extra tools/libraries? Do we split packages like binary distros do or do we use USE flags? What USE flags? Currently some packages are split other use client, server or minimal USE flag(s). Back in 2006 similar problem was discussed many times with no final resolution - it was hard to ban split packages since portage had no support for USE deps. Also some packages started to utilize 'minimal' USE flag to force users read USE flag description and thus reduce its usage and lower number of bugs due to not-installed parts of package. With EAPI=2 both use deps and USE defaults (if necessary) are here so it's possible to introduce some guidelines: 1. do not split packages; use USE flags and USE deps. 2. stop using minimal USE flag to build client or sever only. So are there any good reasons to split packages? In environments with a staging server and binary packages, yes. -- Tiziano Müller Gentoo Linux Developer Areas of responsibility: Samba, PostgreSQL, CPP, Python, sysadmin, GLEP Editor E-Mail : dev-z...@gentoo.org GnuPG FP : F327 283A E769 2E36 18D5 4DE2 1B05 6A63 AE9C 1E30 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil smime.p7s Description: S/MIME cryptographic signature
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
Hi! On Wed, 04 Nov 2009, Christian Faulhammer wrote: Ben de Groot yng...@gentoo.org: What about ppc64? They are MONTHS behind on stabilization, even for security bugs (see bug 281821 for example). The Qt team feels this is no longer acceptable. We propose that any arch that can't keep up will be demoted to experimental status. I surely subscribe to that. At the moment Brent (ranger) is definitely alone on that arch. So am I on alpha.[0] It is doable, but it wears you thin - and it's extra bad because it means I have hardly any free time to mentor anybody. That said, I hope whoever feels the need comes to me /before/ they file a bug for Let's make alpha experimental. Regards, Tobias [0] Yes, armin76 helps, but he does so for many arches (and around of applause for that), but the majority of bugs for alpha are on my plate.
Re: [gentoo-dev] client/server consistency: USE flags / split packages
В Срд, 04/11/2009 в 17:34 +0100, Tiziano Müller пишет: Am Mittwoch, den 04.11.2009, 18:44 +0300 schrieb Peter Volkov: So are there any good reasons to split packages? In environments with a staging server and binary packages, yes. Currently you either have to script your staging server correctly (play with PKGDIR) or use different build hosts for different configurations. In any way, this does not justify pushing USE flags into package names. -- Peter.
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
On Wed, Nov 4, 2009 at 11:31 PM, Tobias Klausmann klaus...@gentoo.org wrote: [0] Yes, armin76 helps, but he does so for many arches (and around of applause for that), but the majority of bugs for alpha are on my plate. +++, armin76 does an awesome job of keywording/stabilizing. I really love how he comes down and destroys bugs with one fell swoop saying alpha/arm/ia64/m68k/sh/sparc done :D -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: [RFC] Improve policy of stabilizations
Ben de Groot wrote: What about ppc64? They are MONTHS behind on stabilization, even for security bugs (see bug 281821 for example). The Qt team feels this is no longer acceptable. We propose that any arch that can't keep up will be demoted to experimental status. ppc is also fairly far behind (much thanks to nixnut for keeping us going!). Part of the problem is that when I do get time to catch up, we're so buried in bugs, it's time consuming just to triage and figure out what to do next, and even to remember where I left off last. I would really help if there were better communication about what bugs absolutely need to be done ASAP and what can slide by for now. That said, please be a bit more patient with us, we just don't have the manpower to fix every single keywording bug immediately. -Joe
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Ben de Groot wrote: 2009/11/4 Dale rdalek1...@gmail.com: Is it possible to just mask and maybe keyword KDE 3? This has already been decided. We are moving it to an overlay. I can't think of a valid reason why you would not use that overlay. Because I don't want one more thing to have to deal with. Gentoo is enough fun already. Maybe do a news item as to why it is being done? There *is* a news item: /usr/portage/metadata/news/2009-11-02-kde-3/2009-11-02-kde-3.en.txt Which references http://archives.gentoo.org/gentoo-desktop/msg_a3e260bd0545cb4e763c81bc60f81de2.xml And for Qt3 there is http://archives.gentoo.org/gentoo-dev/msg_e81a66259e844162ef7f2db2a358d440.xml Cheers, I was talking about *if* KDE 3.5 was masked then have a news item as to why it was being masked. Since keeping it in the tree is not going to happen then there is no point. Dale :-) :-)
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
El mié, 04-11-2009 a las 15:48 -0600, Dale escribió: Ben de Groot wrote: 2009/11/4 Dale rdalek1...@gmail.com: Is it possible to just mask and maybe keyword KDE 3? This has already been decided. We are moving it to an overlay. I can't think of a valid reason why you would not use that overlay. Because I don't want one more thing to have to deal with. Gentoo is enough fun already. But, why do you think having kde3 stuff hardmasked in main tree in unmaintained state will be better than having it on a external overlay? :-/ Also, think about gnome users (like me) that will not need to download all kde3 ebuilds on every sync :-) Yes, maybe they aren't so much but I still fail to see why do you think that preserving kde3 hardmasked is better than using an overlay Regards
[gentoo-dev] Re: FEATURES use or misuse?
tis 2009-11-03 klockan 16:48 +0100 skrev Patrick Lauer: Hi there, All of these bugs were for the use of the FEATURES variable in ebuilds, which is a very convenient thing to work around issues. For example known failures with FEATURE=distcc or funky things like test failures with FEATURES=userpriv and so on. All other methods of expressing that are much more verbose and inherently sucky. I ask myself if what we really want is many different and strange approaches to handle FEATURES? Would it not be better to actually expand some eclasses to be able to say something about your build environment? I mean where the checks for userpriv is needed also prefix will fail, because AFAIK it can be used to build and install programs in an non-root environment? Or if you just test an ebuild and runs it as your user? So would it not just be better to have a check for which privs the user has so it covers more fields? For ccache and for distcc would it not be better to expand toolchain-funcs so you can have a function like tc-getCC from which you can get that sort of information? Also if the ebuilds does not already have a comment about it, do not forget to comment on why these checks are there, and why they are a must (i.e. a broken buildsystem should be fixed, not worked around - while tests that are designed to run as root should not be run as a user even if in the best of worlds all testsuits should test and skip those tests themselves). I would not like to see a new kind of hell where when something is broken it is not fixed properly, but in a strange ways worked around in ways that does not always work. qemu and kvm is good examples on how NOT to do this these with regards to hardened. qemu (which kvm apparently has used as a template) has a broken build system (it does not link with CFLAGS, only LDFLAGS, which is something that also the gcc devs say you should not if you want a predictable result), and it also invokes filter-flags at the wrong place in the ebuild (hint: int should be invoked before the command that sets the CFLAGS, in this case ./configure and not after like in these ebuilds). Instead it has some strange logic to unset/change the GCC_SPECS which if it ever worked certainly does not anymore (bugs filed for both, qemu bug is really old, but very noisy, bug for kvm has been open for about an week which the qemu maintainer may want to check out, with a clean patch of one added sed a move of filter-flags and the removal of the whole src_compile block to make the ebuild install something which (in case of qemu) actually build, and does not segfault as soon as it uses a bit softmmu).
[gentoo-dev] 2.6.31 stable plans
I'm planning to request the stabling of gentoo-sources-2.6.31 on November 13th, a little more than 1 week from now. We have a few regressions we are tracking but they are not far reaching and most are close to resolution. We will follow up on all unresolved regressions. Regressions in external packages in the stable tree are tracked in bug #291927. If any arise, please make every effort to fix these. Thanks, Mike Pagano -- Mike Pagano Gentoo Developer - Kernel Project E-Mail : mpag...@gentoo.org GnuPG FP : EEE2 601D 0763 B60F 848C 9E14 3C33 C650 B576 E4E3 Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3op=index
Re: [gentoo-dev] Re: Lastrite (part 1): KDE3-only applications that won't build when KDE4 is installed
Pacho Ramos wrote: El mié, 04-11-2009 a las 15:48 -0600, Dale escribió: Ben de Groot wrote: 2009/11/4 Dale rdalek1...@gmail.com: Is it possible to just mask and maybe keyword KDE 3? This has already been decided. We are moving it to an overlay. I can't think of a valid reason why you would not use that overlay. Because I don't want one more thing to have to deal with. Gentoo is enough fun already. But, why do you think having kde3 stuff hardmasked in main tree in unmaintained state will be better than having it on a external overlay? :-/ Also, think about gnome users (like me) that will not need to download all kde3 ebuilds on every sync :-) Yes, maybe they aren't so much but I still fail to see why do you think that preserving kde3 hardmasked is better than using an overlay Regards Because I am not familiar with overlays. I have never used one and hope to keep it that way. If it was hardmasked, just run autounmask kde-meta:3.5 or something similar and carry on. Naturally that wouldn't last forever. It would eventually have to go away but most likely it only needs to be there for a couple months, maybe three months. I really believe KDE will be stable and working well in the near future. As for the tree, until recently I was on a very slow dial-up and just syncing the tree took about 45 minutes on average. I never complained about Gnome being there. I don't use Gnome but I know other people do. I did try it once tho. Just prefer KDE. Sorry. I won't complain about Gnome if you don't complain about KDE. lol Dale :-) :-)
[gentoo-dev] Lastrite: gnome-extra/hardware-monitor
This package has a lot of issues, random segfaults (reproducible or not), Corba exceptions... devs not really active on upstream, and we're not interested to being maintainer (if you want a soft for monitoring your hardware use gnome-system-monitor) Pending for removal until 4 Dec. 2009. Regards, Romain. -- Romain Perier Gentoo Linux Developer Site: http://dev.gentoo.org/~mrpouet Blog: http://planet.gentoo.org/developers/mrpouet FP: 5728 DC13 9600 864E 2C37 7D1F 3791 7B66 3B94 72EF signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] 2.6.31 stable plans
On Thu, Nov 5, 2009 at 5:08 AM, Mike Pagano mpag...@gentoo.org wrote: I'm planning to request the stabling of gentoo-sources-2.6.31 on November 13th, a little more than 1 week from now. We have a few regressions we are tracking but they are not far reaching and most are close to resolution. We will follow up on all unresolved regressions. Regressions in external packages in the stable tree are tracked in bug #291927. If any arise, please make every effort to fix these. Are there any plans to stabilize a newer version of linux-headers so that packages can make use of some of the features in the newer kernels[1]? The bug open for this purpose[2] has not made any progress in a long time. 1. http://bugs.gentoo.org/show_bug.cgi?id=290918 2. http://bugs.gentoo.org/show_bug.cgi?id=273358 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
