Re: Kernel panics on new machine
Rob Klingsten wrote: Hi folks, I am over my head here with kernel panics... I've got a shiny new system: Tyan S2865 (nforce 4 ultra), AMD Athlon x2 3800+, a single SATA-2 drive and 1gb of DDR400 RAM. The board and CPU are brand new, the drive and RAM came from a desktop machine which I had no problems with so I think those things are ok. Does the motherboard require the RAM modules to be in pairs? If so, are they? The usual warnings about seating of modules and cables also apply. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel panics on new machine
Rob Klingsten wrote: Yes, I have the DIMMs in banks 1 and 2 out of 4 and I've removed and reseated them; I have swapped out the SATA cable, there are no PCI or PCI Express cards (system is headless.) And it looks like it was just that easy; I pulled one DIMM and ran the system on a single 512, problem gone; I wrote out 3 separate 100gb files without incident. It makes no sense to me as the RAM was fine in the other system, I never had problems. Oh well, guess I'm getting new RAM. thanks, sorry to trouble the list with such a trivial thing. Rob Well ... if you've got the cash, go get four 1 GB DIMMs. Athlon64 X2s work very well with 4 GB of RAM. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 X2
Lennart Sorensen wrote: On Thu, Jun 28, 2007 at 04:51:17PM +0200, Daniel Tryba wrote: If Ed in this thread is correct that the svm flag in /proc/cpuinfo indicates Pacifica, then the Turion64 X2 TL-52 (1.6Ghz) has it (also there is a flag in the bios on this machine). Oh right. I forgot they went from Mobile Athlon 64 to Turion 64. It appears from what I can find that all Turion 64 X2's have virtualization (some of the none X2's have it too, but not all of them). -- Len Sorensen Yes ... I looked at Turion 64 dual-core laptops briefly before buying the desktop Athlon64 X2. There were some Turion 64 dual cores without the virtualization assist, but I think they all have it now. The main reason I didn't get a laptop is that I wanted a reasonable price for 4 GB of RAM and a fast hard drive, not because of the processors. :) Besides, I think my next laptop will be a Mac because that's what most of the Ruby geeks use. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: AMD 64 X2
[EMAIL PROTECTED] wrote: hello, I want to buy a new system with an AMD64 X2, as I want to try virtualization I need to know what kind of processor contains the Pacifica (now AMD-V) set of instructions. Does anybody have any information about that as the documents I have found are not crystal clear. Regards Storm66 If the system you want has been assembled, just get a LiveCD with a recent kernel, boot it up and look at /proc/cpuinfo. I just got (late March) an Athlon64 X2 4200+ at CompUsa and it does have the magic virtualization stuff (the svm in flags is the gimmick, IIRC). This is what mine looks like with a 2.6.21 kernel: processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping: 2 cpu MHz : 2210.046 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 4422.77 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Douglas Allan Tutty wrote: I meant the whole shebang. I don't mean to distribute it. More of a massive benchmark to compare the gcc with the best commercial compiler and see what difference it made to applications we use all the time. It would be interesting to do this for both 32-bit and 64-bit. Since 32-bit gcc is quite mature it could provide some insight into how to make it better. We have the technology. :) Part of the charm of gcc is that it has multiple targets, multiple source languages, is extremely well documents, and can be used as a cross-compiler. On top of that it supports language-level application coverage analysis and profiling. I suspect that the language-independent and target hardware independent parts of gcc are as good as they can be, given the constraints imposed by such things as NP-completeness for a lot of the guts of compile-time optimization. And given the trend towards dynamic languages like Perl, Python, JavaScript, Ruby and the bastard cousin of Perl called PHP, the focus of the open source communities seems to be on making *them* run more efficiently -- gcc is good enough for a Ruby interpreter, a Python bytecode interpreter, etc. But not, apparently, good enough for the Parrot virtual machine -- aren't they using Haskell? In any event, for most of the Intel chips (Pentium MMX and later) and the AMD64 chips (*before* Barcelona, I think) the resources at http://www.agner.org/optimize are freely available and can help both compiler writers and compiler users if they don't have the budget for a chip-specific compiler. As for debian's free software roots, as a comparison, even OpenBSD which rants against the GPL at any opportunity still uses gcc since there's no other alternative; they're too small to be able to make a bsdcc. Speaking of which, another bit of nostalgia. I was a happy Red Hat 9 user when Red Hat announced there would not be a Red Hat 10. So I went and looked at all the distros. I ended up on Debian for a number of reasons: 1. The primary application I had in mind was algorithmic composition and synthesis of music. Most of the projects used either Red Hat or Debian, and since I had ruled out Red Hat, Debian was the logical choice. 2. I was also interested in alternative kernels, and the Gnu Hurd kernel was hosted by Debian 3. The size of the repositories: Woody (stable at the time) had something like 8 or 9 thousand packages, and Sarge had something like 15 thousand. After about six months, though, it looked like the Hurd was a dead project. It depended on specific technologies that weren't active, and there were a number of more interesting and more active kernel research projects, like the Dresden Real-Time Operating System (DROPS). Eventually I just got too busy with other projects to pursue alternate kernels, and the Linux kernel's audio-specific pieces were stabilizing and improving rapidly, so I quit pursuing the alternative kernels. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Giacomo Mulas wrote: Two or three months, when I last compiled the latest version of the big quantum chemistry code (NWChem) I use (which spends a lot of time doing floating point linear algebra). The computer on which I tested is a relatively old Athlon 64 3500+, your mileage may vary on other machines. Oddly enough, an old version of GOTO was the fastest, followed closely by the optimised acml, then head to head the internal implementation provided by the quantum chemistry package and the (then) current GOTO, then atlas. Differences among all but atlas were measurable (i.e. reproducible) but very small, within 2%, atlas was ~10% slower. The Intel compilers produced much faster code than the gcc suite (both 3.4 and 4.1), despite running on AMD processors. This is a VERY specific test, of course, so I do not claim my conclusions should apply to anyone but me. On the other hand, they do apply rather well to my scenario by definition :) I used to do this stuff (tune quantum chemistry codes) for a living. Nostalgia ain't what it used to be. :) The only one I spent any great length of time on was Gaussian (80 way back then) and it proved extremely difficult to vectorize and parallelize, despite the efforts of the developers to make it work well on such beasts as the CDC 205, which had very deep pipelines. If NWChem is anything like that, I'm not surprised the Intel compilers do a better job than GCC -- I don't think GCC knows much about all the specifics of tweaking such things as keeping data in caches, re-use, chip-level parallelism, etc. If NWChem is open source, I'm sure someone will come along and profile/tweak it. I will obviously evaluate again atlas and new versions of the gcc suite if/when it's worth the effort. I look forward seeing an up-to-date version of atlas being included in debian. I would actually be very glad to be able to switch to a completely clean environment using gcc, since I currently have to keep around hosts of libraries compiled with different compilers and it's somewhat messy to maintain. I wouldn't throw away that Intel compiler just yet. For that matter, I'd give serious consideration to switching to a Core 2 Duo and a copy of Intel's tuning tools ... they are quite good. Life's too short to wait for calculations. :) Bye Giacomo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Douglas Allan Tutty wrote: On Fri, Jun 15, 2007 at 06:50:57AM -0700, M. Edward (Ed) Borasky wrote: I wouldn't throw away that Intel compiler just yet. For that matter, I'd give serious consideration to switching to a Core 2 Duo and a copy of Intel's tuning tools ... they are quite good. Life's too short to wait for calculations. :) I don't suppose, for fun, it would be possible to compile debian amd64 on one of the good commercial compilers? Doug. You mean the kernel, or all of the packages, or both? ;) I don't think it would be much fun, given Debian's free software roots. ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Leopold Palomo-Avellaneda wrote: A Dijous 14 Juny 2007 15:21, Lennart Sorensen va escriure: On Wed, Jun 13, 2007 at 04:40:52PM -0600, Sebastian Kuzminsky wrote: Hi folks, I just bought a pair of AMD64 systems for a work project, and I'm confused about the performance I'm getting from them. Both are identically configured Dell Dimension C521 systems, with Athlon 64 X2 3800+ CPUs and 1 GB RAM. On one I installed using the Etch (4.0r0) i386 netinst CD, then upgraded to Lenny. This one's running linux-image-2.6.21-1-686. On the other I installed using the current (as of 2007-06-13) Lenny d-i amd64 snapshot netinst CD. This one's running linux-image-2.6.21-1-amd64. The one with the x86 userspace and 686 kernel is faster than the one with x86_64 userspace and amd64 kernel. The difference is consistently a few percent in favor of x86 over x86_64. My only benchmark is compiling our internal source tree (mostly running gcc, some g++, flex, bison, etc). We're using gcc-4.1 and g++-4.1. I've tried it with a cold disk cache and hot disk cache, in both cases x86 is faster than x86_64. I was expecting a win for 64 bit. What's going on here? 64 bit is faster at some things. For things like gcc you may simply be gaining nothing and loosing a few percent due to having to move around 8 bytes per pointer rather than 4 bytes per pointer. Certainly on sparc64 I believe that is known to cause a slight slow down. On sparc most programs are 32bit I believe, with only a few specific ones that gain from 64bit (like lots of ram) are compiled for 64 bit. Now anything using floating point should gain significantly on 64bit. Of course none of your list of tests do. SSE (the only floating point used on x86_64) is much faster than the old stack based x87 instructions. There are also some programs that gain some performance benefit from the extra registers that you get in 64bit mode, but for most programs it probably doesn't really matter. gcc may also not be very good at using those extra registers yet. Of course if you need more than about 3GB ram in your system, 64bit will probably win simply by avoiding the (not insignificant) overhead of PAE (needed to access more than 4GB address space on x86). Also if a program can take advantage of more than 2 or 3GB ram by itself, on 64bit you can use however much ram you have for the application, while on x86 you are limited to 3GB ram per application. really, reading you makes me doubt about the whole port. How many apps do we have in the debian pool that can win some kind of performance? Regards, Leo Well ... 1. 32-bit isn't going away. The new chips are all going to be 64-bit-capable (and virtualization-capable, multi-core, etc.) but the software is going to lag that. 2. There are two reasons you'd want a 64-bit machine: a. You have a production application that *needs* a 64-bit machine. For the moment, most but not all of those are high-performance scientific computing. b. You want to develop 64-bit applications 3. I've got an Athlon64 X2 (64 bit, dual-core, virtualization capable). I'm running a 64-bit OS (Gentoo, although Etch works just fine on it). I haven't done any 32-bit vs. 64-bit benchmarking or GCC benchmarking on it because quite frankly, I think such efforts are wasted and irrelevant. I got the machine for b. above -- I want to develop 64-bit multi-core virtualization-aware applications. As far as the applications in the Debian pool, or open source in general, are concerned, I would first look at large-scale scientific computing. And I would start with making sure that you have the Atlas (automatically tuned linear algebra subroutines) libraries and their BLAS and LAPACK interfaces all tuned up and ready to install on all the architectures. The ATLAS team is just about ready to release 3.8 -- they are at 3.7.32 at the moment and I think what's in Debian is still 3.6.0. The last test I ran on my Athlon64 X2 4200+ (2.2 GHz) got me about 10 gigaflops in 32-bit arithmetic and about half of that in 64-bit arithmetic. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Lennart Sorensen wrote: On Fri, Jun 15, 2007 at 07:53:44AM +1000, Alex Samad wrote: sounds like a sane thing to do then is to run a amd64 kernel and build your apps in 32 bit mode. They get the advantage of 32 over 64, but you get the advantage of having lots more of them running in your 64 bit kernel ? Well I run a 64bit machine with a 64bit kernel with 32bit user space, and a 64bit chroot. The choice of that setup was because the target of the development runs 32bit x86 code only and 64bit is just to play with. I also haven't seen any 32bit program that is actually faster than 64bit that I have tried lately, so perhaps it is actually 32bit programs that are the exception for good performance rather than the rule. Keep a 32bit chroot for those few programs where 32bit still somehow has better performance, but use 64bit for most things since it seems to be generally the fastest. -- Len Sorensen The strategy the Gentoo devs recommend is to run full 64 bit and have a *32-bit* chroot for those apps which don't work when compiled for a 64-bit architecture. Of course, since most everything in Gentoo is compiled on the user's machine and not pre-compiled like Debian, that strategy might not be optimal for Debian. I have three systems, though, only one of which is 64-bit (and none Intel) ;) so if an app doesn't work on a 64-bit box, I just run it on one of the others. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Giacomo Mulas wrote: On Thu, 14 Jun 2007, Leopold Palomo-Avellaneda wrote: The last test I ran on my Athlon64 X2 4200+ (2.2 GHz) got me about 10 gigaflops in 32-bit arithmetic and about half of that in 64-bit arithmetic. I don't understand that. Are you saying that the 64-bits was really worst tha 32? He is saying that the version distributed by default in debian of the ATLAS linear algebra libraries is much better optimised for performance in the 32 bit version than in the 64 bit version. However, if you are in for speed, you are way better off using a better optimised linear algebra library, such as the GOTO library (hand-optimised assembler written by masatoshi goto), or the acml libraries provided by AMD for AMD processors or the MKML libraries provided by Intel for Intel processors. All of these provide vastly better performance than the current incarnations of ATLAS in 64bit. How recent is your data? I was under the impression that Atlas had caught up with GOTO and ACML, and possibly even the Intel libraries on the Core 2 Duo. I'm on the Atlas mailing list -- I can ask there. In any event, there is enough assembly code in Atlas that I'd expect it to be competitive with both GOTO and the vendor libraries on AMD 64-bit and Intel 64-bit chips. And I think 3.7.32 cleaned out some bottlenecks in the 64-bit SPARC code as well, so it's undoubtedly worthwhile for Debian to put it in the repositories for SPARC at 3.7.32 and probably not for older versions. ATLAS can be expected to improve a lot quickly, but currently is far behind in the 64 bit version. As I noted above, that's not the impression I got. Also, if you are after performance, you should consider using some commercial compiler (if you can afford it) instead of the GCC suite, until GNU compilers become as good at optimising for x86_64 processors as they are for x86. You're probably right here, at least for 4.1 GCC and older. I haven't seen anything on GCC 4.2 yet. If you have an *Intel* chip, you definitely should look at the Intel compilers. They are written by some good folks and neighbors of mine -- I used to work with a couple of them in a galaxy long ago and far away. :) And they have access to all the magic counters on the chip, which as far as I know, isn't even on the GCC road map. Finally, for those of you who love the joy of doing this sort of land speed record chasing, there's an excellent collection of resources at http://www.agner.org/optimize/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Stephen Olander-Waters wrote: On Thu, 2007-06-14 at 16:08 +0200, Leopold Palomo-Avellaneda wrote: really, reading you makes me doubt about the whole port. How many apps do we have in the debian pool that can win some kind of performance? Personally, I don't care. I went 64-bit for *FUN*, not performance, though I am hoping that World Community Grid will port its apps to 64-bit and take advantage of the new registers. Geek out, -s Yeah ... I did it for fun too. :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confused about performance
Leopold Palomo-Avellaneda wrote: A Dijous 14 Juny 2007 16:40, M. Edward (Ed) Borasky va escriure: [...] b. You want to develop 64-bit applications why? you want to develop applications, that they run in a 32 or 64 system it's another thing. Maybe they run better or worst, but the final architecture cannot be a target, I think. Well in my case the fun is developing 64-bit multicore applications and maxing out the machine. I'm not doing this with a profit motive as yet, so I don't have a problem with limiting myself to things that will only run in a 64-bit machine and which are tuned for multicore. [...] As far as the applications in the Debian pool, or open source in general, are concerned, I would first look at large-scale scientific computing. And I would start with making sure that you have the Atlas (automatically tuned linear algebra subroutines) libraries and their BLAS and LAPACK interfaces all tuned up and ready to install on all the architectures. The ATLAS team is just about ready to release 3.8 -- they are at 3.7.32 at the moment and I think what's in Debian is still 3.6.0. ok, but I think that this apps are developed in fortran, and the gfortran is it sufficient developed to make a good difference? Maybe GSL or MTL .. I don't do much FORTRAN and even less C. When I want raw speed I program in Forth, and when I want convenience I use R for number crunching, Perl for quick scripting and Ruby for longer-lived scripting projects. The last test I ran on my Athlon64 X2 4200+ (2.2 GHz) got me about 10 gigaflops in 32-bit arithmetic and about half of that in 64-bit arithmetic. I don't understand that. Are you saying that the 64-bits was really worst than 32? It's natural that 64-bit operations would take longer than 32-bit ones. You're moving and adding/multiplying half the number of bits. That's kind of a cheat, though, because only some signal and image processing operations and some iterative particle-based/simulation models work really well in 32-bit arithmetic. Big matrix jobs require 64-bit arithmetic and sometimes more. But you can do a *lot* of physics, signal processing and image processing with a fast 32-bit floating point unit, so it's a useful thing for at least one class of user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deciding on a new amd64 system
Alexandru Cardaniuc wrote: Hi All! I've been using HP Pavilion zv5260 as a desktop replacement for a while and now decided to get a real desktop. I am not sure if I should build a new box myself or buy a pre-built one. I need a home workstation that is going to be used primarily for writing and debugging code, browsing internet, occasionally watching dvds. I don't edit video and don't play video games. So, I figured that I don't need that powerful and expensive computer. In this case does it make sense to build one myself? I googled and found that Dell offers Dimension n Series E521. http://www.dell.com/content/topics/segtopic.aspx/e510_nseries?c=uscs=19l=ens=dhs~ck=mn It comes with no Windows OS preinstalled. And Dell claims that it is ready to work under linux. Does anybody here have this machine? Are there any compatibility issues? I plan to use it with Debian Etch. Etch comes with linux kernel 2.6.18 Googling I found out about a problem with USB freezing mice and keyboards, but it seems that this problem was solved with BIOS update that Dell issued in January, 2007. Google doesn't show any more problems with it... I am thinking about choosing these parts: - Dell Dimension E521NAMD Athlon 64 X2 Dual-Core 4000+ Operating System: FreeDOS included in the box, ready to install Memory 1GB Dual Channel DDR2 SDRAM at 667MHz- 2DIMMs Dell USB Keyboard and Dell Optical USB Mouse 19 inch SP1908FP Silver Flat Panel Monitor TrueLife (Glossy Screen) 256MB NVIDIA Geforce 7300LE TurboCache Hard Drive 250GB Serial ATA Hard Drive (7200RPM) w/DataBurst Cache No Floppy Drive Included Integrated 10/100 Ethernet Modem 56K PCI Data Fax Modem CD ROM/DVD ROM 16x DVD+/-RW Drive Integrated 7.1 Channel Audio Speakers Dell AS501 10W Flat Panel Attached Spkrs for UltraSharp Flat Panels Limited Warranty, Services and Support Options 1Yr In-Home Service, Parts + Labor - Next Business Day* FREE GROUND SHIPPING! Total Price (taxes included)$757.30 - It seems like the price is right. Before I always built computers myself, but now would I actually be able to build a box myself for this price ? Well, I don't necessarily want cheap, I just don't need a very powerful machine for what I am using it... Any advices or suggestions will be very appreciated! Thanks in advance... I just had a box built at CompUSA. It took me a while to get it up, but it's happily running Linux now. I looked at the Dell Linux-ready systems but ended up with a custom system mostly because 1. I didn't want to wait. 2. The Dell AMD systems didn't include the option to remove the monitor. The Intel systems did, but I wanted AMD. 3. The Dell memory prices were too high. So I ended up with a 4 GB Athlon64 X2 4200+ If you already have a monitor, you could get the low-end Dell Intel Linux-ready system without one and save about $150US, IIRC. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: deciding on a new amd64 system
Lennart Sorensen wrote: On Mon, May 21, 2007 at 11:24:11PM -0700, Alexandru Cardaniuc wrote: Hi All! I've been using HP Pavilion zv5260 as a desktop replacement for a while and now decided to get a real desktop. I am not sure if I should build a new box myself or buy a pre-built one. I need a home workstation that is going to be used primarily for writing and debugging code, browsing internet, occasionally watching dvds. I don't edit video and don't play video games. So, I figured that I don't need that powerful and expensive computer. In this case does it make sense to build one myself? I googled and found that Dell offers Dimension n Series E521. http://www.dell.com/content/topics/segtopic.aspx/e510_nseries?c=uscs=19l=ens=dhs~ck=mn It comes with no Windows OS preinstalled. And Dell claims that it is ready to work under linux. Does anybody here have this machine? Are there any compatibility issues? I plan to use it with Debian Etch. Etch comes with linux kernel 2.6.18 Googling I found out about a problem with USB freezing mice and keyboards, but it seems that this problem was solved with BIOS update that Dell issued in January, 2007. Google doesn't show any more problems with it... I am thinking about choosing these parts: - Dell Dimension E521NAMD Athlon 64 X2 Dual-Core 4000+ Personally at this time I would buy a Core 2 Duo instead. Faster and more efficient. Oh and it's a Dell, so the pwoer supply and mainboard and possibly other things are probably proprietary and never replaceable. And the power supply is probably only barely large enough to handle the system, so upgrades could be tricky. At least that is how Dell Dimension PCs were in the past. Operating System: FreeDOS included in the box, ready to install Memory 1GB Dual Channel DDR2 SDRAM at 667MHz- 2DIMMs Why does Dell (and other rip of the clueless consumer name brands) insist on putting slow ram in machines with fast CPUs? 800MHz ram doesn't cost that much more. I guess they figure their customers only care about price. Dell USB Keyboard and Dell Optical USB Mouse 19 inch SP1908FP Silver Flat Panel Monitor TrueLife (Glossy Screen) 256MB NVIDIA Geforce 7300LE TurboCache And then they slow down the ram some more by making the video card borrow from it. Hard Drive 250GB Serial ATA Hard Drive (7200RPM) w/DataBurst Cache No Floppy Drive Included Integrated 10/100 Ethernet Modem 56K PCI Data Fax Modem CD ROM/DVD ROM 16x DVD+/-RW Drive Integrated 7.1 Channel Audio Speakers Dell AS501 10W Flat Panel Attached Spkrs for UltraSharp Flat Panels Well all that stuff is probably typical. Limited Warranty, Services and Support Options 1Yr In-Home Service, Parts + Labor - Next Business Day* FREE GROUND SHIPPING! Total Price (taxes included)$757.30 - It seems like the price is right. Before I always built computers myself, but now would I actually be able to build a box myself for this price ? Well, I don't necessarily want cheap, I just don't need a very powerful machine for what I am using it... The difficult part in getting a price like Dells is that most people building a computer aren't willing to cut the corners Dell likes to cut. Let us try though: Athlon 64 X2 4000 $122 2 x 512MB DDR2-6400 800MHz OCZ platinum ram $80 Asus M2V mainboard (10/100/1000 ethernet, 5.1 audio) $90 WD 250GB SATA $79 LG 18x DVD+-RW $38 Antec SLK1650 (case with 350W PS) $70 USB mouse/keyboard $30 7300 video card $63 19 LCD screen $200 Total: $772 (canadian) which is about $730 US. Significantly higher quality components than the Dell, but you would have to buy and assemble parts yourself, and you don't get tech support and warrenty (well warrenty on the parts not the system). But overall, Dells price is just OK, not great. Remember the Dell is full of cheap junk which helps them keep the price down. Modem (if you actually need one) which is actually a hardware modem that works with linux is probably $75 or so. Haven't bought one in years. I tend to assume most people don't need it so I will ignore it. I would be surprised if dell included anything other than a winmodem in their system. Personally I would go with spending more on a Core 2 Duo if I was buying one, but I am not at the moment. :) And I would get a 7600GT rather than a 7300, and I would go for a silverstone TJ04-B case and probably a silverstone 450W power supply. And I wouldn't go for less than a 20 screen since I hate 1280x1024 screens, while 20 gives you 1600x1200. Of course those changes would probably add another $500 to the price. -- Len Sorensen Well ... I don't want to get into Intel vs. AMD (until the AMD Quad Cores are out, anyhow) :). But I can't conceive of running a processor that fast in Linux with only a GB of RAM, and I can't conceive of
Re: Problems starting X in a new Athlon 3800+ system
[EMAIL PROTECTED] wrote: Hi. I've been using the latest unstable with a Pentium III for quite a whille now with no problems at all. I decided to upgrade my h/w to an Athlon 3800+ and I thought I could just install the disks from the old system to the new h/w and work from there. The new system, as I said, is an Athlon 3800+ with an ATI Radeon 9200 (from Sapphire). Everything worked just fine until gdm started up. It looks like X will start, but when the screen blanks it just stays that way and I cannot break X or reboot the system with ctrl-alt-del. My old system was running an ATI 128 Rage Pro, but what I did was boot the new system into single user mode and reconfigured 'xserver-xorg' accepting sensible options. The configuration recognized the card and the monitor, etc. But X just doesn't work. At this point, I decided to reinstall using the Debian 4.0 netinst cd thinking that the reinstallation would default to a useful value, but the re-installation has the same problem with X. Does anyone have any suggestions I might follow to get my system back up? Everything works fine in the text console; it's just X that seems to be having problems. BTW, I've tried running a livecd (centos 4.3) and everything works just fine (gdm starts up, etc.). I'd appreciate any help. Thanks -Jose Isn't there a log file -- something like /var/log/Xorg.0.log? Whenever I screw up an X config or something screws it up for me, I usually can get the answer in that log file. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New box crashes
Jack Malmostoso wrote: I've gotten a few traces in /var/log/messages, which I'll post to the appropriate place as soon as I find out what the appropriate place is. If it's kernel related, the LKML is the right place. Yeah ... once I try a 32-bit kernel, that's where I'm going. Etch, Feisty Fawn, Gentoo 2006.1 and CentOS all have similar problems, so it's pretty much got to be either hardware or the upstream 64-bit kernel. In order: 1) Check the memory with memtest for 12+ hours So far it has about five hours with no errors. I'm hoping there are other diagnostics I can use. 2) Check that HD cables are correctly placed in their sockets This seems unlikely -- the messages I'm getting look more like memory management than I/O. I have one GB -- I'm thinking that might not be enough for a 64-bit kernel. 3) Check that the computer isn't running too hot What's the package in Etch that does that? I couldn't find it in the Gnome desktop. 4) Check with another distro. Check the md5sum of the iso BEFORE burning it Pretty much all the distros and kernels ranging from 2.6.17 through 2.6.18 do this. If I can get the 2.6.20 kernel to build without a crash during the compile, I'll check it out. 5) If nothing yields results, disassemble the computer and remount it with more care and love Good luck! By the way, so far, Etch has been the most stable and it's the only one that's configured the video right. Feisty Fawn crashed during the install, CentOS can't give me a reasonable looking screen and Gentoo hasn't been able to do a kernel build without crashing. If I can figure out make-kpkg and start building my own kernels, lenny may be the best choice for this system. It's a scientific workstation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
New box crashes
I just got a new box (Athlon 54 X2 4200+ on a Gigabyte Technology NVIDIA GeForce 6100 Socket AM2 AMD ATX Motherboard). I'm getting miscellaneous crashes on Etch. They usually occur during I/O intensive operations, and at this point I have no reason to suspect the hardware. I've gotten a few traces in /var/log/messages, which I'll post to the appropriate place as soon as I find out what the appropriate place is. So, where does one take this sort of thing? I don't have enough information yet to rule out hardware or enough decent debug traces to file a defect anywhere. If I can find a non-SMP kernel for Etch on an AMD64, I'll probably install it just to see if this stuff goes away. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 stable release signature problems?
On Fri, Aug 04, 2006 at 04:25:06PM +0200, Goswin von Brederlow wrote: Ed L. Cashin [EMAIL PROTECTED] writes: ... So if the Release file has a bad signature, who would be the one to remove the signature? I wouldn't mind contacting that person. Ganneff or aba on irc. I contacted them on IRC and they seem to have resolved the problem. -- Ed L Cashin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 stable release signature problems?
On Wed, Jul 26, 2006 at 12:14:30PM +0200, Goswin von Brederlow wrote: Ed L. Cashin [EMAIL PROTECTED] writes: ... I can get rid of the error that way, but I still am curious about why there's a bad signature on the release file for the amd64 stable APT repository. But sarge users will still have it. You mean amd64 sarge users still have a BADSIG error when running apt-get update? makki:/home/ecashin# apt-get update ... Reading package lists... Done W: GPG error: http://amd64.debian.net stable Release: The following signatures were invalid: BADSIG E415B2B4B5F5BBED Debian AMD64 Archive Key debian-amd64@lists.debian.org W: You may want to run apt-get update to correct these problems If not, I suppose sarge isn't using the public key crypto stuff, which would explain why this still hasn't been fixed. However, then the question would be: if sarge isn't using public key crypto, why is the release file signed at all? So if the Release file has a bad signature, who would be the one to remove the signature? I wouldn't mind contacting that person. -- Ed L Cashin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 stable release signature problems?
Goswin von Brederlow [EMAIL PROTECTED] writes: Jo Shields [EMAIL PROTECTED] writes: T?r?k Edvin wrote: Hi, Today I got this error while running `aptitude update`: W: GPG error: http://amd64.debian.net stable Release: The following signatures were invalid: BADSIG E415B2B4B5F5BBED Debian AMD64 Archive Key debian-amd64@lists.debian.org ... Doh, it is BADSIG. That means the signature in Release.gpg does not match the Release file. Doesn't matter who signed it or if the key is known, it is just broken. Ganneff, can you check this and comment? Has there been any news about the amd64 BADSIG on the Release file at amd64.debian.net? I checked the archives but didn't see any further followups. I still get the error if I include the stable amd64 APT repo in my list of sources. makki:~# cat /etc/apt/sources.list deb http://ftp.us.debian.org/debian/ testing main deb http://amd64.debian.net/debian-amd64/ stable main makki:~# apt-get update Get:1 http://ftp.us.debian.org testing Release.gpg [189B] Hit http://ftp.us.debian.org testing Release Hit http://ftp.us.debian.org testing/main Packages/DiffIndex Get:2 http://amd64.debian.net stable Release.gpg [189B] Hit http://amd64.debian.net stable Release Err http://amd64.debian.net stable Release Get:3 http://amd64.debian.net stable Release [4813B] Ign http://amd64.debian.net stable Release Ign http://amd64.debian.net stable/main Packages/DiffIndex Hit http://amd64.debian.net stable/main Packages Fetched 5003B in 1s (4674B/s) Reading package lists... Done W: GPG error: http://amd64.debian.net stable Release: The following signatures were invalid: BADSIG E415B2B4B5F5BBED Debian AMD64 Archive Key debian-amd64@lists.debian.org W: You may want to run apt-get update to correct these problems ... and ... makki:~# apt-key list /etc/apt/trusted.gpg pub 1024R/1DB114E0 2004-01-15 [expired: 2005-01-27] uid Debian Archive Automatic Signing Key (2004) [EMAIL PROTECTED] pub 1024D/4F368D5D 2005-01-31 [expired: 2006-01-31] uid Debian Archive Automatic Signing Key (2005) [EMAIL PROTECTED] pub 1024D/B5F5BBED 2005-04-24 uid Debian AMD64 Archive Key debian-amd64@lists.debian.org sub 2048g/34FC6FE5 2005-04-24 pub 1024D/2D230C5F 2006-01-03 [expires: 2007-02-07] uid Debian Archive Automatic Signing Key (2006) [EMAIL PROTECTED] I thought maybe there would be a new key out, even though the AMD64 Archive Key doesn't mention expiration, but I didn't see any Debian AMD64 Archive Key in the keyrings here: http://amd64.debian.net/debian-amd64/doc/debian-keyring.tar.gz -- Ed L Cashin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 stable release signature problems?
On Tue, Jul 25, 2006 at 04:03:01PM -0400, Lennart Sorensen wrote: On Tue, Jul 25, 2006 at 12:19:54PM -0400, Ed L. Cashin wrote: Has there been any news about the amd64 BADSIG on the Release file at amd64.debian.net? If you are running etch, why are you still pointing a deb source at amd64.debian.net at all? If I recall correctly, the ntpdate from stable wasn't in etch. ... Not sure about this, but I think the simple answer is to just not use amd64.debian.net anymore. I can get rid of the error that way, but I still am curious about why there's a bad signature on the release file for the amd64 stable APT repository. -- Ed L Cashin [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SATA problem with x86_64 install CD
On Wednesday 22 March 2006 22:17, Nima Talebi wrote: Gday, I've downloaded and attempted to install debian from the debian-31r0a- amd64-netinst.iso image. Everything is fine up until the point where my SATA device is not detected. Fedora and ubuntu detect it, and they also seem to have additional modules available, so I copied those over and loaded them with no errors, however that made no difference, I still cant see /dev/sda, fdisk -l comes back with zilch. While trying to detect the hardware I also get this message which supports the available list of modules... The unavailable modules and devices that need them are: ide-mod, ide- probe-mod, ide-detect etc I can quite happily compile a kernel that does support all the devices on this box, but what would the next step be? Surely there is an easier solution? Nima, I had the same problems. I downloaded the latest install cd and tried that. While it detected my drive it was unable to install (there were logical errors in the iso that broke the installation later) Maybe this is fixed now? In my case I gave up on debian (after 7 years) and installed gentoo. I now have a better, working, but maybe not quite as pristine, desktop (eg. wine, open office 2, flash, many 32bit codecs all work with painless installs). I do miss apt-get. Bottom line, old and/or broken installers cost users. Thanks, Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
console-common missing a depends?
Hi, Got this with todays update. Looks like some perl stuff is now required in console common and its not in a dependency... Errors were encountered while processing: console-common E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up console-common (0.7.55.1) ... Can't locate overload.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/share/perl5/Debconf/Template.pm line 331. BEGIN failed--compilation aborted at /usr/share/perl5/Debconf/Template.pm line 331. Compilation failed in require at /usr/share/perl5/Debconf/Question.pm line 8. BEGIN failed--compilation aborted at /usr/share/perl5/Debconf/Question.pm line 8. Compilation failed in require at /usr/share/perl5/Debconf/Config.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/Debconf/Config.pm line 7. Compilation failed in require at /usr/share/perl5/Debconf/Log.pm line 10. Compilation failed in require at /usr/share/perl5/Debconf/Db.pm line 7. BEGIN failed--compilation aborted at /usr/share/perl5/Debconf/Db.pm line 7. Compilation failed in require at /usr/share/debconf/frontend line 6. BEGIN failed--compilation aborted at /usr/share/debconf/frontend line 6. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new kernel too big for lilo
On Monday 26 December 2005 11:02, Craig Hagerman wrote: Hi, I asked a question last week about why my computer seems to use the CPU a lot during disc access. (Like using find, cp etc) Responses led me to figure out that DMA is not activated. After doing some searching on the internet I found out that I probably should compile a kernel with dma support (or at least compiled in as a module). My problem is that the resultant kernel image is too big ... at least that is the complain that lilo keeps giving me. From within the source directory I do: % make dep make clean make bzImage % make modules % make modules_install How have you created the .config file for your kernel? I suggest you boot into a 2.6 kernel that works and extract the config from it as shown below. A 2.6 kernel does not need the make dep and make bzImage is the default using a non root user: cd /your new kernel dir bzcat /proc/config.bz .config make old_config make clean make become root make modules_install then copy the vmlinux image to /boot, add the appropriate lines to /etc/lilo.conf and then run % lilo which tells me: Fatal: Kernel /boot/vmlinux-2.6.14-dma is too big It is 7258373 b. When I started it was about 850 b. I have gone through make menuconfig a dozen times now, turning off as many options as possible, choosing to build as a module instead of built in where possible ... and STILL I am getting an image that lilo complains about. I suspect you have almost everything built into your kernel. Here my 2.6 kernel is about 1.6m (vs your 7.2m). I don't understand this. Am I doing something wrong? or is lilo wrong? Can anyone tell me the correct way to compile a kernel if I have been doing it wrong. Luck Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: USB mouse and touchpad issues using the unstable release
On Tuesday 22 November 2005 18:06, Clive Menzies wrote: On (22/11/05 23:27), Massimo Perga wrote: Hi All, I've just upgraded the testing version to the unstable version. In the testing version both USB mouse and touchpad were working, but using latest unstable version (xorg server) I'm unable to use both. In particular, USB mouse seems to be detected by the system when it's inserted in the PC but it's not working: I also tried using gpm but nothing changes (when I used the stable release I was able to use the touchpad in the console, too). Could you explain me what changed from the two versions and how can I fix it ? If you are using a 2.6.15-* kernel try changing the makefile to say 2.6.14 and rebuilding your kernel. Thats be reported to fix a probable udev issue on debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=340202 In my case I can work around the issue by doing a 'modprobe mousedev' which causes the input dir to be created and lets X start without errors. Luck, Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hauppauge PVR-250 and PCHDTV-3000 with 2.6.14.2 kernel
On Saturday 12 November 2005 20:06, Dustin Nicholas Jenkins wrote: By default, the cx88* drivers load up fine on my Sarge AMD64 install and take input from my PCHDTV-3000 card. I also have an Hauppauge PVR-250 that requires the ivtv driver. My problem is that when I build the ivtv driver and replace the msp3400, tveeprom, tuner, and tda9887 modules with the ivtv supplied ones, my cx88* drivers no longer load complaining of the following (excerpt from loading cx88-dvb): WARNING: Error inserting cx88xx (/lib/modules/2.6.14.2/kernel/drivers/media/video/cx88/cx88xx.ko): Unknown symbol in module, or unknown parameter (see dmesg) WARNING: Error inserting cx8802 (/lib/modules/2.6.14.2/kernel/drivers/media/video/cx88/cx8802.ko): Unknown symbol in module, or unknown parameter (see dmesg) FATAL: Error inserting cx88_dvb (/lib/modules/2.6.14.2/kernel/drivers/media/video/cx88/cx88-dvb.ko): Unknown symbol in module, or unknown parameter (see dmesg) I ran depmod -a after moving the old versions of the afore mentioned modules aside, but no luck. Are the modules built by ivtv so different? Doesn't depmod take care of this kind of problem? Or should I forget the cx88* drivers that come with the kernel and install the ivtv and PCHDTV drivers separately? I've also read that much of the ivtv stuff is being built into the video4linux module, so I'm wondering if I should build that separately too. I you are using binary modules supplied by ivtv, then they will work best with the kernel they were compiled for. They _might_ work with later kernels. The kernel developers really dislike binary modules since they tend to break things in unpredictable ways - this is even more of a problem if the kernel release has changed since inter module dependencies _will_ change. Have you tried the video4linux module? If it works with your ivtv stuff its probably your best bet. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lockup at boot with kernel 2.6.14...
On Thursday 10 November 2005 07:25, Ed Tomlinson wrote: Hi, 2.6.14.2 should be out this weekend. The .1 fixes a security issue, .2 fixes bind (0 sized icmp packets) and several other bugs. Might be worth waiting. It also is worth trying to boot with apci disabled. Ed Tomlinson 2.6.14.2 is out - Note the fix list - the third one may help you.Its also worth making sure you have an up-to-date modutils package. Debian udev stresses modules loads Ed == Adrian Bunk: airo.c/airo_cs.c: correct prototypes Dimitri Puzin: fix XFS_QUOTA for modular XFS Greg Kroah-Hartman: USB: always export interface information for modalias Linux 2.6.14.2 Herbert Xu: NET: Fix zero-size datagram reception Ivan Kokshaysky: fix alpha breakage Jens Axboe: Oops on suspend after on-the-fly switch to anticipatory i/o scheduler - PowerBook5, 4 Julian Anastasov: ipvs: fix connection leak if expire_nodest_conn=1 Linus Torvalds: Fix ptrace self-attach rule Oleg Nesterov: - fix signal-live leak in copy_process() fix de_thread() vs send_group_sigqueue() race Roger While: prism54 : Fix frame length Stephen Hemminger: tcp: BIC max increment too large - On Thursday 10 November 2005 06:50, Giacomo Mulas wrote: Hello, I am experiencing a very strange behaviour on my Asus A6k Turion64 laptop running sid. It used to work ok with a custom-compiled (from the debian-packaged source) 2.6.12 kernel. When the debian-packaged source for 2.6.14 became available, I copied over my old .config, did a make oldconfig answering the relevant questions, built a new kernel without any errors, installed it. Then I experienced this weird situation: the system boots, loads the ramdisk, does its initial setup, mounts the root filesystem, switches root... all ok until it gets to starting udev. Then udev's hotplug kicks in and starts loading modules and... in an erratic, unpredictable way, it hangs while loading the usb hcd module, without any error message. Sometimes it does, sometimes it doesn't and the boot procedure then goes smooth and the computer runs without a hitch thereafter. It does not happen at all with 2.6.12, therefore it must be something which changed between 2.6.12 and 2.6.14 (a shipload of things, unfortunately...). I was unable to relate the hangs to anything, they seem to be just random. The only thing which is reproducible is that the system always hangs (when it does) while loading the ehci_hcd module. I did not even file a bug report yet, since I don't quite understand whether this is a kernel or a udev issue.
Re: lockup at boot with kernel 2.6.14...
Hi, 2.6.14.2 should be out this weekend. The .1 fixes a security issue, .2 fixes bind (0 sized icmp packets) and several other bugs. Might be worth waiting. It also is worth trying to boot with apci disabled. Ed Tomlinson On Thursday 10 November 2005 06:50, Giacomo Mulas wrote: Hello, I am experiencing a very strange behaviour on my Asus A6k Turion64 laptop running sid. It used to work ok with a custom-compiled (from the debian-packaged source) 2.6.12 kernel. When the debian-packaged source for 2.6.14 became available, I copied over my old .config, did a make oldconfig answering the relevant questions, built a new kernel without any errors, installed it. Then I experienced this weird situation: the system boots, loads the ramdisk, does its initial setup, mounts the root filesystem, switches root... all ok until it gets to starting udev. Then udev's hotplug kicks in and starts loading modules and... in an erratic, unpredictable way, it hangs while loading the usb hcd module, without any error message. Sometimes it does, sometimes it doesn't and the boot procedure then goes smooth and the computer runs without a hitch thereafter. It does not happen at all with 2.6.12, therefore it must be something which changed between 2.6.12 and 2.6.14 (a shipload of things, unfortunately...). I was unable to relate the hangs to anything, they seem to be just random. The only thing which is reproducible is that the system always hangs (when it does) while loading the ehci_hcd module. I did not even file a bug report yet, since I don't quite understand whether this is a kernel or a udev issue. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Eclipse
On Monday 31 October 2005 15:58, Marcin Dębicki wrote: Hamish Moffatt kiedys napisal: On Mon, Oct 31, 2005 at 08:22:31AM -0400, Ed Tomlinson wrote: On Monday 31 October 2005 05:28, Dalibor Topic wrote: The packagers used a specific free runtime to make the eclipse package build and work, so they made that runtime specifically part of the dependencies, as that's a configuration the packagers can focus on to support. You are most welcome to contribute, and help improve the eclipse packages. This does _not_ make a lot of sense. It would make much more sense to suggest gcj/gij and depend on java-virtual-machine. This leaves it up the the user to decide if he can use a non-free jvm. I my case many of the apps I use (non-debian) fail with the free jvms. In short this type of depends is, IMO a bug. It will force me, and many others, to bypass the packaging system, which is usually a bad idea. Your argument is only reasonable if your non-free Java environment is a complete drop-in replacement for building and running Eclipse. If not, then you're asking for extra work to be done to support multiple JVMs. If that's what you need, patches are probably welcome. Hamish Maybe not. Original (downloaded) Eclipse version works with both gcj/gij and Sun JDK. And I think that with Sable and kaffe it could also work wothout patching as far as I know. Maybe when all Eclipse packages will be available, I will repack it and try with each virtual machine. Thanks, If you want the packages tested on another box please ask. Ed Tomlinson
Re: mplayer
On Tuesday 04 October 2005 02:16, Kalle Kivimaa wrote: hjalmar [EMAIL PROTECTED] writes: No I am not running X as root. I can not get mplayer to work as a normal user but I have no problems with it when run as root. You do have a file permission problem. Unfortunately I don't remember which file in /dev or /proc you need to chmod, even though I ran into this same problem a year or two ago... Try asking in debian-users what the device/proc files are for XV. Start mplayer with 'strace mplayer 2 some_file' look at the file. You will probably be able to see where the permission problem is - it make take a bit to understand what strace is telling you. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
amd64.debian.net sick?
Hi Is there a problem or is it just me? W: Couldn't stat source package list http://amd64.debian.net sid/main Packages (/var/lib/apt/lists/amd64.debian.net_debian_dists_sid_main_binary-amd64_Packages) - stat (2 No such file or directory) Got the above doing aptitude update, Sunday 9am EST. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64.debian.net sick?
On Sunday 02 October 2005 10:44, Aritz Beraza Garayalde [Rei] wrote: 2005/10/2, Ed Tomlinson [EMAIL PROTECTED]: Hi Is there a problem or is it just me? W: Couldn't stat source package list http://amd64.debian.net sid/main Packages (/var/lib/apt/lists/amd64.debian.net_debian_dists_sid_main_binary-amd64_Packages) - stat (2 No such file or directory) Got the above doing aptitude update, Sunday 9am EST. Maybe something related with network changes advertised on the post before this one? Yes. I sent the message before the notification reached my box. Thanks Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPG marillat
On Wednesday 28 September 2005 09:15, Marko Kaiser wrote: Read this: http://cvs.cinelerra.org/getting_cinelerra.html Regards, Marko That helps thanks. Would you know where to get the keys for the following? W: GPG error: file: sarge Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 3B9DED8C27F24D73 W: GPG error: http://amd64.debian.net sid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E415B2B4B5F5BBED W: GPG error: http://amd64.debian.net sarge Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY E415B2B4B5F5BBED I would be nice to have aptitude install without complaining about keys... TIA Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: GPG marillat
On Wednesday 28 September 2005 03:11, Marko Kaiser wrote: Hello, get dists/sid/Release.gpg and add that key via apt-key add. Bye, Marko grover:/home/ed# apt-key add marillat_Release.gpg gpg: no valid OpenPGP data found. grover:/home/ed# cat marillat_Release.gpg -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQBDN7jkB9xWPR9BuQcRAomXAKCIB3mxJ/RD8ogR6nNBv3xjN6A99wCdEK5k cdav48pWw/l4U/xj5Y2vOs8= =LBMR -END PGP SIGNATURE- grover:/home/ed# What else has to be done? TIA Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: new 2.6.13 kernel
On Thursday 01 September 2005 21:14, Marco Amadori wrote: On Thursday 01 September 2005 22:36, Jean-Luc Coulon (f5ibh) wrote: [...] [DevFS] I *need* it for my lvm on raid In this bug #323391 [1] there is a patch to make yaird works, I use it, works for my lvm on raid systems, remember to add --verbose on the script `dpkg --listfiles yaird | grep -i raidtab` (I do not remember the name) if u encounter the bug #324774 [2] [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323391 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=324774 So if kernel-package will default with yaird initramfs no devfs will be needed, btw I think that devfs only disappeared from kconfig... Devfs is gone for good. uDev replaces it. The problem with devfs was, from the kernel list, that is was buggy, racey and unmaintained. Over a year ago it was announced that it was going away in the Doc/feature-removal-schedule.txt file in the kernel source. Debain has just been slow to adapt. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
problems with base-config_2.70_all.deb
Hi, Got back from vacation. Updating gets the following: Setting up base-config (2.70) ... /var/lib/dpkg/info/base-config.postinst: line 59: syntax error near unexpected token `db_fset' dpkg: error processing base-config (--configure): subprocess post-installation script returned error exit status 2 I've reinstalled 2.69 and held the package. For some reason aptitude, without any messages why, ignores my instructions to hold the pack and keeps trying 2.70 (probably something requires 2.70 - when/if aptitude overides my instructions it SHOULD tell me why!) Ideas Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problems with base-config_2.70_all.deb
Forget this. I did a second update/upgrade cycle (about 5 minutes after the first) and 2.71 was found - it fixes this problem. Thanks Ed On Friday 19 August 2005 18:13, Ed Tomlinson wrote: Hi, Got back from vacation. Updating gets the following: Setting up base-config (2.70) ... /var/lib/dpkg/info/base-config.postinst: line 59: syntax error near unexpected token `db_fset' dpkg: error processing base-config (--configure): subprocess post-installation script returned error exit status 2 I've reinstalled 2.69 and held the package. For some reason aptitude, without any messages why, ignores my instructions to hold the pack and keeps trying 2.70 (probably something requires 2.70 - when/if aptitude overides my instructions it SHOULD tell me why!) Ideas Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Xorg and RADEON (dri disabled)
Hi, With Xorg I get: (==) RADEON(0): Write-combining range (0xd000,0x800) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] loaded kernel module for radeon driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. And glxgears reports 300 frames per second. How do I get dri back? It was working fine with XFree. The XF86Config-4 was changed by the upgrade dropping some parms in the Device section. Restoring them has no effect on the problem. Ideas? TIA, Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Xorg and RADEON (dri disabled)
On Wednesday 20 July 2005 21:13, Michal Schmidt wrote: Ed Tomlinson wrote: Hi, With Xorg I get: (==) RADEON(0): Write-combining range (0xd000,0x800) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 7, (OK) drmOpenByBusid: drmOpenMinor returns 7 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) RADEON(0): [drm] loaded kernel module for radeon driver (II) RADEON(0): [drm] DRM interface version 1.2 (II) RADEON(0): [drm] created radeon driver at busid pci::01:00.0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xc2411000 (II) RADEON(0): [drm] drmMap failed (EE) RADEON(0): [dri] DRIScreenInit failed. Disabling DRI. And glxgears reports 300 frames per second. How do I get dri back? It was working fine with XFree. The XF86Config-4 was changed by the upgrade dropping some parms in the Device section. Restoring them has no effect on the problem. What kernel do you use? I get the same behaviour with 2.6.13-rc3-mm1, but it works with 2.6.13-rc3. I also use 2.6.13-rc3-mm1. Will try with a previous version an report to lkml if it works. Thanks Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: comments about hardware
Hi, Dual core support is not distro specific. It depends on the kernel used. I believe that debian, with a recent (2.6.12.3+) kernel should be fine. Ed Tomlinson On Monday 18 July 2005 01:36, Faheem Mitha wrote: Dear People, My bioinformatics research group at Duke is buying a server, which will mostly be used as a server, particularly for web based services. The idea here is that a user will submit a request for some bioinformatics calculation via a web interface (often using Python or R or similar), the server does the calculation, and returns it as a web page. None of us are experts about recent hardware, so would appreciate any feedback about hardware specs. The following quote is from Monarch Computers. We plan to run Linux on this. It has not yet been decided yet what, but it seems most likely that it will be either some Red Hat variant (Fedora Core, CentOS), or Debian (possibly Ubuntu). Ok, so here are some specific questions. 1) Dual core Opterons first came on the market in April. The sales rep said that AMD Dual Core Opterons did not work with Fedora Core. Since they only install Fedora and SuSE, they had no info about Debian. Any idea what the status is here? How well are they supported, and how stably do they run under Linux? Also, I was told that a dual core Opteron, which is somewhat more than twice the cost two regular Opterons of similar speed, is not equivalent to two regular Opterons in functionality. Can anyone point me to information about this, or offer a comment? 2) I'm wondering if the listed motherboard is the best choice. I see it listed in http://alioth.debian.org/docman/view.php/30192/27/mainboards.html We are looking for the motherboard that has the least known issues. Preferably something that will work right out of the box. Google found me http://lists.debian.org/debian-amd64/2004/09/msg00443.html but would be interested in other reports. The specs are here http://www.tyan.com/products/html/thunderk8spro_spec.html It looks like both the graphics card and the ethernet cards are onboard. Looks like the graphics card is ATI RAGE XL PCI, which supposedly works with the 'ati' driver. Is this under XFree 4.3? The ethernet cards are an Intel Ethernet Pro 100, which supposedly works with the e100 driver and a Gigabit Broadcom which works with the tg3 driver. There seem to be two cards here. Is that correct? I'm kinda allergic to onboard cards. They are often trouble. Has anyone had experience with Debian Sarge installation with this? Does anyone have a board to suggest that they prefer to this? 3) I'm also wondering if peple have thoughts about the RAID setup. The rep said he would be using RAID 1, but I see RAID 10 is listed. I'll have to check on this. Anyway, assuming this corresponds to http://en.wikipedia.org/wiki/Redundant_array_of_independent_disks#RAID_10 with each RAID 1 set as two drives, and 4 RAID 1 sets striped together, does this seem reasonable? Thanks.Faheem. *** ITEM NUM PRICE PER ITEM TOT Monarch Empro Custom 2U Rack S 1.0075.00 75.00 RMC2K2-9I-XPSS,2U,8 Bays,SATA, 1.00 725.00 725.00 AIC 2U Riser Card/Rear Window1.00 112.00 112.00 Tyan S2882G3NR-D Dual Socket94 1.00 394.00 394.00 Amd OSA265FAA6CB Dual Core Opt 2.00 851.00 1,702.00 Thermal Grease, Shin-Etsu G675 2.0014.0028.00 THERMALTAKE A1838 AMD Opteron2.0025.0050.00 WESTERN DIGITAL 250 GB 2500JD1.00 115.00 115.00 3WARE Escalade 9500S-8 - 8-por 1.00 485.00 485.00 RAID 10 Setup1.0025.0025.00 WESTERN DIGITAL 250 GB 2500JD8.00115.00 920.00 SONY DWD-56A 8X4X2.4 DVD RW+/- 1.00129.00 129.00 SUSE Linux 9.3 Professional Ed 1.00 92.00 92.00 24/7 TECH SUPPORT+ONSITE 3 YR. 1.00199.00 199.00 Net Order: 5,051.00 Freight: 75.00 5,126.00 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [update] More 32bit packages for amd64
On Sunday 17 July 2005 13:28, Goswin von Brederlow wrote: Package fetching is done by reprepro and turning it more verbose gives some more messages but not a download progress for files. The package fetching is also going to be done by a cron job normaly. Unless it gets an error it should not say anything (in the finished package). I will think about something for the initial install but my current plan is to have it create an empty archive and start the cron job once manualy in the background. So, having an interactive (i.e. with download progress) update script is not a high priority just now. Later, for people that don't want the cron job, maybe. But the reprepro maintainer has to provide support for that. How well will this work? For instance, I do not really want to maintain a chroot. The one app I sometimes miss is wine. Do you think this can be supported with the new package arch? TIA, Ed Tomlinson
Re: [update] More 32bit packages for amd64
On Monday 18 July 2005 09:03, Goswin von Brederlow wrote: Ed Tomlinson [EMAIL PROTECTED] writes: On Sunday 17 July 2005 13:28, Goswin von Brederlow wrote: Package fetching is done by reprepro and turning it more verbose gives some more messages but not a download progress for files. The package fetching is also going to be done by a cron job normaly. Unless it gets an error it should not say anything (in the finished package). I will think about something for the initial install but my current plan is to have it create an empty archive and start the cron job once manualy in the background. So, having an interactive (i.e. with download progress) update script is not a high priority just now. Later, for people that don't want the cron job, maybe. But the reprepro maintainer has to provide support for that. How well will this work? For instance, I do not really want to maintain a chroot. The one app I sometimes miss is wine. Do you think this can be supported with the new package arch? TIA, Ed Tomlinson Add wine and libwine to packages.list and it probably works already. I haven't found anything besides libc6 which needs special tricks for the conversion yet, the general conversion rules work very well. This ends up with: The following packages have unmet dependencies: ia32-libwine: Depends: xlibmesa3-gl which is a virtual package. or ia32-libgl1 which is a virtual package. which does not seem to want to resolve... here is what I added: wine libncurses5 libxi6 libwine Suspect that one of these libs might need some help. And wine is on my todo. Next time I wanna play StarCraft at the latest. Thanks Ed Tomlinson
Re: Upgrading to current udev is disastrous if not on kernel 2.6.12
Yes rebooting isn't good! Do the kernel upgrade and you won't have any worries. That is if you don't have heaps of myth/dvb patches to apply :) Regards Ed. On Sat, 2005-07-16 at 16:21 +1000, Hamish Moffatt wrote: On Sat, Jul 16, 2005 at 04:13:36PM +1000, Hamish Moffatt wrote: On Sat, Jul 16, 2005 at 07:02:01AM +0200, Goswin von Brederlow wrote: You can't. The latest version checks the kernel version in preinst. Did you have 0.062-4? Does that work? apt-get upgrade just installed 0.062-4 on my 2.6.8-11 system without complaint. Hmm. The preinst only complains if you had 0.060 before. I upgraded to that earlier in July but never rebooted; now I have 0.062. I guess this is bad, so I'll try to avoid rebooting. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Upgrading to current udev is disastrous if not on kernel 2.6.12
On Sat, 2005-07-16 at 12:28 +0200, Jonas Meurer wrote: On 16/07/2005 Ed wrote: Yes rebooting isn't good! Do the kernel upgrade and you won't have any worries. That is if you don't have heaps of myth/dvb patches to apply :) you have to patch your kernel for mythtv? which patches do you mean? is it only in connection with dvb? i use ivtv modules to use my winTV PVR-350 and i don't use any kernel patches. bye jonas Depends on what card your using. I usually use the Kraxel patches for a Nova-T. Then there are lirc modules that need to be recompiled etc etc. It's not always as simple as apt-get install kernel-image-2.6.x Of course many cards are supported well by the kernel.
Re: Upgrading to current udev is disastrous if not on kernel 2.6.12
I can't imagine how it's a good idea to upload a package which depends on a kernel not available for Debian yet. Packages should not depend on any kernel, since many people run their own. However, I just don't understand why the package has been published at all, since even in experimental there is no 2.6.12. Bye, Ratti Hear Hear!!
Upgrading to current udev is disastrous if not on kernel 2.6.12
I don't usually report these types of problems but this one was particularly nasty. I just had a major disaster by upgrading to udev 0.62. It requires a kernel 2.6.12. After a system reboot my system wouldn't function due to lacking /dev/sda2-5 etc. I sorted it out by coping a new kernel source onto the system and recompiling. Anyway the moral to the story is: Don't install this package unless you have upgraded your kernel Regards Ed.
Re: X.org enters in Sid
On Wednesday 13 July 2005 05:59, v0n0 wrote: Since yesterday night, X.org 6.8.2 is in Debian unstable. Be aware if you dist-upgrade you will get X.org installed over Xfree. Is this bad? If so what has to be done to upgrade to X.org safely? TIA Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Calling 64 bit apps from 32 bit Chroot
On Sun, 2005-07-10 at 07:56 +0200, Goswin von Brederlow wrote: Ed [EMAIL PROTECTED] writes: I am using Galeon Firefox in the 32bit chroot environment. I would like to be able to click on a mailto: link and bring up evolution which is in the standard 64 bit location. Is this easily possible? Regards Ed. Sure, mount your 64bit system inside the chroot. It works in both ways. Great got it working. Thanks. MfG Goswin !DSPAM:42d0b91b154291979117738!
Calling 64 bit apps from 32 bit Chroot
I am using Galeon Firefox in the 32bit chroot environment. I would like to be able to click on a mailto: link and bring up evolution which is in the standard 64 bit location. Is this easily possible? Regards Ed.
Re: Perfomance problems with NVidia
I am using the FX5700 LE on an AMD3000+ I get 2430fps using the latest driver: 7667. (Manually Installed) On Thu, 2005-06-30 at 18:20 +, Sven Krahn wrote: Lennart Sorensen wrote: My FX5200 on an Athlon XP 2800+ machine gets 610fps on default glxgears. An FX5200 is no speedy card at all. Does anybody (Len?) have an idea what the fps rate for FX 5700LE (with an AMD64 3200+) should be? Mine is at roughly 1450fps (with default glxgears), though I remember with an earlier nvidia driver I have it seen at 2700fps already. I have no clue what the benchmark could be...
Re: MSI K8N NEO PLATINUM
On Friday 24 June 2005 10:59, Carrick Detweiler wrote: My MSI K8N Neo4 Platinum works fine with etch amd-64, so I presume that it should be fine with sarge. I found that I had to manually load the forcedeth module for the network driver during the install, although on rare occasions it would load it by itself. Additionally since it has two nics I found that it sometimes assigned eth1 to the nic I was using instead of eth0. So then I had to do an `ifconfig eth1 up` and `dhclient eth1` to get dhcp networking going during the install. Once I had it up and running the only thing I had to do was to download the sound driver from nvidia's site (possibly another way to get sound working...but this worked). No problems here - The kernels alsa drivers support the sound card too. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mysqld on debian-amd64/testing crashing with signal 11
Hi folks, I've been experiencing a problem with mysql-server-4.1 on two different amd64 machines, running two different versions of the package. The errors in the log are similar to http://lists.debian.org/debian- amd64/2005/03/msg00481.html -- but I don't know if the source of the segfault is a client QUIT command. I don't think it is. It's occurred about 10 times in the past 7 days, at seemingly random intervals. I switched to a second server yesterday afternoon, and less than 6 hours later mysqld on the new server segfaulted. The servers get about 300qps on average, about half updates and half selects. I turned on query logging after about the third day, despite the performance hit, and couldn't see any abnormal queries in the logs. Presumably whatever query that causes the segfault, though, wouldn't get logged. Since the mysqld in debian doesn't seem to output a backtrace on crash, I can't use that for further debugging. I'm open to any suggestions, and please let me know if there's any further information I can provide. Error message: Jun 22 17:55:18 localhost mysqld[10680]: mysqld got signal 11; Jun 22 17:55:18 localhost mysqld[10680]: This could be because you hit a bug. It is also possible that this binary Jun 22 17:55:18 localhost mysqld[10680]: or one of the libraries it was linked against is corrupt, improperly built, Jun 22 17:55:18 localhost mysqld[10680]: or misconfigured. This error can also be caused by malfunctioning hardware. Jun 22 17:55:18 localhost mysqld[10680]: We will try our best to scrape up some info that will hopefully help diagnose Jun 22 17:55:18 localhost mysqld[10680]: the problem, but since we have already crashed, something is definitely wrong Jun 22 17:55:18 localhost mysqld[10680]: and this may fail. Jun 22 17:55:18 localhost mysqld[10680]: Jun 22 17:55:18 localhost mysqld[10680]: key_buffer_size=268435456 Jun 22 17:55:18 localhost mysqld[10680]: read_buffer_size=131072 Jun 22 17:55:18 localhost mysqld[10680]: max_used_connections=101 Jun 22 17:55:18 localhost mysqld[10680]: max_connections=100 Jun 22 17:55:18 localhost mysqld[10680]: threads_connected=5 Jun 22 17:55:18 localhost mysqld[10680]: It is possible that mysqld could use up to Jun 22 17:55:18 localhost mysqld[10680]: key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 479743 K Jun 22 17:55:18 localhost mysqld[10680]: bytes of memory Jun 22 17:55:18 localhost mysqld[10680]: Hope that's ok; if not, decrease some variables in the equation. Jun 22 17:55:18 localhost mysqld[10680]: Jun 22 17:55:18 localhost mysqld_safe[18891]: Number of processes running now: 0 Jun 22 17:55:18 localhost mysqld_safe[18893]: restarted Package versions: mysql-server-4.1 - 4.1.11-3 and 4.1.11a-4 kernel: 2.6.8-11-amd64-k8-smp memory: 4GB in one, 2GB in the other cpus: dual opterons at 1.6ghz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
apt-listchanges gets: ImportError: No module named _bsddb
Hi, This ring bells with anyone? Fetched 54.8kB in 0s (76.1kB/s) Traceback (most recent call last): File /usr/bin/apt-listchanges, line 218, in ? main() File /usr/bin/apt-listchanges, line 71, in main seen = anydbm.open(config.save_seen, 'c') File /usr/lib/python2.3/anydbm.py, line 82, in open mod = __import__(result) File /usr/lib/python2.3/dbhash.py, line 5, in ? import bsddb File /usr/lib/python2.3/bsddb/__init__.py, line 40, in ? import _bsddb ImportError: No module named _bsddb TIA, Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lots of probs with SF Azureus
Hi I also use 1.5.0_03 / 2.3.0.2 with very good results. I found that the default setup enables UPnP by default. Here I have to turn if off or azureus stalls ( use tools / options / Plugins / UPnP and unclick and apply). Luck Ed On Sunday 12 June 2005 14:30, Rupert Heesom wrote: I've noticed 1 or 2 historical threads here on Azureus. I'm trying to run the latest SF version 2.3.0.2, but it can't do much without crashing, then refusing to load! I'm using java jre1.5.0_03. Azureus when first installed loads fine, gives startup wizard etc. However when it first is asked to download something, even an update, it crashes! I've found that renaming/deleting the ~/.Azureus/downloads.config helps. At least then Azureus loads! I have noticed that in the corrupt download.config files, that there seems to be some unprintable/foreign characters near the end: (I don't know if foreign characters are normal) A few of my downloads.config files contents: d9:downloadsld9:allocatedi1e9:completedi1000e12:creationTimei1118599928674e9:discardedi0e10:downloadedi72127e15:file_prioritiesli-1ee10:forceStarti1e9:hashfailsi0e5:maxdli0e5:maxuli0e4:path22:/tmp/azupdater_1.7.zip10:persistenti1e8:positioni1e8:save_dir4:/tmp9:save_file17:azupdater_1.7.zip18:secondsDownloadingi0e18:secondsOnlySeedingi0e5:statei0e7:torrent45:/home/raheesom/.Azureus/torrents/AZU44308.tmp12:torrent_hash20:^X909C97üz-ì3¯áû^Vѹ,^P9F¹8:uploadedi0e7:uploadsi4 d9:downloadsld9:allocatedi1e9:completedi0e12:creationTimei1118599689168e9:discardedi0e10:downloadedi0e15:file_prioritiesli-1ee10:forceStarti0e9:hashfailsi0e5:maxdli0e5:maxuli0e4:path64:/home/raheesom/Downloads/Torrents/Downloads/SYMANTECRECO2.00.rar10:persistenti1e8:positioni1e8:save_dir43:/home/raheesom/Downloads/Torrents/Downloads9:save_file20:SYMANTECRECO2.00.rar18:secondsDownloadingi0e18:secondsOnlySeedingi0e5:statei0e7:torrent78:/home/raheesom/.Azureus/torrents/Symantecrecoverydisk.www.Demonoid.com.torrent12:torrent_hash20:79EòT v/^DN28A82ħðIÌmä8:uploadedi0e7:uploadsi4 d9:downloadsld9:allocatedi1e9:completedi0e12:creationTimei1118600068487e9:discardedi0e10:downloadedi0e15:file_prioritiesli-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ei-1ee10:forceStarti0e9:hashfailsi0e5:maxdli0e5:maxuli0e4:path88:/home/raheesom/Downloads/Torrents/Downloads/Symantec.LiveState.Recovery.Desktop.v3.0-iSO10:persistenti1e8:positioni1e8:save_dir43:/home/raheesom/Downloads/Torrents/Downloads9:save_file44:Symantec.LiveState.Recovery.Desktop.v3.0-iSO18:secondsDownloadingi0e18:secondsOnlySeedingi0e5:statei0e7:torrent85:/home/raheesom/.Azureus/torrents/Symantec.LiveState.Recovery.Desktop.v3.0-iSO.torrent12:torrent_hash20:f80;^MEF ÿÌDýtÃk[%^Q8:uploadedi0e7:uploadsi4 I haven't seen any other thread about this sort of behaviour in AZ, normally for others, it either runs or doesn't run! I've noticed others saying that AZ uses java for networking, so it could be a java problem. Maybe I should downgrade my java VM, although there doesn't seem to be another version for amd64 -- Rupert Heesom [EMAIL PROTECTED]
Re: Rescue CD wanted: 2.6.10, SATA and XFS
Knoppix meets the requirements. Beware XFS with NFS and/or Samba. I have recently moved all my clients systems off XFS. Ed. On Fri, 2005-06-10 at 10:11 +0200, Thomas Steffen wrote: Hi, it seems I have to repair my XFS filesystem manually (recovery fails). Can anyone recommend a rescue CD with at least kernel 2.6.10 (needed for my SATA controller) and XFS support? A debian install CD would work, if it had kernel 2.6.10 on it... Is there something like that out there? Thinking about it, I actually need neither AMD64 nor XFS support in the kernel (xfs_check does all that). I would use knoppix, but last time I tried it had no SATA support at all. Thomas !DSPAM:42a94b78172152116712358! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Bug#305238: Installation report: AMD AThlonXP 1800+ / Abit KR7A-RAID133 (with Highpoint Raid controller)
Lennart Sorensen wrote: On Thu, May 19, 2005 at 07:23:44PM +0200, Frans Pop wrote: This installation report has not yet had a reply. As most of the issues seem amd64 kernel related, could someone from the AMD64 team please answer this report? Athlon XP = k7 = i386. Athlon 64 = k8 = amd64. This system can't even run amd64 and certainly wouldn't use an amd64 kernel. Very true, it would be classified as an i386. I do hope to get a mobo/cpu that'll use an AMD64 kernel. :) It is just a plain simple i386 system (although a nice one). Thanks for the compliment :) As a follow up, I wiped the gentoo from my system and put on debian unstable. EVERYTHING went well, AFTER I disabled the highpoint driver... Edward J. Shornock -- Forwarded Message -- Subject: Bug#305238: Installation report: AMD AThlonXP 1800+ / Abit KR7A-RAID133 (with Highpoint Raid controller) Date: Monday 18 April 2005 22:34 From: Edward J. Shornock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Package: installation-reports Debian-installer-version: http://cdimage.debian.org/pub/cdimage-testing/sarge_d-i/i386/rc3/sarge-i3 86-netinst.iso downloaded on 2005-04-17 uname -a: Linux athlonxp 2.6.11-gentoo-r6 #1 Sun Apr 17 20:27:25 EDT 2005 i686 AMD Athlon(tm) XP 1800+ AuthenticAMD GNU/Linux Athlon(tm) XP 1800+ AuthenticAMD GNU/Linux Date: 2005-04-17 @ 21:00 (approx) How did you install? Network Install (did not proceed with installation) What did you install? Sarge What did you boot off? sarge-i386-netinst.iso dated 2005-03-25 Machine: Abit KR7A-RAID133, VIA Chipset (hand-built machine), motherboard webpage at http://www.abit-usa.com/products/mb/products.php?categories=1model=87 Processor: AthlonXP 1800+ Memory:1024MB PC2100 DDR Root Device: IDE, /dev/hda Root Size/partition table: not applicable Output of lspci and lspci -n: lspci output: $ lspci :00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] :00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] :00:08.0 Ethernet controller: Lite-On Communications Inc LNE100TX [Linksys EtherFast 10/100] (rev 25) :00:0b.0 Communication controller: Agere Systems (former Lucent Microelectronics) 56k WinModem (rev 01) :00:0f.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24 [CrystalClear SoundFusion Audio Accelerator] (rev 01) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge :00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:11.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 23) :00:11.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 23) :00:13.0 RAID bus controller: Triones Technologies, Inc. HPT366/368/370/370A/372 (rev 05) :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500] $ lspci -n :00:00.0 Class 0600: 1106:3099 :00:01.0 Class 0604: 1106:b099 :00:08.0 Class 0200: 11ad:c115 (rev 25) :00:0b.0 Class 0780: 11c1:0441 (rev 01) :00:0f.0 Class 0401: 1013:6003 (rev 01) :00:11.0 Class 0601: 1106:3147 :00:11.1 Class 0101: 1106:0571 (rev 06) :00:11.2 Class 0c03: 1106:3038 (rev 23) :00:11.3 Class 0c03: 1106:3038 (rev 23) :00:13.0 Class 0104: 1103:0004 (rev 05) :01:00.0 Class 0300: 1002:5157 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [E and O] Load installer modules: [O] Detect hard drives: [E and O] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [O] Install base system:[ ] Install boot loader:[ ] Reboot: [O] Comments/Problems: When booting off if the CD without any special parameters, the CD detection process will hang for all eternity at the IDE-generic module, with the following in `dmesg` output: HPT372: IDE controller at PCI slot :00:13.0 ACPI: PCI interrupt :00:13.0[A] - GSI 10 (level, low) - IRQ 10 HPT372: chipset revision 5 HPT37X: using 33MHz PCI clock HPT372: 100% native mode on irq 10 ide2: BM-DMA at 0xc800-0xc807, BIOS settings: hde:DMA, hdf:DMA ide3: BM-DMA at 0xc808-0xc80f, BIOS settings: hdg:pio, hdh:pio hde: MAXTOR 6L080L4, ATA DISK drive hdf: MAXTOR 6L080J4, ATA DISK drive ide2 at 0xb800-0xb807,0xbc02 on irq 10 hde: max request size: 128KiB hde: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=65535/16/63, UDMA(133) /dev/ide/host2/bus0/target0/lun0:4hde: dma_timer_expiry: dma status == 0x65 hde: DMA interrupt recovery hde: lost interrupt p1 p2 4hde: dma_timer_expiry: dma status == 0x65 hde: DMA interrupt recovery hde: lost interrupt hdf: max request size: 128KiB hdf: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=65535/16/63, UDMA(133)
Re: Strange aptitude behavior with bind9-host
On Friday 13 May 2005 23:21, Bob Proulx wrote:
Ed Tomlinson wrote:
Looks like the bind9-host package is sticky...
Or has two different sources.
grover:/home/ed# aptitude update
...
grover:/home/ed# aptitude upgrade
...
The following packages will be upgraded:
bind9-host
...
grover:/home/ed# aptitude upgrade
...
The following packages will be upgraded:
bind9-host
...
Notice that it still thinks bind9-host needs to be installed. How
do I find out why? Alternately, how do I fix it?
What is the output of this command?
apt-cache policy bind9-host
I am guessing that there are multiple sources for bind9-host. They
are different. You are alternately installing first one and then the
other. I have seen this behavior from apt with other packages with
that problem. A local rebuild in a local depot was my problem.
What is the output of this command?
apt-get install --print-uris -d -y -qq bind9-host |awk '{print$1}' |xargs -l
I am guessing that as you install first one and then the other that
the URL printed will be changing from one location to the next.
Bob,
grover:/home/ed# apt-cache policy bind9-host
bind9-host:
Installed: 1:9.3.1-2
Candidate: 1:9.3.1-2
Version Table:
1:9.3.1-2 0
500 http://amd64.debian.net sid/main Packages
*** 1:9.3.1-2 0
100 /var/lib/dpkg/status
grover:/home/ed# apt-get install --print-uris -d -y -qq bind9-host |awk
'{print$1}' |xargs -l
http://amd64.debian.net/debian/pool/main/b/bind9/bind9-host_9.3.1-2_amd64.deb
grover:/home/ed#
Which seems to show one url? Wonder if its worth removing the cached version?
Thanks
Ed
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#309072: azureus: crashes on startup. An unexpected error has been detected by HotSpot VM:SIGSEGV
Hi, Try disabling micro PnP suport. Think you have about a minute to get to the options, turn off the pluging, save and exit. Ed On Saturday 14 May 2005 06:41, Gerhard Gauling wrote: Package: azureus Version: 2.3.0.0-2 Severity: important *** Please type your report below this line *** azureus crashes obn startup: # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x2ae4cf9b, pid=9137, tid=46912501786320 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.5.0_02-b09 mixed mode) # Problematic frame: # C [libc.so.6+0x72f9b] Should I post the $HOME/.Azureus/hs_err_pid9137.log.gz [5,3k] ? regards Gerhard Gaußling -- additional System informations: I run ubuntu Hoary Hedgehog 5.04 for amd64 with several packages from debian unstable and the sun java packages build with java-package from hoary. So I put the dist infos here: azureus:2.3.0.0-2 sid/contrib libc6:2.3.5-0ubuntu3 breezy/main java-package:0.24 hoary/multiverse libswt-gtk-3.1-java:3.0+3.1M4-3 sid/main liblog4j1.2-java:1.2.9-1 hoary/universe libcommons-cli-java: 1.0-4 hoary/universe -- System Information: Debian Release: 3.1 Architecture: amd64 (x86_64) Kernel: Linux 2.6.11.8.20050430 Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Versions of packages azureus depends on: ii libcommons-cli-java 1.0-4 API for working with the command l ii liblog4j1.2-java 1.2.9-1Logging library for java ii libswt-gtk-3.1-java 3.0+3.1M4-3Standard Widget Toolkit for GTK Ja ii sun-j2re1.5 [java2-runtim 1.5.0+update02 Java(TM) 2 RE, Standard Edition, S ii sun-j2sdk1.5 [java2-runti 1.5.0+update02 Java(TM) 2 SDK, Standard Edition, -- no debconf information
Strange aptitude behavior with bind9-host
Hi Looks like the bind9-host package is sticky... grover:/home/ed# aptitude update Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done Hit http://amd64.debian.net sid/main Packages Get:1 http://amd64.debian.net sid/main Release [111B] Hit http://amd64.debian.net sid/contrib Packages Get:2 http://amd64.debian.net sid/contrib Release [114B] Hit http://amd64.debian.net sid/main Sources Get:3 http://amd64.debian.net sid/main Release [112B] Hit http://amd64.debian.net sid/contrib Sources Get:4 http://amd64.debian.net sid/contrib Release [115B] Hit http://cyberspace.ucla.edu unstable/main Packages Hit http://cyberspace.ucla.edu unstable/main Release Hit ftp://ftp.nerim.net unstable/main Packages Hit ftp://ftp.nerim.net unstable/main Release Fetched 452B in 3s (137B/s) Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done grover:/home/ed# aptitude upgrade Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages have been kept back: kernel-image-2.6-amd64-k8 openoffice.org openoffice.org-debian-files openoffice.org-l10n-en xprt-xprintorg The following packages will be upgraded: bind9-host 1 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 0B/108kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n/?] Reading changelogs... Done (Reading database ... 164344 files and directories currently installed.) Preparing to replace bind9-host 1:9.3.1-2 (using .../bind9-host_1%3a9.3.1-2_amd64.deb) ... Unpacking replacement bind9-host ... Setting up bind9-host (9.3.1-2) ... Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done We have installed bind9-host grover:/home/ed# aptitude upgrade Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages have been kept back: kernel-image-2.6-amd64-k8 openoffice.org openoffice.org-debian-files openoffice.org-l10n-en xprt-xprintorg The following packages will be upgraded: bind9-host 1 packages upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 0B/108kB of archives. After unpacking 0B will be used. Do you want to continue? [Y/n/?] y Reading changelogs... Done (Reading database ... 164344 files and directories currently installed.) Preparing to replace bind9-host 1:9.3.1-2 (using .../bind9-host_1%3a9.3.1-2_amd64.deb) ... Unpacking replacement bind9-host ... Setting up bind9-host (9.3.1-2) ... Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descr Notice that it still thinks bind9-host needs to be installed. How do I find out why? Alternately, how do I fix it? TIA, Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange aptitude behavior with bind9-host
On Friday 13 May 2005 18:35, Kurt Roeckx wrote: On Fri, May 13, 2005 at 06:12:55PM -0400, Ed Tomlinson wrote: Notice that it still thinks bind9-host needs to be installed. How do I find out why? Alternately, how do I fix it? grover:/home/ed# apt-get clean grover:/home/ed# apt-get upgrade Reading Package Lists... Done Building Dependency Tree... Done The following packages have been kept back: kernel-image-2.6-amd64-k8 openoffice.org openoffice.org-debian-files openoffice.org-l10n-en xprt-xprintorg The following packages will be upgraded: bind9-host 1 upgraded, 0 newly installed, 0 to remove and 5 not upgraded. Need to get 108kB of archives. After unpacking 0B of additional disk space will be used. Do you want to continue? [Y/n] n Abort. No luck with clean. Thanks Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Wednesday 11 May 2005 1:59am, mtms wrote: On 11 May 2005, 00:40, Ed Cogburn [EMAIL PROTECTED] wrote: Because its already been done. mtms announced earlier that he's keeping a mirror of our old non-free. And he's not going to get sued by anyone either. Wait a mo! Not me, bytekeeper.as28747.net keeps the mirror. I'm not involved with them in any way :) Oops! :) You posted the message, so I figured you had something to do with it. I'm wrong. Making assumptions about the messenger based on his message is a mistake I always try to avoid, its too bad others don't try to avoid doing the same. I apologize for the mistake, mtms. At least you're now officially off the hook, so all those hundreds of people lining up to sue over Debian's AMD64 port because its temporarily not on a Debian server won't go after you now. :) (Note to others: if you want to attack and ridicule me some more, you'll need to CC me, as I'm not longer subscribed to this list) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nvidia-glx and other non-free packages
On Sunday 08 May 2005 5:22am, mtms wrote: Who needs nvidia-glx or other non-free packages can (still) find them adding these lines to sources.list: ### non-free deb http://bytekeeper.as28747.net/debian-amd64-alioth-old/pure64/ sarge non-free deb http://bytekeeper.as28747.net/debian-amd64-alioth-old/pure64/ sid non-free Hope it helps, Thanks for this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian We ARE Debian for Heaven's sake! This move to another server is just TEMPORARY! We WILL be Debian as soon as sarge gets out and development on etch picks up. Who in the world is going to get upset when they know we will soon be part of official Debian, and they've already given permission for Debian to distribute their stuff! Get real people! How many non-free packages have been cleared? Why haven't you at least set up non-free and moved the packages known to be ok into it? I know for sure that the rogue-like games in non-free are perfectly fine and can brought on-line now, since they and a lot of other stuff is in non-free just because they are old pre-GPL software with don't sell for money restrictions which make them fail the DFSG test on distribution, but are otherwise fully open-source (and who's earlier authors can no longer be found to ask them if they'd agree to a change to the GPL or some other Free license). In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. thats all you need to get! Hogwash. This sounds like an extremely defensive response. How many packages have been cleared for non-free? Why haven't you just put up a non-free section with the stuff thats been cleared? Why has it been more than a week, with no non-free section at all, no indication of how the vetting process is going, and with you telling us above that we don't need to know anything more? Now do you understand why I'm just a little bit skeptical? Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. Re-evaluating non-free is just silly when we're going to officially become Debian again in a few months, certainly less than a year, anyway (assuming Debian gets Sarge out soon). Heck, Debian doesn't even advertise us, we're the bastard child they don't want to talk about, because when they do it reignites the argument about which architectures to officially support, and why... and why not. NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote: Ed Cogburn [EMAIL PROTECTED] writes: On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. Will you pay us for the work and cover legal fees if any should arise? Sure. Because any rational person knows it won't happen. Give us one reasonable example of why some one would waste time and money to sue the amd64.debian.net server owner in this matter, when they have absolutely nothing to gain, and potentially a lot to LOSE if the judge gets angry about the pointlessness of their suit? This would happen in Germany, and the German judicial system hasn't yet become as screwed up as the American system. Besides, by the time they FIND OUT, we'll be officially part of Debian anyway! Seriously, get some patience and don't inflame the situation please. Things like most of that is of zero help in deciding what can go in and what not. We know most of it can, the question is what packages are those in particular. We can't just add all of non-free and say it is mostly OK. Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Then load everything up but pine, if that's the only one you know of. I've already listed more packages that I know about, and I'm just a regular user. I'll bet if you had asked on d.d you could have quickly put together a list of 30 - 50 packages which were ok. So why nothing in over a week? Are you holding up all of non-free just because of 1 package? And what is the point? We are Debian. It doesn't matter which server we're on. It will be at least 18 month going by the release plans till etch will be stable and sarge amd64 can be dropped. Considering the track record of past timelines 2-3 years is probably more accurate. That is a long time for someone to start suing. Hogwash again. We aren't talking about *release* dates, Goswin, we're only talking about how long it takes before debian.org is ready to move the amd64 port onto it. Once sarge is out, everybody can get back to moving *forward*, as opposed to running in place right now, which means the ftpmasters of debian.org can do what they need to do to make room for pure64 *Sid*, and move it over so we get synced up as Etch. Sarge can stay where it is, that's not the issue. Getting the *next* Debian AMD64 port onto debian.org is not going to take 3 years. In one point you are right though: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With the exception of nvidia* package it seems. That is the only package that users missed so far. Right, only the relatively few users of this technically unofficial and mostly unknown-to-the-world official Debian port have noticed you left non-free behind. So explain to us why you believe any copyright holder of one of these problem packages OUTSIDE OF DEBIAN is going to find out about this, and for some irrational reason bothers to sue amd64.debian.net, because it isn't on debian.org (but its contents *is* Debian)? Geez, compared to that, I'd say me getting hit by a meteorite when I next leave my apartment is a guaranteed certainty... heck, let me go write my will before I go to the grocery store. All you need is official blessing from Debian proper, in writing, or at least publicly announced on the net, that yes, the AMD64 port on amd64.debian.net is officially part of Debian, and isn't on debian.org only because of technical problems, but will be physically integrated soon (which is all true). With that, you don't have to worry about any lawsuits. So please stop with this weird excuse. Please excuse us for not giving it higher priority than fixing RC bugs or otherwise vital archive maintainance. But you do have the time to re-verify non-free all over again? So you've wasted a whole week on this, *but* you'd rather be doing vital work. Uh-huh. Well, I do agree with you on one thing Goswin, we all have important things that need to be done, so please stop this pointless exercise, which basically amounts to nothing more than
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 12:44pm, Rafael Rodríguez wrote: I don't know why some of you are making all that noise... if I have understood correctly, non-free will be made available after sarge release (which is supposed to happen within 3 or 4 weeks)... so... why bother the developers instead of thaking them for all the work they've already made? Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well).
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 1:33pm, Lennart Sorensen wrote: On Tue, May 10, 2005 at 01:12:22PM -0400, Ed Cogburn wrote: Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well). So you think Etch will be released soon? If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 2:09pm, Alexander Rapp wrote: Ed Cogburn wrote: If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. If you are so certain that providing non-free amd64 from a non-debian server will not pose any legal problems, and so determined that there are packages (other than nvidia) in non-free that people actually want to use, then why don't you host it yourself? You can apt-get source -b the source packages from ftp.debian.org, upload the amd64-compiled .debs to any webserver you have access to, and get a script to generate Packages.gz. Because its already been done. mtms announced earlier that he's keeping a mirror of our old non-free. And he's not going to get sued by anyone either. There is no legal threat, that's just the excuse they used to get rid of something they never wanted to keep, even though a majority vote of DDs voted to keep it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 3:22pm, Joerg Jaspert wrote: On 10285 March 1977, Ed Cogburn wrote: Will you pay us for the work and cover legal fees if any should arise? Sure. Because any rational person knows it won't happen. Laywers arent rationale. Give us one reasonable example of why some one would waste time and money to sue the amd64.debian.net server owner in this matter, when they have absolutely nothing to gain, and potentially a lot to LOSE if the judge gets angry about the pointlessness of their suit? With that logic: Why does SCO still exist? All laywers are rational enough to know to not waste their time going after an organization THAT DOESN'T HAVE A BILLION DOLLARS. That's why nobody is going to care, Debian is broke anyway, there is no point in a lawsuit. Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). No we cant. Just get a CLUE, we are *NOT* debian. We are as similar as one can get, but the Debian stuff is on .d.o hosts. What difference does it make where we are located if Debian itself says we're part of them? user. I'll bet if you had asked on d.d you could have quickly put together a list of 30 - 50 packages which were ok. So why nothing in over a week? Are you holding up all of non-free just because of 1 package? No. Because of all the crap that is in there and because WE HAVE MORE IMPORTANT THINGS TODO - which includes reading crap from someone who just trolls on lists and not does any work for it. Nobody did any work before because it wasn't necessary. Now you're telling us there has been no work done at all on non-free. So you guys really had no plan at all to get non-free moved over, did you? So why didn't you just say that to begin with? And what is the point? We are Debian. It doesn't matter which server we're on. We arent, get a clue. I'm not the clueless one here. Hogwash again. We aren't talking about *release* dates, Goswin, we're only talking about how long it takes before debian.org is ready to move the amd64 port onto it. Once sarge is out, everybody can get back to moving *forward*, as opposed to running in place right now, which means the ftpmasters of debian.org can do what they need to do to make room for pure64 *Sid*, and move it over so we get synced up as Etch. Sarge can stay where it is, that's not the issue. Getting the *next* Debian AMD64 port onto debian.org is not going to take 3 years. Hell, please go and read what amd64.d.n is and you would see what a mess you just wrote. amd64.d.n will exist as long as Sarge is there. And I've said twice now that I'm not talking about Sarge, I'm talking about Sid. This has nothing to do with release dates on anything, its just about co-location of the port and non-free. And actually there was one who just went over the non-free crap, looking at the licenses, giving us something to work with. If non-free is so important for you - why did you wasted time writing such mails and havent done that work yourself? Because the work has bloody well already been DONE! Everybody knows we are destined to return to debian.org, and we ARE Debian now in all but a technicality, a technicality that won't make a bit of difference in court and goes away with a simple statement from Debian that we are part of them, just not on their servers yet. But you guys never bothered to ask, you just threw out non-free without thinking about it, because it was something you wanted to do anyway. Thats my last mail in this thread, I have more important things todo. Yea, like annoying users by leaving non-free behind just because you're still mad that the DDs voted to keep it. Sure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 4:23pm, Goswin von Brederlow wrote: Ed Tomlinson [EMAIL PROTECTED] writes: On Sunday 08 May 2005 09:27, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian, thats all you need to get! Ok. So from what I understand you are worried there are packages that debian can distribute but only debian has the permission... If this is the case is there not a way you can ask debian to distribute just the non free stuff? ie. This project builds the packages from debian sources, debian hosts the non free stuff on one of their servers. Who is to say we are allowed to build the binaries? This isn't an answer to his question. He's saying why not let the AMD64 non-free be distributed from a Debian server, since you're original excuse was that you aren't Debian. The answer is of course that you never even bothered to ask Debian for help or for a statement about your identity that would eliminate any theoretical legal threat. Hell, you could have just kept non-free on alioth and linked to it from AMD64's new location until a solution to the problem was found since non-free by itself is very small and the move away from alioth was because of space reasons, but no, even keeping the old location temporarily wasn't acceptable, non-free had to go, period. You saw a chance to get rid of non-free, even though its temporary, even though a majority of DDs have officially disagreed with you in a vote, and its only result is to annoy the AMD64 users until AMD64 returns to a Debian server, all because of your extremist ideology. I've been using Debian since pre-1.0 days when I got it off an Infomagic CD when I didn't have regular net access, but the times have changed, certainly the people around Debian have. I never would have thought that Debian would reach the point where it would deliberately and **pointlessly** annoy its own users because of software religion, instead of just trying to produce the best Linux distro possible, but its apparently come to that. No wonder Ubuntu looms large over Debian now, they're taking the best of Debian, but leaving behind the religious wars, and they will now gain strength and speed as Debian slows down due to endless religious infighting. Anyway, its been fun, but its time to move on now, apparently. Goodbye all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nvidia driver failed to install
On Friday 06 May 2005 6:22am, Alexander Fieroch wrote: (II) LoadModule: v4l2 (WW) Warning, couldn't open module v4l2 (II) UnloadModule: v4l2 (EE) Failed to load module v4l2 (module does not exist, 0) I'm guessing this is for video for linux (v4l), right?Don't know anything about v4l, but your xfree config appears to have several problems besides nvidia. (II) LoadModule: glx (II) Loading /usr/X11R6/lib/modules/extensions/libglx.a (II) Module glx: vendor=The XFree86 Project This is the wrong glx module. The right one is the one from nvidia (the vendor line will say NVIDIA Corporation. It doesn't look like you've loaded nvidia-glx and modified the xfree config correctly... (II) Loading sub module GLcore (II) LoadModule: GLcore (II) Loading /usr/X11R6/lib/modules/extensions/libGLcore.a Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_clip.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_norm.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_xform.o: No symbols found Skipping /usr/X11R6/lib/modules/extensions/libGLcore.a:m_debug_vertex.o: No symbols found (II) Module GLcore: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Server Extension, version 0.2 The instructions for installing the nvidia module told you to remove the glcore line in xfree's config file. IIRC, nvidia (or at least OpenGL) will not work with this module loaded. (II) LoadModule: nvidia (WW) Warning, couldn't open module nvidia (II) UnloadModule: nvidia (EE) Failed to load module nvidia (module does not exist, 0) This is from my xfree.log: (II) LoadModule: nvidia (II) Loading /usr/X11R6/lib/modules/drivers/nvidia_drv.o (II) Module nvidia: vendor=NVIDIA Corporation The module its looking for IS NOT the kernel module, its looking for the XFree driver interface TO the kernel module. There are 3 different modules involved with nvidia: 1) The nvidia kernel module, that has to be loaded before X can even start. If your system is setup correctly that may not be necessary as your kernel can auto-load modules itself if it knows enough about them. In most cases though, people simply put 'nvidia' in their /etc/modules and have it loaded on boot-up. 2) The nvidia_drv module, which is part of the nvidia-glx package, which provides the Xfree interface to nvidia's kernel module. The kernel module speaks to the video card, this driver module is for Xfree to talk to the kernel module. This is the module being referred to as 'nvidia' in your xfree config file, NOT the kernel module, which has to already be loaded, or else THIS module will fail to initialize. 3) The nvidia glx module for accelerated OpenGL video. Nvidia's module is also simply called glx, the same as the xfree86 module, but the vender line will be different, that's why I know you're loading the wrong one now. This is also in the nvidia-glx package. The nvidia-glx debian package is NOT optional! :) You have to have it was well as the kernel module, because it has the nvidia_drv module. Its true that you can leave glx out of your xfree config if you don't want OpenGL, but you need Debian's nvidia-glx package installed anyway for the nvidia_drv module. (Nvidia's own installer installs all of this when you use it, not just the kernel module. Debian has split them up, for some reason I don't understand.) My suggestion: 1) Remove the glcore module reference from xfree's config (and maybe the v4l module too if you don't know why that's there either). FWIW, my module section in my config only has this: Load dbe Load ddc Load extmod Load freetype Load glx Load speedo However, since you're doing the dual monitor magic trick (yes, I'm jealous), you may have to have other modules that I don't need, but I know some of the modules you are loading are optional on conventional setups. Note that when you load the nvidia-glx package it will fix things so that the right glx module, nvidia's, will be loaded by the above reference. This is the Debian packages I have loaded: nvidia-glx 1.0.7174-3 nvidia-kernel-source1.0.7174-3 nvidia-kernel-common1.0.7174-1 nvidia-kernel-2.6.12-rc31.0.7174-3+10.00.Custom The first 2 need to be explicitly selected by you, the 3rd is pulled in by dependencies, and the last one, the kernel module, is created by module-assistant or make-kpkg, from the earlier nvidia-kernel-source. These 4 are all you need to get nvidia working. Clear as mud now? :) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 05:02, Joerg Jaspert wrote: On 10283 March 1977, Ed Cogburn wrote: Note: non-free is NOT provided yet. We need to decide what we do with it, as we may be forbidden to distribute some of the software in it (we aren't Debian). Wait a second, if you *aren't* Debian, it should be *easier* for you to provide non-free, not harder. No, not beeing Debian makes it only harder, not easier. There may be stuff in it with Yes, Debian is allowed to distribute it - which makes it undistributable for anyone else, except he gets the same. Or stuff you aren't allowed to built and then distribute or whatever else some idiot thought about for his license. The only problem with non-free is the internal politics of Debian. No. Ubuntu certainly doesn't have any problem providing access to, but not support for, non-free. I dont care what/how they do it. Maybe they analyzed it, or just ignore it and wait if someone plays law-games with them, i dont know. I dont want law-games for me or for our mirrors or for the place where we host the machine, thats not worth the stuff thats in there, so its not added right away. The best thing is to keep the packages you have now until we find what's going on. Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 09:27, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian, thats all you need to get! Ok. So from what I understand you are worried there are packages that debian can distribute but only debian has the permission... If this is the case is there not a way you can ask debian to distribute just the non free stuff? ie. This project builds the packages from debian sources, debian hosts the non free stuff on one of their servers. Thanks Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libglade 2.5
Hi, Where would I find source for the experimental glade 2.5 stuff that I can built for amd64? Second whats the process to build the binary package (or point me to an faq). TIA Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nvidia driver failed to install
On Tuesday 03 May 2005 6:23pm, Alexander Fieroch wrote: Hello, I've tried again the 64bit version of debian (kernel 2.6.11-9-em64t-p4-smp) but failed again with building the nvidia driver. There is a link /emul/ia32-linux/usr/lib/libGL.so.1 to the existing library libGL.so.1.0.7174, so why does the nvidia installation fail? Because NVIDIA's installer doesn't work on our 64bit system. Some of the directory locations are different, and their installer gets confused. Use the nvidia-* debian packages instead. Install them with apt, and build your NVIDIA module with module-assistant (or kernel-package if you ever decide to start building your own kernels - it can build your external modules when it builds the kernel). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installing nvidia driver for pci express 6600GT?
On Tuesday 19 April 2005 11:08pm, Alexander Fieroch wrote: Lennart Sorensen wrote: On Tue, Apr 19, 2005 at 05:41:20PM +0200, Alexander Fieroch wrote: x.org just adds more complexity and is yet another unknown. If nvidia-kernel-source is installed and built against your current kernel's headers and installed, and nvidia-glx is installed, and X is configured to use the nvidia driver (not nv or vesa or anything else), and your user is in the video group (adduser username video) and the nvidia module is load (adding to /etc/modules works) then is should just work. It almost always does. It all seems to be ok but it does not work. So I think I'm going back to 32bit linux and xfree86 till stable release of sarge. Then I'll try it again. That's rather drastic Alexander, no need to go back to 32bit at all, but I do recommend returning to XFree86 for now because I'm pretty sure you'll have problems getting glx running right on Xorg even if you get it to run now, it depends on where you're getting Xorg and the nividia module packages from, Debian or Ubuntu or somewhere else. If you're getting Xorg from Ubuntu, you might have to get the nvidia modules from them as well. VGA compatible controller: nVidia Corporation: Unknown device ... ... Capabilities: [78] #10 [0001] Your lspci output bothers me, because it doesn't mention the I/O method its using (capability 78 isn't described at all here, which is worrisome), and the fact the device ID isn't even recognized. I'm using the default debian kernel 2.6.8-11-em64t-p4-smp and it should contain drivers for PCIe. I'm sure the drivers are there, but are you absolutely sure that PCIe support is _turned_on_ in your kernel's config? It may not be turned on by default or automatically recognized (AGP support has to be explicitly turned on for most configurations, Athlon64 is probably the only exception because the AGPGart support is builtin to the CPU). I think its possible that your card is recognized only as a normal PCI card and that its standard VGA/VESA features work fine in normal PCI mode, but the nvidia driver is expecting either an AGP or PCIe device and its not finding either one. Note that the nvidia kernel driver can load just fine in some situations even if there is a problem with the card, the nvidia driver doesn't actually get *used* (attempt to initialize a graphics mode using AGP/PCIe I/O) until you actually run X. Show us what the screen output is when you load the nvidia driver (the message from the driver). (II) LoadModule: GLcore Hm, I do have removed GLcore from xorg.conf. Why is it still loaded? Because its the Xorg glx that is being loaded, not the nvidia glx module (they are the same name, and therefore conflict). Look at the log file you posted earlier, every module also prints its author when being loaded. Xorg/XFree glx will pull in GLcore, but NVIDIA's module doesn't use it. This is a separate problem from your card not being recognized, I suspect this is happening because you're using Xorg from somewhere else, but using the nvidia modules from Debian? Your card should still be recognized under Xorg, but to solve the 'glx' problem (which involves the glx modules/libraries being put in the wrong places because there are differences in the directory structures of XFree and Xorg) you'll probably have to reinstall XFree from Debian. Whatever you do, remember my earlier point, if you're getting Xorg from Ubuntu use Ubuntu's nvidia modules too, so you know they are compatible with one another. If you go back to Debian Xfree, use Debian's nvidia modules. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 into mainstream
On Wednesday 20 April 2005 5:34am, Clive Menzies wrote: Debian and Ubuntu appear to have a symbiotic relationship, at least well kinda I regard them as complementary rather than competing offerings. Many of the live CDs and desktop distros are debian based and not only expand user choice but extend the reach of debian and free software. Naturally, there is a fear that widespread adoption of alternative distros will be at the expense of debian; on the contrary, all these debian derivatives are strengthening rather than weakening it. Please show us evidence of this. What I suspect is that the alternatives are moving so far ahead of Debian, because Debian is having a long and painful childbirth of Sarge so all forward looking work is on hold, that very little is getting back into Debian. I'm afraid of what happens if Ubuntu gets so far ahead, and continues to diverge from Debian base while they do, and meanwhile Debian remains mired in its identity crisis, that eventually Ubuntu just decides they can't wait for us to catch up any more and they simply fork Debian. After all modifying and distributing your changes is what free software is all about - so we should embrace it. Except when the changes create incompatibility. It isn't so much code that I'm worried about forking, its the standards Debian is built on. What happens when Debian can't move fast enough for Ubuntu so Ubuntu starts making incompatible improvements to dpkg/apt to improve their customer's experience with updating their system? This wouldn't be much of an issue to me if Debian were moving forward with a clear vision for the Desktop. However Debian doesn't have a clear vision for the Desktop, it doesn't even have a clear vision of what it wants to be 10 years from now. Because of this, Debian is not moving forward at a decent pace, and that's why I worry about the derivatives of Debian moving so far ahead that their symbiotic relationship with Debian simply becomes parasitic, with the derivatives slowly sucking energy, ideas, developers, and users from Debian itself. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of the amd64 gcc-3.4/gcc-4.0 archive
On Monday 18 April 2005 5:02pm, Andreas Jochens wrote: I fully agree with this. Moreover, I think that to avoid confusion, the documentation should be changed so that it does not mention the gcc4 branch at all. Just so you know Andreas, what you're doing with gcc-3.4(4.0) is important and necessary work to get Debian updated for the newer gcc, and folks like me do appreciate your work there, its just that we think its best if new users of Debian AMD64 start out with the official pure64 first, before finding out about gcc-3.4(4.0). Thank you for your effort to make Debian better. Cheers, Ed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installing nvidia driver for pci express 6600GT?
On Tuesday 19 April 2005 4:30am, A E Lawrence wrote: Jacob Larsen wrote: Alexander Fieroch wrote: So whats the problem with the proprietary nvidia driver? The module can be loaded with modprobe and lsmod shows me that it is loaded, but xorg says (EE) Failed to load module nvidia (module does not exist, 0)! There are two components: a kernel module which sounds as if it is loaded, and a driver module which is loaded by X which it sounds as if you are not finding. Almost certainly a ModulePath (?) problem. Umm, no. Its the kernel module that it isn't finding. That's the only module named nvidia. The other module from NVIDIA is their own Opengl module, buts its just called glx, although it identifies its author as NVIDIA and not Xorg/XFree86 when its loaded. From the earlier log, it seems the grand parent doesn't have that setup either, as Xorg is loading its own glx not NVIDIA's version. To the grand parent: can you load the nvidia module with modprobe from the command line before trying to run X? Does lspci (from pciutils deb) show your video card in its list? Do you have PCIe enabled in the kernel? (Just guessing on the last question, I don't have a PCIe mobo myself). If you're also compiling your own kernel, try using the nvidia packages provided by Debian along with kernel-package. Install nividia-kernel-source then use make-kpkg to compile the kernel and nvidia driver for your system, then once thats installed, install nvidia-glx. Warning: There may be a difference between Xorg and XFree86 on this matter. NVIDIA's own package has problems with Xorg, I know from experience (which is partly why I'm back to using XFree - being lazy, I'll just wait for Debian to upgrade to Xorg). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of multiarch?
On 4/9/05, Thomas Steffen [EMAIL PROTECTED] wrote: In general, I agree with the proposal on http://www.linuxbase.org/futures/ideas/multiarch/, but I think it is missing a crucial step: /bin also needs to be separated. The difference between stuff in /bin and /lib is that the names of stuff in bin are important to the user because she has to type that name to run it. Libraries in /lib OTOH, are handled automatically by ldd. Since the different binaries are going to have to have different names so the user can distinguish them from each other, there is no value in putting them in separate subdirs under /bin. You're better off just adopting a standard name extension for these things and having mozilla-browser-amd64 and mozilla-browser-i386, and then setting up an /etc/alternatives symlink called mozilla-browser to point to which one the user prefers as the default. All of that however can be done outside of the LSB Multiarch proposal. In fact it can be done unofficially within Debian as long as the DD's responsible for mozilla-i386 and mozilla-amd64 are willing to cooperate with one another and have their package's install scripts share the /etc/alternatives symlink. This is really what the /etc/alternatives mechanism is designed for, so for Debian at least, that would be how to solve the problem. Keep in mind, that all this effort is to handle just a small number of cases, most of which are temporary and will be solved the proper way some time in the future, like OO (and all other FOSS) eventually getting fixed so it can compile and run in 64 bit mode, various closed-source drivers being updated by their owners to work in the environment where many of their users are now moving too (64bit), or like 32bit Flash being replaced by an open-source equivalent that works in both 32bit and 64bit for example, assuming Macromedia chooses to ignore its customers. Once you take all those cases away, what you're really left with is just old proprietary closed-source software whose owners no longer exist or are uninterested in supporting their Linux users. There is no good solution to those remaining cases, except to stand as excellent examples to people in the future that they should stick to open source software to avoid being abandoned by a profit-oriented company that might one day fold up and disappear on them. The best solution here is to bite the bullet and drop the old software in favor of something newer, even if the alternatives aren't quite as good as the old. The newer stuff at least has a future, and might get as good as the old eventually. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 into mainstream
On Monday 18 April 2005 10:44am, Lennart Sorensen wrote: On Mon, Apr 18, 2005 at 10:07:55AM -0400, Ed Cogburn wrote: And if Ubuntu takes hold Debian may *never* become a good choice for the desktop, that is what I fear, and that would mean abandoning Debian. :( There are many people that really don't care particularly much about desktop anything. I suspect they are often the people that make debian work. Not always but often. Sigh. Which is why it seems the desktop oriented people are migrating to Ubuntu or Gentoo or their doing their own thing within Debian but not *with* Debian, or whatever. This is part of the Identity Crisis I referred to earlier. The Server people aren't interested in the Desktop as Kyuu's post shows, and the Desktop people aren't interested in the Server. This is the kind of dichotomy that I fear may *require* a split just to resolve. Like an amicable divorce. :) Depends on how well Canonical does. If they continue to gain the momentum of The Desktop Debian, then in a few years they may be even in a position to fork Debian all together, or stop supporting compatibility on the package level, if Debian itself doesn't respond to the momentum that Ubuntu is feeding on. Well I sure hope Debian does not decide to trade in quality for speed. Spoken live a true Server dude. :) The Desktop people aren't interested in tossing out quality, but part of their definition of a quality OS is reasonably up to date software. If it can increase speed of development and release without a drop in quality, then sure I am all for it. But it's not a trade I would be willing to do if a trade was requried to get it. Which is why there probably *should* be 2 Debian siblings and not one Debian. The Server and Desktop siblings have common roots and a shared biology but very different, and unfortunately, incompatible goals. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 into mainstream
On Monday 18 April 2005 4:54pm, Niklas Ögren wrote: What do you mean by core archives server? Isn't that what (us.)debian.org is, and what I'm referring to? Despite whatever the ping times are with debian.org (when I was using i386 I was using a faster mirror too), it doesn't have pauses in transfers like alioth has. Alioth appears overloaded, and moving pure64 over to the main debian.org, even while still in an unofficial status, would help alioth. Why are you loading alioth then, when it's not working as expected for you? Personally I'm using its mirrors, like bach.hpc2n.umu.se without any problems... AFAIK, alioth *is* the only local mirror for my region (US). There's nothing else close to me. So is it finally time for The Mother of All Forks? :) Brother Server Debian, meet sister Desktop Debian, your biological twin, she's not as strong as you are, but she's a hell of a lot prettier. :) (Note the use of fork above is merely for humor, in reality a split of Debian would more resemble a corporate reorganisation than a fork. There would I believe be very little, if any, forking of computer code at all.) (Yes, I read all the way down here.. :) Thank you! :) I realize I do have this problem where I occasionally start rambling.,.. :) I totally agree with you. If we want to keep debian as the good alternative, a split may be necessary. In the process more developers needs to be attracted to debian to make it happen, and make it good! I'm sure it's possible, if things happen more quickly when there still is something to save! Right, what people have to realize is this kind of split isn't really a fork or civil war or a bad thing, it would just be two very similar organizations (nearly twins actually) working together where possible, which would be most of the time, and going in different directions where absolutely necessary, just like how Debian and Ubuntu are working together now.
Re: amd64 into mainstream
On Monday 18 April 2005 6:31pm, Christopher Browne wrote: On 4/18/05, Ed Cogburn [EMAIL PROTECTED] wrote: I full agree here: Ubuntu is more attractive to the average end user. But I do not understand why everybody is so upset about this. After all, there is no one size fits all distribution. No, I'm not saying Ubuntu will kill Debian or vice-versa, or anything like, but I am saying that the more energy and momentum for a desktop system Ubuntu takes from Debian, the longer it will be for Debian itself to get its act together on the desktop, because everyone who wants to see Debian on the desktop are now saying Why not just use Ubuntu?, and are moving to it. It seems to me that this misses part of the real problem. As far as I can see, the main merit of Ubuntu isn't anything to do with desktop support, but rather to do with the fact that it is several years more up to date than Debian/stable. I don't know how many people are using Ubuntu on servers, but most comments I see are about people using Ubuntu on desktops. A /. thread I saw some weeks ago about Kubuntu was a fairly large discussion and the topics ranged over many things about Ubuntu/Kubuntu/Debian but there wasn't anyone there talking about Ubuntu on a server, the topics were mainly about Ubuntu being the desktop platform that Debian itself has never bothered to create along with the usual GNOME/KDE flames. :) I find it ludicrous that Debian/stable still has PostgreSQL 7.2.1 as the latest official version of PostgreSQL even though there have been a whole ream of security updates and other fairly severe bug fixes in the binary compatible 7.2.x series. And despite the PostgreSQL project getting accused of having long release cycles, that doesn't even touch the fact that there have been three _MAJOR_ release cycles (7.3.x, 7.4.x, and 8.0.x) since then. And I usually _am_ something of a curmudgeon on stability of releases; at work, we never wound up touching 7.3.x because by the time we were ready to consider an upgrade from 7.2, 7.4 had been out for a while. And we're now just starting to _think_ about 8.0 upgrades... I am running Debian/unstable on my desktop pretty happily; I just find it painful that the stable release is so woefully out of date. I agree. But I really see several problems here, not just one bogeyman we can point to. The threads in debian.devel after the infamous meeting where Debian decided to get rid of some lesser ports pointed to many different problems in Debian's organization, most of which require different solutions. The quotes above are used because I don't really know the true nature of that meeting, only that it was interpreted that way by some DDs. The fact that there is so much suspicion involved is another indicator of serious trust issues, mainly between some DDs and the ftp masters of debian.org. That alone is a major problem I hope Brandon can get to the bottom of. The Server/Desktop problem is tangential but still related to the delay problems. The example you chose to use (not being critical here - your example is a good one - but also indicative of the Desktop/Server problem as well), a SQL database server kind of illustrates the dilemma that a Debian-for-everyone now has. The Server people want up-to-date SQL, PHP, and Apache, while the Desktop people are clamoring for KDE, GNOME, nvidia drivers, OpenOffice, games, etc, etc. Yet Debian's infrastructure is having a hard time keeping up with everything at once, especially the package auto-building, and *especially* on those older ports with (relatively) less powerful machines to act as auto-builders. Right now the current problems can be alleviated by not releasing some of the lesser ports as often as, and not at the same time, as the major ports are released, which is what's being discussed. What isn't being discussed is the underlying issue that's created the current problem in the first place: Debian trying to be everything to everyone only to end up dissatisfying many. Ubuntu is proof Debian, in its current form, can't be everything to everyone, and I think we generally agree with that, however It may well be that there is room for two systems: 1. Debian, as the grand collector of package updates, and 2. Ubuntu, as the folks that actually create release candidates on some reasonably regular schedule. That is unacceptable to me for the same reason you chose Debian for your Server needs. Ubuntu != Debian. That's why there's still people like me hanging around with Debian even though we'd probably be better served in a technical sense by moving to Ubuntu's platform. You want Debian on the Server, we want Debian on the Desktop. Its beginning to look like Debian clearly can't do both to both our satisfaction. Just as the Linux world found out that Linus couldn't scale, the Debian community I think is beginning to see that Debian
Re: Sarge and Sid
On Tuesday 19 April 2005 10:33am, Marcin Dbicki wrote: I've just installed Sarge. I want to upgrade it to Sid (previously I did all deb upgrades for Sarge). I am replacing sources.list entries, apt-get update and then apt-gate dist-upgrade. Nothing happens. It seems like Sarge and Sid have the same packages Show us what your sources.list was, and what it is now.
Re: ia32-libs-openoffice.org [Fwd: Re: Conflict with ia32-libs]
On Tuesday 19 April 2005 11:08am, Olleg Samoylov wrote: Package: ia32-libs-openoffice.org Version: 1.0.1 Severity: serious Conflict witn ia32-libs: incorrect. Must I rewrite bug report to maintainer of ia32-libs or you will fix this? I won't. As I said I once made a unofficial package but since amd64 isn't in Debian I didn't pursue it further. Ask the amd64 folks, not us... And ask them, why they didn't change Maintainer:, too. sarcasm Well, gee, and all this time I thought we were all running the same Debian. Apparently though, we've already reached the us vs. them stage even amongst ourselves. /sarcasm As long as we're unofficial, we don't exist. Grrr.. Another reason we're losing people to Ubuntu and Gentoo, who've already adopted AMD64 because they realize that's where the x86 world is headed. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: amd64 into mainstream
On Monday 18 April 2005 4:35am, Thomas Steffen wrote: On 4/18/05, Ed Cogburn [EMAIL PROTECTED] wrote: Alioth doesn't perform as well as us.debian.org for me for some reason, Neither does the core archives server, but that is what mirrors are for :-) What do you mean by core archives server? Isn't that what (us.)debian.org is, and what I'm referring to? Despite whatever the ping times are with debian.org (when I was using i386 I was using a faster mirror too), it doesn't have pauses in transfers like alioth has. Alioth appears overloaded, and moving pure64 over to the main debian.org, even while still in an unofficial status, would help alioth. We're talking about work that is going to happen eventually anyway, everyone seems to agree pure64 is ready. As for the mirrors they have always had the choice to not mirror everything from debian.org. And don't forget about the rest of the Debian infrastructure, like having non-us support us too, Which includes some 8 obscure packages. I think it is time to do away with it, anyway. Or create debian-non-EU, debian-non-india and debian-non-china for fairness :-) I'm sure the people who rely on non-us are amused. :) How may of these third parties support PPC, mipsel or S390 because they are supported ports? No, I think support is missing because third parties can always tell people to go with mainstream, which means 32bit userland (and kernel). Redhat and SuSE have already created facts: they are (trying to be) fully compatible to 32bit userland. For Linux, the kernel and userland can be compiled for whichever one you want. SUSE, Mandrake, RHEL, Ubuntu and most others have already done that, The *only* problem is with closed-source products that I and many others can, and do, happily live without. 64 bit support is not what is keeping AMD64 from being an official Debian port. There are a *lot* of Athlon64s out there already, compatible with and competitively priced against existing 32bit X86 chips, Sure, but that does not translate into an incentive to install debian/amd64. On AMD, you will see a nice performance gain, but on Intel you don't even get that. Does EM64T only add the 64 bitness, and not the extra 8 gp registers? [snip] (And most of these problems are not 64bit related...) Right, all of that would be also true if the system had a 32bit CPU. The whole testing process seems to be mostly stalled due to changing problems with one of the more obscure platforms... no, I don't want to restart that debate, but I want to mention the bigger picture. I'm fairly well aware of the bigger picture, as thats what I'm grumbling and whining about. :) But alas, despite the writing on the wall, we still have to wait for Debian to get its act together, all the while losing more people to (K)Ubuntu - I have to admit to having been seriously tempted to switch myself lately - if our AMD64 support is complete, then Ubuntu's AMD64 platform is polished. I full agree here: Ubuntu is more attractive to the average end user. But I do not understand why everybody is so upset about this. After all, there is no one size fits all distribution. No, I'm not saying Ubuntu will kill Debian or vice-versa, or anything like, but I am saying that the more energy and momentum for a desktop system Ubuntu takes from Debian, the longer it will be for Debian itself to get its act together on the desktop, because everyone who wants to see Debian on the desktop are now saying Why not just use Ubuntu?, and are moving to it. Debian can still be the best distribution for servers, for weird hardware and for development, but for the average desktop user it never was an outstanding choice. And if Ubuntu takes hold Debian may *never* become a good choice for the desktop, that is what I fear, and that would mean abandoning Debian. :( What I would really like to see is binary compatibility between Debian and Ubuntu. So far, that seems to be mostly the case, but it is more a coincidence of freeze dates than a feature. Depends on how well Canonical does. If they continue to gain the momentum of The Desktop Debian, then in a few years they may be even in a position to fork Debian all together, or stop supporting compatibility on the package level, if Debian itself doesn't respond to the momentum that Ubuntu is feeding on. Sure if they turn evil down the road, we can always come back to Debian, but in the meantime Debian itself will not have improved much because most of the users and developers interested in the desktop will have spent their energies in the Ubuntu camp. And yes, a resurgent Debian could theoretically pick up the last pieces of Ubuntu before they went to the dark side, but that would mean making major alterations to Debian to integrate Ubuntu's work which will have deviated significantly from base Debian by then, and it means users like me will have switch *again
Re: ia32-libs conflict error against ia32-libs-openoffice.org during apt-get upgrade
On Monday 18 April 2005 9:39am, Max wrote: Lennart Sorensen wrote: Sure, the libs should work fine, but who owns the conflicting files now? the oo libs or the ia32 libs package or both or neither? Who cares? As soon as you know what and where might be a problem, it is I think Lennart is concerned that there doesn't appear to be good coordination among DD's of important library packages. 2 packages trying to own the same file is a rare problem for Debian normally, especially packages providing shareable libraries. I don't know the details though, as I don't use the ia32 stuff. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc-3.4 archive
On Monday 04 April 2005 3:16pm, Javier Kohen wrote: Hi, I've been using the /gcc-3.4 archive from Alioth. Is there any difference among that one, debian-gcc-3.4 and debian-pure64-3.4? I mean a user-noticeable difference, I've read archive-structure and I think I understand, but gcc-3.4 isn't mentioned there and I don't really know what the consecuences of arch:all being rebuilt on amd64 are. Thanks for your advice, I asked the same question just a few weeks ago. :) gcc-3.4 began, and still is, an experimental branch of pure64 using a later version of gcc. It began by using gcc-3.4 for building itself, hence its name, and is now almost completely converted over to gcc-4.0. As I understand it, it will always remain an experimental branch and at some point in the distant future, when pure64 upgrades to gcc-4.0, will simply go away. For starting out with AMD64, you should stick with pure64 (now called debian-pure64 on alioth). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: List split?
On Tuesday 29 March 2005 4:38pm, John Goerzen wrote: On Tue, Mar 29, 2005 at 01:18:34PM -0800, Ryan Lovett wrote: Now that debian-amd64 is successful enough that newbies have managed to get it working, could the list be split into something like -user and -devel? I'm more interested in the development of the port and not other (still important) issues like how to get GNOME/KDE/networking/etc. working on amd64 which have dominated the list of late. Shouldn't most of those go to the regular debian-user list? When Debian officially adopts us eventually, a d-u equivalent is where the user-level stuff should go, but right now d-u is pretty much useless because all the AMD64 users are on this list. :) Seriously though, d-u's traffic is so high, I long ago gave up on it, even when I was still running i386. I don't know what the official position is on this, but I would prefer Debian keep the AMD64 specific user mailing list (the developers OTOH, may *want* to integrate into the official d-d, I don't know), since the regular d-u is now a de-facto i386-specific list. AMD64 users will just be drowned out on that list, forcing most of us to use Subject headers to separate us, e.g. Subject: [AMD64] xxx, at which point you have to ask, why bother? For a long while to come AMD64 users are going to have AMD64 specific issues/problems, so I believe we should keep our own specific user list for now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Future of gcc-3.4?
On Tuesday 29 March 2005 7:32pm, Theodore Kisner wrote: I have appended the message below. Thanks Theodore. 3. The documentation should clearly state that the 'pure64' archive is the 'official' one for the amd64 port which will be integrated into the Debian archive after sarge is released. Should we even make new users aware of gcc-4.0 when making their initial decision to try AMD64? In other words, perhaps we should remove all references to the experimental branch in the AMD64 HOWTO, especially if I understand Andreas above to mean that the gcc-4.0 branch is a dead-end that will at some point in the distant future simply go away (or that the official branch will eventually catch up to gcc-4.0 and render it redundant)? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Buildtime woes and other stuff
On Thursday 24 March 2005 7:16am, Oliver Korpilla wrote: I hate this $%?!@ board!!! (I've overlooked the fact that ATI made not only the onboard graphics but the chipset as well!) Nothing works as intended... If MSI or ATI would be so kind to give me some documentation so I could fix this mess myself... But MSI does not feel responsible, and ATI failed to react. Their fglrx driver for x86_64 even fails to compile - and I guess this is what they meant with This board supports Linux ... I sympathize for you Oliver. Its frustrating to the extreme to get hardware that works fine for Windows but doesn't work well under any other operating system because the manufacturer simply doesn't care. ATI's dismal record with video drivers for Linux suggests to me that they wouldn't be much better when supporting their mobo chipset under Linux either. They're just fine if you're only going to run Windows on your machine, but I would stay away from them until their Linux reputation improves. I've heard better things about Nvidia, but I don't use their mobo chipset, only one of their separate graphics boards, so I can't speak to their mobo chipset. I'm using an older MSI Neo board using VIA chipsets, and it works exceedingly well under Linux. Everything I have is recognized including SMBus, ACPI, and Ethernet. However, I don't use SATA, so I can't speak to that. When you replace your current motherboard I suggest looking at a VIA-based MSI board. I have a suspicion that MSI and VIA, both being Taiwan companies, are together able to make a better mobo than MSI working with a foreign company. MSI has been making VIA-based boards for a long time, and no one else has yet produced a mobo with the equivalent of MSI's Corecell technology, AFAIK. The only downside is of course not having built-in graphics on the mobo, I've always preferred a separate video card, but YMMV. Your timing/clock problems are however more widespread. I have related problems too with spurious messages about lost timer ticks. They all appear to stem from problems with the kernel's ACPI driver and/or the kernel not handling a changing CPU clock speed well (this happens to me precisely because I've got the Corecell activated on the mobo and its dynamically changing the CPU speed based on load). I've seen one conversation on lkml about it, and it appears to be a work-in-progress problem, that will eventually be solved within the kernel itself. Whatever you do, do not buy a mobo unless you know ACPI works correctly under Linux (for modern AMD64 mobos, ACPI appears to have become very important), or buy from some vendor with a return policy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: i386 Wine on an amd64 without chroot
On Thursday 24 March 2005 8:07am, Alexander Rapp wrote: In my experience, if you don't have a complete chroot in /emul/ia32-linux/, you can, after installing ia32-libs, just getting the necessary i386 debs for whatever other libraries you need and run sudo dpkg -x foo.deb /emul/ia32-linux/ and it will be extracted into the appropriate directories. Dumb question: How do you get the i386 debs? Do you have to get them manually by browsing debian.org's archive, or is there some way of telling apt to get a deb for a different architecture? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#250086: extipl: please add amd64 support
On Monday 14 March 2005 5:05pm, Taketoshi Sano wrote: Hi. Goswin von Brederlow [EMAIL PROTECTED] wrote: Just plain lseek will do. With _FILE_OFFSET_BITS=64 that is all you need. I don't see the point of using the lseek64 alias. I don't know much about that. My experience told me that libc5 system had llseek, but glibc system don't. And _llseek has just worked on both of them. If you know much about 64bit file access, then please let me know, what point do you see of using just plain lseek and _FILE_OFFSET_BITS=64. And, I want to know from which version of glibc we can use it safely (or can we use it on libc5 too ?) It will help me to explain this to the upstream. FYI, from glibc's info docs: 'When the source file is compiled with `_FILE_OFFSET_BITS == 64' the `lseek' function is in fact `lseek64' and the type `off_t' has 64 bits which makes it possible to handle files up to 2^63 bytes in length.' I believe that define is for building the libc library, not a user program, so if the system has a libc with Large File Support (defined as being compiled with `_FILE_OFFSET_BITS == 64' I assume), then a user app should only need to use lseek and off_t, and the right lseek function will be used by the library. I ran into a similar situation with stat/stat64 with an old glibc that did not transparently switch functions (on my system at least) as it claimed at the time. AFAICT, it does so now. PS, FWIW: '_lseek' or '_llseek' are not listed anywhere in glibc 2.3.2's info docs' function index. If its still there somewhere its probably only for backwards compatibility, and AFAIK we're supposed to be using lseek now. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kino
On Monday 14 March 2005 08:46, Philippe wrote: hi, first a little question should i report bug in sid amd64 on this list or in debian bts ? i'm not sure I can report to debian bts because amd64 is not an official port... Now my bug, I am using kino on 32 bit sid and it work very well but in 64 bit playback is lagguy and blocky, it's totaly unuseable. I don't know if it's a problem with libdv or kino itself. I've also noticed that when encoding it fails to use sse and so is much slower than 32bit. Ed Tomlinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Abit AV8 Gigabit Ethernet
The module is the via_velocity, the Debian AMD64 installer has this module on it though it won't autodetect it. I can't remember if I modprobed it before or after the base install. It is a buggy module under 2.6.8 however, I would recommend upgrading to to a later kernel as soon as possible. It works flawlessly under 2.6.10 Regards Ed. Velocity is AUTO mode eth0: Link autonegation speed 100M bps full duplex On Thu, 2005-03-10 at 21:54 -0800, David Liontooth wrote: Joshua Moore wrote: FYI, I've heard several people have been having trouble getting the onboard ethernet on the Abit AV8 board to work. I just tried the new Hoary version of Ubuntu for AMD64. It appears that it detects the onboard ethernet. As for the speed, I don't know much about how to check that, but it definately gets me connected. Just thought I'd let the world know. Hi Josh, Could you give us some dmesg snippets showing it loading and the name of the module? Dave -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux kernel + gcc-4.0
On Tuesday 08 March 2005 6:49pm, Javier Kohen wrote: Hi, Has anybody attempted to compile the Linux kernel with gcc-4.0? Given that gcc-4.0 is now the default compiler in the gcc-3.4/4.0 archive I attempted to use it to compile the kernel, but it failed during compilation. It displays a bunch of warnings an errors. Googling a bit shows that there are some ongoing attempts at fixing gcc-4.0 miscompilations of the kernel, but I'd like to hear what you're experience on AMD64 was. I'm still using 2.6.10. It *can* be done: 11:20am ed (pts/2) :~ cat /proc/version Linux version 2.6.11-bk2 ([EMAIL PROTECTED]) (gcc version 4.0.0 20050304 (prerelease) (Debian 4.0-0pre7)) #1 Wed Mar 9 04:48:13 EST 2005 I've stopped at bk2 because bk3 makes changes that break NVIDIA's driver. The only problem I had moving from i386 (other than having to recompile libqt3 - which you'll have to if you use KDE) was the warning: losing many ticks problem (its been mentioned on lkml). A warning message some are getting constantly. Related AFAICT to the thermal sensing code in ACPI, turning that off made most of the messages go away, along with disabling HPET control of RTC's IRQ (?). However, those of us with an MSI motherboard that dynamically changes CPU speed will have to put up with false warning messages for the time being because it looks like some parts of the kernel can't deal with CPU's changing speeds dynamically (this is the impression I got from an archived conversation on lkml). Other than those messages, its been rock solid, even KDE too, but it will all come down to your hardware of course. Possibly, I'm just lucky it worked for me. First compile was of 2.6.10-ac12 using the version of gcc-4.0 prior to their latest upgrade to 4.0.0-pre7 in the gcc-3.4 version of pure64. 2.6.11-bk3 also worked (except for nvidia driver). Had to install gcc-3.4 to rebuild libqt3 to fix KDE, and then revert the kernel back to 2.6.11-bk2 while awaiting fixes in NVIDIA's driver. Have an MSI Neo mobo (VIA chipset) with A64 3200+, SCSI and ATA hard drives, ALSA running VIA's audio hardware on the mobo, NVIDIA's driver running an NVIDIA 5600 video card, 1GB ram. PS: Yes, you will get a lot of warnings during a kernel compile, but the majority seemed to be of the nitpick variety, mainly over the signedness of long integers, so my guess is this is a relatively new warning in gcc that only really appears on 64 bit systems and the problems it shows aren't real errors, just something that hasn't been cast properly in the code to make the warning go away. Of course, there's always then the chance that a real warning/error gets buried under all those false alarms. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
aptitude loosing its mind?
Hi, Thought the advice was to use aptitude because it will remove unused packages... Well it seems to think xfs is unused, guess that ps is must be wrong... Me thinks I'll revert to apt-get - aptitude seems very broken. Anyone else see this sort of error on pure64? Ed grover:/usr/bin# aptitude upgrade Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages are unused and will be REMOVED: xfs xfwp xnest xvfb The following packages will be upgraded: cpp-3.3 g++-3.3 gcc-3.3 gcc-3.3-base gij-3.3 ifupdown imagemagick libgcj-common libgcj4 libglade2-0 libglade2-dev libmagick++6 libmagick6 libobjc1 libstdc++5 libstdc++5-3.3-dev perlmagick tora 18 packages upgraded, 0 newly installed, 4 to remove and 0 not upgraded. Need to get 16.2MB of archives. After unpacking 10.6MB will be freed. Do you want to continue? [Y/n/?] n Abort. grover:/usr/bin# ps -ef | grep xfs root 4793 1 0 15:29 ?00:00:00 /usr/bin/X11/xfs -daemon root 7452 7334 0 16:37 pts/100:00:00 grep xfs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: aptitude loosing its mind?
On Saturday 05 March 2005 17:31, Mike Reinehr wrote: Ed, There are times that I certainly wondered what the h___ was going on! The first thing that comes to mind is that xfs was installed automatically to satisfy a dependency of some other program, which subsequently has been removed. (IIRC there are two different font servers that can be used with XFree86, but I can't remember the name of the other one.) In any case, if you wish to keep it on your system, just mark it as manually installed 'm' in aptitude. Is there any way to do this from the command line? More to the point. Aptitude seems a little (just a little) brain dead. It might be a REAL good idea to see if anything from the package is running before deciding it should be removed... Thanks Ed Hi, Thought the advice was to use aptitude because it will remove unused packages... Well it seems to think xfs is unused, guess that ps is must be wrong... Me thinks I'll revert to apt-get - aptitude seems very broken. Anyone else see this sort of error on pure64? Ed grover:/usr/bin# aptitude upgrade Reading Package Lists... Done Building Dependency Tree Reading extended state information Initializing package states... Done Reading task descriptions... Done The following packages are unused and will be REMOVED: xfs xfwp xnest xvfb The following packages will be upgraded: cpp-3.3 g++-3.3 gcc-3.3 gcc-3.3-base gij-3.3 ifupdown imagemagick libgcj-common libgcj4 libglade2-0 libglade2-dev libmagick++6 libmagick6 libobjc1 libstdc++5 libstdc++5-3.3-dev perlmagick tora 18 packages upgraded, 0 newly installed, 4 to remove and 0 not upgraded. Need to get 16.2MB of archives. After unpacking 10.6MB will be freed. Do you want to continue? [Y/n/?] n Abort. grover:/usr/bin# ps -ef | grep xfs root 4793 1 0 15:29 ?00:00:00 /usr/bin/X11/xfs -daemon root 7452 7334 0 16:37 pts/100:00:00 grep xfs -- Debian 'Sarge': Registered Linux User #241964 More laws, less justice. -- Marcus Tullius Ciceroca, 42 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: k3b doesn't respond
I can run and use K3B with no problem. I am using the ide-cd module not scsi emulation. Version: k3b 0.11.20-1 HTH Regards Ed On Mon, 2005-02-28 at 20:20 +, Dr Gavin Seddon wrote: Hi I have a dvd writer on this new amd so I need software to run it. However K3B freezes upon starting. Is this normal for the amd architecture, or, how do I fix? Cheers gs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug in pthread code
Just thought I post the result of some problems with MythTV to the list. It appears that there are still some problems with AMD64 the libc library? Ed. Hi Kyle. I forwarded on your patch to a guy on the Debian AMD64 List. It fixed his problem. There is a bug in the pthread_rwlock code in libc for AMD64. I'm surprised this hasn't affected any other programs. Kyle From: Hanno 'Rince' Wagner [EMAIL PROTECTED] Subject: Re: [Fwd: Re: [mythtv-users] Debian Pure64] To: Ed Murray [EMAIL PROTECTED] Date: Fri, 4 Feb 2005 07:10:06 +0100 Reply-To: Hanno 'Rince' Wagner [EMAIL PROTECTED] User-Agent: Mutt/1.3.28i Hello Kyle, Ed Murray schrieb am 01. Februar 2005: I got sent this patch on mythtv mail list. Is it relevant to your problem? You might want to give it a go... Try this patch and tell me if it works. Apparently, it does! I created a second bootsystem (pure64), copied my old films on my storage drive (which took some days, which is why I have answered now) and tested it. The first part worked fine - I was able to scroll through the films and see them. Next will be to put the tv-card into the system... ;) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
mythtv
I am struggling against a fairly unstable Mythtv. Is anyone using the debian mythtv packages (Compiled using the source version) on pure64 ? I have been going at it for -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
