Re: [gentoo-dev] KDE and Ruby herd call for help
On Friday 15 September 2006 00:28, Nick Devito wrote: Here's a (probably bad) idea, but, how about we do something like the way g-cpan does things. It's just an idea, and, I really don't have a clue as to how g-cpan actually works. *shrugs* Actually, g-gem for gem-based packages is already being worked on by pclouds and Aggelos Orfanakos. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphrLjP2xbkH.pgp Description: PGP signature
Re: [gentoo-dev] AutoMake and paralle safe makefiles [WAS: using -j1 with distcc?]
On Wednesday 13 September 2006 16:51, Alec Warner wrote: If I'm using Autotools, aren't they smart enough (given that I specify the proper headers, and source files and whatnot) to generate parallel safe makefiles? Or is it a shot in the dark as to whether it works or not? If you use automake, 90% they are parallel make safe. There are issues in cases a) you refer to a library in the same directory as the Makefile providing the full pathname; b) you don't put the SUBDIRS variable in the correct order for things to being built; c) you provide custom targets for instance to run scripts that create source files. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpAbErQnrwoD.pgp Description: PGP signature
[gentoo-dev] New libcaca license
So, I was working on updating libcaca to 0.99_bea4 version, but there's a new license to add, and I'd liek to know if anybody has a problem with this ... http://sam.zoy.org/wtfpl/ -- DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE Version 2, December 2004 Copyright (C) 2004 Sam Hocevar 22 rue de Plaisance, 75014 Paris, France Everyone is permitted to copy and distribute verbatim or modified copies of this license document, and changing it is allowed as long as the name is changed. DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION 0. You just DO WHAT THE FUCK YOU WANT TO. -- If nobody has a problem with this next evening (UTC+2), I'll commit libcaca-0.99 under p.mask and this license to the licenses directory. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6SkTIZtfzD.pgp Description: PGP signature
Re: [gentoo-dev] New libcaca license
On Wednesday 13 September 2006 02:37, Peter Gordon wrote: The DO WHAT THE FUCK YOU WANT license is apparently a perfectly valid (though amusing) Free software license, according to an old post [1] on the debian-legal list. I never intended otherwise, but better safe than sorry, I'd rather check this with other people ;) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppGPfZaQxPg.pgp Description: PGP signature
Re: [gentoo-dev] New libcaca license
On Wednesday 13 September 2006 03:19, Jason Wever wrote: You appear to be violating the license by considering anyone else's opinion but your own :-P I never said I will consider other opinions anyway ;) But you're probably right. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpV7Zui4rPe4.pgp Description: PGP signature
[gentoo-dev] Looking for a confcache maintainer
After sending this mail, I'll be removing myself from the metadata of dev-util/confcache ; I've tried maintaining the ebuild and supporting confcache usage in Gentoo, but I'm unable to proceed with this task. The main issue are that confcache codebase, maintained by Brian, need a way to check which package changed what in the cache, so that you can find who poison it. There's then the problem that the failure with the cache happens not with the package you need to fix or restrict but with other packages, and you need to find the primary cause. Finally, the pkg_cv_ values needs to be blacklisted, because every package use them in a different way, and thus they result in quite a borkage when different packages use the same name for different concepts, that results in eternal revdep-rebuild cycles when not using --as-needed, for instance. Anyway, dev-util/confcache needs a new maintainer and supporter. Enjoy! -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpgYha8cR6eq.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: packages going into the tree with non-gentoo maintainers
On Thursday 07 September 2006 04:09, Carsten Lohrke wrote:
How wonderful this sort of maintenance is you can read here:
I'll try to overlook the reverted changes in kdelibs for bug fixes, the
improper ${ROOT} injected in my changes where it wasn't supposed to be, the
broken opengl on kdelibs checks that appeared last month, unhelpful comments
when trying to achieve something from the users, a bug lingering for an year
and a half because my solution wasn't good enough, and that was the solution
that now kde 3.5.4 implements, decisions against the interest and request of
all the users and developers, QA bugs opened without checking facts, GWN
articles sent without notes on [EMAIL PROTECTED] alias for what I can see ...
No, I'm not referring to Stefan. He's human and he did mistakes, but if
someone would be allowed to put them in public, that would be his lead (that
in this case is Caleb, not you), or the QA team.
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpwZ010qa0PD.pgp
Description: PGP signature
Re: [gentoo-dev] Re: cdrtools license issues
On Tuesday 05 September 2006 05:38, Luis Medinas wrote: Now the license problems are fixed and we can ship this on our portage tree tarballs for our new releases etc... Err, I think the problem was for binpkg, we could already ship cdrtools on the portage tree tarballs... ebuilds are GPL2. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphFjNrs5HlY.pgp Description: PGP signature
Re: [gentoo-dev] Re: The Age of the Universe
On Sunday 03 September 2006 00:16, Carsten Lohrke wrote: Neither Gnome nor KDE (no use flag in this case) accessibiliy stuff builds now - and bug 116030 is open since nine months. And waiting other 2, 3, 4, 5, 6 months won't change the thing. Why? Because we have _no_ accessibility team right now. If we had one, the problem would have been solved. Unfortunately that software is doomed to lag behind the rest of Gentoo unless someone maintain it. If it wasn't for the need of that software by some users, probably treecleaners would have removed that already. In _this_ particular case, the notice interval is not important. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp5nlXyUJjEz.pgp Description: PGP signature
Re: [gentoo-dev] cdrtools license issues
I'm the first to not like Schilling's ways, but... On Friday 01 September 2006 14:44, Carsten Lohrke wrote: building GPL software with CDDL licensed makefiles Can't see how this is pertinent, I can build BSD licensed software with autoconf that is GPL, and use GCC to compile.. as well as linking mkisofs to libscg, which he relicensed to CDDL lately. This is a bit more debatable, he *can* link it, if he can change mkisofs license to allow linking to non-GPL-compatible code. Of that, I'm not sure tho. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpX4YspCqhvt.pgp Description: PGP signature
Re: [gentoo-dev] cdrtools license issues
On Friday 01 September 2006 15:36, Paul de Vrieze wrote: The build scripts are part of the source code. And as such must be licensed under the GPL. It's opinable, as you don't mix them with the actual code. I think it's one of the gray points. Still it does not make any sense to ship the makefiles under CDDL and the rest under GPL ... it's just insane. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpfsdUlwsqgI.pgp Description: PGP signature
Re: [gentoo-dev] atom matching behavior
On Thursday 03 August 2006 07:07, Marius Mauch wrote: Opinions? I actually tried to brought this in a few times, and mostly I was either ignored or told to live with it I think. But I agree with you in requiring a solution. As Harald said, changing the behaviour in the run isn't a funny choice, probably adding 1.2.* that also accept 1.2 would be reasonable. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp8Ah056PFb4.pgp Description: PGP signature
[gentoo-dev] Last rites for media-libs/tunepimp
I'm sending the last rites before the p.mask this time because I'm currently occupied in the whole KDE commit so I'd rather not to mix stuff up. Later today media-libs/tunepimp is going to be masked, the musicbrainz useflag dropped, and removed in 30 days. The reason is a security issue (bug #140184) together with the fact that 0.3 and 0.4 are now obsoleted by 0.5, but we cannot add 0.5 yet as only picard (that is not in portage) supports it at this time. Please note that, whenever a 0.5.x version, non-vulnerable, would be needed/usable by software in portage, even during the 30 days masking period, it could reappear normally. *But* I would really like to wait till upstream decides on a format and an API because it was really too much in flux in the last months. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp98xPKOqbHe.pgp Description: PGP signature
Re: [gentoo-dev] New developer: joslwah
Welcome joslwah! :) On Saturday 22 July 2006 17:28, Bryan Østergaard wrote: I'm a research mathematician with interests in linguistics. I'm a Brit., living in China, so am used to utf-8 and CJK issues. Uh, fresh meat for the CJK herd and possibly for an eventual future i18n project? :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpJvbix5TwHY.pgp Description: PGP signature
Re: [gentoo-dev] architectures which support Java
On Thursday 20 July 2006 23:17, Joshua Nichols wrote: Supports: amd64 ppc x86 Work-in-progress: ~x86-fbsd (diablo-jre-bin in tree, waiting for Timothy to give me the ebuild for diablo-jdk and then we'll be all set). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKakFYAEb2W.pgp Description: PGP signature
Re: [gentoo-dev] sys-libs/slang - call for maintainer
On Wednesday 19 July 2006 15:52, Jakub Moc wrote: Any volunteers? Thanks! If nobody else steps in, I'll take a look to this as soon as I'm sure pulseaudio is good enough in Portage. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpRTAjswDmEf.pgp Description: PGP signature
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 06:03, Daniel Watkins wrote: Is there a rationale behind this decision? On some systems libmad does not work and has to be masked, if I called it mp3, it couldn't be use.masked or all the mp3 supports, even when not provided by libmad, would have been removed. Per-package use.mask is not here for another year and in the mean time I needed a working solution, this is it. I would also say that it helps not to overload the same useflag with different meanings, as we already seen a couple of times where v4l and v4l2 useflags are better to be two different things, ibidem for qt3/qt4. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpYqhpoelYus.pgp Description: PGP signature
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 16:38, Chris Gianelloni wrote: If a user has USE=mp3 -mad then they should *always* have working mp3 support. Give me per-package use.mask baby, and I'll do whatever you want. But as when I asked it was considered low priority, then you can start barking at portage devs, instead of me. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpeSAxueMUb7.pgp Description: PGP signature
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 16:43, Chris Gianelloni wrote: While it is a working solution, it isn't necessarily a sensible one. You can take over xine-lib and fix it however you prefer. As this, as well as any other idea you can find, is just an HACK until portage devs implements the per-package use.mask that i asked WAY before 2.1 release, but was then left OUT of the freeze and thus of the featureset we can use 6 months from now, I REFUSE to change the behaviour. You should know better than me this problem, considering that you masked media-video/transcode on x86 2.4 profile because it was depending on linux-headers 2.6 (as it should have been) with v4l2 useflag enabled. You should have use.masked (as it was later done) that useflag as it's 2.6 specific, and I did it that way to satisfy sparc requirement of not having v4l useflag present for them, as it failed with 2.4 kernel. So if I didn't do it that way, forcing people wanting v4l support to use v4l v4l2, now I should still have the stupid, broken, idiotic transcode 0.6 in the tree, or one of the x86 deptrees broken, or one of the x86 deptrees with NO v4l at all. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpks64mzEi0Z.pgp Description: PGP signature
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 20:20, Chris Gianelloni wrote: See, it is this kind of self-serving attitude that really needs to stop around here. So the portage devs didn't include something that you wanted in the latest release... Did you give them a patch for it? Do I ask people to give me patches to xine-lib when they report bugs? Making decisions like this that confuse our users and make the distribution harder to use and more inconsistent I find disputable that my solution is harder to use and more inconsistent. I actually find it more consistent across all the arches and platforms we have, as Ciaran already said. because you have a personal beef with another team simply because they didn't drop No I didn't do that decision because they didn't put per-package use.mask . I did that decision because the only other way to have the same behaviour is resorting to the arch hacking thing that is not acceptable to my eyes. Both solutions aren't beautiful, I still find my solution better than the arch hacking. What I'm saying with that thing about portage is that you cannot get to me screaming that I used an improper solution because the only proper solution was _postponed_ by portage team. Which means that if you really don't like this situation you have to tell them, not me. No thanks. I would much rather have a consistent and working distribution than cater to some childish self-important bullshit that only harms our users. Exactly my point, so why instead of starting criticising my choice in favour of your choice you don't go writing the famous patch? By the way, a patch there was, by antarus, but needed to be cleaned up. My python skills are weak, and you really don't want to see me hacking to portage, but KingTaco iirc offered to take a look. But freeze was entered before anybody could do anything. I don't give a crap about transcode. I was talking about USE=mp3. Changing the subject doesn't help anyone. I'm not changing the subject, I'm just showing you that xine-lib's USE=mad is just _one_ of many other similar problems that don't have a proper solution. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUUxX9TQR1D.pgp Description: PGP signature
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 20:24, Simon Stelling wrote: In the specific case of xine-lib, the mad USE flag can simply be replaced with mp3 because mips, which is the only arch that has the mad USE flag in use.mask, doesn't have any version keyworded. If I revert the change, mips won't be able to re-keyword xine-lib anytime soon. And I try to make sure that everything I maintain can be used as widely as possible. It would be even worse if I now change to mp3, and then mips ask to keyword and I have to change it back to mad. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpDMuWZ0zwIC.pgp Description: PGP signature
Re: [gentoo-dev] 'mad' vs 'mp3' USE flags
On Friday 14 July 2006 22:24, Zac Medico wrote: It think we can have it sooner than another year. There are lots of fixes in 2.1.1_pre and I'd like to close the merge window pretty soon so that it can be stabilized. I'll work on a patch for package.use and package.use.mask so that we should be able to have it in a stable 2.1.1 release within a month or two. That would be great, of course that goes a bit against your current schedule, no? :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpx4KFO61r1F.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe, doins, doman, dodoc die by default
On Wednesday 12 July 2006 23:21, Henrik Brix Andersen wrote: How could that slip through the initial testing of the ebuild performed by the developer doing the version bump? I think that is the point, during testing. If I'm testing the version bump of something that takes 2 hours to build, I'll be happy to see a big fat warning about it, but not that happy to see it fail entirely. Also, we already discussed in the past that there are cases in which dodoc is called within eclasses with a series of names that might or might not exists, because they are mostly standard, and left to dodoc to find the ones good and the ones not. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpHBG80Fh83P.pgp Description: PGP signature
Re: [gentoo-dev] Making dobin, doexe die by default and doins, doman, dodoc warn initially
On Thursday 13 July 2006 02:26, Daniel Black wrote:
4. FEATURES=noauto ebuild {package}.ebuild install
FEATURES=noauto has broken at least two times in different ways with portage
2.1 pre-releases.
Same as broke FEATURES=digest and FEATURES=autoaddcvs or whatever that was.
I won't rely on those FEATURES because nobody has a clear idea of what they
should and what they should not do.
if these use doins/man/doc then the should probably check them before
installing:
[ -f ${doc} ] dodoc ${doc}
dodoc of 30 files of which some might not exists take less runtime than 30
checks for files and following dodoc file-by-file.
Better a dodoc $(ls ${doc} 2/dev/null) probably
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgp6PFDk51UF9.pgp
Description: PGP signature
Re: [gentoo-dev] new herd: vdr - topic reanimated
On Monday 10 July 2006 02:25, Luca Barbato wrote: c is simpler. I like it. Yes, of course if _all wranglers_ respected metadata, instead of stopping to herd tag and assigning to that even when a particular maintainer is listed. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpe2GF5WZw0k.pgp Description: PGP signature
Re: [gentoo-dev] Re: Gentoo activity graphs
On Sunday 09 July 2006 01:10, Duncan wrote: An interesting observation was that of all the FLOSS projects, perhaps only Debian had successfully crossed the line from medium to large. It does seem common around here to criticise them for constant politics and being almost stuck, sometimes, but that's one thing they've done that few others have managed. Yes but at the same time they have maintainers that often does not know what their work is, and screw things up very bad (unstable and experimental are what they call them, but really a bit of user-caring wouldn't be bad from their part). Examples at hand? Amarok 1.4.0 was added with ruby as suggested dependency that resulted in lots of users in #amarok to ask why lyrics didn't work. Amarok 1.4.1 seems to have been added with the same error, and without the properly patched xine-lib to play flac files (that I tried to advertise as much as I could). So I'm not sure if what they do, their policies and the quizzes and the other stuff they require to join debian work. Most likely they work to discourage people more interested in actual work than bureaucracy. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpBrKSLqpRB4.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 15:53, Martin Schlemmer wrote: Check Chris Gianelloni's mail just now. For some compilers with some -march's on x86 it did not explicitly turn on some features (or maybe not to such a high extend). Uh no, I think he meant that for some borderline processors there's not a -march value, like for Athlon64 Revision D, that has sse3 support. In those cases you have to use -msse3 or whatever else to tell the compiler what to generate. So where say CFLAGS=-march=pentium3 would work, CFLAGS=-march=pentium3 -msse would fail to build, or generate bad code (segfaulting binaries). This might have been true with _older_ GCC, but all the series 3.3, 3.4, 4.0 and 4.1 behaves correctly: -march=pentium3 implies -msse without doubt. What you might incorrectly remember is -mfpmath=sse that is totally another thing, and dies usually on bad code anyway, and it's enabled by default on 64-bit CPUs just because on there the 80-bit limit for doubles is not pertinent anymore. I might seem an idiot, but I have enough experience to know what I'm talking about. Seems instead that other people confuse SEGFAULT with SIGILL and -msse with -mfpmath=sse (or simply remember just what happened with GCC 3.2). A little note here: tools improve. GCC 2.95 was a joke, GCC 3.0, 3.1 were almost unusable, 3.2 started to be usable but full of problems, 3.3/3.4 series improved, drastically. Stuff like visibility is badly broken up to 4.0, but works fine on 4.1. You cannot think that a flag or a support will always be broken because a release had it broken, you have to watch what you're doing to do it correctly. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLOzIWZ4SFL.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 16:20, Danny van Dyk wrote: I suggest to add a CPUFLAGS USE_EXPAND variable to the tree. Improvement respect the current situation? You're just asking for the same exact treatment that is in place now, but changing its name like it is a change... -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp4qiuLrXRKA.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 16:40, Danny van Dyk wrote: USE_EXPAND useflags do not need to be added to either use.desc nor use.local.desc. You need to put them in misc/whatever.desc Further, we keep track of other hardware-related metadata in USE_EXPAND, too. See INPUT_DEVICE and VIDEO_CARDS. Quite a different thing to me, considering the wide quantity of them. But for an handful of useflag it would be a bit of overkill. Yes also KERNEL, ELIBC, USERLAND are handled as use-expand, but that's just an hack-that-works. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwqqDMNZdVq.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Adding CPUFLAGS USE_EXPAND variable to the profiles
On Friday 07 July 2006 16:53, Stephen P. Becker wrote: Perhaps you are thinking too narrowly here. Consider that this USE_EXPAND could potentially be used to enable cpu specific flags over more arches than just 32/64-bit x86. It seems clear that ppc and sparc could already benefit, and I can think of at least one situation on mips where it would be useful. So the question is: why they aren't useflags in the first place? There has to be a reason, or it would just be that up to now we did the same thing in different ways just because of it. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp6Xq9wGP5Fk.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 17:31, Martin Schlemmer wrote: As I pointed out on irc (to clarify), its still an issue even with gcc-3.4.6. Its just well enough filtered, and as Mike pointed out, they 'fixed' it in 3.4.5 via specs, and 3.4.6 by backporting patches from 4.0.1 I think. For what I know, the last issue was fixed with 3.3/3.4, so this sounds new to me. That said, I think this is up to now the only point that would make me rethink over this whole idea. For a pure simple and practical problem. I did not imply this as far I know, and if it seemed that way, I can only say that I assumed that newer guys had the advantage of most ebuilds filtering or -mno-sse/whatever for known broken stuff Probably, but never assume that gentoo is the first experience for everyone ;) I had my own share of GCC problems way before, and I remember how much shit GCC 3.2 created, 3.3 compared to it was a different order of magnitude: it worked. I'd say only 4.0.1 and upwards really solved most of those issues, especially the long comming sse one. Maybe because SSE wasn't that widespread in the past, I remember most issues to be related to MMX/3Dnow! extensions mainly, a part a big one with -msse that I thought dead with GCC 3.3, but I might be mistaken on that then, and I beg you pardon in that case. Of course there's the usual -mfpmath=sse that do cause problems on 32-bit systems (although it's the default on 64-bit). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpvc4mXWJpWb.pgp Description: PGP signature
Re: [gentoo-dev] SpanKY's Nominations for the Gentoo Council 2007
On Tuesday 04 July 2006 21:04, Mike Frysinger wrote: some other peeps: Kugelfang / Ramereth / Mr_Bones / spb / plasmaroo / Weeve / `Kumba / jaervosz / KingTaco / Flameeyes / dostrow / dsd / kito / exg I gladly accept the nomination, too. And add my nominations for lu_zero, seemant, solar, koon, mr_bones_ and wolf31o2. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpaC2ZdiFnTR.pgp Description: PGP signature
[gentoo-dev] Replacing cpu-feature USE flags
So, I've been drafting this up in my blog[1], and it is a simple way to
replace the CPU feature useflags. Let's try to summarise:
Right now we have mmx, 3dnow, 3dnowex, sse, sse2 and so on useflags present in
the tree, almost never used to get new dependencies, but usually used to
supply econf switches.
This works as long as the user enable the flags, but for AMD64 the story was,
until now, that we simply enabled them when they worked, because we had some
minimum support available. Unfortunately this became a problem with the
introduction of nocona, because that is an amd64-like system but with no
3dnow. And there is the problem that sse3 is supported only in later versions
of Athlon64 and so on.
To try to clean up this mess, and to make it simpler to work in
cross-compilation, I thought of using the definitions created by the C
Preprocessor (CPP) by default for the given CFLAGS. Basically when
using -march=athlon64, the preprocessor will enable a few definitions that
tells the availability of MMX, 3dNOW, SSE and so on... if we wrap that
around, we can use it to know if it's the case of enabling something or not.
This is customisable by the user by setting the CFLAGS themselves. If one does
not want MMX instructions to be generated, but still want the rest of
Athlon64 optimisations, it's simply the matter of
using -march=athlon64 -mno-mmx.
So, rather than the functions proposed in [1], I've sampled today the
following function:
has_cpuset() {
local def hasfeat
while [[ -n $1 ]]; do
case $1 in
mmx)
def=__MMX__ ;;
3dnow)
def=__3dNOW__ ;;
3dnowex)
def=__3dNOW_A__ ;;
sse)
def=__SSE__ ;;
sse2)
def=__SSE2__ ;;
sse3)
def=__SSE3__ ;;
altivec)
def=__ALTIVEC__ ;;
*)
ewarn Instruction set $1 not supported.
die Instruction set not supported.
esac
echo | $(tc-getCC) ${CFLAGS} -dM -E - 2/dev/null | grep -q ${def} ||
hasfeat=no
shift
done
if [[ ${hasfeat} == no ]]; then
return 1
else
return 0
fi
}
that can be tested easily with the following code:
yesno() {
if $@; then
echo yes
else
echo no
fi
}
echo Does it have 3dnow mmx sse2?
yesno has_cpuset 3dnow mmx sse2
echo Does it have mmx sse sse3?
yesno has_cpuset mmx sse sse3
echo Does it have altivec?
yesno has_cpuset altivec
Note that you need to set your CFLAGS corretly or it will, by default, tell
you that everything is disabled.
Thoughts? Comments?
SPARC team: I'd like to know if VIS does a similar thing, would make simpler
for instance its handling in xine-lib ebuild.
[1]
http://farragut.flameeyes.is-a-geek.org/articles/2006/06/24/crazy-idea-an-alternative-to-cpu-features-useflags
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgprX2XeoSak4.pgp
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:19, Ciaran McCreesh wrote: Sounds rather flaky and unreliable... Sounds rather vague and without arguments. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpBJXhfBv3GB.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:35, Kevin F. Quinn wrote: This could easily be done by configure scripts; perhaps it would be a good idea to look into writing some autoconf macros. Actually there's little need, you can simply use the #ifdef in the code, unless you have separated source files for MMX, SSE and so on (that might as well be), but even then, it's really trivial to autoconf. The problem is that many autoconf scripts do it the other way around, by forcing -march or -mcpu (that is deprecated by -mtune too) deduced from /proc/cpuinfo. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwZMttvPvt1.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 14:49, Ciaran McCreesh wrote:
Well, you're assuming that
Properly listing, what an arcane science.
a) everyone's using a C compiler,
No, I assume that everyone is using a compiler. You cannot have a C++ compiler
without a C compiler. The first person I see that sets CXXFLAGS but not
CFLAGS I'm personally going to give him the doesn't have a clue prize.
b) that gcc has the slightest clue what it's doing,
No, I assume that gcc has a big clue about which capabilities are available to
the -march switch. I might be assuming that users have a clue on what they
are doing, but that's an assumption I do have to do, or I shouldn't be
working on Gentoo but on Debian, which seems pretty good at optimising for
i386 still.
c) that the user has no problem using nasty hacks to regain control,
Where regain control is doing something that could have done before but
made actually no sense to do before. And the bashrc thing is not a big nasty
hack, works quite well for me.
d) that this information is only needed at compile time,
Well of course use flags are available at runtime for the packages built to
know, this is perfectly logic of you.
You really was getting out of arguments, don't you?
If I have to enable a configure switch I need it only at buildtime. If it has
to be known at runtime there's the cpuid function!
e) that various gcc internal definitions won't change...
It's like assuming that gcc will always output the correct hello world for
int main() {
printf(Hello, world!\n);
return 0;
}
If it does change those values, it's going to be a killer for way more than
just Portage.
You're adding a lot of complexity, and thus
room for very weird breakages, to something that doesn't need it.
You're not exposing any of such breakages, I find it to reduce complexity to
users that cannot try to enable SSE3 on an Athlon-TBird system.
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpBazG9uNTou.pgp
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 17:33, Ned Ludd wrote: I tend to agree this might be a cleaner approach vs having to edit redit CFLAGS all over the place. Really if one has to disable mmx support in one package, it should be disabled altogether, in the real world we're all in, mmx useflag is enabled by the vast majority of our users. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpiOpxvI3HJS.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 18:02, Luca Barbato wrote: - if you care do whatever you want, eg: turn cflags for vector units AND autovectorized and shut down hand vectorized code (yes it could be dump if the handmade stuff isn't wrong) In the case you need to shut down the hand vectorised code, it has to be done always, not selected by users. It should be transparent for them, and if the code is wrong, just punt it entirely. Or fix it, your call. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppcbVBjcpSV.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 18:58, Ned Ludd wrote: All together as in across the board? Or simply for the 1 pkg in question? For the package in question of course. Do you think I'm an idiot? Seriously? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpTaMpZzqze8.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 19:51, Ciaran McCreesh wrote:
And for a single compile?
I always leave the two of them in sync, even C++ apps might have parts
building CFLAGS. In case you know you're going to use only C++ is not
difficult to use
CFLAGS=${CXXFLAGS} has_cpuset 3dnow
don't you think?
And your assumption would be wrong. I can assure you that relying upon
-march doing anything sensible with __MAGIC__ is entirely unsafe. Go
and look at the VIS handling if you want a perfect example.
Okay, maybe VIS handling is broken. But we can rely pretty safely on x86,
amd64 and PPC gcc to know the table of arches and extensions supported.
Remember that I asked to talk with SPARC team for VIS just because I only
know about the other three arches.
No no. Where regain control means the user has to screw around with
nasty hacks and pray, rather than setting a well defined, specific
variable.
Find me a reason to do that, a part for broken MMX code that should be
disabled on the ebuild itself already.
Uh. USE flags are available at DEPEND time.
If you talk about the nasm dependency, then it is rare, most of the MMX
support is inline in C sources anyway.
And at the metadata phase?
Should be already transparent or something is strange. nasm is simpler to add
the dependency for x86, there is really few people not enabling mmx already.
Yes it is a bit of regression, but for a small percentage of users, while
there's more safety for many other people.
Er. No. Not at all. The __MAGIC__ isn't guaranteed. Quite the contrary.
This ain't no magic. The magic is in the _CODE_ that GCC creates, but not in
the _DEFINES_ that GCC emits.
You're trying to guess what the user wants based upon hairy magic,
No, about their chosen architecture.
rather than doing what the user says (aren't you always yelling at
upstreams for doing that?)
The user asks for athlon64 support? They get athlon64 (mmx, 3dnow, 3dnowex,
sse, sse2)
The user asks for G3 support? They get G3 (nothing)
The user asks for Pentium4 support? They get what they want (mmx, sse, sse2,
sse3 in case)
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpEMEE1Ith5N.pgp
Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:02, Curtis Napier wrote: Every developer who has ever commented on one of these threads has always agreed with that. Put it in USE not CLFAGS. Well it's not totally right. Putting them in CFLAGS, when using -march, is redundant, pure and simple. -march=athlon64 -msse -msse2 -mmmx -m3dnow -m3dnowex would be equivalent of -march=athlon64 If you have a new Athlon64 that supports SSE3, using -march=athlon64 -msse3 is not only legit, but also (in my opinion at least) suggested. GCC can improve heavily if it knows what it has to do. The problem is that people think that using -march=pentium3 -mmmx will bring them more acceleration, while this isn't true. So I would suggest anybody wanting to comment on these issue to know the difference of using mmx in useflag and -mmmx in CFLAGS at the moment. And then evaluate the change in behaviour. Note: -march=i586 -mmmx for Pentium (classic) MMX is a good idea most of the times, as it's not an i686 but at the same time it has MMX support. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppXtMqRbnIf.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:24, Ciaran McCreesh wrote: Well, if you're playing that game, I'd suggest that anybody wanting to make proposals on this issue should know what CFLAGS is and understand how it is nothing other than a set of flags that are passed to the compiler when compiling a C program, and then evaluate the impact of subverting such a variable for nefarious purposes. And I suggest that anybody willing to comment on user-side of things would know what an user is and understand how users feel about issues, instead of going on and on and on commenting without having a clue. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpZvC5MwKfS1.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 23:10, Kevin F. Quinn wrote: There's -march=pentium-mmx for this. I forgot about it, thanks for pointing it out :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzOhSWFVsLH.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 22:58, Ciaran McCreesh wrote: You're not going to give in gracefully, huh? Ok, I'd like to ask the council to declare that abusing CFLAGS in the manner proposed in this thread is a very bad idea. If you finished the proper arguments, the next one will be that it's all a cabal of infra against you, I suppose. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpjBAukAFhDn.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Thursday 06 July 2006 23:23, Ciaran McCreesh wrote: No, Diego. The argument is that you're coming up with a horrible and unnecessary hack where there are far cleaner alternatives, and that you're blindly sticking to it and trying to throw off any objections by devious means because you don't want to scrap said hack after all the misguided effort you've spent on it. However, since you seem to be incapable of admitting the gaping flaws in your own work, I'm asking for someone else to point this out to you in a formal manner rather than watch this thread go on for even longer. Wait, isn't that what _you_ usually do? Like climbing up on mirrors when you misunderstood something and blamed someone for an error that was never made, trying to find another glitch in the procedure to back it up? Yeah that really sounds like you more than me. I'm entirely ready to scrap what I have here if I find _valid reasons to_. All you seem to be able to say is that you don't like this, you point to a control that users have not much for a valid reason than for the simple fact that the useflag was a good way to allow user to choose what it had without forcing it to use support that was not supported on their system. A solution that worked, but that is not the only one, and that I wouldn't consider a great choice that users really need to be able to use Gentoo. The most interesting point shown up until now is the one about non-gcc compatibility, that I actually thought about for a while, but I thought -dM was unix standard option, Harald got me there, and I'll be checking for something in ICC. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpx6QSrOFiRm.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 01:16, Ciaran McCreesh wrote: Please try to keep this technical, even if your co-developers can't... You started this. * it's relying upon non-guaranteed GCC internals. Not that internals, that part is guaranteed to work, or we cannot consider guaranteed __PIC__ either, and we rely on that heavily. * it's relying upon GCC knowing the state of the underlying system, which fails at least for VIS. Define state of underlying system because that is not a complete definition. This is not a state machine we're talking about, and we're not in science class. * it's removing the ability to get access to the data at the metadata phase, leading to what you yourself called a regression. Yes, a little regression. That's what procons consideration are needed for after all. * it's forcing users to use insane CFLAGS hacks, which we've spent years telling them not to do and for good reason, to get back to previous behaviour. No, we never spent years telling them not to use your so-called CFLAGS hacks that are rather a proper usage of what the compiler gives you. I would _not_ ask someone why he's using -mno-mmx for instance, but I _will_ tell someone using -march=athlon64 -mmmx -msse -msse2 -m3dnow -m3dnowex that he's not doing anything useful. Kinda like I do to people who uses -Wl,--enable-new-dtags [1] * a large part of the justification is based upon a misunderstanding of how cross compilation should be done. The correct way around this problem was already posted to the thread by solar. No I'm not misunderstand how cross compilation should be done with a package manager. I'm saying that this will anyway give a hand to that. What I was referring to mostly comes down to the fact that, if I want to build a bin package for amd64 nocona arch, right now I am not guaranteed that setting CFLAGS to -march=nocona will produce the right result. * it's removing transparency and simplicity and replacing them with obfuscation and complexity. It's removing green and yellow and adding black and white. Your words are useless unless you explain them. * it's taking a variable with a well defined purpose and abusing it for something unrelated. No it is not. Want to get the news? People at binutils were discussing about adding -march support to gas, so that it would refuse to build asm sources that contains instructions not supported by the -march value passed. So using -march=i586 with mmx useflag wouldn't work anymore. It does make sense to them and it does to me too. Will that lot do or would you like some more? You have the innate ability to find more arguments when the ones you brought on are not accepted. For what concerns me, I brought the idea, I find the single regression acceptable, I find it a proper usage of $CFLAGS variable, I find the internals guaranteed enough to work. My work is done here, I leave to anybody else to say what they think, as it seems I'm not the only one thinking this is a good idea. [1] http://farragut.flameeyes.is-a-geek.org/articles/2006/06/22/nonsensical-hacks-why-i-find-kdenewldflags-stupid -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyJw1w2B75S.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:01, Luca Barbato wrote: Using a proper profile and not hardwire useflags to use amd64 is a solution too. Yes it is, I would more likely see that than adding even more useflags to profiles. So using -march=i586 with mmx useflag wouldn't work anymore. ...I don't see why not since gas is supposed to accepth -m* flags related (see man as) Uh, -march=i586 will tell gas to accept only instructions present on i586, even if they come out of inline asm. If the inline asm is MMX, gas refuses to produce code. It would only work with nasm sources. but isn't the only way and as I told you already I'd rather have stuff properly set in profiles specific even if I like the idea of being able to check for compiler support. Yes, you told me, and this is why we're not here discussing that. I told you want I think of the idea, I don't dislike it although I find it (thinking as it is now) a bit more complex. I'm waiting to see a sample implementation tho, as that is what we should base on. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKj2tjLDPuq.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:20, Danny van Dyk wrote: Ehm, no. Athlon64 can also optionally include: sse3 (for latest steppings) and xchg16 (which is a bit older already) That is the point, if they ask -march=athlon64 they get the base athlon64. If you add -msse3 (as you should if you have an Athlon64 capable of SSE3) you get the whole stuff with sse3 support too. For free! Afaik Pentium4 has support for xchg16 since the very beginning. I don't remember any useflag for that, and I don't seem to find that instruction reported in gcc's documentation, so I cannot comment on that. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpzcsyxKLcjT.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 02:46, Mike Frysinger wrote: this sort of closed mindedness isnt really encouraging ... Err I actually thought if icc in the first place and tried to inform myself. I'm not the kind of person (and you should know) who likes breaking unsupported stuff. I think it's reasonable to find a solution that works with ICC, and actually Harald already gave one later in the thread. It's just a matter of fact that we don't have anybody right now to follow what might and might not break this or that unsupported compiler. As soon as there is a single person ready to at least answer to questions about it, the situation changes. I'm just saying that I wouldn't discard entirely a solution just because some unsupported software _might_ not work (note the conditional). I wouldn't discard a solution just because it _might_ not work on GNU/kFreeBSD; I would discard it if I _know for sure_ that it does not work on GNU/kFreeBSD (in which case, knowing it doesn't work, I would look for a working solution). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp3WfZaRwdgm.pgp Description: PGP signature
Re: [gentoo-dev] Replacing cpu-feature USE flags
On Friday 07 July 2006 03:15, Mike Frysinger wrote: x86_64 toolchain accepting 3dnow on a nocona arch? :) that isnt a cross-compile nor a different architecture This is the whole point of my solution. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUJ4qne0Opb.pgp Description: PGP signature
Re: [gentoo-dev] autotools - 'make' infinite loop
On Wednesday 05 July 2006 22:05, Marcus Furlong wrote:
Running 'configure' goes fine, but running 'make' just keeps running
configure over and over.
It's commonly caused when the timestamp of configure and the sources for
configure are messed up. Make sure no file has modification time in the
future, and let the configure script to be regenerated forcefully before
make.
If you're using kde eclass, just remove the 'configure' file before
kde_src_compile, and the eclass will take care.
If the files have modification time in the future, you must run in src_unpack
something like
find ${S} -type f -print0 | xargs -0 touch
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpTu6gSG0jX7.pgp
Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Thursday 06 July 2006 01:36, Joshua Jackson wrote: does that mean that only one third of your personalities will be productive in meetings and the other two disruptive? Probably only that one will be productive, two disruptive, and the other we'll know when we'll see. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpQUcGrdqfWh.pgp Description: PGP signature
Re: [gentoo-dev] Nominations open for the Gentoo Council 2007
On Tuesday 04 July 2006 22:39, Kevin F. Quinn wrote: I nominate SpanKY, vapier and Mike Frysinger. I second these nominations, all three. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpbe7QUL9PfA.pgp Description: PGP signature
Re: [gentoo-dev] Future developer
On Friday 30 June 2006 21:54, Paul de Vrieze wrote: I'm proud to announce the arival of a future developer. His name is Tom. Congratulations Paul :) Now you can join that club of old geezers :P ps. If I'm a bit away these days, it is due to me being preoccupied with my mentoring task. Take your time, at the end we'll need fresh developers soon enough, all the others are burning out ;) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpFpNSVAMPqN.pgp Description: PGP signature
Re: [gentoo-dev] Modular X (7.0) stable on x86
On Friday 30 June 2006 23:06, Donnie Berkholz wrote: (No, I didn't add evdev to non-Linux profiles, calm down =) Oh you could have, I've masked the use-expanded useflag anyway ;) But thanks for taking care :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpw21WyJDaML.pgp Description: PGP signature
Re: [gentoo-dev] GPL and Source code providing
On Wednesday 28 June 2006 11:21, Mivz wrote: Does this obligation, to provide your own source, also count for a none Gentoo developer making a overlay tree for one of his projects which is licensed under de GPL-2? Because that is a derived distro form Gentoo right? The problem there is with binary packages. The problem does come down to, then, just GRP and other release methods, like solar's tinderbox and my Gentoo/Alt stages. For the rest, Gentoo uses sources, not binary packages. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpjxPX0tzd53.pgp Description: PGP signature
Re: [gentoo-dev] GPL and Source code providing
On Wednesday 28 June 2006 12:47, Mivz wrote: So that would not be when a stage 3 install cd for the Overlay tree is published? Because that cd contains binary precomplied packages. Well, IANAL and as Stuart said the last word is up to trustees, but from my understanding, as long as the overlay contains only ebuilds, it has to be treated as a source-only repository. In the moment you release a stage or a CD out of that overlay, you have to comply to GPL for the ebuilds, which means that the overlay has to be available, and for the GPL software released in the stage/CD. The main difference that I can see from Debian (and based distributions) is that their packages are built out of the original sources (that might and might not be GPL) and their debian/ directory (that is GPL). As I said, IANAL and I'm speaking only for myself not for anyone else. I only try to apply some logic to the text of GNU's GPL... although seems like logic is overestimated with some people as we now see, unfortunately. If we have to resort to lawyers just to get a distro going, I think there's something entirely wrong with what the free software is today. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpKFtletHiKf.pgp Description: PGP signature
Re: [gentoo-dev] GPL and Source code providing
On Wednesday 28 June 2006 17:42, Chris Gianelloni wrote: This is a common misconception. All that you really need to provide is the patches. Not really, no. As Ciaran already said, FSF seems not to think this way and this is the most important thing on that article. But there's a simple way of course to handle the whole stuff, and is to just send the changes upstream. This is anyway a good idea, btw. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgptlTY6QbrmT.pgp Description: PGP signature
Re: [gentoo-dev] Re: Scientific Gentoo reorg: the proposal
On Monday 26 June 2006 21:44, Duncan wrote: A four-letter geol/geom/whatever would clear that up. What about geomancy ? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUCjr9Ckhsv.pgp Description: PGP signature
Re: [gentoo-dev] Qt use flag recap
On Friday 23 June 2006 14:16, Tuan Van wrote: I don't really object to #2 but please do inform current users so thing still work after an `emerge world -Du` That's why we're going to ask them to be added to default useflags :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpfMLlyELJqU.pgp Description: PGP signature
Re: [gentoo-dev] Re: [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 10:58, Kevin F. Quinn wrote: ok; so in gtk-land we have gtk2 to prefer the newer interface whereas the proposal for qt/qt3 is to have a specific flag for the older interface. I do prefer the qt/qt3 approach, even though it's inconsistent with what happens on gtk. I don't suppose changing gtk/gtk2 to gtk/gtk1 would be popular... Please don't talk about interface, Qt is way more than interface as I said, so talking about frontends and interface is misleading. If it was just interface, of course it would be possible to choose the best between Qt4 and Qt3, but this is not an interface problem, it's a bindings problem. As I said, enabling just one between qt3 and qt4 in bindings would be like just having one of pbindings useflag, and every ebuild decides if it will provide python or perl bindings, just because they happen to start with 'P'. Qt3 and Qt4 are different enough to be considered different languages from some POVs, it does not make sense to treat Qt the exact same way of GTK, because it's not only a GUI thing. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp8jAcxCqUux.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 15:21, Caleb Tennis wrote: Solution: The qt flag represents the latest qt major version for the package. The maintainer can either put in another flag for the older version (qt3?) or provide a separate package (e.g. dbus-qt3 ). Although I can see why you suggest this (Qt 4 is what should become mainline asap), right now I think it's going to be a bit of a mess for KDE users, Remember we don't have use-deps and that splitting packages is something that, if done without upstream support, can give very bad headaches (we both know how KDE split is right now). Also, this puts us back again in gtk's system, with different meaning for the same flag (qt can then either be for Qt3 or Qt4, no clear distinction), that might even change on maintainer's decision, becoming a mess to handle in dependent packages. Why you think it's better this way rather than having one meaning every useflag? Another thing that this setup is going to make incredibly difficult to manage is use.mask masking on profiles. If for some reasons Qt3 or Qt4 needs to be masked on a profile, even temporarily, by having qt mean one or the other depending on the package is going to be a mess as we don't have per-package use.mask (and we won't have till portage 2.2 gets the main scene). This is another of the main reasons I don't think it's a good idea to overload useflags with different (albeit slightly) meanings. I agree on the other part tho, pushing Qt4 is indeed a good idea, although it might mess up the lookfeel of a desktop, but that is marginally important. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUEQgyAF1ov.pgp Description: PGP signature
Re: [gentoo-dev] 1/2 OT: Comprehensive Source Database
On Tuesday 20 June 2006 04:02, Andrew Cowie wrote: I'm not sure if any other distros besides Ubuntu are using it yet, but certainly things will improve geometrically as they start to. Considering it's not Free Software nor Open Source for the most part, I would be surprised. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpcYoQdk4uee.pgp Description: PGP signature
Re: [gentoo-dev] GWN Comments
On Tuesday 20 June 2006 04:32, Alec Warner wrote: CAPTCHA Those are evil. You use one, I'm personally going to track you down and send you a thousand photos of Chris White and Jeffrey's goats circus stars together.. with a pole! -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpGz4kbKrQ9A.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tuesday 20 June 2006 18:40, Stefan Schweizer wrote: 3) split the qt flag into a qt3 and a qt4 flag. This allows users to specifically pick qt3 or qt4 and the flag meanings are obvious - downsides are it is a lot of work. I would like migration to this idea, that would have been what I've liked to see for gtk too. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpr9mpgtI9J6.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tuesday 20 June 2006 19:10, Joshua Jackson wrote: I don't want to go down the path again of having two nearly identical flags for a different slotted version of a framework. I'd like to see just qt with a maintainer deciding if its going to be qt3 or qt4. Unfeasible. GTK 1.2 was deprecated when the two flags were merged, Qt3 is all but deprecated right now. If you decide to use just one version of qt, it would be qt3 for all, and a mess when KDE 4 will come out, we can't think of NOT having time for the change from 3.x to 4. Also, gtk and gtk2 flags did NOT work as I asked, gtk2 was to enable gtk2 version when both a 1.2 and 2 version was available, so for instance ethereal +gtk -gtk2 built gtk 1.2, and -gtk +gtk2 built NOTHING. What I'm asking is for qt3 enable the qt3 version, qt4 the qt4 version, qt3 and qt4 both if possible (that is usually the case for stuff that has both version available, as one does not obsolete the other right now). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpkdzlOIoCBy.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Tuesday 20 June 2006 19:41, Simon Stelling wrote: I don't know all the details, but assuming no app supports qt3 and qt4 at the same time (i.e. you have two interfaces, one against each, which is pretty senseless), wouldn't something like We're not talking about interfaces, but more likely bindings right now. Would you accept being able to build only either python or perl bindings for a package, depending on what the maintainer thought it was the best for you? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpEmjST7FmsQ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 00:52, Donnie Berkholz wrote: Yes, you will need to introduce a qt4 flag as upstreams port packages to qt5, if they choose to also retain a qt4 frontend. You're trying to compare gtk to qt directly. They are not the same. gtk regards only the graphic library, qt is a library of utility functions too. Qt can be considered like gtk+glib, and that make things more complex. As I said, I'd rather see two flags, qt3 and qt4, to identify the two versions. A simpler alternative would be qt (defaults to 3) and qt4, but that's going to be confused on the long run to something similar to gtk. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphRiuuiKxow.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 02:12, Donnie Berkholz wrote: I disagree with this and agree with Caleb's earlier suggestion. Presumably he has some clue what he's talking about when it comes to qt. I suppose he has, that does not mean that I don't have any at all. Probably, if you want to put it this way, I have more clues than you when it comes to interfacing with users. But _that_ is what you asked me to say. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp0zdq01LWDL.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 03:06, Donnie Berkholz wrote: I never said you didn't. And there's no need to bring in completely offtopic points here, we're trying to have a discussion about qt. I am talking about qt. Maybe I wasn't clear enough, I was thinking of KDE users, that are, casually, the main users of Qt-related stuff. In this particular issue, KDE (3) users are the main part, they need poppler and other stuff built for Qt 3. There are still just a few packages that relies on Qt 4 right now. Still, I'm not for the idea of just putting qt to mean Qt 3 and discard Qt 4 until it's the chosen one, not only for a compatibility reason with migration from older version, but also because we do have people using gentoo for KDE 4 development (I happen to know a few of them), and they need Qt 4 support. I want to save both of them, asking a little bit more work for the developers, as they usually know what to do, rather than for users, which might as well be half clueless. Did I explain this long enough, or should I demonstrate again that I don't say stuff just because I have a mail client and a GPG signature? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpLqTDHv9L1n.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Useflags: qt, qt3, qt4?
On Wednesday 21 June 2006 03:34, Donnie Berkholz wrote: OK, so we can add qt3 to make.defaults. Firulì Firulà (sounds of whistling in Italy at least) -* says nothing to you? :) I was looking at the less work possible for both users and bug wranglers. Still, I think you took too personally the fact that I cleared up the gtk+glib vs qt stuff; maybe that's my fault, I want to clear that up so that people not used to know how qt works can know the situation, as the idea of dropping one of the two support stated in other mails of this thread and on IRC is something really unfeasible. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp1yqK7Ozpud.pgp Description: PGP signature
Re: [gentoo-dev] strict-aliasing rules, don't break them
On Saturday 17 June 2006 12:17, Luca Barbato wrote: Long term solution: The best long term solution would have been to fix the code, but actually I didn't ever found a quick explanation of how to fix this kind of code... -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpy0mG0pHVmf.pgp Description: PGP signature
Re: [gentoo-dev] strict-aliasing rules, don't break them
On Saturday 17 June 2006 13:43, Luca Barbato wrote: you can use unions or rewrite completely the line using it in another way, in certain case the type pun is the quickest solution so it's better to append -fno-strict-aliasing in the Makefile. Err give me an example of the line, a lot of strict aliasing breakage was due to double pointers. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpg5SjnSV15q.pgp Description: PGP signature
Re: [gentoo-dev] strict-aliasing rules, don't break them
So, just for people to know.. On Saturday 17 June 2006 15:32, Kevin F. Quinn wrote: kde-base/kdm-3.5.1 Fixed in latest ~arch (and upstream) media-libs/faad2-2.0-r11 Fixed in latest ~arch media-libs/xine-lib-1.1.2_pre20060328-r9 Fixed in latest ~arch (and upstream) media-video/vlc-0.8.5-r1 Testing in progress, will be fixed for tomorrow. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgphvpIH3hhk2.pgp Description: PGP signature
Re: [gentoo-dev] nss_* and system users
On Friday 16 June 2006 05:03, Mike Frysinger wrote: nss is glibc-only, so such a solution would be inadequate Actually this is one of the strange and rare cases that's not only glibc's. FreeBSD can use nss too :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpc6fXCqO0w4.pgp Description: PGP signature
Re: [gentoo-dev] eclasses maintainers - raise your hands please
On Thursday 15 June 2006 12:26, Jakub Moc wrote: gems.eclass - ruby, are you taking bugs for this? pythonhead's been MIA for ages, not much useful as a maintainer contact I'll try to learn how it works and see to take this over for ruby herd. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpNDr5S1vIWY.pgp Description: PGP signature
Re: [gentoo-dev] eclasses maintainers - raise your hands please
On Thursday 15 June 2006 16:50, Mike Frysinger wrote: this is dead as it's been integrated into portage Can gnuconfig_update calls go away from new ebuilds, then? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUZcaWFduQ7.pgp Description: PGP signature
Re: [gentoo-dev] eclasses maintainers - raise your hands please
On Thursday 15 June 2006 22:39, Harald van Dijk wrote: The question was explicitly about new ebuilds, so your answer concerning only new ebuilds is the reasonable assumption without an indication otherwise. I limited to new for backward compat... but as portage updates them anyway now, I'll drop it from video and sound and other ebuilds later now. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp9pDbbfqlHr.pgp Description: PGP signature
Re: [gentoo-dev] eselect-compiler updates and unmasking
On Friday 09 June 2006 10:15, Danny van Dyk wrote: Have a look at eselect binutils please, which is shipped with app-admin/eselect. It's sub-optimal compared to eselect compiler, x86_64 ld does not work with i686. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgppmkbojAU5g.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Friday 09 June 2006 11:06, Jakub Moc wrote: The thing has been sitting in bugzilla for ages, I've asked Flameeyes to commit it and he said he's not going to put any mode pam stuff into the tree unless he's using the modules himself. Or if somebody wants to help with PAM and related... considering right now Azarah is mostly away and I'm almost alone handling the rest. Yes it's offtopic, but a quick way to remember that we need more PAM maintainers :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpyjpJZELOjq.pgp Description: PGP signature
Re: [gentoo-dev] Re: Re: Re: Re: [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Friday 09 June 2006 13:44, Peter wrote: And, anyone who goes through the trouble to svn the overlay, edit make.conf, etc., would not be an ignorant newbie (no disrespect to newbies intended). I had a bug from an users unable to build kdesktop with gcc 4.1. I built it fine I told him, and the line where the error was reported didn't contain anything of the extra qualification reported, so I asked him to check as he was probably using an overlay. He started ranting that we have a bad user support and so on... until he actually recognized he was using xgl overlay. That said, I wouldn't be surprised if especially with layman people ends up using overlays without knowing that. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpRMTwFZBiuu.pgp Description: PGP signature
[gentoo-dev] [RFC] i18n project
So, as someone might have read in my blog[1] I've been thinking for a couple of days about creating an i18n project. What would an i18n project be needed for? Mainly, to try to provide to our non-English native users a more friendly environment. We discussed many times in the past about making simpler having UTF-8 support, or even enabling it by default, but of course it's difficult to handle this right now, and this is not the only concern. What I have in mind is establishing some kind of team that would collaborate with the current doc translators that would like to help, trying to get other parts of Gentoo accessible to non-English speakers. Translating man pages for Gentoo-specific software, making Portage and other gentoo-specific packages i18n-capable and translating them, translating forums (I think the Forums stuff already handle that, but maybe it would help if we're able to get a more complete team). Least but not last, also translating software that's missing translator, like I did for xine-lib/xine-ui/gxine and Italian this week, or at least release poupdate tarballs with translations updated from CVS when the ones in the releases are obsolete. This might also help to find a home to utf8 and cjk herds, for instance. I'm actually going to work to add to Portage (will-be-2.2) i18n capabilities next week, and I'll be doing for sure the Italian translation. Comments, thoughts, translation, are all welcome :) [1] http://farragut.flameeyes.is-a-geek.org/articles/2006/06/08/do-we-need-an-i18n-project -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpdosLJCtYfL.pgp Description: PGP signature
Re: [gentoo-dev] [ANNOUNCE] Project Sunrise - Gentoo User Overlay
On Thursday 08 June 2006 15:46, Chris Gianelloni wrote: Having to troll through some overlay only increases our work load. +1 for chris -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpciKqnLh3FT.pgp Description: PGP signature
Re: [gentoo-dev] Project Sunrise thread -- a try of clarification
On Thursday 08 June 2006 20:58, Markus Ullmann wrote: 3) replacement for bugs.g.o I would prefer if people would still comment on the bugs when they do some changes on the overlay so that at least we know that. Some ebuilds found their way into the overlay, we talked about that internally and I'll remove them after this mail is sent out, so that we stick to maintainer-wanted things here. This is appreciated. On this note, I would like to ask what are you going to do with eclasses. From my POV I'd ask to absolutely _not_ touching eclasses at all in the overlay. I have bad past experiences with overlays replacing eclasses. As bad as with xgl overlay rewriting some of the kde packages and breaking then with gcc 4.1 :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpO5e5GSRzQc.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 11:17, Carsten Lohrke wrote: I'd say 99,9% don't want mikmod. Arguments please, not vague assertions. :) SDL based games requires mikmod quite often. I suppose Mike knows what he's saying. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp5k7lnsFXCV.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups: -apm -foomaticdb -fortran -imlib -motif -oss -xmms
On Tuesday 06 June 2006 08:34, John Myers wrote: I use alsa-driver with 2.6 kernels. I forget exactly why (this was almost two years ago), but I actually switched _away_ from the in-kernel-tree drivers to alsa-driver for some particular reason. There are a few issues with in-kernel driver when they are not in-sync with the userland, ALSA does not assure compatibility between versions. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpg3hG1xnqEh.pgp Description: PGP signature
Re: [gentoo-dev] Default useflag cleanups - discussion status
On Tuesday 06 June 2006 12:13, Stefan Schweizer wrote: If you want to help with this effort, we need to create a tracker bug and check [1] 71 packages :) Add to fix and mark stable, _stable_, them before 2006.1 release. Oh and of course you'll have to take the pieces if something breaks :P Again, I don't think this is much of advantage compared to the disadvantages, especially since I for one don't want to waste time on this if users starts complaining. Sound has enough problems by itself. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsDIpGVQ46c.pgp Description: PGP signature
Re: [gentoo-dev] QA subproject, TreeCleaners
On Tuesday 06 June 2006 00:12, Eldad Zack wrote: If an interested developer comes along the day some time later, and the ebuild is untrivial, it can be a time-saver starting from the last version at some cases - especially if the ebuild was punted because of security issues. That's why we use a SCM for managing the ebuilds: the removed ebuilds are still found via cvs commands and on sources.gentoo.org -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpUFZPswYaHp.pgp Description: PGP signature
Re: [gentoo-dev] Need a use-expanded TV_GRAB variable for xmltv
On Sunday 04 June 2006 14:56, Mike Frysinger wrote: what about TV_CAPTURE_CARDS You got it quite wrong, it's not about the TV cards :) It's about TV guide grabbers. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpEqyAQhunfd.pgp Description: PGP signature
Re: [gentoo-dev] User Relations Co-lead
On Saturday 03 June 2006 17:40, Andrej Kacian wrote: Will that result in dramatic increase of anime smilies in Gentoo environment? Of course, else we'll be all angry _ .. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpacyU9qGsqO.pgp Description: PGP signature
Re: [gentoo-dev] [useflag] v4l2 : video4linux2 support
On Tuesday 30 May 2006 23:41, Henrik Brix Andersen wrote: Any reason why we can not use the existing 'v4l' use flag for version 2 as well? Why repeat the gtk/gtk2 mistake? Because v4l2 is not available on 2.4 kernel, and if transcode didn't have v4l2 instead of v4l I should have resurrected transcode 0.6 and freaking contined to support that stupid package :P -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpP6dXllHvr4.pgp Description: PGP signature
Re: [gentoo-dev] Future of tetex
On Friday 26 May 2006 13:02, Martin Ehmsen wrote: We are currently considering using the same approach as with the perl packages (using new-style virtuals), but I guess thats on hold until it is okay to introduce additional new-style virtuals? As long as the name does not clash with the name of the package (perl prefixes the names with perl-) you are fine, so if you have virtual/tex-latex-beamer you should be fine :) I would support this approach btw, especially if you're going with a split way to add TeX sources, as seems more finegrained :) Comments, suggestions, offers of help, anything would be useful :) Count on me for testing, and for ~amd64 and ~x86-fbsd marking when needed ;) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgp9Wj0DJFpid.pgp Description: PGP signature
Re: [gentoo-dev] cmake.eclass
On Friday 26 May 2006 01:10, Danny van Dyk wrote:
DEPEND=dev-util/cmake-${NEED_CMAKE+-${NEED_CMAKE}}
And see it die of a strange death missing the = in front?
--
Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE
pgpbqO0tFujdd.pgp
Description: PGP signature
[gentoo-dev] Moving virtual/eject to new-style virtual
So, right now virtual/eject is the old-style virtual that gets listed in virtuals file in the profiles, defaulting to sys-apps/eject that is Linux only. I would like to move it to a new-style virtual to make it simpler to handlef or other platforms, having the deps this way: || ( kernel_linux? ( sys-apps/eject ) sys-block/unieject kernel_FreeBSD? ( sys-apps/eject-bsd ) ) this way when used with a kernel different by Linux it defaults to unieject (my reimplementation) that using libcdio would be simpler to port. Thoughts? -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpoh2Pl1FNZl.pgp Description: PGP signature
Re: [gentoo-dev] Moving virtual/eject to new-style virtual
On Tuesday 23 May 2006 13:25, Harald van Dijk wrote: How does it help? New-style virtuals have several disadvantages, and the usual advantages of new-style virtuals don't apply here. If it actually provides real benefits, then no objections from me, but how is this easier to maintain than a virtual/eject sys-block/unieject entry in the default-bsd profile? I should have explained what my whole plan was, probably :) Currently there are things provided by sys-apps/eject that are not available on either unieject or eject-bsd.. the final idea was, from my part, to identify those features in three versions 0a 0b 0c (the 0 version is to avoid collisions between virtual/eject and sys-apps/eject binpks). 0a would be simply the basic eject command, what it is now. 0b would be basic eject + --trayclose (needed by rip for instance) 0c would be ability to eject usb/scsi devices. The first case is the dependency as it is now, the second is eject or unieject, the third would be just eject and thus not keyworded ~x86-fbsd at all. When I'll be able to provide 0c features in unieject, I'd add that to 0c. The need for usb/scsi eject is given by libgpod and related :) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpVxNGdS8vFK.pgp Description: PGP signature
Re: [gentoo-dev] New git.eclass
On Friday 19 May 2006 23:44, Donnie Berkholz wrote: If you just want the latest git rather than snapshots etc, you could do a git-sources-.ebuild. That seems to have become the standard. I would suggest a 2.6.999 just to be on the safe side ;) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpGswxmmQji5.pgp Description: PGP signature
Re: [gentoo-dev] RFC - Gentoo Knowledge Base
On Wednesday 17 May 2006 15:17, Kristian Gavran wrote: Why reinvent the wheel?!? Because it's not the same thing, gentoo-wiki is not and can't be official, there are many things there that are totally unsupported. What Sven is proposing is (as far as I can see it) is something official and officially supported. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpsIuW33padP.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 16:17, Patrick McLean wrote: Deprecated profiles are considered unsupported, as are most of the gentoo-alt profiles default-bsd *is* supported. Gentoo/FreeBSD project (that would be myself) takes care of all the bugs related as fast as possible. The unsupported Gentoo/Alt profiles are in the Gentoo/Alt overlay. -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpWkNQloXzYr.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 14:02, Thomas Cort wrote: No influence? Last I checked, the number of Gentoo developers on the project out numbered the number of non-Gentoo developers 5 to 1. See http://paludis.berlios.de/Authors.html Uh we don't _work_ for Gentoo. I'm the sole author of unieject and RubyTag++, but they both has nothing to do with Gentoo (I even moved out rubytag++ from my dev space on woodpecker to move it on my own server). Gentoo != Gentoo Developers (only) -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpGkzO83Klar.pgp Description: PGP signature
Re: [gentoo-dev] Paludis and Profiles
On Wednesday 17 May 2006 18:26, Thomas Cort wrote: rpm, stow, and dpkg are 100% incompatible with portage and I'm fairly certain that upstream has no intentions of making them compatible, yet they are in the tree and stable on many arches. Are you also suggesting that we mask them too? And you don't see profiles that uses any of them. Nor you'll ever see them. They are there mainly for developers' peace when they have to inspect RPMs or DEBs (I actually do that often). -- Diego Flameeyes Pettenò - http://farragut.flameeyes.is-a-geek.org/ Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE pgpwvfpJ5ns37.pgp Description: PGP signature
