Re: [gentoo-amd64] UDEV
On Saturday 26 March 2005 14:47, Mark Constable wrote: Is anyone else successfully using a udev-only system on amd64 or is this a general/amd64 wide issue (and not just for me) ? Seeing as how udev implies udev-only (udev and devfs are mututally exclusive), I suspect many people have udev-only setups... The first time I tried moving to udev, it was nothing but headaches, so I switched back quite quickly. A few weeks ago, when I tried again, it seemed to work, so I'm now using a udev system... However, CD/DVD burning is an issue for me: One drive will burn only if cdrecord is *not* setuid root, the other will not burn at all. I do not use an initrd, so there's one major difference between your system and mine. Have you tried rebuilding the initrd lately? -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] KDE 3.4 arts build problem
On Wednesday 02 March 2005 00:13, you wrote: probably I'm not the first to encounter the following problem. I try to install KDE 3.4. I'm using the kdecvs-build script but I can't even compile arts. The problem is because Gentoo is using a broken backport of the GCC visibility feature and they don't seem to care to fix it. I disabled it for my GCC by adding this to make.conf: GENTOO_PATCH_EXCLUDE='13_all_gcc34-visibility1.patch.bz2 15_all_gcc34-visibility3.patch.bz2 14_all_gcc34-visibility2.patch.bz2' YMMV. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
On Tuesday 01 March 2005 20:33, Creamer, Mark wrote: This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated. On Tuesday 01 March 2005 23:01, Simone Piunno wrote: this is just to inform you I have received an email from you but I wasn't a named addresse. According to the notice that was included in that email, I was not authorized to read, print, retain, copy and disseminate that email without your consent, and that doing so could be unlawful. Then I've decided to fulfill the request to reply and inform you of what happened, as I'm doing now. I confirm I've already deleted the email from my system. I hope this will be appreciated. This is to inform both of you that while Mark can legally deny your/our right to print, copy, or disseminate his emails, but he cannot prevent you/us from reading or retaining it. Likewise, you/we are not legally obligated to delete or erase his emails, nor to inform him of any such mistakes simply because he tells you to. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
On Wednesday 02 March 2005 02:09, Joseph LeMoyne IV wrote: Hate to burst your bubble, guys, but Simone was joking. Notice the almost word-for-word reply. I hope this will be appreciated. Come on. I was primarily replying to Mark, not Simone. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] http_proxy syntax for ISA server
On Wednesday 02 March 2005 05:09, Renzo Rosales wrote: Is anyone going to help this guy? lol He doesn't want us to. He'd rather we all delete his email! =p -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Recommendations for Intel Xeon
On Sunday 20 February 2005 22:07, gentoo-user wrote: I'm getting a server with Intel Xeon CPUs that support EM64T (Intel's version of AMD64). Would you recommend sticking with i686 compile options for a production-level server? What are the benefits of compiling with 64-bit support? Is the speed difference (if any) worth the potential loss of stability? From what I've heard, Intel's x86_64 CPUs really are just x86 with added 64-bit emulation on the chip. 64-bit code therefore runs slower, etc... Might want to confirm it from someone who actually has one, though. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: KDE 3.4.0_beta1
On Thursday 10 February 2005 09:45, Duncan wrote:
Luke-Jr posted [EMAIL PROTECTED], excerpted below,
on Thu, 10 Feb 2005 03:41:33 +:
on PPC...
mkdir -p /etc/portage
for d in /usr/portage/kde-base/*; do
pkg=${d/\/usr\/portage\//};
echo ${pkg} ~x86 x86 /etc/portage/package.keywords echo ${pkg}
/etc/portage/package.unmask
done
That should work on any arch, though it will make a technically invalid
package.keywords file. It will work perfectly fine, though. :)
OK, that will /normally/ work fine, and might work fine on all current KDE
3.4.0 betas, but as you say, it's technically incorrect (because it's
telling portage to treat your arch like x86, which it isn't, and that
can cause interesting complications, see below), and it /will/ cause
problems with some packages, which is why the technotes say don't do it.
Only packages that won't work on your platform.
Here's the deal. Certain ebuilds conditionally build in or compile
certain features based on the keywords.
Based on USE flags.
One example I know of, altho it's keyworded amd64 so there'd be no reason to
use package.keywords to hack things, is xorg.
Nope. It uses USE flags to determine what arch.
Others would be both mplayer and xinelib.
Those are checking USE flags also...
Even more commonly, amd64 specific patches are conditionally applied based
on keywords.
s/keywords/USE flags
If you tell portage to use x86 (in either form), these tests will be screwed
up.
If portage is changing my USE flags based on package.keywords, then portage is
screwed up.
Thus, what one /really/ should be doing before they go trying x86 (in
either form) in the keywords is verifying that the ebuild doesn't have any
of these specific tests in it, or at minimum, that if it does, they aren't
serious issues (an example being the lib/lib64 issue, presently).
As far as I am aware, ebuilds are not supposed to go checking KEYWORDS
themselves.
--
Luke-Jr
Developer, Utopios
http://utopios.org/
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Several problems with Gentoo AMD64
On Thursday 10 February 2005 19:42, Jason Harmening wrote: 1. app-text/ghostscript (espgs) segfaults on about half the postscript files that are given to it. dmesg output is as follows: WFM 2. After doing an ACCEPT_KEYWORDS=~amd64 emerge -u world earlier this week, ~amd64 isn't guaranteed to be stable. I don't see any reason to use it for an entire system... But now when I try to emerge arts, I get an error indicating that simple C++ files cannot be compiled. Here are the relevant contents of Would this be a problem with the gcc/g++ installation, or with the arts configuration? Arts (the same version) had previously built fine for me with gcc 3.4.2, but I need to remerge it in order to link it with libogg/libvorbis. Not related to the problem you are having, but don't expect to be able to compile KDE with the more recent Gentoo revisions of GCC. They enable a broken backport of the visibility stuff which breaks KDE. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: KDE 3.4.0_beta1
On Thursday 10 February 2005 03:51, Mark Constable wrote:
Luke-Jr wrote:
mkdir -p /etc/portage
for d in /usr/portage/kde-base/*; do
pkg=${d/\/usr\/portage\//};
echo ${pkg} ~x86 x86 /etc/portage/package.keywords
echo ${pkg} /etc/portage/package.unmask
done
That should work on any arch, though it will make a technically invalid
package.keywords file. It will work perfectly fine, though. :)
Spot on, thank you :-)
# ACCEPT_KEYWORDS=~amd64 emerge kde -p
You don't need ACCEPT_KEYWORDS=~amd64 in there after you run that...
Suggestion: emerge -vp kde-meta
--
Luke-Jr
Developer, Utopios
http://utopios.org/
--
gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Making Radeon 8500 Work
On Saturday 05 February 2005 12:59 am, Mike Melanson wrote: btw - the 8500 will work without Ati's binary drivers. The 3D won't be as fast, but it will work. As long as the Xv works, I would be very happy. As my email address implies, I am heavy into multimedia development, particularly on Unix (xine and FFmpeg). Xv should work fine without any immoral/proprietary software/drivers with any nVidia or ATi cards. -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: warning for sun-jdk 1.5.0.01 sandbox
On Fri, January 28, 2005 6:39 am, Duncan said: Dylan Carlson posted [EMAIL PROTECTED], excerpted below, on Fri, 28 Jan 2005 06:40:07 -0500: This is because the installer for sun-jdk tries to access /dev/random which violates the sandbox. So, the solution is to emerge sun-jdk without using the sandbox feature. e.g. FEATURES=-sandbox emerge -v sun-jdk That's correct, but sandbox is after all a security related feature, and some of us simply don't like the idea of giving an emerge carte blanche, as root no less, during the compile phase. What if something is wrong and it deletes all of /bin ? (I once had a Mandrake Cooker RPM do something like this. Luckily, I had a copy of that dir recently backed up under a different name, and was able to use absolute path commands to get back up.) Actually, sandbox is more of a precaution for bugs than a security feature. If someone wants to bypass sandbox, all they need to do to bypass it is to ignore the preloaded library, either by manually getting the function out of the libc (dlopen, dlsym; should be compatible with all systems/kernels) or by making the kernel calls directly (specific to whatever kernel the code is designed for). -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] Re: Re: Installing 32 bit?
On Wed, January 26, 2005 1:58 pm, [EMAIL PROTECTED] said: Luke-Jr [EMAIL PROTECTED] wrote: I don't care that x86_64 CPUs are compatible with x86. If the price range was the same for a non-x86-based 64-bit CPU, I would have gone with that. I chose x86_64 for its price, not compatibility. Good for you. Then you won't mind putting up with the 32-bit support you get with the lower cost. If it weren't for the overhead of 32-bit libraries, no, I wouldn't mind. But I don't have the disk space to have two copies of every library on my system... I'm a home computer user and the pure 64-bit approach has turned out, in practice, to be a PITA, because it is too dogmatic about the 64-bit aspect. How is that? I am using a pure 64-bit system perfectly fine. No complaints so far. If it's a PITA for me, it isn't less so because it's no PITA for you. One of the problems for me is that Unicon (unicon.org) is not yet supported on AMD64. There is limited support behind the scenes, but only because I wrote it, and it doesn't keep up with the CVS, and it doesn't support hardened gcc. Unicon is all GPL, LGPL, and public domain material, so this has nothing at all to do with proprietary vs. free software. A single program is no real reason to keep 32-bit versions of all your libraries... Perhaps the ones it uses, but not all of them. -- gentoo-amd64@gentoo.org mailing list
Re: [gentoo-amd64] 64-bit Broadcom wireless works!
On Sunday 23 January 2005 2:50 am, [EMAIL PROTECTED] wrote: x86_64 is now supported with ndiswrapper-1.03-rc3. This means there's finally a way to get Broadcom wireless adapters working. Why would anyone buy these, I wonder? I can understand Airport Express coming in Macs, but that would be PPC, not x86_64... Follow instructions at: http://ndiswrapper.sourceforge.net/phpwiki/index.php?Installation (be sure CONFIG_NET_RADIO=y is compiled into the kernel) ...or just emerge Cardoe's ebuild from http://dev.gentoo.org/~cardoe/ndiswrapper-1.0_rc3.ebuild -- Luke-Jr Developer, Utopios http://utopios.org/ -- gentoo-amd64@gentoo.org mailing list
