Re: [gentoo-amd64] qt compile problem
On Wed, Aug 15, 2007 at 09:55:37AM -0400, Richard Freeman wrote: I must admit that revdep-rebuild is one of gentoo's weak points. Ideally non-security bumps would just leave the old so intact and then there would be a better mechanism (ie faster and more reliable) for updating packages that depend on it in the proper order (order might not even matter as much with the old so still around). Then the old so would removed only once it was no longer needed. A database of so dependencies would probably make this work if it were tied in with portage's database of package dependencies, but I won't suggest that this is a trivial task (which is probably why it hasn't been done yet). It's worth noting that RPM tries to do this -- when an RPM is built, all .so's that its binaries link against are listed as deps. I wouldn't say RPM's gotten it right, either. It doesn't help that lots of software doesn't do shared object versioning right :( Dustin -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] 32 or 64 for web server and mysql
On Fri, Jul 20, 2007 at 09:21:10PM +0800, P.V.Anthony wrote: The reason for this questions is that there are some information on the net that says that there is no much difference between them. Is that true? Thought that 64bit is always better. Building a system 64-bit buys you: - wider integers (so math with 64-bit integers is faster) - wider pointers (so an application can have a *lot* more address space allocated to it) - bigger binaries and data structures (so more RAM consumed) - future-proofing (in a few years, 32-bit hardware will not be available new) There's no better and it's not inherently faster in any way. As another poster said, most UNIX apps have been running 64-bit on other architectures (SPARC being the most common) for years, so compatibility isn't a big deal. Those are the points on which I base my 32/64 decisions. Dustin -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] how to best run a script at boot
On Sun, Jul 15, 2007 at 01:36:57PM +0300, Daniel Iliev wrote: AFAIK the places intended for that purpose are /etc/conf.d/local.start and /etc/conf.d/local.stop for starting and stopping custom programs at boot and shut down time respectively. So, you may want to put that line in /etc/conf.d/local.start As an example, I used this once upon a time to tune my ethernet adapter's settings (with mii-tool), since autoneg wasn't working with the switch it was on. Dustin -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64]
On Fri, Jul 06, 2007 at 09:02:05AM -0400, B. Nice wrote: I also feel a little guilty that my only contribution as an AT is to make fun of people trying to unsubscribe from the list. It's not exactly productive, and only serves to reinforce the bad rep that Gentoo has. Where do people get the idea that Gentoo has a bad reputation? I've Well, keep in mind that I run in what is probably a slightly different circle -- server admins. Gentoo has a *lot* to recommend it technically for administering a server -- fine-grained control, careful management of the upgrade path, transparency, extensibility, etc. But the cultural shift is painful when folks like me try to interact with the Gentoo user or developer community. I think I'm a fairly technically adept person (hey, I passed the ebuild quiz), yet several of my bugs have been blown off fairly rudely, by developers who had obviously not read the entire bug. Of course, interactions on IRC are even worse. The result is that I don't file bugs anymore -- I make a fixed local copy of the ebuild and call it a day. Since I can't recommend that my clients and employers do the same, I set them up with a RedHat-derived base system and then hand-compile the necessary software on top of that. By way of comparison, problems I have had with specific pieces of business-critical software (vs. with the distro) have been handled with professionalism and dignity. Maybe the problem is that Gentoo devs are *too* accessible, and aren't really given a choice in the matter. Does e.g., https://bugzilla.novell.com/ see the same level of activity as Gentoo's? I imagine that a lot of the grumpy devs would probably do well just sitting in the background and coding. Those are my musings.. Dustin P.S. I should add that the amd64 group does not seem to share these difficutlies -- this list is sometimes irreverent, but never insulting. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64]
On Thu, Jul 05, 2007 at 04:02:00PM -1000, Joshua Hoblitt wrote: [EMAIL PROTECTED] Cc: Bcc: Subject: Re: [gentoo-amd64] unsubscribe Reply-To: In-Reply-To: [EMAIL PROTECTED] Ahem... I think you missed your queue. Sorry -- I hadn't had my coffee yet. I also feel a little guilty that my only contribution as an AT is to make fun of people trying to unsubscribe from the list. It's not exactly productive, and only serves to reinforce the bad rep that Gentoo has. Dustin -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Time Drift
On Fri, Jun 08, 2007 at 10:38:00PM -0400, Richard Freeman wrote: I just noticed that my time was off and after checking the logs I saw that ntpd was adjusting the time by 5 minutes several times a day for the last month. Searching around I found some hints that disabling apic might help. This is on a K8V deluxe motherboard and running 2.6.20-r7. Before I disable apic, will this have any negative effects on the system? This is a desktop system so I don't really care about power-saving features (although I'd like to keep cpudyn working if possible). I'm also running ivtv (mythtv backend) which apparently can cause clock skew due to some kind of DMA error, but I'm not seeing that in the logs. Any advice? First, in general, both openntpd and ntpd are cranky little beasties. For a service that should be as basic and reliable as, say, ssh, an NTP installation requires a tremendous amount of ongoing TLC -- daemons randomly die or get wedged, or just fail to update the time correctly. Sometimes they actively skew a machine's time off. Second, the worst problems I ever saw with NTP weren't actually NTP's fault. I had a box which lost 15m/day, and (surprise surprise) NTP couldn't keep up and kept erroring out. It was an amd64 box that was (for reasons unbeknownst to me) installed x86, which I thought was the problem. Turns out it was bad RAM. The box ran for months as a postgresql server using that RAM, but NTP? No-can-do. Go figure. Dustin -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] System crashes when idle
On Tue, May 29, 2007 at 08:42:10AM +0100, Peter Humphrey wrote: A couple. Either RAM or hard disk would be my first suspect. You can check the RAM best by compiling any large package, such as gcc itself. Memtest and its like can only find the most obvious faults and in my opinion aren't worth their salt - if they can find a fault, it will already be obvious to you. FWIW, their value is in finding that the fault is with RAM, not with anything else. Compiling isn't going to narrow down the problem beyond yep, the computer's broken :) That said, that this happens when the system is quiet suggests it's not the HD. Dustin -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] test
Everyone's patience? ;) On Thu, May 24, 2007 at 04:04:33PM +0200, Isidore Ducasse wrote: 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 -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] UNSUBSCRIBE
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? --- Here's how to unsubscribe: First, ask your Internet Provider to mail you an Unsubscribing Kit. Then follow these directions. The kit will most likely be the standard no-fault type. Depending on requirements, System A and/or System B can be used. When operating System A, depress lever and a plastic dalkron unsubscriber will be dispensed through the slot immediately underneath. When you have fastened the adhesive lip, attach connection marked by the large X outlet hose. Twist the silver-coloured ring one inch below the connection point until you feel it lock. The kit is now ready for use. The Cin-Eliminator is activated by the small switch on the lip. When securing, twist the ring back to its initial condition, so that the two orange lines meet. Disconnect. Place the dalkron unsubscriber in the vacuum receptacle to the rear. Activate by pressing the blue button. The controls for System B are located on the opposite side. The red release switch places the Cin-Eliminator into position; it can be adjusted manually up or down by pressing the blue manual release button. The opening is self-adjusting. To secure after use, press the green button, which simultaneously activates the evaporator and returns the Cin-Eliminator to its storage position. You may log off if the green exit light is on over the evaporator. If the red light is illuminated, one of the Cin-Eliminator requirements has not been properly implemented. Press the List Guy call button on the right of the evaporator. He will secure all facilities from his control panel. To use the Auto-Unsub, first undress and place all your clothes in the clothes rack. Put on the velcro slippers located in the cabinet immediately below. Enter the shower, taking the entire kit with you. On the control panel to your upper right upon entering you will see a Shower seal button. Press to activate. A green light will then be illuminated immediately below. On the intensity knob, select the desired setting. Now depress the Auto-Unsub activation lever. Bathe normally. The Auto-Unsub will automatically go off after three minutes unless you activate the Manual off override switch by flipping it up. When you are ready to leave, press the blue Shower seal release button. The door will open and you may leave. Please remove the velcro slippers and place them in their container. If you prefer the ultrasonic log-off mode, press the indicated blue button. When the twin panels open, pull forward by rings A B. The knob to the left, just below the blue light, has three settings, low, medium or high. For normal use, the medium setting is suggested. After these settings have been made, you can activate the device by switching to the ON position the clearly marked red switch. If during the unsubscribing operation you wish to change the settings, place the manual off override switch in the OFF position. You may now make the change and repeat the cycle. When the green exit light goes on, you may log off and have lunch. Please close the door behind you. --- Dustin On Mon, May 21, 2007 at 08:39:35PM -0400, me wrote: Did they ever? - Mac On Monday 21 May 2007 10:09 am, Mark Haney wrote: NiQoZ wrote: Doesn't ANYONE read the unsubscribe options anymore? -- Mark Haney Sr. Systems Administrator ERC Broadband -- [EMAIL PROTECTED] mailing list -- [EMAIL PROTECTED] mailing list
Re: [gentoo-amd64] Can't build kernel
Really, this is hard to read. Part of the problem is HTML mail, coupled with using HTML attributes for quoting that don't show up in text. I'm not which of htese paragraphs David wrote, and which somebody else wrote (since there's no quote attribution either). This isn't a Windows Vista Home Edition support forum. Let's stick with text in email, eh? Dustin On Sun, May 20, 2007 at 10:04:10PM -0700, Peter Hoff wrote: - Original Message From: david [EMAIL PROTECTED] To: gentoo-amd64@lists.gentoo.org Sent: Sunday, May 20, 2007 3:21:17 PM Subject: Re: [gentoo-amd64] Can't build kernel Here is a working kernel .config for a nforce 550. I have to use acpi=off also. I left the acpi stuff in there though. [1]http://abbottdavid.com/pictures/config Cool, thank you. I'll give it a try when I get home tomorrow. I notice you have ac97 in there. Is the on board sound working now? References 1. http://abbottdavid.com/pictures/config -- [EMAIL PROTECTED] mailing list
