[gentoo-dev] [PATCH] toolchain.eclass: Remove kludge that blocks gcc-6+ on sys-libs/uclibc-ng systems
The following kludge is present in toolchain.eclass, in
toolchain_pkg_pretend():
[[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
die "Sorry, this version does not support uClibc"
The below patch removes this. I've been running a gcc-6-built,
sys-libs/uclibc-ng in chroot for some time now, have completed several
catalyst runs, and am at the tail end of a fresh install of a
sys-libs/uclibc-ng userland on actual MIPS hardware.
Signed-off-by: Joshua Kinard
---
eclass/toolchain.eclass |3 ---
1 file changed, 3 deletions(-)
--- a/eclass/toolchain.eclass.orig 2017-07-29 19:06:30.894211203 -0400
+++ b/eclass/toolchain.eclass 2017-07-29 19:06:40.514211133 -0400
@@ -375,9 +375,6 @@ toolchain_pkg_pretend() {
"in your make.conf if you want to use this version."
fi
- [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \
- die "Sorry, this version does not support uClibc"
-
if ! use_if_iuse cxx ; then
use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled
due to USE="-cxx"'
use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler,
disabled due to USE="-cxx"'
Re: [gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Fri, Jul 28, 2017 at 05:56:25PM -0400, William L. Thomson Jr. wrote > If upstream does a new release, fixes bugs. Gentoo marks a previous > release stable. It is stabilizing a package with issues fixed upstream. > That does not make sense. Gentoo issues maybe good, but not upstreams. > > I maintained packages like iText which used to have a 30 day release > cycle. Up till recently Jetty was about the same. As a end user, I > needed the bug fixes. Not the delay for it be marked stable. > > I stopped running Redhat long ago due to time to vet updates. I run > Gentoo for the speed of being able to package and test out new code. What I get out of this discussion is that some people prefer to run ~arch versus stable arch. I have no problem with that. But I do object to dropping "stable" altogether. I personally run stable with the rare occasional unstable package, where it's either not available as stable, or the unstable version fixes a bug in the stable version. And just for kicks I'm running gcc 6.3.0. It's one thing to rush-stabilize a new package that fixes a security hole. But I don't see the point of rush-stabilizing everything "just because". I recommend mostly keeping our current setup, with one change, i.e. allowing security-fix ebuilds to go "stable" immediately. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Sat, 2017-07-29 at 19:41 +0300, Mart Raudsepp wrote: > > why take away the stable choice? > > I think it is rather clear that stable keywords aren't going anywhere > for architectures like amd64. I suggest we drop all of the subthreads > on this topic and get back to other interesting thoughts (which may > include dropping stable for some other arches of course; I mean doing > it for all doesn't deserve e-mails imo). > > > Mart > I demand you stop asking for dropping stable for "some other arches", otherwise I might have to stop arch testing on ppc and sparc.
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Tue, 25 Jul 2017 09:22:08 +0200 Dirkjan Ochtman wrote: > Second, I believe a lot of the value in our stable tree comes *just* > from the requirement that stabilization is only requested after 30 > days without major bugs/changes in the unstable tree. Assuming there > are enough users of a package on unstable, that means important bugs > can be shaken out before a version hits stable. This could mean that > potentially, even if we inverted our entire model to say we > "automatically" stabilize after a 30-day period without major bugs, > we hit most of the value of the stable tree with again drastically > reduced pain/work. I’m a stable user when I can be. I use Gentoo for the configurability, not for instant access to the newest versions of things. I think this is a fairly reasonable proposal if stabilization is otherwise happening too slowly right now. If 30 days with no bugs plus an automated successful build against an otherwise-stable set of dependencies led to an automatic stabilization, I’d be fine with that. Some clarification would be needed on what bugs block stabilization, and of course there would need to be a flag that maintainers could add to specific ebuilds to indicate whether or not they’re stabilization candidates (though I wonder if it would be better to flag the ones that *aren’t* candidates, rather than the ones that *are*). -- Christopher Head pgpnLOp9yoUTL.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Fri, 28 Jul 2017 12:44:20 +0200 Andreas K. Huettel wrote: > Am Dienstag, 25. Juli 2017, 01:22:44 CEST schrieb Peter Stuge: > > > > I hold a perhaps radical view: I would like to simply remove stable. > > > > I continue to feel that maintaining two worlds (stable+unstable) > > carries with it an unneccessary cost. > > > > That's not feasible. It would kill off any semi-professional or professional > Gentoo use, where a minimum of stability is required. > > (Try keeping ~10 machines on stable running without automation. That's > already > quite some work. Now try the same with ~arch. Now imagine you're talking > about > 100 or 1000 machines.) ~50 hosts here on ~arch. Stable vs unstable is not an issue for production. The main problem (at least in my case) is upgrade path, especially with hosts not that often updated. Upgrade of Gentoo-based production hosts takes considerable time, not just due to compilation time and issues, but due to the need to update dozens (sometimes hundreds) of config files properly and this process can't be fully automated. Another problem is short support time: only update path for systems up to one year old is supported more or less. IRL even half year old system may be PITA for a full update. To make it worse there are cases when people deliberately make such updates harder: some developers are refusing to set minimal version requirements for dependencies if dependency versions below minimal were below latest stable 1 year age. While such behaviour is within established policies I frankly do not understand such devs: having >=cat/foo-1.2.3 instead of cat/foo doesn't hurt, but makes life of fellow users much easier. Best regards, Andrew Savchenko pgplBwoP5YPz9.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
> why take away the stable choice? I think it is rather clear that stable keywords aren't going anywhere for architectures like amd64. I suggest we drop all of the subthreads on this topic and get back to other interesting thoughts (which may include dropping stable for some other arches of course; I mean doing it for all doesn't deserve e-mails imo). Mart
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
Am Freitag, 28. Juli 2017, 23:12:26 CEST schrieb A. Wilcox: > > At least I have a good reason to unsubscribe now. > > > Farewell, > --arw > Please don't take William as a typical Gentoo developer. He isn't. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, perl, libreoffice)
Re: [gentoo-dev] [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?
On Thu, 27 Jul 2017 18:12:52 -0500 Denis Dupeyron wrote: > On Mon, Jul 24, 2017 at 4:22 PM, Sergei Trofimovich > wrote: > > > TL;DR;TL;DR: > > > [...] > > Here's a data point you may, or may not, find relevant. in 16 years of > using Gentoo exclusively, the only one time I used stable on one machine > for about 2 years it ended up being much more of a pain than unstable. > Actually, I can't say I have anything to complain about unstable. On my > critical machines I snapshot the system subvolume before I update. I can't > remember the last time I had to roll back. +1 I do not use stable, even in production. Too few packages, too old versions, too long time to stabilize newer versions. I'm just OK with ~arch. > I'm sure most will disagree with me but since you're indirectly asking for > my opinion here it is: I think people working on stable are wasting their > time. But who am I to stop them... I support stable in my packages, but mostly because I have to. One of the real benefits from the stable for me is stabilization process which sometimes uncovers otherwise undetected problems. Of course there are people who use stable, I respect their opinion; they have different use cases, practices, experience. So I'm not asking to abandon stable, just explaining that for me and my cases it is mostly useless. Best regards, Andrew Savchenko pgprrqrPZspmA.pgp Description: PGP signature
