Re: [gentoo-dev] Ohloh Organizations - Gentoo Linux
On Mon, Nov 26, 2012 at 12:58 PM, Dirkjan Ochtman d...@gentoo.org wrote: On Fri, Nov 23, 2012 at 12:18 PM, Dirkjan Ochtman d...@gentoo.org wrote: I haven't heard back from them, maybe you can ask them what's up. This has been setup (with Donnie's help): https://www.ohloh.net/orgs/gentoo I've claimed 15 of the projects on there that I could easily find, analysis on those should complete shortly. If you're on Ohloh, please nominate further projects. You can also add the organization as a tag to your project contributions (which I've done for my gentoo-x86 commits). Also, if you're an active Ohloh user, let me know if you want to be a manager for the Gentoo organization. Cheers, Dirkjan Sure, I would like to be a manager. I'd like to add these as well: https://www.ohloh.net/p/gentoo_loongson_overlay https://www.ohloh.net/p/gentoo_catalyst
Re: [gentoo-dev] borked release media
On Fri, Dec 7, 2012 at 8:55 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Hey people, what are we going to do with bugs like: https://bugs.gentoo.org/show_bug.cgi?id=421839 https://bugs.gentoo.org/show_bug.cgi?id=445848 I'd like to help with things. Is the process of building livecd .isos and stages documented somewhere? I'd like to reproduce problems locally, work on fixes, and join the release teams. I also think points made at https://bugs.gentoo.org/show_bug.cgi?id=438234 are very reasonable, and we should do more testing of published media/stages. The serious problem here is that we need *new* users. A non-working install CD is a really bad thing here, don't you think? ;-) Again, I'm willing to do the work, just need some documentation/pointers. Paweł Indeed, it is a problem. Fortunately the missing /run was confirmed fixed earlier today on IRC, so that should be resolved shortly and with it the second bug you mention. The main problem here is that it's really easy to break the release media. Mistakes happen and are a normal part of development, but for instance stabilizing linux-headers-3.6 (bug 443532) with multiple outstanding bugs caused some completely predictable breakage. I have never once been able to grab a portage snapshot and build a stage 1, 2, 3 series from it without encountering at least a couple of problems with the tree. I think we should consider things that break release media serious regressions. I don't know what that entails specifically, but whether it need be QA bashing down your door or a quick fix or revert, it sure would be nice to get Gentoo to a place where release media always works. In any case, we'd love some extra help. jmbsvicetto and armin76 have been managing all of the autobuilds, to my knowledge, for a long time. catalyst could also use some work. Spend a day or so building some stages and I have no doubt you'd find things you want to change. :) In short, I think the conversation we should be having should be about how to avoid breaking release builds and how to quickly fix problems when they're discovered. Thanks, Matt
Re: [gentoo-dev] Time based retirements
On Thu, Dec 20, 2012 at 7:21 PM, Doug Goldstein car...@gentoo.org wrote: I'm curious who had the brain dead idea to retire Gentoo developers that are still interested in the distro, that maintain low activity packages for herds that are stretched way too thin, and are still contributing to the distro in many ways other than direct CVS commits (e.g. overlays, user support, providing hardware to other devs, etc). I could MAYBE understand it if they're consuming some valuable resource that we need to free up by retiring them. But instead they get a nasty-gram about their impending retirement and decide if that's how they are to be treated that they can be retired. When they finally want to contribute again they have the lovely uphill of our dreadfully painful recruitment process. I'm really just trying to understand the sense in this. -- Doug Goldstein Probably best to give an example.
[gentoo-dev] Wordiness
On Thu, Dec 20, 2012 at 10:09 PM, Duncan 1i5t5.dun...@cox.net wrote: Do you realize that you just wrote a two-and-a-half page single-spaced thousand-word email? Seriously, this is way too much. This mailing list is way too much.
Re: [gentoo-dev] Re: Wordiness
On Thu, Dec 20, 2012 at 11:05 PM, Duncan 1i5t5.dun...@cox.net wrote: My point is that you consistently write long essays that I, and apparently most others, don't bother to read. I'm not sure if you're aware of this. Someone said on IRC this morning in response to this thread the tragic thing is that guy would be able to make valuable contributions if it weren't for the excessive length of his mails So, your emails are way too long. A huge percentage of recipients don't bother to read them. I don't know whether you just enjoy writing (you must!) or if you hope to actually be heard, but as it stands now you're not being heard by most.
Re: [gentoo-dev] Local bindist descriptions
On Sat, Dec 29, 2012 at 3:54 PM, Alexander Berntsen alexan...@plaimi.net wrote: All packages should have local descriptions of what the bindist USE-flag specifically does. This should be a policy when writing ebuilds that include it. Agreed. media-libs/mesa Fixed. (bug 448932)
Re: [gentoo-dev] Switching order of packages in virtual/pkgconfig
On Wed, Jan 2, 2013 at 4:11 AM, Samuli Suominen ssuomi...@gentoo.org wrote: i'd say never. there is no benefit in switching. pkg-config is the default implementation from freedesktop.org. pkg-config is now lighter and has less dependencies than before as the switch from bundled glib1 to glib2 allowed dropping of the popt library. As a data point: pkgconfig and glib:2 are built during stage3 and removed during --depclean. Switching to pkgconf avoids glib:2 entirely and saves some stage3 building time.
Re: [gentoo-dev] January stabilization candidates
On Wed, Jan 16, 2013 at 5:58 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: net-wireless/b43-fwcutter-017 be my guest, although I prefer the bugs personally. That's what he's doing... asking maintainers if it's okay to open stabilization bugs for their packages.
Re: [gentoo-dev] January stabilization candidates
honestly this list is such a tinderbox that I hardly read it. I actually missed the email at first and had to go back in the thread when I saw a lot of responses. Hence, I would prefer to get bugs than random emails that I have to search through. So ignore it and he'll open bugs just the same. This was just an early opportunity for people to say no, this shouldn't be stabilized.
Re: [gentoo-dev] Getting proper USE_EXPAND variable(s) for multilib
On Sun, Jan 20, 2013 at 3:01 PM, Thomas Sachau to...@gentoo.org wrote: So you want to re-implement multilib-portage in an eclass without the additional benefits a package-manager level implementation has? I really wish you'd just make the PMS diff and get your stuff implemented. How long has it been?
Re: [gentoo-dev] The gx86 multilib project -- masterplan
On Sun, Jan 27, 2013 at 7:12 AM, Michał Górny mgo...@gentoo.org wrote: 5. Solutions to specific problems - 1. x11-proto packages Those packages install headers to /usr/include and pkg-config files to /usr/lib64. This supposedly means that the headers could be ABI-specific; however, so far I haven't seen a single difference. Possible solutions: a) check the headers by hand, move pkg-config files to /usr/share, b) make the proto packages multilib. This will cause identical .pc files to be installed to lib32 lib64 but will also enable eclass checks for header consistency. See http://lists.x.org/archives/xorg-devel/2012-September/033715.html In short, there seem to be a couple cases of platform-dependent substitutions in headers, but for the most part they're platform independent.
Re: [gentoo-dev] Porting ZFS to additional architectures
On Tue, Feb 5, 2013 at 11:25 AM, Richard Yao r...@gentoo.org wrote: Dear Everyone, Does anyone have root access to Linux systems on any of the following architectures that is willing to help ZFS development? Alpha HPPA IA-64 MIPS/MIPS64 PPC/PPC64 SH SPARC/SPARC64 I want to port ZFSOnLinux to all Gentoo Linux architectures this year. The above architectures either are not currently supported or have not been tested in a while. Most of them will require patching isa_defs.h, which I am in a position to do. I am not distributing the patches because I don't know if ZFS will build on those platforms. People willing (and able) to help should email me with their architecture and distribution. Gentoo Linux is preferred, but not required. No knowledge of programming is required. I will provide you with instructions on how to build and test ZFS on your architecture. Yours truly, Richard Yao I talked to ryao on IRC, but didn't seem to get my point across: (Almost?) no one runs Gentoo on any of these architectures for anything other than the novelty. There is zero point in maintaining ZFS on them, and it only stands to add load to the arch teams. These architectures operate on a we-only-keyword-things-necessary-or-users-ask-for policy. I don't think ZFS falls into either of these cases.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog profiles.desc
On Tue, Feb 19, 2013 at 7:19 AM, Alexis Ballier aball...@gentoo.org wrote: On Mon, 7 Jan 2013 00:02:33 + (UTC) Mike Frysinger (vapier) vap...@gentoo.org wrote: [...] + 07 Jan 2013; Mike Frysinger vap...@gentoo.org profiles.desc: + Mark s390 profiles stable. + 06 Jan 2013; Justin Bronder jsbron...@gentoo.org package.mask: Remove net-nntp/sabnzbd mask, fix already released and updated in tree. [...] --- profiles.desc 3 Jan 2013 16:08:06 - 1.201 +++ profiles.desc 7 Jan 2013 00:02:32 - 1.202 @@ -122,10 +122,10 @@ ppc64 default/linux/powerpc/ppc64/10.0/64bit-userland/server dev # S390 Profiles -s390default/linux/s390/10.0 dev -s390default/linux/s390/10.0/s390x dev -s390default/linux/s390/10.0/server dev -s390default/linux/s390/10.0/server/s390xdev +s390default/linux/s390/10.0 stable +s390 default/linux/s390/10.0/s390x stable +s390default/linux/s390/10.0/server stable +s390 default/linux/s390/10.0/server/s390xstable # SH Profiles sh default/linux/sh/10.0 dev please run 'repoman full | grep s390' on gentoo-x86 and fix the broken deps, they are now errors and I just hit one: dependency.bad16 app-text/texlive-core/texlive-core-2011-r6.ebuild: DEPEND: s390(default/linux/s390/13.0) ['media-libs/silgraphite'] A. Yep, me too with a Mesa revision bump.
Re: [gentoo-dev] [PATCH multilib-build] Tee the build logs to ABI-specific files.
On Thu, Feb 21, 2013 at 3:27 AM, Michał Górny mgo...@gentoo.org wrote:
This makes reading them a bit easier, especially with phases run
in parallel.
---
gx86/eclass/multilib-build.eclass | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gx86/eclass/multilib-build.eclass
b/gx86/eclass/multilib-build.eclass
index feac748..93c4335 100644
--- a/gx86/eclass/multilib-build.eclass
+++ b/gx86/eclass/multilib-build.eclass
@@ -100,7 +100,8 @@ multilib_foreach_abi() {
local ABI
for ABI in $(multilib_get_enabled_abis); do
multilib_toolchain_setup ${ABI}
- BUILD_DIR=${initial_dir%%/}-${ABI} ${@}
+ local BUILD_DIR=${initial_dir%%/}-${ABI}
+ ${@} | tee -a ${T}/build-${ABI}.log
done
}
@@ -127,8 +128,8 @@ multilib_parallel_foreach_abi() {
multijob_child_init
multilib_toolchain_setup ${ABI}
- BUILD_DIR=${initial_dir%%/}-${ABI}
- ${@}
+ local BUILD_DIR=${initial_dir%%/}-${ABI}
+ ${@} 21 | tee -a ${T}/build-${ABI}.log
)
multijob_post_fork
--
1.8.1.2
Definitely seems like a good idea.
Re: [gentoo-dev] Re: GCC 4.7 unmasking
On Mon, Feb 25, 2013 at 5:02 PM, Ryan Hill dirtye...@gentoo.org wrote: On Sun, 24 Feb 2013 23:03:01 -0600 Ryan Hill dirtye...@gentoo.org wrote: I'm going to be unmasking 4.7.2 later this week. There are still 47 open bugs blocking the 4.7 tracker, so if any are yours now would be a good time to take a look at them. https://bugs.gentoo.org/390247 Forgot to say, now would also be a great time for those crazy arch people to attempt a build on their crazy arches. :p mips looks good! :)
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 8:35 AM, Alec Warner anta...@gentoo.org wrote: In terms of 'following Gentoo policy.' We encourage packages to be as close to upstream as possible. I cannot fathom why when you basically find a performance bug in malloc, you start a thread on the list about replacing it; as opposed to filing a bug against glibc or emailing the glibc lists and asking them about it. We may not understand it, but it does completely fit ryao's typical modus operandi.
Re: [gentoo-dev] Evaluating a new malloc()
On Tue, Feb 26, 2013 at 1:37 PM, Maciej Mrozowski reave...@gmail.com wrote: On Tuesday 26 of February 2013 11:44:31 Rich Freeman wrote: On Tue, Feb 26, 2013 at 11:35 AM, Alec Warner anta...@gentoo.org wrote: I see a *HUGE* reason. glibc ships with ptmalloc. If you think they should use jemalloc, talk to them. Don't just do it in Gentoo. Certainly I think it would be far more productive to talk to the glibc maintainers first. You mean productive like below? ;) http://sourceware.org/bugzilla/show_bug.cgi?id=11261 Ulrich Drepper: Stop reopening. There is a solution for people who are stupid enough to create too many threads. No implementation will be perfect for everyone. The glibc implementation is tuned for reasonable programs and will run much faster than any other I tested. Drepper is no longer around. Upstream glibc is really friendly now, probably in an attempt to throw off the image you rightly had. Merge of jemalloc upstream is likely never going to happen. Indeed, but not because of Drepper, but rather because GNU projects require copyright assignment for non-trivial contributions and I highly doubt that the jemalloc developers who put it under the BSD license are going to be okay with relicensing to LGPLv3+ and assigning copyright on their work to the FSF.
Re: [gentoo-dev] Re: Last rites: media-tv/tvtime
On Sun, Mar 24, 2013 at 7:43 AM, Markos Chandras hwoar...@gentoo.org wrote: And what if it breaks again in the future? Should we go over the same discussion again? Can't this be restated as Shouldn't we tree clean it now since it could have bugs in the future?? Tree cleaning packages over future hypothetical bugs seems like bad policy.
Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask
On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman ri...@gentoo.org wrote: On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers j...@gentoo.org wrote: Er, you can't be seriously suggesting we will drop repoman checks with the migration to git? I don't see how that would benefit anyone. Interesting point. One thing to keep in mind with git is that commits don't affect the central repository. Pushes are what impacts the repository. If I spend six months working on a bunch of coordinated package changes, nobody will see a thing until I push those commits and 500 ebuilds all change atomically (not that I'm suggesting that lack of communication is to be encouraged). A repoman check on a commit may not reflect its impact six months later when it actually hits the main tree. ... if you're squashing 6 months of work into a single commit before pushing. I don't think we want to do that, do we? Maybe bisecting isn't particularly interesting for the portage tree.
Re: [gentoo-dev] Making systemd more accessible to normal users
On Wed, May 1, 2013 at 2:40 PM, Peter Stuge pe...@stuge.se wrote: Steven, I think you can behave a lot better on the internet. kthx. Amazing. I came to the exact opposite conclusion.
Re: [gentoo-dev] Re: GCC USE flag changes
On Wed, May 1, 2013 at 5:59 PM, Ryan Hill dirtye...@gentoo.org wrote: On Wed, 01 May 2013 08:00:29 +0100 Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 01/05/2013 06:29, Rick Zero_Chaos Farina wrote: I don't mean to start a flamewar here but the test suite situation is so bad with circular deps (I'm looking at you ruby herd) and random failures that I only enable tests for my own packages. Sadly it is so bad that we have a FEATURES=test-fail-continue I can't really say anything negative, that fact really says it all... You might not mean to but honestly, do you really think that we have circular deps because we like them? FFS I've been the biggest user of FEATURES=test, and the one who poured in more time to get stuff to work, so please don't effing go around blaming people without even having a clue about what's going on, you just piss me off. He wasn't singling you out, just naming a part of the tree that has a lot of circular deps. He could've said python just as easy. He may not have meant to, but he said ruby herd specifically... on which Diego does a lot of work.
Re: [gentoo-dev] Re: CPU use flag detection
On Fri, May 17, 2013 at 9:39 PM, Ryan Hill dirtye...@gentoo.org wrote: On Wed, 15 May 2013 16:59:57 +0200 yac y...@gentoo.org wrote: Hi, I was recently investigating what cpu flags do I have and how does it work. I have put what I have so far at [1]. So I thought I let you know in case someone wants to chip in. [1] https://github.com/yaccz/cufd I've seen gcc -Q --help=target giving false results before due to the way that options are parsed and some flags that set other flags not getting processed on the --help code path. The second option you list is better. -native doesn't set 3dnow, mmx, sse, sse2, sse3, ssse3 or sse4a. I'm guessing they're just handed through the -march setting. Yes, they are. sys-apps/cpuid is awesome. MMX2/MMXEXT still confuses me. SSE1 and /Enhanced/ 3DNow! added some extra MMX instructions. Some (pshufw and pmulhuw particularly) turn out to be rather useful in software compositing. I use them in the pixman MMX code. See http://mattst88.com/programming/asmref/ (Sorry about the broken search box. It works, you just don't see what you type) Set Requires = Enhanced 3DNow!. The instructions that are listed as 'Enhanced 3DNow! or SSE1' are what are known as MMX2 or MMXEXT. The particularly annoying thing about using them is that there's no -mmmx2 or -mmmxext, but turning on -msse causes illegal instructions to be generated for old AMD or Geode CPUs, while -m3dnow causes the same problems for Intel CPUs. And, there's not actually even an -m3dnowext flag (anymore?) anyway, so it's kind of a mess.
Re: [gentoo-dev] Re: CPU use flag detection
On Sun, May 19, 2013 at 8:47 AM, Alexis Ballier aball...@gentoo.org wrote: On Sat, 18 May 2013 22:31:11 -0400 Walter Dnes waltd...@waltdnes.org wrote: [...] ...shouldn't mmxext be moved out of use.local.desc into use.desc? all the cpu flags should be global IMHO, regardless of how many packages use them: we already mask/unmask them globally on arches where they are irrelevant. Alexis. Yes, they should. And while we're at it, we should stop naming them differently. (sse4_1 vs sse41) Also, since SSE4 isn't a thing (there's SSE4.1, SSE4.2, and SSE4a) we shouldn't have /any/ USE=sse4 in the tree. And we should never set up the masks like this: https://bugs.gentoo.org/show_bug.cgi?id=470220
Re: [gentoo-dev] Going against co-maintainer's wishes (ref. bug 412697)
On Sun, May 26, 2013 at 9:15 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: Perhaps this was covered already, but how exactly did this one file, added by your co-maintainer, hurt you? Did it cause additional bugs? Did it break a working ebuild? Did it kill your cat? It would seem to me that the co-maintainer (a person who cares that some users are interested in systemd enough to add one file to the package) made the package support a slightly wider range of systems (gentoo is about choice) and this affects you in exactly no way. What am I missing here? Are you just trying to force your will on others or do you have an actual issue caused by this commit? It is not for us developers to force one way on the users, gentoo is supposed to be about choice, your co-maintainer chose to support systemd, an action which as far as I can see didn't harm you, and helped some users. This has been a very long thread for something I don't get at all. Please, seriously, what am I missing here? Thanks for asking this. After reading the 34 emails in this thread, I still have this question as well.
[gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Fri, Jul 5, 2013 at 7:18 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: When we then move onto stage 2, it uses just the packages built during stage1 (/tmp/stage1root becomes /). This means, if seed stage has mpc.so.0.1 but portage has since included mpc.so.2 that the gcc in stage2 is linked against mpc.so.0.1 but only mpc.so.0.2 is installed. To combat this kind of failure we are currently running emerge --update - --deep --newuse --complete-graph --rebuild-if-new-ver gcc which could just be emerge --update gcc if eapi 5 subslots were used properly. The best solution to this is, and has always been, just updating gcc's deps during update_seed. Or am I misremembering something? As far as I know, you don't need to waste time rebuilding the seed stage's gcc, since gcc is rebuilt in stage2 and then everything is built by it in stage3.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Sat, Jul 6, 2013 at 12:46 AM, Brian Dolbec dol...@gentoo.org wrote: Yes, it does need to be rebuilt if key deps are updated. The gcc produced in the stage1 is broken, so won't run to rebuild itself during the stage2 run. But we keep the old libs around via preserve_libs, and once stage1 is done we effectively throw the seed stage out.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Sat, Jul 6, 2013 at 8:28 AM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: You are misremembering that we are using preserve_libs to save our butts when mpc is updated and gcc is still linked to the old mpc. I feel very uncomfortable as the recommendation of preserve-libs is to remerge as soon as possible not build a whole system like this. Is there an actual failure here? Not that I've seen yet, but it's an awkward way to build in my opinion. Keeping the old libs seems perfectly fine, since it's in a seed stage that we don't care about after stage1 is complete. An unnecessary build of gcc may not matter much on a relatively fast amd64, but it's going to be a pain on a bunch of slower architectures. And on mips/multilib it'll be even worse since we get to build the libraries for three ABIs.
Re: [gentoo-dev] Re: toolchain update was Re: [gentoo-project] Re: Questions for candidates for Gentoo Council 2013/2014
On Wed, Jul 10, 2013 at 8:36 PM, Rick Zero_Chaos Farina zeroch...@gentoo.org wrote: On 07/10/2013 10:03 PM, Robin H. Johnson wrote: On Fri, Jul 05, 2013 at 09:27:46PM -0700, Brian Dolbec wrote: The other thing we needed to do was completely remove the use of or building of binpkgs during the update_seed stage. Portage has no capability to check binpkg linking to ensure the binpkg was properly usable. Can somebody actually please implement this, to run before the binpkg merge phase? Please be more specific, this is currently implemented... He's talking about portage, not catalyst.
Re: [gentoo-dev] new category: games-adventure/
On Sun, Jul 14, 2013 at 10:15 AM, Peter Stuge pe...@stuge.se wrote: Diego, hasufell wrote: I would object... 10 games are wa too few for a new category and especially pkg moves.. 1 app-antivirus/ 3 net-zope/ 5 x11-base/ 7 gpe-utils/ 8 app-officeext/ 11net-voip/ 12games-kids/ 12gnustep-libs/ 13mail-mta/ 13dev-ada/ Diego Elio Pettenò wrote: And? Two wrongs don't make a right. What do you mean by And? - it doesn't make much sense as a reply. :\ He means that none of those provide justification. Are you being intentionally obtuse?
Re: [gentoo-dev] RFC: toolchain-r1.eclass
On Thu, Jul 25, 2013 at 9:26 AM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: Then there is a question whether toolchain packages should use EAPI 5, EAPI=5 would be useful for both the mips team (for bug 477956) and for catalyst builders (for subslot dependencies when dealing with binary packages).
[gentoo-dev] Autobuilds go to /experimental and to /releases only when someone actually tests them
(I sent this to gentoo-releng@. Resending to gentoo-dev@ for a wider audience) Can we make autobuilds go to /experimental and then only move them to /releases when someone actually tests them? Looking at bugzilla and listening in #gentoo-releng, it's kind of embarrassing how often someone downloads a Live CD only to find out that networking is totally broken by a udev upgrade, or something to that effect. We don't commit version bumps straight to stable; I don't see why we do with release media. Matt
[gentoo-dev] Adding ABI_MIPS USE_EXPAND
Hi, Any objections to me adding an ABI_MIPS USE_EXPAND variable so that I can take advantage of the multilib work on mips? Thanks, Matt
Re: [gentoo-dev] Dropping static libs support from cryptsetup and lvm2
On Mon, Jul 29, 2013 at 5:28 PM, yac y...@gentoo.org wrote: I have fully encrypted systems, including /, which requires an initramfs with cryptsetup built staticaly. Doesn't it actually require them built statically, or simply that the necessary libraries are also in the initramfs? I think this has already been covered.
Re: [gentoo-dev] Adding ABI_MIPS USE_EXPAND
On Mon, Jul 29, 2013 at 5:41 PM, Alexis Ballier aball...@gentoo.org wrote: go ahead -- note that some packages have broken multilib deps though Thanks! ah, and it wont work if you dont add support to multilib-build.eclass also. Of course :)
Re: [gentoo-dev] Adding ABI_MIPS USE_EXPAND
On Tue, Jul 30, 2013 at 12:44 AM, Michał Górny mgo...@gentoo.org wrote: Dnia 2013-07-29, o godz. 17:21:15 Matt Turner matts...@gentoo.org napisał(a): Any objections to me adding an ABI_MIPS USE_EXPAND variable so that I can take advantage of the multilib work on mips? But please sent the patches for a quick review first. Sorry, I committed it last night before your email. Here's the diff of the eclass: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/multilib-build.eclass?r1=1.16r2=1.17 I did ask you twice on IRC over the last few days and never received a response.
[gentoo-dev] media-tv/xmltv bugs
All versions of xmltv in the tree are EAPI=0. It needs a version bump (bug 288927), an updated home page (bug 325437), and to be ported to EAPI=5 and stabilized (bug 479056). Anyone use it and want to handle these bugs?
Re: [gentoo-dev] Adding ABI_MIPS USE_EXPAND
On Wed, Jul 31, 2013 at 5:12 AM, Jeroen Roovers j...@gentoo.org wrote: On Tue, 30 Jul 2013 09:04:56 -0700 Matt Turner matts...@gentoo.org wrote: I committed it last night before your email. # Keep it sorted. Please do not add anything without prior discussion # on gentoo-dev. n32 n64 o32 This is not a valid format for a .desc file. You should use: flag - description Indeed, you are right. I'll add descriptions. Thanks for noticing. Matt
Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8
On Fri, Aug 9, 2013 at 12:11 PM, Ben de Groot yng...@gentoo.org wrote: It doesn't help to keep so aggressively pushing it. Neither does so aggressively pushing against it.
Re: [gentoo-dev] multilib conversion: Please keep building binaries for all target ABIs
On Fri, Aug 9, 2013 at 10:52 AM, Michał Górny mgo...@gentoo.org wrote: ...so, allowing for the ability of 32bit userland with 64bit toolchain (via, say, setting ABI_X86=32 in make.conf) using the eclasses is just outright not ever going to happen? Never mind not supporting it, but essentially not allowing it? Nope. That would require every package to be multilib. The amount of work exceeds the benefit from it. If you really want to play like this, you are either looking for multilib-portage or some hackery in make.conf. I don't see why that would be. I think it would require some profile support, but that's simple. For instance on mips I'd like to be able to build the toolchain as 64-bit binaries (tracked in bug 477956) as to avoid the small virtual memory limit of the 32-bit ABIs. The rest of the system I want to remain ABI_MIPS=n32. As far as I can tell the things that would need to be built for N64 would be: sys-libs/zlib : DONE as of 1.2.8-r1 dev-libs/mpfr : Not done (EAPI=3) dev-libs/gmp : Not done (EAPI=0) (part of baselibs) dev-libs/mpc : Not done (EAPI=0) sys-devel/gettext : Not done (EAPI=2) (part of baselibs) dev-libs/cloog-ppl: Not done (EAPI=4) dev-libs/isl : Not done (EAPI=4) Under a multilib profile, gcc's libraries are built for each ABI. Same for glibc. I think this is doable, and I think I have a good reason for wanting to be able to do it. I have no idea why Tommy[D] or AxS want to do it. I've never discussed my plans with them.
Re: [gentoo-dev] systemd team consensus?
On Sun, Aug 11, 2013 at 2:22 PM, Alon Bar-Lev alo...@gentoo.org wrote: On Mon, Aug 12, 2013 at 2:08 AM, Gilles Dartiguelongue e...@gentoo.org wrote: Le dimanche 11 août 2013 à 22:09 +0300, Alon Bar-Lev a écrit : On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman tom...@gentoo.org wrote: On Sun, 11 Aug 2013 13:29:16 -0500 William Hubbs willi...@gentoo.org wrote: You may ask why I have offered patches instead of just fixing the ebuild since I am a team member. That is because even team members aren't allowed to touch bugs assigned to syst...@gentoo.org [1], Well, if there are conflicts within a team then I can agree that no member is allowed to touch the bug without a collaborative decision; but from what it appears this bug has been handed in a way that one member appears to take all decisions and the other member has nothing to say. In particular, comments 5 and 11 change the state of the bug without giving any reasoning about why that change in state was made; this is unacceptable, it gives us no reason to believe the state change. This is expected, as it is similar to how systemd/gnome is managed :) I hope you are not talking about the Gentoo Gnome team as this would be very wrong. Every team member is heard on the team. I was talking about the designated upstreams. Regards, Alon In the future: don't. You've added nothing of substance to this thread, except three additional emails.
Re: [gentoo-dev] Sets in the tree
On Wed, Aug 14, 2013 at 4:42 PM, Patrick Lauer patr...@gentoo.org wrote: On 08/15/2013 04:21 AM, Markos Chandras wrote: On 14 August 2013 21:17, Ulrich Mueller u...@gentoo.org wrote: On Wed, 14 Aug 2013, hasufell wrote: And their lack of time (to be polite) should not block general progress in gentoo. Perhaps these basic notions of how Gentoo development works You certainly are not an authority when it comes to that question... Well no exactly Stop it. Now. gentoo-dev is a list for technical topics, so please take your personal quarrels elsewhere. Ulrich Last warning for both hasufell and Ciaran. Keep the discussion on acceptable technical and polite levels or go away I'm quite surprised that you attack hasufell now for his valid opinion that PMS is not well maintained and does not reflect reality adequately. Wow, I had exactly the opposite opinion -- that Ciaran had responded politely to much trolling. And I really do not appreciate this weirdness of LAST WARNING!!11 ... it doesn't work on 6-year-olds, so don't expect it to work on a group of strongly individualist nerds. Makes me want to tell you Last warning! Don't warn people again, OR ELSE! just to see what happens. I agree with this.
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 4:04 AM, Markos Chandras hwoar...@gentoo.org wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc I want some level between stable and completely supported and loses all its stable keywords., at least for alpha. Is switching their profiles to dev the way to do that?
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 8:40 AM, Mike Gilbert flop...@gentoo.org wrote: The proposal is to drop stable keywords on arches that cannot keep up. Do you feel this is not the case on alpha? I'm not sure if that's my claim. I'm worried because I think it might be a disaster for alpha (and perhaps other architectures).
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I've run into issues when I simply wanted to fix a mips-specific problem and wound up spending inordinate amounts of time dealing with general ~arch issues. I'm worried that dropping stable keywords, while it'll make it seem like the architectures are in better shape since there are fewer bugs, will actually make using or developing them significantly worse.
Re: [gentoo-dev] New license: Adaptec
On Thu, Aug 29, 2013 at 4:17 AM, Ulrich Mueller u...@gentoo.org wrote: The license contains nasty clauses like this: If you are a European Consumer you must not export Software outside the country in which you download it without our prior written permission. I.e., if you install the software on your computer, you're not allowed to travel with it. Not sure if this would be enforceable for travel within the EU, but nevertheless, I suggest that you add the license to the @EULA group. And the ebuild needs mirror restriction, at least. That seems like a pretty crazy interpretation of that text.
[gentoo-dev] Re: [gentoo-project] Minor arches (was: Call for agenda items - Council meeting 2013-09-10)
On Tue, Sep 17, 2013 at 6:04 AM, Ulrich Mueller u...@gentoo.org wrote: On Sun, 15 Sep 2013, Rich Freeman wrote: I didn't really get any response to this one way or another. At the last council meeting a majority of the votes were in favor of delaying taking action, so this is back on the agenda. I have yet to see either of the following on this list: 1. Specific examples of bugs where a minor arch is making a maintainer's life difficult. Please post if you have them. 2. Members of these arch teams posting here committing to either stabilize new versions or unkeyword old versions in a timely manner. The responses to either of these (or lack thereof) are likely to influence my vote at the meeting. Note, I'm not interested in mere comments that people want an arch to stay stable supported (which I've seen plenty of). I'm interested in COMMITMENT to be stable-supportable (which I've seen none of). The lack of the latter is what is going to cause a package to be dropped - I'd love to see every arch that exists stable-supported on Gentoo, along with world peace. This is a volunteer distro - in general you get the features you pitch in to help deliver, and if you're depending on a minor arch you REALLY need to step up as there aren't many of you out there. That said, I would like specific examples of cases where dropping a minor arch would have helped - the onus is on those wanting the status quo changed to present a case. [Crossposting to -dev. Replies should go to -project if possible.] Again, no reply. I suspect the outcome of today's vote will be that stable keywords for the architectures in question (alpha, ia64, m68k, s390, sh, sparc) should be dropped. Arch teams, last chance to speak up. Ulrich I've already spoken up as have others. I'm an alpha maintainer and I'm against this. jmorgan is a sparc maintainer and he's against it. I don't care about the others, and frankly understand the frustration with long stable requests, but leave alpha out of it.
Re: [gentoo-dev] RFC: FEATURES=binchecks strip for plain file packages e.g. latex, perl, python
On Fri, Sep 20, 2013 at 10:58 AM, Justin (jlec) j...@gentoo.org wrote: what is your opinion to set FEATURES=binchecks strip for all those packages which purely install files. For example python package only installing scripts, or perl packages or latex. There might be more. It may help to describe what this would improve (presumably reduce the installation time?).
Re: [gentoo-dev] Re: [RFC] Policy for migrating library consumers to subslots
On Fri, Sep 27, 2013 at 12:48 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: I was not suggesting inlining the list into the dependency but only inlining the USE-flag into the (single) perl ebuild. Currently if I have a package which needs e.g. Term-ANSI-Color, but not in a particular version, if I do not want to install an unnecessary duplicate version, I must inline a dependency like || ( =dev-lang/perl-5.14 virtual/perl-Term-ANSIColor ) and possibly change this if perl-5.20 does no longer contain perl-Term-ANSIColor. Isn't that exactly what the virtual should do?
Re: [gentoo-dev] Re: New global USE flag neon for ARM NEON optimization(s)
On Fri, Dec 23, 2011 at 4:26 AM, Duncan 1i5t5.dun...@cox.net wrote: Samuli Suominen posted on Thu, 22 Dec 2011 21:03:41 +0200 as excerpted: i'll add USE=neon to use.desc and punt the local descriptions if nobody objects media-libs/libpng: support ARM NEON cpu instruction set media-libs/vo-aacenc: Enable neon cpu instructions media-video/ffmpeg: Enables NEON optimizations for arm processors. media-video/libav: Enable NEON optimizations for arm processors. media-video/vlc: Enables NEON optimizations for arm processors. x11-libs/pixman: Enables NEON optimizations for ARM processors. For users not familiar with the ARM arch, neon is arguably more likely to be associated with net-libs/neon. Certainly that's what I would have immediately thought, tho my only familiarity with the library is as a dependency that IIRC used to trigger lots of subversion rebuilds, etc (now days I don't even have subversion on the system, it's all git, but according to equery d, neon is still required by musicbrainz). As such, to avoid confusion I'd suggest arch-neon or arm-neon (or armneon/ archneon) if it's to be a global flag. Ugh. NEON (the SIMD extensions) are turned on by the neon flag much more often than support for net-libs/neon is. Let's not rename USE flags like this.
Re: [gentoo-dev] crossdrev mingw 64 bit
On Fri, Jan 13, 2012 at 5:49 AM, Dmitrij K kdi...@live.ru wrote: Maciej Mrozowski wrote: On Tuesday 10 of January 2012 03:34:06 Dmitrij K wrote: Dear developers of crossdev. Can you realize --target mingw64 (for creating windows app 64 bit) (like mingw-w64.sourceforge.net)? And can you to add choising of building compilation: dynamic OR static linking to GCC library, for LGPL license of GCC using (mingw32.dll etc)? Hello, It is already there: crossdev --target x86_64-w64-mingw32 I had did following things: 1) localhost # emerge --sync --metadata ... 2) localhost # emerge -upv crossdev These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB 3) localhost # crossdev --target help | grep mingw - mingw32 http://www.mingw.org/ Dear Maciej Mrozowski, you said to me about --target mingw64 is true there... where is ? can you explain me how I can to intall mingw64 by crossdev package (without outside packages like mingw-w64.sourceforge.net)? Did you try the command he suggested? I think it may simply be that crossdev doesn't display mingw64 as a target in the --help.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in sys-libs/glibc: glibc-2.14.1-r2.ebuild glibc-2.12.2.ebuild glibc-9999.ebuild glibc-2.15.ebuild glibc-2.10.1-r1.ebuild glibc-2.14.1-r1.ebuild
On Thu, Jan 19, 2012 at 12:37 AM, Duncan 1i5t5.dun...@cox.net wrote: Mike Frysinger posted on Wed, 18 Jan 2012 22:00:52 -0500 as excerpted: On Wednesday 18 January 2012 21:42:14 Michael Weber wrote: Um, what happend to the policy to not f*** around with stable ebuilds? take a chill pill phil I see a violation of this rule at least on [glibc-]2.13-r4, which leads to useless rebuilds on `emerge -avuND world` on every single gentoo install world-wide. i don't have too much compassion for -N. if people really care enough about it, they'd read the ChangeLog and see that it is meaningless. Considering glibc was just one of some 200-ish packages I rebuilt early today due to -N, most of the rest being kde-4.7.97 (aka 4.8-rc2) which will be in-overlay for just a few more days as 4.8-release is due next week, because gentoo/kde just removed the long-masked kdeenablefinal USE flag, which because it was masked (and I didn't unmask it) did NOT affect my kde as installed so I basically did the rebuild for nothing... Paragraphs like these are why I have such a hard time reading your entire emails. :P
Re: [gentoo-dev] Last rites: media-sound/minitunes
On Sat, Jan 21, 2012 at 5:28 AM, Markos Chandras hwoar...@gentoo.org wrote: # Markos Chandras hwoar...@gentoo.org (21 Jan 2012) # Package renamed to media-sound/musique # http://flavio.tordini.org/minitunes-renamed-to-musique # Removal in 30 days media-sound/minitunes Is it normal to wipe out the ChangeLog when renaming the package?
Re: [gentoo-dev] The following USE changes are necessary to proceed - Why?
On Fri, Feb 10, 2012 at 2:17 PM, ross smith gaur...@gmail.com wrote: The line above is not prompting you to turn on the nettle use flag, which appears to already be on. It's prompting you to add the gmp use flag for dev-libs/nettle. Which looks like it's on as well. In either case -- this isn't gentoo-dev material.
Re: [gentoo-dev] profiles/features/64bit-native/package.use.mask contents redundancy
On Mon, Feb 13, 2012 at 11:16 AM, Sergei Trofimovich sly...@gentoo.org wrote: some mips profiles are scary too: http://dev.gentoo.org/~slyfox/profiles_mips.png Weird. I'll take a look at that.
Re: [gentoo-dev] Re: About gcc-4.6 unmasking
On Mon, Feb 20, 2012 at 8:03 PM, Ryan Hill dirtye...@gentoo.org wrote: On Mon, 20 Feb 2012 21:34:14 +0100 Pacho Ramos pa...@gentoo.org wrote: I don't know if this has been discussed before but, what issues are preventing us from unmasking gcc-4.6 (and think on a near stabilization)? I have read hardmask message but it simply explains that it's masked for testing purposes :-/ Grub is the only blocker. I don't want to unmask something that makes people's systems unbootable. I'm also out of ideas and open to suggestions. Is it a bad idea to go ahead and unmask it on architectures that don't use grub?
Re: [gentoo-dev] lurking *.ebuild'less packages
On Thu, Mar 15, 2012 at 4:59 PM, Sergei Trofimovich sly...@gentoo.org wrote: slep noticed and reported an odd thing: $ euse -i kate ... ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-perl-*: No such file or directory ls: cannot access /gentoo/portage/metadata/cache/kde-base/kdebindings-ruby-*: No such file or directory ... The dirs they don't contain ebuilds. Only metadata. KDE team is aware and fixing their orphans. I've decided to write a hack to find such instances in tree: $ ./find_empty.sh ~/portage/gentoo-x86/ kde-base/kdeaccessibility-colorschemes kde-base/kdeaccessibility-iconthemes kde-base/kdebase-wallpapers kde-base/kdebindings-csharp kde-base/kdebindings-perl kde-base/kdebindings-ruby kde-base/kvtml-data kde-base/smoke media-plugins/mytharchive media-plugins/mythbrowser media-plugins/mythgallery media-plugins/mythgame media-plugins/mythmovies media-plugins/mythmusic media-plugins/mythnetvision media-plugins/mythnews media-plugins/mythweather x11-themes/mythtv-themes Is there any reason to leave such ebuildless directories? Thanks! -- Sergei Let's get this script added to http://qa-reports.gentoo.org/
[gentoo-dev] Change USE flags when compiling with FEATURES=test
So you run set FEATURES=test to run a package's test suite during keywording. Later, you emerge -vuNDa ... and portage wants to reemerge that package with USE=-test. Can't we avoid this somehow? I presume in the vast majority of cases emerging with FEATURES/USE=test doesn't actually affect what's installed. I'd guess we'd need to be able to remove 'test' from the set of IUSE and have a new helper function to check if 'test' is in FEATURES? Matt
Re: [gentoo-dev] About suggesting to create a separate partition for portage tree in handbook
On Wed, Mar 28, 2012 at 10:59 AM, Richard Yao r...@cs.stonybrook.edu wrote: On 03/28/12 03:16, Brian Dolbec wrote: On Tue, 2012-03-27 at 19:16 +0100, Ciaran McCreesh wrote: But that's ok, because extensive studies have shown that the only possible reasons for putting /usr/portage on its own partition are historical, since everyone has an SSD now. Yeah, right. Since I must be the only one out there that doesn't yet have an SSD, you'll give me (and anyone else that still doesn't) one? In response to the people who don't like what Brian had to say, I would like to say that we can't start making assumptions about what hardware people have and ignore anyone who does not fit those assumptions. I support Brian on this. If you guys want to have documentation on more advanced disk tricks, make a separate handbook that specializes in partitioning and filesystems. The main handbook can include a reference to it for advanced users. You seem to have missed it too, so let's someone just spell it out before this goes farther. Ciaran was mocking the argument that's given by proponents of merging / into /usr. He *doesn't* actually feel like that. So let's stop this.
Re: [gentoo-dev] Happy 10th birthday (in advance)
On Fri, Mar 30, 2012 at 5:55 PM, Richard Yao r...@cs.stonybrook.edu wrote: On 03/30/12 17:15, Joshua Kinard wrote: Maybe it's time for Gentoo-2.0? I think we should wait for Portage 2.2 to be stabilized before we declare Gentoo 2.0. @preserved-libs is enough of an advance that I think claiming 2.0 would be merited, if only for the attention it would draw at Phoronix. We don't want that kind of attention.
Re: [gentoo-dev] RFC: ocamlopt unmask on arm
On Wed, Apr 18, 2012 at 10:14 PM, hero...@gentoo.org wrote: Dear All, I have just emerged ocaml-3.12.0[ocamlopt] on arm and used it to compile mldonkey[ocamlopt]. It seems to work well. it was masked on Apr 18, 2010, , | /usr/portage/profiles$ grep -n -B3 ocamlopt ./arch/arm/use.mask | 31-# Raúl Porcel armi...@gentoo.org | 32-# Fails to build/work | 33-openexr | 34:ocamlopt ` Debian has arm port for ocamlopt since 3.12: http://packages.debian.org/search?searchon=nameskeywords=ocaml-native-compilers I failed to find the changelog of ocaml, though :( How about unmasking it now? Yours, Benda Related: https://bugs.gentoo.org/show_bug.cgi?id=340607
Re: [gentoo-dev] RFC: A tiny news item for migrating to libjpeg-turbo
On Mon, Apr 23, 2012 at 7:58 AM, Richard Yao r...@cs.stonybrook.edu wrote: What is the plan for platforms that are not supported by libturbo? It's not that they're not supported, just that libjpeg-turbo doesn't have optimized routines for them. It'll still run fine. (Check the keywords, you'll see that it's stabilized.)
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert id...@gentoo.org wrote: I haven't followed the prev. conversation but what's wrong with a USE flag for SSE2? We already have SSE2 flags, even global.. That's not it. The flash binary uses SSE2 instructions without checking for their presence, which causes bad things on systems without SSE2. The purpose of the 'sse2check' flag was to die if the system doesn't have SSE2 and print a message telling the user to use an older version of flash. The relevant bug is https://bugs.gentoo.org/show_bug.cgi?id=410547
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, Apr 26, 2012 at 4:06 PM, Alexis Ballier aball...@gentoo.org wrote: wouldnt adding a sse2 useflag and putting it in REQUIRED_USE solve the problem ? afaik portage wont even try to upgrade if people have -sse2 If that works, which I think it will, that does sound like the best thing to do.
Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in www-plugins/adobe-flash: metadata.xml adobe-flash-11.2.202.228.ebuild ChangeLog
On Thu, Apr 26, 2012 at 1:01 PM, Christian Ruppert id...@gentoo.org wrote: On 04/26/12 at 06:00PM +0200, Jeroen Roovers wrote: On Wed, 25 Apr 2012 23:04:08 -0600 Ryan Hill dirtye...@gentoo.org wrote: Arg, no. Please just print the warning if the host doesn't do SSE2. There's no reason to have a USE flag here (and _really_ no reason to make it fatal) I entirely agree there. :) I haven't followed the prev. conversation but what's wrong with a USE flag for SSE2? We already have SSE2 flags, even global.. , especially for an instruction set that every system has supported for over a decade. Er, some of my teenage systems run desktops just fine here, thanks. And one of them is just nine years old right now but still doesn't support SSE2 (merely SSE[1]). Regards, jer [1] http://en.wikipedia.org/wiki/AMD_Athlon_XP#Barton_and_Thorton - see [2] right above that for the actual specs. [2] http://en.wikipedia.org/wiki/AMD_Athlon_XP#Thoroughbred_.28T-Bred.29 -- Regards, Christian Ruppert Gentoo Linux developer, Bugzilla administrator and Infrastructure member Fingerprint: EEB1 C341 7C84 B274 6C59 F243 5EAB 0C62 B427 ABC8 Jim?
Re: [gentoo-dev] Possible lastrite of sys-fs/rar2fs (waiting for upstream reaction)
On Sat, May 5, 2012 at 8:35 AM, Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (05 May 2012) # Broken with unrar-4.2.1 wrt upstream ticket of: # http://code.google.com/p/rar2fs/issues/detail?id=10 # Either waiting for fixed release, or the package will # be removed in 30 days =sys-fs/rar2fs-1.15.0 Heh, last riting a package because of an unfixed issue that was only reported today? You've got tree cleaning on the brain.
Re: [gentoo-dev] latest commits to dev-lang/go
On Tue, May 15, 2012 at 9:07 PM, William Hubbs willi...@gentoo.org wrote: On Tue, May 15, 2012 at 06:37:39PM -0500, William Hubbs wrote: All, I know my latest commits to dev-lang/go haven't updated the ChangeLog. I got into the habbit of using repoman commit -[Mm] to do that, but for some reason that stopped working. I will use echangelog from this ponit until I hear that repoman commit has been fixed. Thanks to Zac's quick assistance on irc, I found that this was an issue with my repository, not repoman. William So that others don't have the same problem -- what was the issue?
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 12:47 PM, Robin H. Johnson robb...@gentoo.org wrote: 2. Arches were Git repos are too heavy (Kumba wanted this for MIPS) Please don't go to this trouble for the ability to commit to portage on *really* slow systems.
Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
On Wed, May 23, 2012 at 3:37 PM, Arun Raghavan ford_pref...@gentoo.org wrote: I, for one, think we should stay with CVS and leave all this git Linusware to the new-fangled Fedora kids with their fancy init systems and tight coupling. CVS was good enough for my grandfather, and it's good enough for you. -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME) I seriously cannot tell this is serious, trolling, or sarcasm. If it's either of the latter two, can we please cut that out? Way too often sarcasm and inside jokes are misunderstood and we waste a lot of bandwidth figuring it out.
Re: [gentoo-dev] RFC: PROPERTIES=funky-slots
On Sat, Jun 23, 2012 at 1:54 PM, Michał Górny mgo...@gentoo.org wrote: On Sat, 23 Jun 2012 18:45:46 +0100 Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Sat, 23 Jun 2012 19:43:10 +0200 Pacho Ramos pa...@gentoo.org wrote: It treats -r300 as being newer than -r200, and so will treat the gtk3 version or the jruby version as being newer versions of the gtk2 version or the ruby 1.8 version, just as it tries to bring in a newer GCC and so on. And what problems is that causing for you? The problem is that there's no way of knowing that -r300 is not a newer version than -r200 It's actually not though, is it? I think -r300 is simply the same thing as -r200 except that it uses gtk3 instead of gtk2.
Re: GLEP draf for cross-compile support in multilib profiles (was: Re: [gentoo-dev] Re: spec draft for cross-compile support in future EAPI (EAPI-5))
On Fri, Jun 29, 2012 at 10:30 AM, Thomas Sachau to...@gentoo.org wrote: I'm interested in this because I'm regularly annoyed with the emul- packages and also because multilib is pretty important for mips. If a package has dependencies, then those dependencies are required to have at least the same targets enabled as the package That seems like the obvious (but perhaps naive) choice. What about depending on packages that don't install libraries, like x11-proto/ packages or generators like dev-util/indent? Maybe I just don't understand. Would these packages even have ABI flags? It's clear to me that libraries would be installed in different lib* directories dependent on their ABI, but how would typical executables be handled? For mips, we'd like to have gcc built as an n64 binary, which would require its run-time dependencies (mpfr, mpc, gmp, etc.) to be available as n64 as well, but the rest of the system to be n32 binaries. Does this fit with your understanding (and proposed solution) of the problem? Thanks, Matt
Re: [gentoo-dev] Re: GLEP draf for cross-compile support in multilib profiles
On Sun, Jul 1, 2012 at 4:52 PM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: I suppose that's just for ease of implementation? Not having to special-case packages that don't install binaries. I dont follow. Did you think about only having additional ABI flags for certain cases? Right. It seems to me that not having the ABI flags for packages like x11-proto/* would make more sense, but may be more work to implement. Those ABI flags behave the same as other USE flags: When you change them, you have to recompile the package including all the content, that has been compiled previously. If you want the compile for each ABI seperate, then you would have to handle them more like SLOTS, but with a new syntax, with a collision handler for the common content and how to handle that in the user UI. I fear, that this would be way more complicated to implement in a sane way, so i dont plan to go that route. Ouch. I already think a mechanism for telling the package manager you don't need to rebuild this entire package to turn on /this/ USE flag is needed. For ABIs, the situation seems much more clear-cut. In fact, it seems rather important.
Re: [gentoo-dev] Make connman a global USE flag
On Sat, Jul 21, 2012 at 4:51 AM, Pacho Ramos pa...@gentoo.org wrote: Several packages are using it with the same sense (support connman), maybe we should move it from local to global USEs, what do you think? Off-topic question, but how is connman related to NetworkManager? Is it an alternative, or is it useful in the presence of NetworkManager?
Re: [gentoo-dev] Unified DEPENDENCIES concept
On Fri, Sep 7, 2012 at 4:45 AM, Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: Since DEPENDENCIES hasn't been written up in a Gentoo-friendly manner, and since the Exherbo documentation doesn't seem to suffice to explain the idea here, here's some more details on the DEPENDENCIES proposal. I like this. It seems well planned and thought out and very flexible. If I understand correctly paludis already supports this, so a working implementation is already available which is clearly beneficial for a proposal. Thanks a lot, Ciaran, for writing this up. Matt
Re: [gentoo-dev] example conversion of gentoo-x86 current deps to unified dependencies
On Sun, Sep 16, 2012 at 6:15 AM, Brian Harring ferri...@gmail.com wrote: 1) 746 hits in the tree for COMMON_DEPEND; that's 2%, and the usages I'm aware of have been for literally, what it sounds like- depends that are both DEPEND and RDEPEND. CDEPEND is pretty common as well. I could 466 files with CDEPEND.
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 03:18, Alec Warner anta...@gentoo.org wrote: On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller u...@gentoo.org wrote: Readability is more important, and there I still don't buy the argument that the new syntax is better, and that any gain would outweigh the cost of changing. After all, the existing variables for dependency specification won't disappear, so devs would have to remember both. I agree it is a con, but is it a blocker? I mean basically any change proposed requires know the old way, and the new way..that is how changes work... Which is why changes need to have clear benefits that outweigh the costs of change. In this case the benefits are purely cosmetic, so they don't. Change for change' sake is not worth the effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin I'm sorry. Are you reading the same threads that I am? From the other thread (example conversion of gentoo-x86 current deps to unified dependencies): 1) This unifies the existing syntax down into a collapsed form. In doing so, there are measurable gains across the board for PM efficiency and rsync alone. 2) In unifying the syntax via reusing our /existing fucking syntax/, we formalize the adhoc common dependency assignments devs already are doing in the tree. 3) In moving to a unified syntax, it positions us to easily introduce new dependency types without introducing more redundancy. Easier to add new dep types, faster to add new dep types, more efficient in doing so in comparison to existing approaches, and done in a fashion that devs can reuse existing conditionals. 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. I know you must have seen this (and the rest...). You've participated in that thread.
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Tue, Sep 18, 2012 at 11:36 PM, Ulrich Mueller u...@gentoo.org wrote: On Tue, 18 Sep 2012, Matt Turner wrote: From the other thread (example conversion of gentoo-x86 current deps to unified dependencies): [Sorry, I've missed this one in the other thread, so replying here.] 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based. Meaning you do not need to knee-jerk attack it because of some notion it's ciaran based/related. What kind of reasoning is this? Does it mean that the syntax was deliberately changed to make it different from exherbo's? We should accept (or reject) things based on their technical merits, not because of ad-hominem or not invented here arguments. Ulrich Brian was mocking how so many people reject anything Ciaran proposes out of hand. He actually discussed the reasoning why he doesn't actually like labels in another thread.
Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal
On Wed, Sep 19, 2012 at 12:12 AM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 14:01, Matt Turner matts...@gentoo.org wrote: On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot yng...@gentoo.org wrote: On 19 September 2012 03:18, Alec Warner anta...@gentoo.org wrote: On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller u...@gentoo.org wrote: Readability is more important, and there I still don't buy the argument that the new syntax is better, and that any gain would outweigh the cost of changing. After all, the existing variables for dependency specification won't disappear, so devs would have to remember both. I agree it is a con, but is it a blocker? I mean basically any change proposed requires know the old way, and the new way..that is how changes work... Which is why changes need to have clear benefits that outweigh the costs of change. In this case the benefits are purely cosmetic, so they don't. Change for change' sake is not worth the effort. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin I'm sorry. Are you reading the same threads that I am? You've seen me participating in those, so obviously: yes. So then you must have also read Brian's email detailing the metadata savings, and allowing the PM to parse fewer things (even with quantitative measurements!). Search your email for 'cold cache'. [snip] Looking at what you call cosmetic makes me think that you're collapsing cosmetic and a useful change down into cosmetic in order to disregard it.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sat, Sep 22, 2012 at 6:59 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 22/09/2012 18:54, Matt Turner wrote: I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. If that's the case, please consider a more broad strategy, in particular: - unforce the multilib flag for the packages that are _built_ for multilib; In progress: https://bugs.gentoo.org/show_bug.cgi?id=435094 :) - make 32-bit binary packages depend amd64? ( whatever[multilib] ) instead of blanketing all xlibs. I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 9:07 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 22/09/2012 20:42, Matt Turner wrote: I think this means make 32-bit binary packages' dependencies on amd64 not use the emul- packages? If so, that'd certainly be a component of getting rid of emul-linux-x86-xlibs. It's not in the scope of my project to get rid of /all/ of the emul- packages, but I agree that that is a worthwhile goal. Mostly I don't want to have to build Xaw in both variants given I use neither.. but that would happen if you just made the emul depend on the packages that are converted... Ahh, indeed. You mean that existing dependencies on emul-linux-x86-xlibs should be converted into finer-grained dependencies on individual libraries. Of course, that is a very good idea. In the case of Xaw, I added a deprecated USE flag recently that controls the building of the old Xaw6, so we're already working toward trimming Xaw from users' systems. :)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 3:02 AM, hasufell hasuf...@gentoo.org wrote: I prefer the stronger solution. This is just a quick workaround. And I'd prefer if people who aren't involved with what I'm working on don't try to block my progress. I appreciate your opinion, and truthfully I'd just rather have portage handle this for me but until that time comes I'm going to use Michal's eclass.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 2:07 AM, Thomas Sachau to...@gentoo.org wrote: Matt Turner schrieb: On Sat, Sep 22, 2012 at 2:24 PM, Michał Górny mgo...@gentoo.org wrote: It is a simple eclass using autotools out-of-source builds to build packages for multiple ABIs when multilib is supported. Thanks a lot, Michał! This looks good to me. Use case: xorg packages, ask Matt. So the idea is that users want up-to-date 32-bit drivers for games and WINE. The emul- packages aren't a very good solution for a number of reasons. I'd like to add multilib USE flags to Mesa and thus its dependencies. I realized that almost everything in x11-libs/ could be converted very easily, which would allow us to get rid of emul-linux-x86-xlibs in addition to emul-linux-x86-opengl. This looks like a shortened duplication of a subset of multilib-portage features. While this wont hurt multilib-portage (since it does exclude most actions on ebuilds with USE=multilib), it will mean a rewrite for many ebuilds, which then again need another rewrite (or more likely revert), when multilib-portage is accepted in a future EAPI. I'd much rather have portage handle this for me as well. Unfortunately, the last mail I see about multilib-portage is from two months ago. If it were in EAPI 5, I'd be happy to wait for it. If it even looked like it were progressing, I might wait. But, as you know, gentoo-dev is where ideas go to die. As far as ebuild conversions go, this is really simple. So i would prefer some help/support with multilib-portage to get it accepted sooner, instead of this additional workaround for a subset of packages. That seems like a reasonable request. Let me re-read the previously mentioned thread and get back to you.
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Sun, Sep 23, 2012 at 5:30 AM, Pacho Ramos pa...@gentoo.org wrote: One problem that I remembered now: If every ebuild inheritting this eclass (either this one or similar) will add a multilib USE, people running multilib profiles will get it enabled for ALL packages inheritting it, causing them to see how their systems grow a lot because they will have 32bits libs for all packages, even when not needed. For example, in my systems I need gtk+ 32 bits libs, but not qt ones as I don't have any qt based app requiring 32bits installed. Currently, yes, that is the case. The fix is pretty simple though, and is in progress: https://bugs.gentoo.org/show_bug.cgi?id=435094 (previously mentioned in this thread...)
Re: [gentoo-dev] [PATCH] autotools-multilib: wrapper eclass for multilib builds.
On Mon, Sep 24, 2012 at 3:22 PM, Alexis Ballier aball...@gentoo.org wrote:
On Tue, 25 Sep 2012 00:10:21 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:59:14 -0300
Alexis Ballier aball...@gentoo.org wrote:
On Mon, 24 Sep 2012 23:51:27 +0200
Michał Górny mgo...@gentoo.org wrote:
On Mon, 24 Sep 2012 18:19:43 -0300
Alexis Ballier aball...@gentoo.org wrote:
you dont need this, the PM has already done the work for you:
call directly the relevant function.
src_multilib_compile() {
forall ABIS; do
prepare ABI variables
src_compile
done
}
Err, what? Who calls the function? Where?
bash. here.
How can an eclass call a phase function while eclass needs to be
called from the phase function to call the phase function...?
Read again. Esp. the part you deleted.
I never said it should do this, on purpose...
I'm especially confused by what your point is. I can't see how your
snippet could ever work, and you're being evasive about answering
that.
Re: [gentoo-dev] ship app-arch/pbzip2 instead of app-arch/bzip2
On Wed, Sep 26, 2012 at 1:30 PM, Michael Mol mike...@gmail.com wrote: A few months ago, I filed bug 423651 to ask that bzip2 on the install media be replaced with pbzip2. It was closed a short while later, telling me that it'd involve changing what's kept in @system, and that had to be discussed here, rather than in a bug report. If we're going to ship a parallel bzip2 implementation, it should be lbzip2 and not pbzip2. lbzip2 can decompress bz2 archives with multiple threads that haven't been compressed with lbzip2/pbzip2.
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:05 PM, Walter Dnes waltd...@waltdnes.org wrote: As I posted elsewhere, working on a project based on hate only lasts so long. I should know, that's the reason I started udev in the first place over 9 years ago. The Xfree86 people generated a lot of hate, just like Sievers and Poettering. Xorg hasn't burned out yet. Let's be fair. The Xorg fork was done by a lot of really competent professional developers who had been developing XFree86 for a long time.
Re: [gentoo-dev] Re: udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:06 AM, Duncan 1i5t5.dun...@cox.net wrote: Richard Yao posted on Sun, 18 Nov 2012 00:35:22 -0500 as excerpted: Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? FWIW... I run a monolithic kernel here, no modules /to/ load. As a result, for quite some time I had module-init-tools in package.provided, because I really didn't need it at all. Then udev switched to kmod as a build-time dep. I could no longer package.provide kmod as I had module-init-tools, because it was required to /build/ udev. For no valid reason on my system. Like any unnecessary feature that can be used to load an exploit, it's worse than useless. But it was required to build, just because someone decided people had no valid reason to run a monolithic kernel system any longer, and that people who did so apparently no longer mattered, udev-wise. That's only one such decision of a whole list following a similar pattern, simply deciding that some segment of the Linux-using populace or another no longer matters, because it's not the segment that the udev folks are focused on. In many cases, they've already said they're not interested in patches resolving the issues, too. Thus, no, submitting the patches for inclusion upstream isn't working. Seems reason enough for a fork, to me. Back on subtopic, yes, I'm definitely interested in a udev fork that doesn't force the otherwise useless on my systems kmod as a build-time dep. package.provided worked for years as a workaround for the module- init-tools @system dep. And I'd like to get back to not having to have a module-loader package installed at all, since I don't have any modules to load anyway. # du -sh /var/tmp/portage/sys-apps/kmod-11-r1/image/ 240K/var/tmp/portage/sys-apps/kmod-11-r1/image/
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 3:25 PM, Richard Yao r...@gentoo.org wrote: On 11/18/2012 11:59 AM, Jason A. Donenfeld wrote: All I'm asking is some kind of coherent mission statement. How can we define a mission statement when we are still in the process of understanding the codebase, what it does well and what it can do better? Most people would have a reason to fork before forking. Or maybe mission statement != reasons and we're having a communication breakdown.
[gentoo-dev] Restabilizing MIPS
Hi, I'd like to begin stabilizing packages on MIPS. I've gotten acks from Redhatter, leio, and r0bertz, and Kumba doesn't really care. What's the best method to go about doing this? Stabilize the system packages, then remove ~mips from ACCEPT_KEYWORDS in the profiles? Should we target package versions that aren't stabilized on other architectures yet, so that we'll have an extended testing period before they'll come up for stabilization? That is, can I plan to make gcc-4.5.1 or something the first restabilized version of gcc, go ahead and begin testing it, and be ready for stabilization when toolchain requests it? Thanks, and any advice is appreciated. :) Matt
Re: [gentoo-dev] Restabilizing MIPS
On Thu, Nov 11, 2010 at 6:13 PM, Robin H. Johnson robb...@gentoo.org wrote: On Thu, Nov 11, 2010 at 06:00:00PM -0500, Matt Turner wrote: I'd like to begin stabilizing packages on MIPS. I've gotten acks from Redhatter, leio, and r0bertz, and Kumba doesn't really care. Out of interest, what MIPS hardware do you have? I have a Broadcom BCM91250a with a dual-core 800 MHz SiByte CPU and a 200 MHz O2 with 1 GB RAM. See http://mattst88.com/computers/bcm91250a/ . I need to post some pictures, but that'll have to be for later. Matt
Re: [gentoo-dev] Re: Restabilizing MIPS
On Thu, Nov 11, 2010 at 8:28 PM, Ryan Hill dirtye...@gentoo.org wrote: On Thu, 11 Nov 2010 18:00:00 -0500 Matt Turner matts...@gentoo.org wrote: Should we target package versions that aren't stabilized on other architectures yet, so that we'll have an extended testing period before they'll come up for stabilization? That is, can I plan to make gcc-4.5.1 or something the first restabilized version of gcc, go ahead and begin testing it, and be ready for stabilization when toolchain requests it? I'd work on getting it ~mips before you think about stabilizing. ;) Last report I got it doesn't build. I've been using gcc-4.5.1 for the last two weeks or so. :) Should I add a ~mips keyword? What's your target hardware for stabilization? Are we still focusing on SGI stuff or moving on to newer platforms? SGI stuff is going to become less and less interesting, but it's still the most common MIPS hardware Gentoo users have [1]. STMicroelectronics MIPS systems (Lemote, Gdium, etc) are becoming more common, and we should definitely do a better job supporting them. (I should mention that I've been loaned a Yeelong by Daniel Clark, of freedomincluded.com, to fix up the siliconmotion driver.) I think we can reasonably support both. The Broadcom board I have can with the switch of a jumper operate in big or little-endian mode, so I can use it for both. Matt [1] http://archives.gentoo.org/gentoo-mips/msg_65e25b7dae79f7b897ed59199919a2a2.xml
Re: [gentoo-dev] LibreOffice project: request for contributors and mentoring
On Thu, Nov 11, 2010 at 8:13 PM, Stuart Longland redhat...@gentoo.org wrote: On Thu, Nov 11, 2010 at 05:40:03PM +0800, David Nelson wrote: A number of Linux distributions have announced their intention to ship LibreOffice with their future releases. We know that they frequently do re-branding work to integrate their chosen office suite in lines with their project's thinking. So we are keen to involve you in our project branding and development, so that we ship releases that better fit your needs. Do we even brand OpenOffice? I can't spot the difference between the self-built OpenOffice.org binary I have, and the official Sun binary I had previously. My concern with LibreOffice would be more to do with compiling it... it'd be a nice package to have on the Yeeloong, but AFAIK it needs Java..? Something I've been trying to bootstrap unsuccessfully for the best part of two years now. (gcj-jdk is a long way from usable, and there's a chicken-egg issue with icedtea6.) It also needs _lots_ of RAM and disk space ... not a plentiful resource on MIPS. gNewSense, which came installed on the Yeelong I have, has OpenJDK and OpenOffice, so it's certainly possible. Matt
Re: [gentoo-dev] Re: Restabilizing MIPS
On Thu, Nov 11, 2010 at 9:55 PM, Stuart Longland redhat...@gentoo.org wrote: STMicroelectronics MIPS systems (Lemote, Gdium, etc) are becoming more common, and we should definitely do a better job supporting them. (I should mention that I've been loaned a Yeelong by Daniel Clark, of freedomincluded.com, to fix up the siliconmotion driver.) Interesting... I've found Zhang Le's overlay includes a quite workable siliconmotion driver which runs fine on my Yeeloong. The only catch is that one must compile it with -march=loongson2f in CFLAGS... -mips3 (my preference) won't do. The main purpose of my project here is to write a kernel modesetting driver. Apparently lots of FSF fanatics use Yeelongs entirely from the terminal, so the potential for faster console scrolling speed is somewhat appealing to them. ;) Out of interest... did you get around to those n32 stages at all? I'd like to get some of my old SGI kit up and going, some of them will need a complete reinstall... so I may as well do that using n32 from the outset. My O2 can remain o32 for now since it was the one still standing after all this time. The others, the userland is broken/stale to the point of uselessness. I tried again last week to make n32 stages, but have had a terrible time with catalyst. The main problem I run into is that I can't get catalyst to acknowledge any package.keywords files (which as I understand might be by design), so I'm unable to put together a stage from the versions I'd like to stabilize. Are your recent o32 stages straight-up ~mips? Can you post your spec files somewhere? Matt
Re: [gentoo-dev] Re: Restabilizing MIPS
On Thu, Nov 11, 2010 at 10:34 PM, Ryan Hill dirtye...@gentoo.org wrote: On Thu, 11 Nov 2010 20:37:51 -0500 Matt Turner matts...@gentoo.org wrote: On Thu, Nov 11, 2010 at 8:28 PM, Ryan Hill dirtye...@gentoo.org wrote: On Thu, 11 Nov 2010 18:00:00 -0500 Matt Turner matts...@gentoo.org wrote: Should we target package versions that aren't stabilized on other architectures yet, so that we'll have an extended testing period before they'll come up for stabilization? That is, can I plan to make gcc-4.5.1 or something the first restabilized version of gcc, go ahead and begin testing it, and be ready for stabilization when toolchain requests it? I'd work on getting it ~mips before you think about stabilizing. ;) Last report I got it doesn't build. I've been using gcc-4.5.1 for the last two weeks or so. :) Should I add a ~mips keyword? Kumba told me about some weird behavior he saw where the stage 2 and 3 comparison failed and the build restarted from scratch again and got into an endless loop. Maybe a hardware problem? I talked with him on IRC last night and he's fine with adding ~mips. No idea what's the deal with his box. If you want to keyword 4.5.1 then you'll need to keyword dev-libs/mpc (bug #279851) and either keyword dev-libs/cloog-ppl or mask the graphite USE flag in your profiles (bug #269088). Keyworded mpc-0.8.2, cloog-ppl-0.15.9, and gcc-4.5.1. Please check to make sure I didn't screw anything up. I'm new at this you know. :) Thanks, Matt
Re: [gentoo-dev] Re: Restabilizing MIPS
On Mon, Nov 15, 2010 at 1:15 PM, Panagiotis Christopoulos pchr...@gentoo.org wrote: On 11:20 Mon 15 Nov , Christian Faulhammer wrote: I don't want to stop you, but you are relatively new to the real keywording business. amd64 at a point had over 30 members and could not work on the backlog in a timely manner. Think about ... I completely agree. I don't know even what's the status of ~mips in the main tree. It would be better, I believe, to start working on the ~mips system/world set, then start stabilizing only toolchain and/or @base-system packages. Please don't start keywording/stabilizing random packages without taking into *serious* consideration what Christian wrote. I was here when we dropped the stable mips keyword, I don't want to see it happening again. I'm not planning an ad-hoc at-random stabilization/keywording spree. I'd just like to have a stable and tested base system.
[gentoo-dev] IUSE=minimal seems like a bad idea
matts...@sempron /usr/portage $ egrep -l 'IUSE=.*minimal' `find -name '*.ebuild'` ^ shows lots of ebuilds with IUSE=minimal. Instead of having a minimal use flag for these packages, shouldn't we have, possibly local, use flags for whatever feature(s) the minimal flag turns off? Thanks, Matt
Re: [gentoo-dev] Maintainer notes in metadata.xml?
On Wed, Dec 1, 2010 at 1:25 AM, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Wed, Dec 1, 2010 at 6:30 AM, Diego Elio Pettenò flamee...@gmail.com wrote: Hi all, I was wondering if we have space already, or if others would feel strongly about making space for, maintainer notes in packages' metadata.xml. [snip] What I'm thinking of is having some sort of maintainernotes element, but not a passive one that has to be tested for, rather something that repoman would spit out on the terminal when doing a scan/full. Comments? Why don't we just encourage maintainers to add !-- -- comments to metadata.xml? I'd love to have a new element if the data to be stored in that element would need to be parsed/categorized by external programs, but otherwise xml comments would work just fine. And have repoman scan/full print out all !-- -- comments? I think that's why Diego is suggesting a new XML tag. Matt
Re: [gentoo-dev] Move x86/amd64 CPU extensions USE flags to a new USE_EXPAND variable
On Sat, Dec 11, 2010 at 5:57 PM, Jeroen Roovers j...@gentoo.org wrote: [snip] I agree that this could be better. To me, most of the problems with this are due to users not knowing which of these should be set for their particular CPU. Instead of having defaults set by a profile, I'd like to figure out a way we can have these flags set by default dependent on the user's CPU. This might require some additional logic in portage; I don't know. Matt
Re: [gentoo-dev] [warning] the bug queue has 118 bugs
On Wed, Dec 15, 2010 at 12:25 PM, Paweł Hajdan, Jr. phajdan...@gentoo.org wrote: By the way, we have a nice team of arch and herd testers - how about encouraging them to wrangle some bugs? Yeah, I just came here to say this. One certainly doesn't need to have completed the developer quizzes to sort bugs. Matt
Re: [gentoo-dev] On hosting self-produced distfiles
On Thu, Jan 20, 2011 at 2:50 AM, Diego Elio Pettenò flamee...@gmail.com wrote: Il giorno mer, 19/01/2011 alle 21.44 -0500, Mike Frysinger ha scritto: you really need to start off discussions as here is the problem i perceive and here is a solution i think will address it. shooting off e-mails from on high as an official edict without room for discussion is no way to run a team. There is nothing new or revolutionary in what I said — are you trying to challenge the need for traceability of distfiles? Good grief. No. He seems to be simply stating that you'd do better to say we have a problem with $this and I think it'd be fixed with $that instead of This is to be considered QA policy, so we're going to ask soon to enforce this. Not hosting distfiles from dev.g.o is a reasonable thing that I think everyone understands and agrees with, but this will be official policy jargon is annoying and doesn't really serve any purpose. Matt
