Re: [gentoo-amd64] win32codecs on AMD64?
le Thu, 14 Jun 2007 05:58:45 -0400 B. Nice [EMAIL PROTECTED] a écrit: On Wed, 2007-06-13 at 19:26 -0700, Mark Knecht wrote: If you're not married to the idea of using mplayer, vlc works well on an amd64 and plays pretty much every file format I've ever come across. I haven't installed any binary packages, so I'm fairly certain it's 64bit. It _is_ 64 bits. Besides, vlc can use your hardware acceleration chipsets, whereas mplayer can't (it's a software-rendering player). And confirming what you mention, I was surprised to notice that vlc can play wma and such without the need for win32codecs. The only thing I'm using mplayer for, is re-encoding tecplot's avi exports, which don't seem to work with vlc. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Re: Baselayout 2 (Was: Sun and GPL)
le Tue, 29 May 2007 21:38:17 -0700 Wil Reichert [EMAIL PROTECTED] a écrit: On 5/29/07, Joshua Hoblitt [EMAIL PROTECTED] wrote: On Wed, May 30, 2007 at 02:33:18AM +0200, Florian D. wrote: FYI, genkernel is creating an initrd, not an initramfs, which is the preferred way nowadays. Information on how to setup an initramfs can be found at: http://lldn.timesys.com/docs/initramfs Umm, I think you need to check your facts. genkernel creates a gzip'd CPIO archive named initramfs-genkernel-arch-versionstring... So the command 'genkernel initrd' creates a file called 'initramfs-...' which contains files called etc/initrd.defaults and etc/initrd.scripts. Poor naming conventions but it looks like an initrd to me. I'm afraid it isn't. Try zcat initramfs | cpio -t . initramfs are cpio archives. And genkenrel is such a wild beast, that it compiles a static busybox against uclibc _if_ you have an uclibc toolchain available for your arch through crossdev (this feature really impresses me). If I'm not wrong, when you haven't got any such toolchain, it uses a prebuilt version of busybox. Those informations were gathered empirically by using genkernel. Could someone confirm/infirm/precise? -- [EMAIL PROTECTED] mailing list
[gentoo-amd64] Sun and GPL
le Sun, 27 May 2007 08:48:11 +0200 Joerg Gollnick [EMAIL PROTECTED] a écrit: [ Sujet: Re: [gentoo-amd64] Can I run a complete desktop remotely? ] If you access a remote machine on a regular base outside the LAN, you have the choice: open source solutions VNC and FreeNX or closed source solution (Sun Global Desktop / Citrix ...). I've heard that Sun recently released the Java platform under GPL, and that all of their softs are going to follow in a near future. I've synced portage 2 days ago and dev-java/sun-jre-bin is still licensed against dlj-1.1 . Does anybody know how long it can take to have the license changed? Will it change at the occasion of a new release or is it applicable with the current version? Does it mean we'll have a 64-bit java web browser plugin some day? $ eselect java-nsplugin list Available 32-bit Java browser plugins [1] emul-linux-x86-java-1.5 current Available 64-bit Java browser plugins -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Re: Sun and GPL
le Sun, 27 May 2007 23:32:49 + (UTC) Duncan [EMAIL PROTECTED] a écrit: Not necessarily (or likely) /all/ their software, but significant parts of it. OpenSolaris is currently CDDL, which /is/ OSI approved as a real open license, but was designed in part deliberately to be GPLv2 incompatible. Apparently, they weren't interested in Linux stealing their technologies, which they thought would happen if they made it GPLv2 compatible. Solaris' dev team had diverging points of view about GPL being relevant for a private firm as Sun. Now it looks like there was room for a single conception over there. They ARE considering dual-licensing Solaris under GPLv3, however, which they've been working closely with the FSF on. Of course that's not a given until it's out, but it'd definitely widen the interest base (I for one may well be interested, especially if Linux stays GPLv2 only). You mean the bare kernel, right? Solaris' kernel could be an alternative to linux? Is the latter really different from the *BSD's? I've installed a NetBSD on my machine for fun recently (tho I switched back to using my good'ol gentoo, can't get used to anything else now. pkgsrc looks like a sympathetic old auntie); it appears to practice monolithic kernel. What would be different in running a GPLv3 kernel? I've read about the anti-DRM part of it; is there some other reason you/we could be interested in it? BTW isn't there a technical issue licensing a single version of a soft against two incompatible licenses? Or did you mean dual-licensing GPLv2 and GPLv3? Of course Linus and the other kernel devs were originally very much against early GPLv3 drafts. Is it a matter of diverging positions towards industrial partners/users? The Gentoo Java devs are working on it, but as I said, I don't believe enough of the entire Java infrastructure has been released as GPL yet to do the entire thing as sources. Even after it has, it'll take several months as experimental ebuilds in the Java overlay (emerge layman and read up on using it, if interested) Ok! Does anyone know the difference between the java-overlay and the java-gcj-overlay? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] test
le Thu, 24 May 2007 07:48:14 -0500 Mike Bonar [EMAIL PROTECTED] a écrit: Okay, I'm testing...now what? Good question. What are you actually testing? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] UNSUBSCRIBE
2007/5/22, Dustin J. Mitchell [EMAIL PROTECTED]: I missed my cue this time, sorry. The instructions *are* fairly long -- maybe we should build an eunsubscribe tool, or add a wiki page to explain how to read the documentation? The eunsubscribe tool idea seems funny _ quite gentooish. The wiki documentation howto isn't a bad idea in my opinion, seriously.
Re: [gentoo-amd64] chipset temperatures?
le Sun, 8 Apr 2007 15:42:49 -0700 Mark Knecht [EMAIL PROTECTED] a écrit: Hi, I have an Asus A8N-E motherboard which had a motherboard chipset fan go bad yesterday. After doing some reading I found many folks have had this same problem and switched successfully to Zalman passive heat sinks so I did the same thing today. The machine has been up for about 4 hours with no problems. So far so good My question is how can I monitor chipset temp from my my desktop to watch this for awhile? If I drop into BIOS I see a temperature listed and had to turn off boot time warnings about the chipset fan going to slow so it seems the BIOS knows what's going on. Is there a way for me to do this in Gnome? Thanks in advance, Mark Try sys-apps/lm_sensors and gnome-extra/hardware-monitor . You'll find more info at http://gentoo-wiki.com/HARDWARE_Sensors -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Gentoo crashing?
le Wed, 16 May 2007 01:03:42 +0200 Hemmann, Volker Armin [EMAIL PROTECTED] a écrit: Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, why are you building the nvidiafb crap in the first place? As far as I remember, I used the default genkernel. Now in fact, and though stated differently on NVIDIA_HOWTO , nvidia LKM works fine here even with nvidiafb loaded. It's just that I have no framebuffer functionality. To stick to the subject: (Why was his gentoo crashing all of a sudden?) this Kernel hacking option seems to be enabled by default by genkernel. It caused my brother's dual core machine to turn into a black screen under X: Linux Kernel v2.6.20-gentoo-r8 Configuration ── ┌── Detect Soft Lockups ──┐ │ CONFIG_DETECT_SOFTLOCKUP: Say Y here to enable the kernel to detect soft lockups, which are bugs that cause the kernel to loop in kernel mode for more than 10 seconds, without giving other tasks a chance to run. │ When a soft-lockup is detected, the kernel will print the current stack trace (which you should report), but the system will stay locked up. This feature has negligible overhead. (Note that hard lockups are separate type of bugs that can be detected via the NMI-watchdog, on platforms that support it.) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Gentoo crashing?
le Tue, 15 May 2007 08:57:01 -0400 Peter Davoust [EMAIL PROTECTED] a écrit: Ok, I thought I had turned it to plain text, but gmail is obsessive about these things. Ok, so I haven't tried with acpi off. My brother's computer (intel dual core, as far as I remember) used to hang up randomly when used with acpi. He also had a problem with the preemption option inkernel, leading to hang-ups. But those issues had nothing to do with loading X. I'll have a glance at gmail's options next time I use the web interface; sorry for the inconvenience if the [ originally text ] message gets blown as html. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Re: Gentoo crashing?
le Tue, 15 May 2007 11:06:23 + (UTC) Duncan [EMAIL PROTECTED] a écrit: Peter Davoust [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 14 May 2007 17:08:42 -0400: things, and see how it goes. brbr-Peterbrbrdivspan class=gmail_quoteOn 5/14/07, b class=gmail_sendernamea href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a/b lt;a FWIW, I was trying to ignore this, but after multiple posts, it's becoming difficult to do so. Please kill the HTML. While your at it, top posting isn't so great either, but it's not the security issue that HTML posting can be, so killing the HTML is the big thing. It seems my messages get transformed to have both text/plain and text/html bodies. Is this what you receive from me? Does it bother? -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Gentoo crashing?
le Tue, 15 May 2007 19:58:40 +0100 Antoine Martin [EMAIL PROTECTED] a écrit: Try running a later or earlier driver, if it's an nvidia or ati. If it's not then you'll need to try a different version of Xorg. IIRC, there are issues with nvidia and framebuffer modes. Try booting with vga=normal on the kernel command line. Antoine Yes, I use nvidia-drivers and udev keeps loading the nvidiafb LKM, which doesn't work since we've been presented. I even tried to update udev rules, moving the nvidia* rule to nvidia, so that it would only load the private firmware, but in vain. Florent -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] GDM hates me
Sorry for the misunderstanding, I had only read the first mail of the topic, and far too quickly. That'll learn me not to trust in my sudden enthusiasm (and to use my mail reader!). On Sun, 13 May 2007 20:09:55 -0400 Peter Davoust [EMAIL PROTECTED] wrote: No, I'm not new to Gentoo, I've just been switching back and forth for a while, although I always appreciate some verbose instructions. Now X and gnome have begun working, I'm just dealing with some other problems. -Peter -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Re: Gentoo crashing?
Very interesting post! Could you explain what mobo means? And BTW (_almost_ off-topic...) I've heard that RAM sticks should be identical when plugged on the same motherboard, but it was some good vendor advice so I'd rather rely on some experienced user's answer. So is there an issue if two RAM sticks of different brands are plugged on the same motherboard? What if, whilst of the same brand, they don't have the same capacity? Could Peter's issue be related to this kind of problem? On Mon, 14 May 2007 10:50:31 + (UTC) Duncan [EMAIL PROTECTED] wrote: Peter Davoust [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Mon, 14 May 2007 02:04:30 -0400: I agree, it could be the heat, and that was the first thing that came to my mind, but Vista boots and runs for long periods of time with no issues. I'll check it out with the new kernel in the morning and see what it does. Note that Gentoo tends to use hardware to its limits rather more than most OSs, MSWormOS and other Linux distributions alike. Vista is so new, and /does/ stress at least the video hardware rather more (if aero is on, anyway), so I don't know if anyone can rightly say with it, but certainly with older MS platforms, it hasn't been uncommon at /all/ for Gentoo to cause problems where MS didn't, and even other Linux distributions didn't. Part of the reason is that Gentoo tends to be compiled/optimized for the specific CPU it's running on, so it makes more efficient use of it, including use of functionality distributions (and MS) compiled for use on generic hardware simply don't use, plus simply the fact that when the CPU is busy, it's often getting more done in the same time, so it IS working harder and therefore stressing out the hardware more. Anyway, just because another OS doesn't have problems on a computer doesn't mean Gentoo won't, and there are quite a number of folks on the forums and on the gentoo-user list that will tell you the same thing -- learned from hard experience. Meanwhile, you mention specifically that one of the crashes was during a bz2 decompress. As someone who has HAD memory issues in the past, I can DEFINITELY tell you that bz2 DOES often trigger memory errors, if ANYTHING will! If the issues with BZ2 turn out to be common, CHECK THAT MEMORY, and check it again! You mentioned you have 2 gigs. Hopefully it's in the form of 2 or more sticks. If so, you should be able to take part of it out and see if the problem persists. Then test the other memory. If the problem happens with one set but not the other, you have your problem. Do note, however, that just because the problem continues to occur with either memory set doesn't necessarily mean it's not the memory, particularly if they are the same brand and size, purchased from the same place at the same time, so are likely in the same lot. In my case, I had purchased generic memory that couldn't quite do its rated pc3200 (clock at 200 MHz x 2, since it was DDR). I ran memtest and it passed with flying colors, because the memory worked fine, and memtest apparently doesn't really stress the memory timings, only testing the memory cells. However, I was crashing in operation, sometimes just the app, sometimes the entire kernel would panic. I turned on the kernel's MCE (machine check exception) reporting, and the memory was indeed the problem (google MCEs, there's an app available that you can run, feeding it the numbers, and it'll spit out the error in English), only wasn't quite sure whether it was the memory itself, or the mobo, causing perfectly good memory to generate errors upon data delivery because it couldn't reliably get the data to the CPU. While I didn't have the necessary BIOS settings at the time, sometime later a BIOS update gave me additional memory settings, and I found that reducing the memory timings by a single notch, to 183 MHz (DDR doubled to 366), effectively PC3000 memory, did the trick. I was even able to tweak some of the individual wait-state settings to get back a bit of the performance I lost with the under-clocking. The memory and entire machine was rock-stable at the 183 MHz PC3000 memory setting. Later I upgraded from my then two 512 MB sticks to four 2 GB sticks, 8 gigs memory total. It was indeed the memory, not the board, as the new memory was just as stable at PC3200 as the old memory had been at the under-clocked PC3000 speed. Anyway, the way bzip2 works is apparently extremely stressful on memory, as more than anything else, that would trigger the errors. Compiles were frustrating too, but sometimes I could compile for quite some time without issues. That's why I didn't think it was the CPUs even before I got the program to read the MCE numbers and tell me what they were. They confirmed, it was memory related, the errors were on data as the CPU got it. I just didn't know
Re: [gentoo-amd64] GDM hates me
I assume you're quite new to gentoo, so I'll be as verbose as I can. Ask for more if you need some. I have always experienced troubles with X at startup on fresh installs, whatever distro I use (mainly Debian and Gentoo, and a bit of NetBSD). And if gdm is running at boot, there's no access to the whole boot log on tty1. I know it lies somewhere, but I don't want it printed on screen just for fun. For these reasons, I never use gdm by default. To fix your problem, I would disable it the following way: - boot with a livecd of any kind. - mount your gentoo root and chroot into it. - source /etc/profile env-update - rc-update del xdm default - reboot your system. Once you've rebooted, you can try to launch an x session customizing ~/.xinitrc and using startx . If that doesn't work you probably have a misconfigured /etc/X11/xorg.conf . You could generate a sample one with X -configure . The web page http://gentoo-wiki.com/Xorg is worth a glance in this neverending quest. When it does work you can issue a /etc/init.d/xdm start . -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] adding arcmsr support to the initramfs image
On Thu, 5 Apr 2007 11:51:51 -1000 Joshua Hoblitt [EMAIL PROTECTED] wrote: What is the right way to add kernel modules to the initramfs image? I like I'm doing something slightly dirty by editing /usr/share/genkernel/x86_64/modules_load to add the arcmsr module. -J -- Same for me using aufs module. -- gentoo-amd64@gentoo.org mailing list
