Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Fri, Apr 15, 2022 at 09:07:10AM +0200, Elmar Stellnberger wrote: > That is not correct. You can make use of SSE instructions also in > x86_32/i386 mode. > > I found f.i.: > https://gcc.gcc.gnu.narkive.com/k0KqaZF2/i386-sse-test-question Well x86_64 uses it all the time, not just optionally, and twice the registers still matters. -- Len Sorensen
Re: amd64 running on Intel Celeron and Pentium? (was: [SECURITY] [DSA 5113-1] firefox-esr security update)
On Thu, Apr 14, 2022 at 03:45:37PM +0200, Levis Yarema wrote: > Is there in deed any reason to prefer amd64 over i586 if you have the > choice and a machine with 2GB RAM or less, apart from perhaps long term > support? Twice the registers and sse instructions for fpu rather than x87? -- Len Sorensen
Re: can we got xorg in debian 10 ?
On Thu, Apr 25, 2019 at 08:39:34AM +0200, Omnis Moriar wrote: > Can we got xorg in minumal version of debian with X-window system ??? I > fight for xorg couse Wayland is our danger to linux world I don't get it. https://packages.debian.org/search?keywords=xorg-server seems so show xorg is in jessie, stretch, buster and sid, so I can't see anywhere it isn't available. -- Len Sorensen
Re: severe bug dpkg following upgrade to buster
On Fri, Nov 30, 2018 at 07:59:06PM +, ael wrote: > zless /usr/share/doc/util-linux/NEWS.Debian.gz is where this was > announced. Wow, I never knew the su command used to have such misbehaviours on Debian. I guess being used to doing 'su -' from years of using different unix systems I never noticed. -- Len Sorensen
Re: severe bug dpkg following upgrade to buster
On Sat, Nov 24, 2018 at 08:43:29PM +0100, Francesco Pietra wrote: > Hi > Following amd64 upgrade from stretch to buster on both a vaio laptop and an > asus desktop,command disappeared, while a severe bug arose with > dpkg that breaks upgrade/install > > pkg: warning: 'ldconfig' not found in PATH or not executable > > dpkg: warning: 'start-stop-daemon' not found in PATH or not executable > > dpkg: error: 2 expected programs not found in PATH or not executable > > Note: root's PATH should usually contain /usr/local/sbin, /usr/sbin and > > /sbin > > E: Sub-process /usr/bin/dpkg returned an error code (2) > > How did you become root? Remember 'su' keeps the environment (including PATH) of current user, while 'su -' gets the proper environment of the root user (so /sbin and such is in PATH). I think sudo already does the right thing. su without the - is almost always the wrong thing to do. -- Len Sorensen
Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
On Fri, Jun 29, 2018 at 10:20:50AM +0100, Luke Kenneth Casson Leighton wrote: > in addition, arm64 is usually speculative OoO (Cavium ThunderX V1 > being a notable exception) which means it's vulnerable to spectre and > meltdown attacks, whereas 32-bit ARM is exclusively in-order. if you > want to GUARANTEE that you've got spectre-immune hardware you need > either any 32-bit system (where even Cortex A7 has virtualisattion) or > if 64-bit is absolutely required use Cortex A53. The Cortex A8, A7 and A5 are in order. The A9, A15, A17 etc are out of order execution. So any 32 bit arm worth using is pretty much always out of order execution. For 64 bit, I think the A35 and A53 are in order while the A57, A72 etc are out of order. Of course non Cortex designs vary (I think Marvel's JP4 core was out of order execution for example). After all, in general in order execution equals awful performance. -- Len Sorensen
Re: Troubleshooting touchpad Acer Aspire AO1-413
On Fri, May 05, 2017 at 12:00:45PM +, Hugo Ricardo wrote: > Ive bougth a new machine, it had Windows 10 preinstaled. I changed it for > Deepin but now, the touchpad isnt working... how can I solve this problem? A quick search makes it look like a common problem with Acer's. https://unix.stackexchange.com/questions/223111/acer-aspire-touchpad-not-detected It has two optinos there. One is to change a BIOS setting for the touchpad from advanced to basic, which apparently fixes it, or you can do some manual fixing of the X config to make it work. Apparently even windows users sometimes have issues with the advanced mode setting. Advanced mode is apparently required to get swipe and pinch zoom and such to work. If you just want it to work as a mouse, basic is much more compatible. -- Len Sorensen
Re: optimize.py issues with stretch and jessie
On Mon, May 01, 2017 at 08:11:45PM +0200, Francesco Pietra wrote: > Hi Lennart: > I solved the problem of importing python module scipy.optimize by > installing Anaconda2. That worked with the drug-hunting software with both > debian8 and debian9. I was short of time and, most importantly, probably > incapable of understanding why debian python did not work. Of course those > (and other errors) arise by merely commanding > > python > >>>imprt scipy.optimize > > thanks for your suggestions Well at least you are then running it the way the authors of scipy expect, which should then work quite well. -- Len Sorensen
Re: Fwd: Probmes in running scipy with amd64
On Sun, Apr 30, 2017 at 06:59:56AM -0400, Francesco Pietra wrote: > All python bugs solved by installing Anaconda2. The drug-hunting software > is running in Debian9 (stretch) on Anaconda2 python. Or another way of looking at it: All scipy bugs worked around by giving it exactly the version of everything that it assumes. scipy is not very robust when it comes to dealing with variations in python library versions. My impression is that the scientific software in general does not spend time on making things portable, as long as it works in the one environment they work in. Anything more would be time wasted that could have been spent on something else. -- Len Sorensen
Re: Failure lauching application since iceweasel -> Firefox
On Fri, Jul 15, 2016 at 06:57:28PM +0200, Francesco Pietra wrote: > I fear that on the amd64-gnome box my sources list should be amended: > > deb http://debian.netcologne.de/debian/ wheezy main contrib non-free Wheezy is long gone, given jessie was release well over a year ago now. Might be worth an upgrade. -- Len Sorensen
Re: Failure lauching application since iceweasel -> Firefox
On Tue, Jul 12, 2016 at 04:08:36PM +0200, Francesco Pietra wrote: > On last "upgrade" of amd64 wheezy I found Firefox in place of iceweasel. > OK, except that the single commercial application in my box (Vuescan) now > fails to upgrade > > > francesco@tya64:~/Vuescan$ ./vuescan > gvfs-open: http://www.hamrick.com/upgrade-l64.html: error launching > application: Failed to execute child process "/usr/lib/iceweasel/iceweasel" > (No such file or directory) > francesco@tya64:~/Vuescan$ > > > I was unable to remedy with a softlink. What to do? Thanks Why would some application be poking at another package's private internals? It should not be poking in /usr/lib/iceweasel. If it wants to do anything with iceweasel (or firefox) it should use the binary in /usr/bin to do so. I don't know who is responsible for gvfs-open trying to do that. -- Len Sorensen
Re: [Stretch] Status for architecture qualification
On Mon, Jun 20, 2016 at 10:35:20PM +0200, Geert Uytterhoeven wrote: > Yeah, apparently it's cheaper to bootstrap a complete new little endian > platform than to fix portability issues in existing software... I believe a big reason is that Nvidia cards expect little endian data, and the overhead of converting between the host and the nvidia cards is big enough to matter. power8+ and power9 will have nvlink connections on the CPU for a reason after all. -- Len Sorensen
Re: [Stretch] Status for architecture qualification
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote: > Well, we just did a full archive rebuild of "ppc64" to be able to > support ppc64 on the e5500 cores by disabling AltiVec, didn't we? Well it is getting there. -- Len Sorensen
Re: [Stretch] Status for architecture qualification
On Sun, Jun 19, 2016 at 08:35:02PM +0200, Florian Weimer wrote: > Do they implement the ISA required by the existing Debian port? Yes. The only ones that don't are the Freescale 85xx and P10[12]x chips, which are powerpcspe due to using the e500 core. All the 83xx and 82xx chips which are still shipping in many current products are plain old 32bit powerpc. Also I suspect many users of 64 bit capable freescale chips (e5500 and e6500 cores) are running 32 bit powerpc since they don't have enough ram to actually really gain anything from going to 64 bit, and the ppc64 port isn't done yet. But those would be a case of running 32 bit on 64 bit. -- Len Sorensen
Re: [Stretch] Status for architecture qualification
On Thu, Jun 16, 2016 at 09:04:12AM +0200, Mathieu Malaterre wrote: > The debian-powerpc@l.d.o mailing list is active so I would say it > still has some users. I have been using partch.d.o for doing some work > on PowerPC. I posted a summary of work people have been doing on this > port lately: > > https://lists.debian.org/debian-powerpc/2016/06/msg00046.html > > However I do agree that true PowerPC hardware is actually > disappearing, and it is alive mostly thanks to being an ABI using > 32bits integer for PPC64 CPU(s). There are a lot of 32bit powerpc chips still going into embedded systems being built today. They are not going away anytime soon. -- Len Sorensen
Re: Rename amd64 to klinux-amd64
On Wed, May 11, 2016 at 05:04:06AM -0700, Amir H. Firouzian wrote: > Hello alls, > Due to fact that other kernels are become populate like BSD, and Debian is > universal OS, So is it better to rename all Ports and mention the kernel > use that inside like kfreebsd-amd64 or khurd-i386? > > https://www.debian.org/ports/ i386 was't renamed when it stopped even supporting i386 and moved to i486 and later i586. Too many things already know the port name and depend on it. I think historical precedence says that Debian is linux unless it says otherwise in the port name. linux is implied. -- Len Sorensen
Re: Please explain
On Sat, Jan 09, 2016 at 04:28:18AM -0800, Will Puffenbarger wrote: > New user need explain for difference between 32 and 64 bit how to get to > ubuntu faster on smaller device by faking pathways Well the difference between 32 and 64 bit is: 64 bit x86 has twice as many registers (which makes things a bit faster in general), can have more memory per process (32 bit is limited to about 3GB per program, while 64 bit is not), and 64 bit uses SSE for floating point rather than x87, which is also quite a bit faster. 64 bit does use a bit more memory since pointers are 64 bit rather than 32 bit (In the future one would be able to get all the benefits of 64 bit x86 except for the memory limit per process, without the size impact by using the new x32 architecture, but it is still being worked on). The rest of your question I can't understand. -- Len Sorensen
Re: Regarding dual boot
On Thu, Aug 13, 2015 at 04:55:49PM +0530, Himanshu Shekhar wrote: Sorry dear! I tried with all genuine methods and installed debian 8.1. But whoa! I lost my activated version of Windows 10. I WAS able to access all my hard drives as I did a proper shutdown but the grub os list showed no link to windows. Running update-grub puts it in the boot menu. This has been happening for many people for quite a while and no one seems to have figured out why since it always works the next time it seems. I reinstalled windows 10 and still am eager to run linux flawlessly. Please guide me. Well the occational bug where os-proper doesn't add windows to the boot menu has the simple work around I mentioned above. A reinstall of windows is certainly complete overkill and a serious waste of time. -- Len Sorensen
Re: Regarding dual boot
On Thu, Aug 13, 2015 at 11:30:14AM +, Dohtre, Shekhar [HDS] wrote: If you want to dual-boot your favorite Linux distribution and Windows 10 Technical Preview on any computer, whether the computer has UEFI firmware or not, the Windows 10 Technical Preview installer is only capable of creating partitions using an MBR partitioning scheme. And so you should be aware of that when creating partitions for installing any Linux distribution. Note that this might not necessarily be the case when the final edition of Windows 10 is released. But just something you have to keep in mind before then. If you want to test-drive Windows 10 Technical Preview, ISO images are available for download here. My understanding is that the windows installer uses MBR if booted in BIOS mode, and GPT if booted in EFI mode. So make sure you boot it the way you want it used. Often the boot menu has two options for booting each bootable device. One legacy, one EFI. So when I created partitions to use for installing Ubuntu 14.10 alongside Windows 10 Technical Preview on the same hard drive, one of the Ubuntu 14.10 partitions had to be a (extended) logical partition. And the boot loader had to be installed in the Master Boot Record (MBR) of the target hard drive. -- Len Sorensen
Re: Regarding dual boot
On Thu, Aug 13, 2015 at 12:25:49AM +0530, Himanshu Shekhar wrote: I want to dual-boot windows 10 with debian 8.1 (amd64), as I have been an avid linux user for many years. I want to make sure that I shall not lose my original copy of Windows 10 if I try to install Debian. Also please make me clear about issues of dual-boot windows with debian. Well make sure you have unused space on the disk before installing (that is, not part of a partition, not free space on C:). As long as you don't touch the windows partitions while installing, windows should survive just fine. Of course backups are always recommended before doing anything major, like an OS install. -- Len Sorensen
Re: Urgent! Questions/Confirmations concerning *Debian 7.7.0 amd64* before I install it.
On Mon, Dec 08, 2014 at 10:23:04AM +, Darac Marjal wrote: I believe Debian limits this to 8 with a default kernel. However, you can recompile the kernel to raise the limit to 4096 (or 8192 with a newer kernel). Well the config in the amd64 3.2 kernel says: CONFIG_NR_CPUS=512 So that's a lot more than 8. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141208152816.gt24...@csclub.uwaterloo.ca
Re: module nvidia not found / amd64 jessie
On Thu, Nov 13, 2014 at 03:27:26PM +, Francesco Pietra wrote: Hello: Following update/upgrade with amd64 jessie, the 2 GTX 680 are seen by the graphical package VMD, however, nvidia -smi does not respond. The GTX are used in the absence of X-server, for number crunching. I rerun upgrading at no help. # modinfo nvidia ERROR: module nvidia not found modinfo nvidia-current perhaps? Do you have linux-headers-`uname -r` installed (as in matching your current kernel)? If not, you won't have a module built. -- Len Sorensen # dpkg -l | grep nvidia root@gig64:/home/francesco# dpkg -l | grep nvidia ii glx-alternative-nvidia0.5.1 amd64allows the selection of NVIDIA as GLX provider ii libegl1-nvidia:amd64 340.46-3 amd64NVIDIA binary EGL libraries ii libgl1-nvidia-glx:amd64 340.46-3 amd64NVIDIA binary OpenGL libraries ii libnvidia-compiler:amd64 340.46-3 amd64NVIDIA runtime compiler library ii libnvidia-eglcore:amd64 340.46-3 amd64NVIDIA binary EGL core libraries ii libnvidia-ml1:amd64 340.46-3 amd64NVIDIA Management Library (NVML) runtime library ii nvidia-alternative340.46-3 amd64allows the selection of NVIDIA as GLX provider ii nvidia-cuda-dev 6.0.37-4 amd64NVIDIA CUDA development files ii nvidia-cuda-doc 6.0.37-4 all NVIDIA CUDA and OpenCL documentation ii nvidia-cuda-gdb 6.0.37-4 amd64NVIDIA CUDA Debugger (GDB) ii nvidia-cuda-toolkit 6.0.37-4 amd64NVIDIA CUDA development toolkit ii nvidia-detect 340.46-3 amd64NVIDIA GPU detection utility ii nvidia-driver 340.46-3 amd64NVIDIA metapackage ii nvidia-installer-cleanup 20131102+2 amd64cleanup after driver installation with the nvidia-installer ii nvidia-kernel-common 20131102+2 amd64NVIDIA binary kernel module support files ii nvidia-kernel-dkms340.46-3 amd64NVIDIA binary kernel module DKMS source ii nvidia-libopencl1:amd64 340.46-3 amd64NVIDIA OpenCL ICD Loader library ii nvidia-modprobe 340.46-1 amd64utility to load NVIDIA kernel modules and create device nodes ii nvidia-opencl-common 340.46-3 amd64NVIDIA OpenCL driver ii nvidia-opencl-dev:amd64 6.0.37-4 amd64NVIDIA OpenCL development files ii nvidia-opencl-icd:amd64 340.46-3 amd64NVIDIA OpenCL installable client driver (ICD) ii nvidia-profiler 6.0.37-4 amd64NVIDIA Profiler for CUDA and OpenCL ii nvidia-settings 340.46-2 amd64tool for configuring the NVIDIA graphics driver ii nvidia-smi340.46-3 amd64NVIDIA System Management Interface ii nvidia-support20131102+2 amd64NVIDIA binary graphics driver support files ii nvidia-vdpau-driver:amd64 340.46-3 amd64Video Decode and Presentation API for Unix - NVIDIA driver ii nvidia-visual-profiler6.0.37-4 amd64NVIDIA Visual Profiler for CUDA and OpenCL ii nvidia-xconfig340.46-1 amd64X configuration tool for non-free NVIDIA drivers ii xserver-xorg-video-nvidia 340.46-3 amd64NVIDIA binary Xorg driver root@gig64:/home/francesco# I can't remember which nvidia driver was operating before these problems. # uname -a 3.16-3-amd64 #1 SMP Debian 3.16.5-1 x86 64 cpu family : 6 model : 62 model name : Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz stepping : 4 microcode : 0x416 cpu MHz : 1237.546 cache size : 12288 KB Thanks for advice francesco pietra -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113155628.gm24...@csclub.uwaterloo.ca
Re: Fwd: module nvidia not found / amd64 jessie
On Thu, Nov 13, 2014 at 06:10:24PM +0100, Hans wrote: Hi franceso, I am checking the necessary packagaes by module-assistant. It is the easiest way. Try it out. Install package module-assistant , start with m-a, and then go through the 4 steps (update, prepare etc.) Nice tool, and is helping much. Nice, but dkms is much less work and appears to have worked. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113222701.gn24...@csclub.uwaterloo.ca
Re: Fwd: module nvidia not found / amd64 jessie
On Thu, Nov 13, 2014 at 04:33:26PM +, Francesco Pietra wrote: Sorry, I forgot: $ dpkg -s linux-headers-$(uname -r) Package: linux-headers-3.16.0-4-amd64 Status: install ok installed Priority: optional Section: kernel Installed-Size: 2235 Maintainer: Debian Kernel Team debian-ker...@lists.debian.org Architecture: amd64 Source: linux Version: 3.16.7-2 Depends: linux-headers-3.16.0-4-common (= 3.16.7-2), linux-kbuild-3.16, linux-compiler-gcc-4.8-x86 Description: Header files for Linux 3.16.0-4-amd64 This package provides the architecture-specific kernel header files for Linux kernel 3.16.0-4-amd64, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-3.16.0-4-amd64, and can be used for building modules that load into the kernel provided by the linux-image-3.16.0-4-amd64 package. Homepage: https://www.kernel.org/ I can add that the X-server and web browser are ok It seems you have the module. Is it loaded? lsmod | grep nvidia -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141113222738.go24...@csclub.uwaterloo.ca
Re: complaints about systemd
On Tue, Oct 21, 2014 at 11:47:51AM +1100, Dean Hamstead wrote: I think BSD style init is underrated. Controlling everything in rc.conf is wonderful :) Lets have that in Debian please? Next you will suggest config.sys and autoexec.bat are a good design too. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141021133211.ge24...@csclub.uwaterloo.ca
Re: What is the evidence for and against systemd?
On Thu, Oct 16, 2014 at 03:34:45PM +0200, jp.po...@izzop.net wrote: I really hate systemd, since it is installed on one of my machine starting and stopping the system are painful. Starting is more than one minute with the X screen appearing at the very end. Stopping is the more painful thing, that machine wait more than 7 minutes before to stop, other systems are stopping in less than 1 minute. As someone noticed samba is often the culprit taking 5 minutes to stop the service. I want really often to unplug the cord ! But didn't do it. Systemd is hard to understant and even harder to diagnose when something goes wrong as it did often. At least the 5 minute wait for samba goes away if you clean up the /etc/rc*.d/*samba symlinks that samba never removed when it split the init script. Those leftovers that no other init system is bothered by really upset systemd. Doesn't fix systemd's many problems, but at least removes the 5 minute shutdown delay. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141016181137.ga24...@csclub.uwaterloo.ca
Re: complaints about systemd
On Thu, Oct 09, 2014 at 09:25:23AM -0700, Ray Andrews wrote: Can *anything* justify creating a problem that can't be debugged? I noticed on a reboot yesterday that there was a 5 minute countdown shutting down samba by the looks of it. Seems to be bug #762002. Again, bedrock principles: Do one thing, and do it well. Keep entanglements to a minimum. Keep everything as modular as possible. How can it even be considered that a desktop is somehow entangled with an init system? Supposing I bought a new fridge, and found my stove no longer worked? Supposing I bought a new car from Toyota but it could only run on Toyota gas? That would certainly be unreasonable too. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141009234920.gb4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
On Sun, Oct 05, 2014 at 07:59:17AM -0700, Ray Andrews wrote: On 10/04/2014 07:03 PM, Lennart Sorensen wrote: Lennart, The best option will actually end up being x32 (which is 32bit programs using the 64bit cpu so you get all the new registers and SSE floating point, but without the pointer overhead). Not sure how far along x32 is at this point. Interesting. So that would be another flavour of package again? (not 'i386' not 'amd64', but something else?) The flavour is x32. It is not done yet though. https://wiki.debian.org/X32Port -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005171221.gs4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
On Sun, Oct 05, 2014 at 10:12:18PM +0200, Michael wrote: Lennart, What do you think, chances does X32 have ? Will this be, like, fused, into AMD64 compilers some day ? I see no reason for it to fuse given multiarch works now. I expect people to have amd64/x32 multiarch systems though since the majority of programs don't need a 64bit memory space so you would gain smaller binaries and less cache usage due to the smaller pointers. The kernel would obviously be 64bit. For those few programs that have a use for 64bit memory space, yo would use amd64 packages. Essentially I think it makes sense to run 64bit kernel, with x32 as the default and amd64 for select applications, and perhaps i386 for the few things that can't be bothered to upgrade away from old 32bit. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005202149.gt4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
On Fri, Oct 03, 2014 at 02:45:59PM -0700, Ray Andrews wrote: Ok thanks, that's a good start right there. Looking at various blogs and such, it seems no two people can agree if the conversion to '64 is beneficial or even wise. I have only 2 GB of RAM on this machine, so that's no motive. I hear talk of various problems on the one hand, vs. claims of better performance on the other. Can I sorta slide from '32 to '64 by degrees? I mean, so that whenever I do an upgrade it will convert what's convertible while leaving the rest of the system '32? Or should I start afresh? Or should I just leave this older machine alone? 64bit has twice the registers than 32bit in the case of x86, so some programs gain some performance that way. Also 64bit always uses SSE for floating point, while 32bit by default uses x87 floating point which is a lot slower. Now 64bit does have some overhead due to the pointers being twice as big, which means more cache use and memory bandwidth, although probably not that much in general. The best option will actually end up being x32 (which is 32bit programs using the 64bit cpu so you get all the new registers and SSE floating point, but without the pointer overhead). Not sure how far along x32 is at this point. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141005020355.gq4...@csclub.uwaterloo.ca
Re: new software if moving to amd64?
On Fri, Oct 03, 2014 at 08:38:51AM -0700, Ray Andrews wrote: Gentlemen, Are you sure that is always true? Sure I may be, but not everyone on the list is likely to be. I just upgraded to the 'amd64' kernel. I've always been a 32 bit lad up till now. The kernel runs fine, but I'm wondering if there is anything else to do, specifically if my software needs to be somehow changed from 32 bit to 64 bit. There seems to be no special repository for 64 bit. Or am I all good? Well you can run a 64 bit kernel with 32 bit user space. You can even create chroots with debootstrap that are amd64 architecture inside and that works too. Of course with multiarch in wheezy and above you can even install packages from both i386 and amd64 at the same time (using apt-get install packagename:architecture), after telling dpkg once to add the other architecture. dpkg has a concept of the default architecture of an installation which was whatever it was installed as initially, although you can change it. The sources.list doesn't change in general, it simply starts downloading all the enabled architectures that you told dpkg to use (using dpkg --add-architecture). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141003182048.gp4...@csclub.uwaterloo.ca
Re: Looking for Debian 6.0.5 AMD ISO image
On Mon, Aug 11, 2014 at 05:04:09PM +, Christopher Carlson wrote: Not yet. I have only downloaded 2 DVDs (1 5). DVD 1 had 57 files it could not download. DVD 5 had 20. Each download is taking between 6 and 8 hours, so if I do them serially, it will be close to a week to get them all downloaded (since I'm doing this at my job). When I tried to download one of the missing files, jigdo didn't like any of the URLs I provided (I tried different combinations from more/less path to specifying the exact .deb file). Since I don't know jigdo at all and I'm just flying by the seat of my pants, there may be some incantation I'm missing. If I have to identify each of the missing files to jigdo to complete a DVD, this could take me weeks. I'm wondering how the promises made by the jigdo web page are kept. You download the files manually, put them all in a directory, and then point jigdo at that directory when it is doing it's scan. You do NOT give the URl to jigdo. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811172547.gv17...@csclub.uwaterloo.ca
Re: Looking for Debian 6.0.5 AMD ISO image
On Fri, Aug 08, 2014 at 08:27:00PM +, Christopher Carlson wrote: Thank you very much for your quick response. I took your advice, installed jigdo-lite and attempted to download debian-6.0.5-amd64-DVD. It is made up of 8 DVDs, which surprised me, but I guess it's everything. Unfortunately, there were 20 files that could not be found. I'm not sure I need them, but what now? I have a file debian-6.0.5-amd64-DVD-5.iso.tmp that appears to be an ISO image. What are the missing files? You could check snapshot.debian.org to see if you can find them there and provide them to jigdo. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808205529.gr17...@csclub.uwaterloo.ca
Re: Looking for Debian 6.0.5 AMD ISO image
On Fri, Aug 08, 2014 at 08:56:48PM +, Christopher Carlson wrote: Argh! They've scrolled off the top of the window. I'm trying to build all 8 DVDs. They may not have been life/death parts. Here are some that just popped up: --2014-08-08 13:57:20-- http://ftp.us.debian.org/debian/pool/main/s/srtp/libsrtp0_1.4.4~dfsg-6_amd64.deb Reusing existing connection to ftp.us.debian.org:80. HTTP request sent, awaiting response... 404 Not Found 2014-08-08 13:57:20 ERROR 404: Not Found. --2014-08-08 13:57:20-- http://ftp.us.debian.org/debian/pool/main/libu/libupnp/libupnp3_1.6.6-5_amd64.deb Reusing existing connection to ftp.us.debian.org:80. HTTP request sent, awaiting response... 404 Not Found 2014-08-08 13:57:20 ERROR 404: Not Found. Running jigdo again afterwards on the in progress image should list them again. http://snapshot.debian.org/archive/debian/20100404T050037Z/pool/main/s/srtp/libsrtp0_1.4.4%7Edfsg-6_amd64.deb http://snapshot.debian.org/archive/debian/20100519T220908Z/pool/main/libu/libupnp/libupnp3_1.6.6-5_amd64.deb Just put them in a directory and tell jigdo to scan it for files to include. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808210115.gs17...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Sun, Nov 17, 2013 at 10:45:58AM +0100, Francesco Pietra wrote: I am attacking the problem from another side, directly from within the OS itself: #lspi - tells that the link speed (= link status) LnkSta is at 5Gb/s, no matter whether the system is at number crunching or not. I.e., my system is at PCIe 2.0. This might explain why upgrading from sandy bridge to ivy bridge gave no speed gain of molecular dynamics. PCIe 3.0 was not achieved. As far as I could investigate, nvidia suggests to either: (1) Modify /etc/modprobe.d/local.conf (which does not exist on jessie) or create a new /etc/modprobe.d/nvidia.conf, adding to that 1. options nvidia NVreg_EnablePCIeGen3=1 Might need nvidia-current instead of nvidia. Actually, on my jessie, nvidia.conf reads alias nvidia nvidia-current remove nvidia-current rm mod nvidia Some guys found that useless, even when both grub-efi and initramfs are edited accordingly, so that nvidia offered a different move, updating the kernel boot string, by appending this: 1. options nvidia NVreg_EnablePCIeGen3=1 *** That is NOT the syntax for a kernel command line. It is the syntax for the modprobe config. Something like nvidia.NVreg_EnablePCIeGen3=1 or nvidia-current.NVreg_EnablePCIeGen3=1 (depending on the name of the module as far as the module is concerned). I did nothing, as I hope that the best adaptation to jessie may be suggested by those who know the OS better than me. The kind of information about links includes: LnkSta: the actual speed LnkCap: the capacity of the specific port, as far as I can understand. LnkCtl: ?? One could also run #lspci -vt to determine the bus where the GPU card is located, then running # lspci -vv -s ## where ## is the location. ** So, it is a tricky matter, but perhaps not so much when one knows where to put the hands. At any event, being unable to go to 8GT/s, as from PCIe 3.0, means loosing time and energy (=money and pollution), at least when the GPUs are used for long number crunching. Well it means slower transfers of data to and from the card. If the data set fits in the card entirely during a long number crunch, then bandwidth would not matter much at all. So depends on the size of the data set and how often data has to be moved in and out of the card. I'll continue investigating. The above seems to be promising. Hope to get help. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131118170238.gm20...@csclub.uwaterloo.ca
Re: Fwd: Fwd: upgrade to jessie from wheezy with cuda problems
On Mon, Nov 18, 2013 at 10:39:53PM +0100, Francesco Pietra wrote: I forgot to mention that LnkSta 8GT/s is obtained only when actually carrying out the MD simulation. I believe to save power the link speed changes on the fly based on demand. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131118215951.go20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 10:13:15AM +0100, Francesco Pietra wrote: I think it was renamed. No idea why. modinfo nvidia-current should work though. Yes, it does. Do you have the cuda libraries for the 319 version installed? Yes I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. 500,000 atoms, as in my test, is a large system for unbiased molecular dynamics. At any event, I looked at the the nvidia-cuda-toolkit version 5.0. nvidia for GPU Computing SDK, to build examples that should include a bandwidth test, offers linux packages for Fedora RHEL Ubuntu OpenSUSE and SUSE. No Debian. I had unpleasant experiences with Ubuntu packages, and it is well known that Ubuntu, unlike LinuxMint, is not compatible with Debian. Therefore, I did not try the cuda toolkit. I wonder why Ubuntu has so widely replaced Debian among the mass. Sad, and somewhat irritating, for me. I tried francesco@gig64:~/tmp$ ls CUDA-Z-0.7.189.run francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-657a-580e-a8aa-0faa/cuda-z: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory Try: LD_LIBRARY_PATH=. ./CUDA-Z-0.7.189.run See if it finds that lirary then. francesco@gig64:~/tmp$ ls CUDA-Z-0.7.189.run libXrender.so.1 francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-a3db-49bf-8cb7-059d/cuda-z: error while loading shared libraries: libXrender.so.1: cannot open shared object file: No such file or directory francesco@gig64:~/tmp$ Actually the required lib is available, as shown by my copy into tmp. I don't remember the source of this GNU CUDA-Z tool. Any experience with? I have also met reports of unexciting experience with PCIe 3.0, that is meager or no gain over PCIe 2.0, however it deals of people carrying out games, which is different from NAMD molecular dynamics, where most is done by the GPUs but AT EACH STEP energy has to be calculated by the CPU. I see a package in Debian named 'nvidia-cuda-toolkit'. Does that include that you were looking for? I guess the bandwidthtest isn't built normally. -- Len Sroensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113171328.gg20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 10:32:26AM +0100, Francesco Pietra wrote: My answer seems to have disappeared. I summarize here. modinfo nvidia-curred works well. CUDA libraries are installed. For nvidia-cuda-toolkit, nvidia offers SDK packages for Ubuntu, not for Debian. I don't like to get into troubles with Ubuntu, which, unlike LinuxMINT, is not compatible with Debian. I tried GNU CUDA-Z-07.189.run (don't remember from where it was downloaded). However it does not find the shared libXrender.so.1, even if made available into the same folder of CUDA-Z. Actually root@gig64:/home/francesco# apt-file search libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1 libxrender1: /usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 libxrender1-dbg: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libXrender.so.1.3.0 root@gig64:/home/francesco# francesco@gig64:~$ echo $PATH /opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2:/opt/amber12/bin:/opt/amber10/bin:/opt/UCSF/Chimera64-2012-10-10/bin:/opt/namd2.9_cuda4.0_2012-09-26/bin/namd2 francesco@gig64:~$ Should /usr/lib/x86_64-linux-gnu be put on my path explicitly? The PATH is not for libraries. LD_LIBRARY_PATH is, as is /etc/ld.so.conf stuff. Also is what you downloaded 32 or 64 bit? Try: ldd CUDA-Z-07.189.run See what it is looking for. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113171504.gh20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 07:40:10PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ export LD_LIBRARY_PATH=/usr/lib/x86_64-linux-gnu/ That is unnecesary. That is already in the library path. The local directory is not. Windows implicitly looks in the current directory for files, linux (and almost all other systems) does not. hence: export LD_LIBRARY_PATH=. (. for current directory), or LD_LIBRARY_PATH=/tmp if that is where you put the library you were trying. francesco@gig64:~/tmp$ ./CUDA-Z-0.7.189.run CUDA-Z 0.7.189 Container Starting CUDA-Z... /home/francesco/tmp/CUDA-Z-95b0-7943-3edd-827e/cuda-z: error while loading shared libraries: libXrender.so.1: wrong ELF class: ELFCLASS64 francesco@gig64:~/tmp$ What does 'file ./CUDA-Z-0.7.189.run' say? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113185253.gi20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 10:53:30PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ file ./CUDA-Z-0.7.189.run ./CUDA-Z-0.7.189.run: data francesco@gig64:~/tmp$ OK that's weird. I expected to see x86 32 or 64bit binary. Seems to be a shell scripts with compressed code in it. Yuck. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131113224347.gj20...@csclub.uwaterloo.ca
Re: Fwd: upgrade to jessie from wheezy with cuda problems
On Wed, Nov 13, 2013 at 05:43:47PM -0500, Lennart Sorensen wrote: On Wed, Nov 13, 2013 at 10:53:30PM +0100, Francesco Pietra wrote: francesco@gig64:~/tmp$ file ./CUDA-Z-0.7.189.run ./CUDA-Z-0.7.189.run: data francesco@gig64:~/tmp$ OK that's weird. I expected to see x86 32 or 64bit binary. Seems to be a shell scripts with compressed code in it. Yuck. :) OK I got it running. It is a 32bit binary. I had to install these: ii libcuda1:i386 331.20-1i386 NVIDIA CUDA runtime library ii libcudart5.0:i386 5.0.35-8i386 NVIDIA CUDA runtime library ii libgl1-nvidia-glx:i386331.20-1i386 NVIDIA binary OpenGL libraries ii libstdc++6:i386 4.8.2-4 i386 GNU Standard C++ Library v3 ii libxrender1:i386 1:0.9.8-1 i386 X Rendering Extension client library ii zlib1g:i386 1:1.2.8.dfsg-1 i386 compression library - runtime Then I was able to run it. No messing with LD_LIBRARY_PATH or anything. To install :i386 packages you first have to enable multiarch support with dpkg and run apt-get update. So something like: dpkg --add-architecture i386 apt-get update apt-get install libcuda1:i386 libcudart5.0:i386 libgl1-nvidia-glx:i386 libstdc++6:i386 libxrender1:i386 zlib1g:i386 Don't worry about the exact versions, since I am running unstable+experimental. You don;t need to do that to get it working. For your 64bit code you probably need libcuda1 libcudart5.0 and such installed in the 64bit version. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131114023334.gk20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Tue, Nov 12, 2013 at 03:54:32PM +0100, Francesco Pietra wrote: Hello: I decided to try jessie to get PCIe 3.0 with a recent nvidia driver, thus upgrading from wheezy. wheezy was uname -r 3.2.0-4-amd64 nvidia-smi 304.88 nvcc --version 4.2 (the latter is also the version at which the molecular dynamics code was compiled, and used without calling the X-server) Following aptitude update aptitude-upgrade a number of dependecies related to gnome were not met (evolution-common lbfolks25 gnome-panel gnome-shell gnome-theme-extras gnome-theme-standard libreoffice-evolution). This notwithstanding, I decided to upgrade. After rebooting to get linux matching with nvidia: nvcc --version 5.0 uname -r 3.10-3-amd64 nvidia-smi the nvidia kernel module has version 304.108 but the nvidia driver component has version 319.60. Driver 319.6 is just what I wanted. Now, how best fix the problems? Install linux image 3.2? In the past I tried dist-upgrade, getting into devastating problems. Do you have nvidia-kernel-dkms installed? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112145937.gc20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Tue, Nov 12, 2013 at 05:22:18PM +0100, Francesco Pietra wrote: Yes. Also, # apt-get remove nvidia-kernel-dkms # apt-get install nvidia-kernel-dkms (which, in the year 2011, served to clear the driver at /lib/modules/2.6.38-2-amd64/updates/dkms. But now the kernel was 3.2.) left the issue unaltered. # modinfo nvidia ERROR: module nvidia not found $ dpkg -l |grep nvidia |less shows libl1-nvidia-glx:amd64 319.60 and libg1-nvidia-legacy-304xx--glx:amd64 304.108-4 NVIDIA metapackage rc nvidia-glx 304.88-1-deb7u1 nvidia-legacy-304xx-driver 304.108-4 nvidia-legacy-304xx-kernel-dkms 304.108-4 nvidia-settings-legacy-303xx 304.108-2 xserver-xorg-video-nvidia-legacy-304xx304.108-4 Everything else 319.60-1 and cuda 5.0 I don't understand why these 304xx are threatening. I had also run # nvidia-xconfig I think you should remove all packages with legacy-304xx in the name, and install the current ones (nvidia-kernel-dkms, nvidia-glx, etc). legacy-304xx will never move beyond version 304.xx after all as the name implies. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112165947.ge20...@csclub.uwaterloo.ca
Re: upgrade to jessie from wheezy with cuda problems
On Tue, Nov 12, 2013 at 10:35:53PM +0100, Francesco Pietra wrote: # apt-get --purge remove *legacy* did the job. I wonder how these legacy packages entered the scene while updating/upgrading from a clean wheezy. The bad news are that with the new driver 319.60 there was no acceleration of molecular dynamics for a job of modest size (150K atoms) and slight acceleration (0.12 s/step vs 0.14 s/step) for a heavy job (500K atoms). Weather bringing from PCIe 2.0 (with the 304.xx driver of wheezy) to PCIe 3.0 (with driver 319.60 of jessie) (increasing the bandwidth from GPUs to RAM from 5 to 8GB/s) has not the effect that I hoped on the calculations, or PCIe is still 2.0 with jessie. Now, with cuda 5.0, it should be easy to measure the bandwidth directly. I have to learn how and I'll report about in due course. Now nvidia-smi activates the GPUs for normal work, nvidia-smi -L tells about the GPUs, dpkg -l |grep nvidia shows all 319.60 or 5.0.35-8, the X-server can be started and gnome loaded (startx, gnome-session), nvcc --version gives 5.0, however # modinfo nvidia ERROR: module nvidia not found In analogy with wheezy 3.2.0-4, I expected /lib/modules/3.10-3-amd64/updates/dkms/nvidia.ko Instead, there is /lib/modules/3.10-3-amd64/nvidia/nvidia-current.ko is that a feature of jessie or something wrong? I think it was renamed. No idea why. modinfo nvidia-current should work though. Do you have the cuda libraries for the 319 version installed? I don't play around with GPU computations, but from what I have read it does need a certain size job before the overhead of transfering the data and managing the GPU makse it worthwhile, but for large jobs the high core count and memory bandwidth makes a big difference. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131112223724.gf20...@csclub.uwaterloo.ca
Re: CUDA bandwidth test
On Tue, Oct 29, 2013 at 03:06:08PM +0100, Francesco Pietra wrote: Hello: I am looking for how to test the cuda memory bandwdth for GTX (GTX-680) with cuda tools in amd64 wheezy. I tried GNU CUDA-Z, however it did not find libXrender.so.1. I guess its is looking for it from ia32-libs (as that lib is present in my 64 libs), which is not installed on my servers. Does that CUDA-Z work well and installation of ia32-libs can be safely carried out without any detrimental effect? If you are using wheezy, then you should be using multiarch to install 32bit libraries. So something like this: dpkg --add-architecture i386 (only need to do this once ever) apt-get install libcuda1:i386 Or whichever package has the library you want a 32 bit version of. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131029141153.gu13...@csclub.uwaterloo.ca
Re: RedHat or Debian amd64
On Sun, Sep 29, 2013 at 06:45:40PM +0200, Francesco Pietra wrote: Really the only difference between distributions is their packaging system, their support infrastructure, their release schedule/policy, and how up to date the software is and what software they offer packages for. Thanks. Now my project at the Italian supercomputer center is going to production. I had no problems with RedHat as far as number crunching is concerned. Now, however, I need to access their Remote Visualization service to deal - also on the X server - with large files. To this end, I need to download software compatible with Debian amd64. The variety of graphic and non-graphic tools that I use is very large. Their 64 bit Linux list (lacking any GNU Linux for either 64 or 32 bit) RCM_darwin RCM ubuntu 12.04 RCM RHL 5.6 RCM openSUSE 11.4 and 12.2 I would appreciate advice as to which RCM will likely work for me. I heard about ubuntu but, to avoid being flooded by messages, i put it in the spam. The advice I can even from the center is very limited as they don't know what I have. Well Ubuntu is based on Debian, so there is at least a good chance a package for ubuntu will work on Debian. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130930142433.gx13...@csclub.uwaterloo.ca
Re: Roll call for porters of architectures in sid and testing (Status update)
On Fri, Sep 20, 2013 at 11:19:24AM -0400, Federico Sologuren wrote: i have a HP Visualize B2000 that i managed to install last night from iso distribution that i found after a lot of looking. at this point only terminal is working. will keep reading to get debian up and running. i would like to get involved. will need some additional information on what is needed and what skills are required. what does DD/DM stand for? DD = Debian Developer DM = Debian Maintainer unless I remember wrong of course. :) -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130920181059.gj13...@csclub.uwaterloo.ca
Re: Roll call for porters of architectures in sid and testing (Status update)
On Thu, Sep 19, 2013 at 10:38:29AM +0200, Niels Thykier wrote: Here is a little status update on the mails we have received so far. First off, thanks to all the porters who have already replied! So far, the *no one* has stepped up to back the following architectures: hurd-i386 ia64 mips mipsel s390x I have pinged some people and #d-hurd, so this will hopefully be amended soon. Remember that the *deadline is 1st of October*. In the list above, I excluded: amd64 and i386: requirement for porters is waived s390: Being removed from testing during the Jessie cycle (Agreement made during the Wheezy release cycle) The following table shows the porters for each architecture in *unstable* that I have data on so far: armel: Wookey (DD) armhf: Jeremiah Foster (!DD, but NM?), Wookey (DD) kfreebsd-amd64: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD) kfreebsd-i386: Christoph Egger (DD), Axel Beckert (DD), Petr Salinger (!DD), Robert Millan (DD) powerpc: Geoff Levand (!DD), Roger Leigh (DD) sparc: Axel Beckert (DD), Rainer Herbst (!DD) If you are missing from this list above, then I have missed your email. Please follow up to this mail with a message-ID (or resend it, whichever you prefer). Message-ID: 20130904160124.gt12...@csclub.uwaterloo.ca Sent September 4th. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130919145648.gf13...@csclub.uwaterloo.ca
Re: Roll call for porters of architectures in sid and testing
Hi, I am an active porter for the following architectures and I intend to continue this for the lifetime of the jessie release: For powerpc, i386, amd64, armhf, I - test most base packages on this architecture - fix toolchain issues - triage arch-specific bugs - fix arch-related bugs - run a local build server I also have personally some Alpha and Mips machines I play with at home when I have time, but I haven't done that much with those lately (although I keep meaning to help more). I am not a DD/DM I work on a router that runs a PPC cpu and is Debian based, so I rebuild on our own build server a large number of debian packages and do file bug reports and patches as needed for those packages. We also have an older router using x86 that I also build for, and we will almost certainly move to armhf as well at some point soon (not to mention I have a few armhf systems I play with at home). Currently using an IBM x3650 and an IBM p710 as the local build machines (probably one of very few high end IBM PowerPCs running Debian on the bare metal). I should probably apply to become a DD or something one of these days, but honestly having to go get a GPG key signed seems like too much trouble (which does sound pretty pathetic really). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130904160124.gt12...@csclub.uwaterloo.ca
Re: RedHat or Debian amd64
On Wed, Jun 26, 2013 at 04:33:20PM +0200, Francesco Pietra wrote: Hello: I noticed that in my country supercomputer center all machines, both CPU (FERMI) and GPU (AURORA, PLX) run on RedHat Linux. As a long time user of Debian GNU Linux amd64, I am curious whether such machines elsewhere also run, or could run, on Debian am64. If not, why? A problem of kernel? Some people want someone to blame if there are problems, or to demand support from if they need something solved right away. Redhat will sell you support contracts and will solve problems. But you pay for it. If you like doing it yourself or to solve things by cooporating with the community instead, then Debian works great. I certainly have the impression that locations that have their own IT people that understand the system and want to be in control of their own situation tend to run Debian (or a Debian derived system), while those that just want things solved and don't care to have the expertise themselves tend to run Redhat enterprise linux instead. After all if you have the people and a large installation, the support contract with redhat could pay for a lot of competent IT staff. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626144049.gs11...@csclub.uwaterloo.ca
Re: RedHat or Debian amd64
On Wed, Jun 26, 2013 at 06:11:31PM +0200, Francesco Pietra wrote: Hi Lennart: I forgot that what is found on supercomputers might result also from what you say. I found it problematic to compile a code for molecular dynamics (MD) inclusive of an elaborate plugin. Better, I succeeded when only the simplest part of the plugin was implemented, getting a valid MD executable. In contrast, implementing the whole plugin resulted in a MD executable that fails to recognize the GTX-680cards of my machine. Calls to the forum for both the MD code and the plugin had ho answer. Those of the MD code do not like the plugin (as they have the simplest part of it already hard coded their own way), while those of the plugin do not know that MD code, they use another one. Then, I heard that at the supercomputer center of my country (where I should run the project, but I need to go there with a system that runs) even GPU machines run that full plugin. Before asking them how they succeeded, I was wondering about the different Linux OSs. I am now curious about their answer, if any. Really the only difference between distributions is their packaging system, their support infastructure, their release schedule/policy, and how up to date the software is and what software they offer packages for. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130626162308.gt11...@csclub.uwaterloo.ca
Re: Printer driver for Epson AcuLaser C1100 please convert to x64...
On Sat, Jun 15, 2013 at 02:08:12AM -0700, DutchGlory wrote: I have printer driver here for Epson AcuLaser C1100 if someone is able to convert this to x64... (amd64) i'll (and many others) be *MORE* than happy :) It has no source code, only binaries, and the binary is 32bit only. Now you could perhaps run a 32bit binary filter with cups on a 64bit system, so it might still be usuable. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130617190736.gl11...@csclub.uwaterloo.ca
Re: After a few weeks of almost no issues, Wheezy doesn't boot anymore
On Mon, May 13, 2013 at 10:02:00AM -0400, Harry Prevor wrote: Thanks again for all your help guys. I was having a lot of problems, but I somehow managed to start the computer for just long enough to quickly install memtest86+ before it crashed with a kernel panic. On memtest, every single test was failing, so I decided to try taking out my two 8GB RAM sticks and testing them individually with memtest. Sure enough, one of my RAM sticks (Crucial brand; DDR3) had gone bad, and once it was removed Wheezy started working fine. memtest is great at telling when there is an error for sure. It's never good at saying there isn't an error, since maybe it just didn't test well enough. But fortunately for you it did exactly what you needed. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130513160702.gb14...@csclub.uwaterloo.ca
Re: After a few weeks of almost no issues, Wheezy doesn't boot anymore
On Fri, May 10, 2013 at 01:23:09PM -0400, Harry Prevor wrote: Thanks a lot for your helpful responses guys. I'm at a public computer right now and haven't had a chance to try your ideas yet, but I've noticed a few things that I'd like to clarify: On 5/9/13, Chris Swenson ch...@cswenson.com wrote: Given that these problems were occurring before, I'm guessing you have bad hardware that just decided to coincidentally die with your new install of the OS. Perhaps all the writes to the disk did it when you upgraded. I installed Wheezy from the get-go on this machine; I had done a few apt-get upgrades but no major distribution upgrades. Oddly enough, the hardware didn't seem to die in conjunction with anything important; just a reboot. On 5/10/13, Артём Н. artio...@yandex.ru wrote: 10.05.2013 05:04, Harry Prevor пишет: The normal images didn't work for some reason now forgotten, so I had to use the unofficial installation images that included nonfree drivers. What are the drivers? I've forgotten by now, but all I remember is that the official USB installation images didn't work because they thought my USB was a CD drive or something along those lines, and then tried to look for CD drives and failed (because I have none on this machine). I asked #debian about it and they said to try the unofficial images, so I did and they worked fine. How did you install the system? From DVD or from network? Or in some other way? I installed it via the unofficial USB installation images with included proprietary drivers. - Two HDDs connected and set via /etc/fstab to mount on boot (this configuration worked in previous boots so I doubt that is the issue) SSD? No; they are HDDs unfortunately. On 5/10/13, vi...@tiensuu.eu vi...@tiensuu.eu wrote: Have you installed/upgraded any drivers or installed a new kernel just before you rebooted the system and it started to crash on boot like this? Nvidia's proprietary drivers have always been a pain. No, or at least, not that I know of. I might have done an apt-get upgrade or something, but nothing major. I had already booted successfully directly after installing the nvidia driver before. On 5/10/13, Darac Marjal mailingl...@darac.org.uk wrote: If the only proprietary driver you need is the Nvidia X driver, then a rescue disc will work fine for you. You're likely to be pottering about at the command line anyway. I don't *need* the nvidia driver at all; everything works in the installation without the drivers AFAIK -- But because my brother uses this machine for gaming he needs the better 3D performance, so I installed it after installing the system. I had to use the installation image with drivers for other reasons -- See above. When I get home, here is a list of the things I'll try, in order: - Make sure the RAM is securely in place - Try to boot into single-user mode via GRUB; if that doesn't work, I'll try going in via a LiveUSB and chroot into the system - Pastebin /var/log/messages and /var/log/syslog - Pastebin partition / filesystem information - Pastebin /etc/fstab plus result of sfdisk -lxuM /dev/sd - Pastebin debsums -c - Run fsck on my hard drives - Include SMART logs (will look that up later) - Install and try out the memory checking package If any of this is wrong, please let me know. Thanks again. I would say that either very corrupt disk, bad ram or bad cpu seems most likely. Of course a bad power supply can also make everything not work reliably. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130510182245.ga14...@csclub.uwaterloo.ca
Re: Wheezy
On Wed, May 08, 2013 at 03:18:09AM -0500, Jaime Ochoa Malagón wrote: After my upgrade to wheezy my X has failed. I tried to find the problem to fix it, and I was not be able to do it... I have a partial success narrowing the problem... And I ask you for help to find it clearly I don't know if it is amd64 specific or not... The usual suspect is the nvidia driver BUT only after the upgrade? Do you have the debian packages for the nvidia driver installed? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508135702.gm28...@csclub.uwaterloo.ca
Re: nvidia 9800 GT with nouveau on wheezy
On Fri, Apr 26, 2013 at 04:08:58PM +0200, Giacomo Mulas wrote: On Wed, 24 Apr 2013, Hans-J. Ullrich wrote: Don't use the nvidia package from debian for googleearth. They do not work, as the 32-bit-libs of nvidia have dependency problems. Obviously no one cared for this at the moment. Just download the installer from the nvidia website and execute it - works like a charm! yes, sure. Then relax as it hoses your system... I had to fix countless workstations because someone had done exactly this. Then, sooner or later (typically: sooner) one or another software upgrade conflicts with the many files distributed by the nvidia installer throughout the system, without registering them with the packaging system and no regard with debian filesystem hierarchy guidelines. Cleaning up the resulting mess is quite a bit of work, when (not if) you will need to. I have done many cleanups too. I even documented nicely how to install the debian packaged version for many years. I think it is Windows's fault that people think downloading and running random executables is a good idea (which also probably explains why windows machines are so often broken). of course when the upgrade eventually breaks it, people blame debian's upgrade, not the mess they chose to create. I have an alternative suggestion: if you really need recent, up to date nvidia drivers, get the _source_ debian package from unstable. You can do this by adding a deb-src line pointing to unstable in your /etc/apt/sources.list, or a file containing it in /etc/apt/sources.list.d/ (mind you: deb-src, not deb!). Then you just do: apt-get source nvidia-glx then you go into the newly created directory, read the debian/README.source file and follow the instructions to create a clean backport, resulting in proper deb packages that you can install. The additional utilities (e.g. nvidia-kernel-common etc.) and scripts can be installed from the http://backports.debian.org repository matching your installed distribution. A bit more work to do, but this will be a long-term solution, easy to maintain following upgrades, and it will not hose your system. Just my 2¢... I will double that too. Good luck, indeed! Yeah anyone following the advice of using nvidia's isntaller will need it. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130426160917.gi21...@csclub.uwaterloo.ca
Re: RAID1 all bootable
On Wed, Mar 06, 2013 at 06:59:01AM +0100, Francesco Pietra wrote: I had all my data on another raid1 machine. Following the new install, all data were scp transferred. All my machine are on a router, with passwordless scp. Which is also used to contact external server for computational work. Following a seemingly correct installation, with grub installed 'grub-install /dev/sda' and 'update grub' command grub-install /dev/sdb led to a system that did no more boot. I can't see what was wrong with the installation. I have now the same situation (install from the wheezy installer). If you suggest what to check, I'll do that. Thanks a lot for your generous help. I (we) learned a lot from you. Are you running with raid1 on raw sda and sdb or are you creating partitions and running raid on the partitions (which to me is the normal thing to do)? If you are running raid on the raw device, then grub-install would have to be on /dev/md0 or whatever your raid device is. If you have partitions, then it would be on /dev/sda and /dev/sdb. If you have no partitions, then doing grub-install /dev/sdb probably broke the raid. It's such an unusual and weird setup to not use partitions that most people simply assume you have partitions and any advice you get will make that assumption. Somewhat makes it a dangerous setup to use for that reason. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130306154459.gk20...@csclub.uwaterloo.ca
Re: RAID1 all bootable
On Fri, Mar 01, 2013 at 08:20:09PM +0100, Francesco Pietra wrote: Hi: With a raid1 amd64 wheezy, one of the two HDs got broken. Unfortunately, I had added grub to sda only, which is just the one broken. So that, when it is replaced with a fresh HD, the OS is not found. Inverting the SATA cables of course does not help (Operative System Not Found). In a previous similar circumstance, I was lucky that the broken HD was the one without gru. Is any way to recover? perhaps through Knoppix? I know how to look into undamaged RAID1 with Knoppix. Also, when making a fresh RAID1 from scratch, where to find a Debian description of how to make both sda and sdb bootable? (which should be included by default, in my opinion) You can boot the install disk in rescue mode, select the root partition to chroot into, then run grub-install from there. When grub asks where to install, you should configure it for both sda and sdb. I think 'dpkg-reconfigure grub-pc' is where that is selected. Might need it to use -plow to asks all levels of questions. Not sure. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130301213542.gd20...@csclub.uwaterloo.ca
Re: sound card problems
On Wed, Feb 06, 2013 at 05:44:42PM +0100, Francesco Pietra wrote: Hello: With Debian amd64 wheezy I was unable to get the sound card working correctly (bumping voice or sound) for a Gygabyte GA-X79-UD3 motherboard, while with other motherboards there are no problems. :~$ lspci | grep -i audio 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 05) 02:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1) 03:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1) :~$ cat /proc/asound/cards 0 [PCH]: HDA-Intel - HDA Intel PCH HDA Intel PCH at 0xf912 irq 72 1 [NVidia ]: HDA-Intel - HDA NVidia HDA NVidia at 0xfb08 irq 17 2 [NVidia_1 ]: HDA-Intel - HDA NVidia HDA NVidia at 0xf908 irq 17 As far as I can understand, Intel is chosen by the system, while I should change to NVIDIA. I found some suggestions how to make NVIA card first choice but they did not work. You want the intel if you want sound to come out the 1/8 jack on the back. You want the nvidia if you want sound over HDMI from the video card. Of course in my experience a simple way to get sound working when it doesn't unfortunately is: killall pulseaudio It shouldn't have to be that way, but well pulseaudio is pretty buggy even if it is somewhat useful when it works. Could also be a mixer setting problem. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130206165016.gi30...@csclub.uwaterloo.ca
Re: Just to be very clear about Office
On Tue, Feb 05, 2013 at 11:21:15AM -0500, Robert Isaac wrote: OpenOffice still doesn't write OOXML and there is very little macro compatibility with Excel. Well only Microsoft Office 2013 can write OOXML files. 2010 could read them. OOXML of course being defined as ISO/IEC 29500. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130205180733.gg30...@csclub.uwaterloo.ca
Re: packages requiring ia32-libs ia32-libs-gtk
On Mon, Oct 15, 2012 at 02:00:00PM -0500, Seb wrote: Packages ia32-libs and ia32-libs-gtk are not installable in sid, and this prevents installation of some packages like the Debian amd64 version provided by Skype and google-earth-stable. How do we get around this? Well one option might be to use equivs to create a fake package, assuming the actual libraries can be installed already using multiarch. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121015192740.gd18...@csclub.uwaterloo.ca
Re: your mail
On Sat, Jul 21, 2012 at 07:22:47PM +0200, Pietro Paolini wrote: I tried to add the firsts you wrote me and no result. Before add the last one I have a question, what I have to do is run: apt-get update apt-get upgrade I would recommend always using dist-upgrade, not upgrade. upgrade isn't allowed to do anything that requires installing a new package or removing another package. This can really prevent installing things a lot of the time. If you just need a newer kernel, you could add backports to your sources and install the kernel from there. If you do: lspci -n | grep 0200 You can find out the PCI id of your network cards. It can then be used to look up which kernel version added support for that particular network card/chip. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120723140114.gk19...@csclub.uwaterloo.ca
Re: About gdm3
On Wed, Nov 16, 2011 at 09:44:45PM +0100, Francesco Pietra wrote: Hello With my i386 wheezy desktop I had the surprise of gdm3 display manager, whereby now the X server is started automatically, without startx gnome-session. How should I manage not to have the same situation with one of my cpu-gpu servers? It is usually used for chemical computations from the console, while there is also a dormant X server to be used occasionally with a gpu-enabled graphic program. The X server has not to be started in order that the cpu-gpu calculation can be run. You can uninstall gdm3. apt-get remove gdm3 Then it won't do that anymore and you can still use startx and such as you are used to. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2016213204.gb6...@caffeine.csclub.uwaterloo.ca
Re: Differences between amd64 and i386.
On Tue, Oct 18, 2011 at 11:50:08AM -0700, Instruisto Jose wrote: What are the main advantages of debian amd64 compared to i386 debian besides to address more than 4GB of memory? The standard Debian 6.0 kernel image of i386 has already been compiled with SMP-alternatives support. Are there differences in processing speed between them? amd64 has twice as many register as i386. This makes amd64 faster in many cases. amd64 uses sse for floating point math. i386 by default uses only x87 which is awful slow. This makes amd64 much faster in many cases. amd64 can use more than 3.2GB ram without overhead of PAE. This makes amd64 a bit faster in some cases. i386 is optimized for i486 level CPUs. amd64 is optimized for a much newer baseline since all amd64 capable CPUs are at least Pentium 4 level instructions. This makes amd64 a fair bit faster in most cases. Most other architectures that have moved to 64bit haven't really had the same kind of improvements, and instead have usually just had pointer size overhead going to 64bit. Certainly this is true for powerpc, sparc and mips as far as I know. I don't believe Debian has distributions for the 64bit variants of those, instead just a 64bit kernel and certain libraries and programs where it makes sense to have 64bit memory space are made. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111018192413.gg15...@caffeine.csclub.uwaterloo.ca
Re: Fastest card for CUDA
On Fri, Jul 29, 2011 at 11:12:41AM +0200, Francesco Pietra wrote: I suddenly got the opportunity to change the two GTX-470 on my Gigabyte GA-890FXA-UD5/PhenomII-1075T with two faster cards, while sticking to gaming hardware for CUDA number crunching (molecular dynamics). Considering the limits of the motherboard (North bridge AMD890FX, South bridge AMD SB850, 2-Way/3-Way ATI CrossFireX), is GTX-580 the fastest card that could replace GTX-470? Yes the 580 is the fastest, unless you consider the gtx590 which is a dual GPU card, but at a bit lower speed than the 580. I think you said earlier that there wasn't much gained having more than two GPUs though, so a pair of the 580s would be the fastest. Of course a pair of 580s would use about 180W more than your pair of 460s as far as I can tell. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110729142212.gi8...@caffeine.csclub.uwaterloo.ca
Re: key server error
On Wed, Jul 27, 2011 at 04:15:12PM +0200, Francesco Pietra wrote: gpg --keyserver hkp://www.keys.eu.pgp.net --recv-keys 1F41B907 gpg: keyserver receive failed: keyserver error I have always used subkeys.pgp.net There seems to be a problem though: lennartsorensen@lennartsorensen:~$ host subkeys.pgp.net subkeys.pgp.net has address 195.113.19.83 subkeys.pgp.net has address 208.90.26.99 subkeys.pgp.net has address 213.239.206.174 subkeys.pgp.net has address 64.71.173.107 subkeys.pgp.net has address 116.240.198.71 lennartsorensen@lennartsorensen:~$ gpg --keyserver 195.113.19.83 --recv-keys 1F41B907 gpg: requesting key 1F41B907 from hkp server 195.113.19.83 gpg: key 1F41B907: public key Christian Marillat maril...@debian.org imported gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: Total number processed: 1 gpg: imported: 1 lennartsorensen@lennartsorensen:~$ gpg --keyserver 208.90.26.99 --recv-keys 1F41B907 gpg: requesting key 1F41B907 from hkp server 208.90.26.99 ?: 208.90.26.99: No route to host gpgkeys: HTTP fetch error 7: couldn't connect: No route to host gpg: no valid OpenPGP data found.
Re: Fwd: /bin/sh linked to dash? SOlVED, however..
On Fri, Jul 08, 2011 at 05:39:01PM -0400, Robert Isaac wrote: It's more trivial to change the default shell to bash if it is necessary for a configuration, there is no need to get defensive about dash or force its use upon anyone that doesn't want to use it. So a few seconds saved whenever a kernel update is issued justifies breaking existing configurations? Are you really making that argument? Anyone that writes scripts assuming /bin/sh is bash has always been broken. Many unix systems do NOT have bash as /bin/sh. This has mainly been the case on a lot of linux systems, but not much else ever. So yes I will make that argument. Scripts that are broken and always have been are simply broken. Just because they worked for a lot of people (but not all) doesn't mean they were ever right. Some people have put a lot of effort into improving boot speeds. Some people have put a lot of effort into finding and fixing bashisms in scritps that are supposed to only require posix. Clearly they thought this was worthwhile. Are you going to argue that changing the first line of a script so that it is correct, works everywhere (rather than just a lot of places by accident) is a bad idea? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110709000246.gl7...@caffeine.csclub.uwaterloo.ca
Re: Fwd: /bin/sh linked to dash? SOlVED, however..
On Sat, Jul 02, 2011 at 11:34:30PM +0200, Francesco Pietra wrote: The first I did (after having computed successfully with mopac on the basis of sh - bash), was to remove the symlink, having now again sh - dash, in order to avoid possible problems in addition to the many I am having since I added GPU to CPU for simulations. Then I went through the forum of AMBER, into whose metacode mopac is found. I came across a suggestion alike the one I used. ** On Wed, Nov 11, 2009 at 5:04 PM, Wallace Kunin kunin.marshall.edu wrote: This is antechamber.out: Total number of electrons: 58; net charge: 0 Running: /home/kunin/amber10/bin/mopac.sh ln: creating hard link `FOR005': File exists /home/kunin/amber10/bin/mopac.sh: 12: Syntax error: Bad fd number Error: cannot run /home/kunin/amber10/bin/mopac.sh of bcc() in charge.c properly, exit Reply from: Jason Swails jason.swails.gmail.com Date: Wed, 11 Nov 2009 17:30:35 -0500 Hello, As for confirmation about /bin/sh, I too use Ubuntu. The first thing I did when I began setting up my environment was to redirect /bin/sh to /bin/bash rather than /bin/dash, since it causes a lot of headaches. You could, of course, go through the Amber source tree and change #!/bin/sh to #!/bin/bash to make it use the proper shell, but this issue is pervasive enough that I think it is worth changing /bin/sh permanently. Well they are wrong. /bin/sh is and always has been posix shell, not bash (except on many linux systems). Any script that breaks if /bin/sh is not bash is simply broken and should be fixed. If you google Bad fd number, you will see countless hits of people saying Ubuntu links /bin/sh to dash rather than bash. (since /bin/sh is a symbolic link to /bin/dash). The almost unanimous fix for this issue is something along the lines of sudo rm /bin/sh; sudo ln -s /bin/bash /bin/sh to make /bin/sh point to /bin/bash. It would be worth seeing if this fixes the issue. Just because lots of people say This works doesn't make it right. Any script that uses #!/bin/csh should be fine since it explicitly calls cshell as long as you have cshell installed (which Ubuntu does NOT come with by default, but can be obtained via apt-get install csh). Same with #!/bin/bash. Hope this helps, Jason It seems that with sh - dash I should correct some hundreds of codes in FORTRAN. Luckily, I have abandoned such main code, only using some fringe tools. In those rare cases I'll put temporarily again the symlink for sh - bash. Finding all scripts with /bin/sh and changing them to /bin/bash can be done in a couple of lines of perl. Trivial to do really, and fixing the problem once and for all would be a good idea (and /bin/sh is not going back to bash, it is going to dash or other smaller and more efficient posix shell choices since it speeds up boot time to not have to load bash for things that don't require bash). Debian has spent years clearing out all the bashisms from init scripts in order to allow the transition to dash. Computational chemical code is very conservative. Beyond those marginal problems above, such conservative aptitude is faced by the need of following the needs of GPU-CPU computing, which is at the opposite side of conservative. Being conservative is fine. Being wrong isn't. Among the many odds I am encountering, at gnome-session or ck-launch- session gnome-session I am warned that metacity-session was not saved. Actually, I am using twm not metacity. Very confusing. Both NAMD (a molecular-mechanics code) and VMD (a viewer and tools for NAMD) use CUDA. Launching VMD as the first application, it says creating CUDA device pool and initialing hardware and works fine. Closing VMD, if I try to launch it again, the same phrase creating CUDA... appears, while the computer hangs. Same issue if VMD is launched after a run with NAMD. With the large files from NAMD (20-100 GB) I need the speed up of CUDA to VMD for my system of nearly 300,000 atoms. The version on CPUs alone has difficulty. In contrast to VMD, NAMD needs to have the CUDA cards ready for use, which I do with nvidia-smi -L command. However, if issued without gnome support (from the linux prompt, without X-server) NAMD fails to find the CUDA cards and the computer hangs. From a terminal window in gnome-2, NAMD runs fine on CUDA, however, once the run is finished, it proves difficult to go out from gnome/X-server and the computer hangs. I have tried with user logout or even Ctrl-Alt-F1. Normally the computer hangs, only rarely it was closed correctly. What is wrong in my system has defeated so far my understanding. The only good point is that once a NAMD simulation, or a VMD investigation, are started, they run without any problem and finish without any warning. -- Len SOrensen -- To UNSUBSCRIBE, email to
Re: Fwd: /bin/sh linked to dash? SOlVED, however..
On Fri, Jul 01, 2011 at 10:39:05PM +0200, Francesco Pietra wrote: Solved by # mv /bin/sh /bin/sh_original # ln -s /bin/bash /bin/sh now ls -l sh - /bin/bash and mopac does its job. Hopefully, this should also allow the hundreds of other codes inside the main code to work, if the same problem occurs. However, I would like to have the opinion of those who know if this is the correct way of doing and why with wheezy this change. Yeah as already said, not the thing to do. Fix the scripts. If they say /bin/sh then they are asking for a posix shell, and trying to do anything else is a bug. Trying to use bash features is certainly a bug. If the scripts explicitly ask for bash then it is fine to use bash features. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110702202147.gj7...@caffeine.csclub.uwaterloo.ca
Re: about latest nvidia cuda driver 275.09.07
On Thu, Jun 30, 2011 at 10:21:15AM +0200, Francesco Pietra wrote: Following kind guidance by Lennart Sorensen as to the correct installation of the nvidia driver, I recently got a two GTX-470 computer work perfectly for molecular dynamics simulations with NAMD-CUDA. The simulations were launched from linux terminal, without calling the X server. Command (as root) nvidia-smi -L was first needed to activate the GTX 470 cards (udev normal affair) On 27Jun the system was upgraded from driver 270.41.19 to 275.09.07. On rebooting, dkms did its job for the existing headers 2.6.38-2. However, now the above NAMD-CUDA MD launching does not work any more. Sincerely I can't say if the crash described below occurred immediately after the driver upgrading, but the dates are very close. Now, on launching MD as above described, the system hangs, the screen shows blinking characters and letters, and the power must be shut down. The log of the simulation says CUDA error cudaStreamCreate on P2 0 which is a normal message of NAMD when the graphic boards are not seen. However, the computer should not hang. Launching NAMD-CUDA from a terminal window of gnome-2, the procedure runs correctly. I understand that this report fails to analyze correctly what happens. It is a simple warning to see if other amd64 users had problems with the new nvidia driver. Are all the nvidia packages the same version? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110630144944.gh7...@caffeine.csclub.uwaterloo.ca
Re: cuda error cudastreamcreate,
On Tue, Jun 14, 2011 at 07:54:16AM +0200, Francesco Pietra wrote: Hello: With a gaming machine Gigabyte GA 890FXAUD5 Six-core AMD PhenomII 1075T 2x GTX 470 Debian GNU-Linux amd64 wheezy I run successfully NAMD code (molecular dynamics simulations). Now I am having problems getting GTX 470 to work and I can't understand whether it is hardware or software problem, and if software the OS is concerned. I am submitting the same problem to NAMD, s it might be NAMD specific. When the code works, the top of the log file says: nfo: Based on Charm++/Converse 60303 for net-linux-x86_64-iccstatic Info: Built Sat Jun 4 02:22:51 CDT 2011 by jim on lisboa.ks.uiuc.edu Info: 1 NAMD CVS-2011-06-04 Linux-x86_64-CUDA 6gig64 francesco Info: Running on 6 processors, 6 nodes, 1 physical nodes. Info: CPU topology information available. Info: Charm++/Converse parallel runtime startup completed at 0.00650811 s Pe 5 sharing CUDA device 1 first 1 next 1 Pe 2 sharing CUDA device 0 first 0 next 4 Did not find +devices i,j,k,... argument, using all Pe 5 physical rank 5 binding to CUDA device 1 on gig64: 'GeForce GTX 470' Mem: 1279MB Rev: 2.0 Pe 2 physical rank 2 binding to CUDA device 0 on gig64: 'GeForce GTX 470' Mem: 1279MB Rev: 2.0 Pe 0 sharing CUDA device 0 first 0 next 2 Pe 3 sharing CUDA device 1 first 1 next 5 Pe 1 sharing CUDA device 1 first 1 next 3 Pe 1 physical rank 1 binding to CUDA device 1 on gig64: 'GeForce GTX 470' Mem: 1279MB Rev: 2.0 Pe 0 physical rank 0 binding to CUDA device 0 on gig64: 'GeForce GTX 470' Mem: 1279MB Rev: 2.0 Pe 3 physical rank 3 binding to CUDA device 1 on gig64: 'GeForce GTX 470' Mem: 1279MB Rev: 2.0 Pe 4 sharing CUDA device 0 first 0 next 0 Pe 4 physical rank 4 binding to CUDA device 0 on gig64: 'GeForce GTX 470' Mem: 1279MB Rev: 2.0 Info: 1.64104 MB of memory in use based on CmiMemoryUsage Info: Configuration file is min-02.conf When failure: Info: Based on Charm++/Converse 60303 for net-linux-x86_64-iccstatic Info: Built Sat Jun 4 02:22:51 CDT 2011 by jim on lisboa.ks.uiuc.edu Info: 1 NAMD CVS-2011-06-04 Linux-x86_64-CUDA 6gig64 francesco Info: Running on 6 processors, 6 nodes, 1 physical nodes. Info: CPU topology information available. Info: Charm++/Converse parallel runtime startup completed at 0.0124412 s Pe 5 sharing CUDA device 0 first 0 next 0 Pe 5 physical rank 5 binding to CUDA device 0 on gig64: 'Device Emulation (CPU)' Mem: 0MB Rev: . FATAL ERROR: CUDA error cudaStreamCreate on Pe 5 (gig64 device 0): no CUDA-capable device is available - Processor 5 Exiting: Called CmiAbort Reason: FATAL ERROR: CUDA error cudaStreamCreate on Pe 5 (gig64 device 0): no CUDA-capable device is available Did not find +devices i,j,k,... argument, using all Pe 0 sharing CUDA device 0 first 0 next 1 Pe 0 physical rank 0 binding to CUDA device 0 on gig64: 'Device Emulation (CPU)' Mem: 0MB Rev: . Pe 3 sharing CUDA device 0 first 0 next 4 Pe 3 physical rank 3 binding to CUDA device 0 on gig64: 'Device Emulation (CPU)' Mem: 0MB Rev: . Pe 1 sharing CUDA device 0 first 0 next 2 Pe 1 physical rank 1 binding to CUDA device 0 on gig64: 'Device Emulation (CPU)' Mem: 0MB Rev: . FATAL ERROR: CUDA error cudaStreamCreate on Pe 0 (gig64 device 0): no CUDA-capable device is available - Processor 0 Exiting: Called CmiAbort Reason: FATAL ERROR: CUDA error cudaStreamCreate on Pe 0 (gig64 device 0): no CUDA-capable device is available FATAL ERROR: CUDA error cudaStreamCreate on Pe 3 (gig64 device 0): no CUDA-capable device is available - Processor 3 Exiting: Called CmiAbort Reason: FATAL ERROR: CUDA error cudaStreamCreate on Pe 3 (gig64 device 0): no CUDA-capable device is available FATAL ERROR: CUDA error cudaStreamCreate on Pe 1 (gig64 device 0): no CUDA-capable device is available - Processor 1 Exiting: Called CmiAbort Reason: FATAL ERROR: CUDA error cudaStreamCreate on Pe 1 (gig64 device 0): no CUDA-capable device is available Pe 2 sharing CUDA device 0 first 0 next 3 Pe 2 physical rank 2 binding to CUDA device 0 on gig64: 'Device Emulation (CPU)' Mem: 0MB Rev: . FATAL ERROR: CUDA error cudaStreamCreate on Pe 2 (gig64 device 0): no CUDA-capable device is available - Processor 2 Exiting: Called CmiAbort Reason: FATAL ERROR: CUDA error cudaStreamCreate on Pe 2 (gig64 device 0): no CUDA-capable device is available Pe 4 sharing CUDA device 0 first 0 next 5 Pe 4 physical rank 4 binding to CUDA device 0 on gig64: 'Device Emulation (CPU)' Mem: 0MB Rev: . FATAL ERROR: CUDA error cudaStreamCreate on Pe 4 (gig64 device 0): no CUDA-capable device is available - Processor 4 Exiting: Called CmiAbort Reason: FATAL ERROR: CUDA error cudaStreamCreate on Pe 4 (gig64 device 0): no CUDA-capable
Re: Fwd: cuda error cudastreamcreate,
On Tue, Jun 14, 2011 at 07:23:38PM +0200, Francesco Pietra wrote: I forgot to answer: yes, sometime it works, sometimes not, everything being the same. As a matter of fact, after a day of failure, I have now renamed back /lib/modules/2.638-2-amd64/updatesdkms/no_nvidia.ko to /lib/modules/2.638-2-amd64/updatesdkms/nvidia.ko and the NAMD simulation started regularly using both gtx 470. The machine had not been touched either. I wonder if having the 9800 card in there along with the 470 gtx cards is confusing the driver. Maybe the card order is getting swapped around on some boots. What is the 9800 doing in the box anyhow? -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110614190157.gf21...@caffeine.csclub.uwaterloo.ca
Re: running CUDA cards
On Sat, Jun 04, 2011 at 08:32:13AM +0200, Francesco Pietra wrote: That was the point and I can summarize how the error arose. It may help other users about debian-6.0.1a-amd64-netinst.iso for wheezy. (1) Manual partitioning with raid1, two raids, one for /boot and another one lvm with home, opt, usr, etc. (2) German mirror (univ-Koeln) for standard system installation only. (3) Being no other OS present, install grub on /boot. (4) Removed CDROM, boot into the sytem, kernel 2.6.32-5 (I wronly assumed it was for wheezy). 6.0 is squeeze, so that's what you get with the 6.0.1a installer. To get a testing installer you would have had to go to www.debian.org/devel/debian-installer/ and look for the daily images. (5) Edited sources.list for wheezy. Update, upgrade, install X, nvidia packages. There was a mismatch from the installed kernel and the subsequent installations for wheezy. nvidia packages were actually installed according to the procedure that you indicated, but because of the mismatch (6) dist-upgrade, getting kernel 2.6.38-2 (not 2.6.38-5). (7) Installed twm and xinit and modified .Xsession: #!/bin/sh xrdb -load $HOME/.Xresources xterm exec twm startx works correctly, while linux-image-2.6-amd64 and linux-headers-2.6-amd64 are correctly installed. May I ask (a) What should have been done in between steps (4) and (5) to avoid the mismatch? Best bet for running wheezy is use the testing installer, not the stable installer. Otherwise a dist-upgrade should pull in the current kernel (which step 6 seems to have done). Installing stable and changing sources.list and doing a dist-upgrade works too, but takes a bit longer. (b) Should I look for 2.6.38-5? No, I hit the wrong key. :) (c) I don't remember how to remove the previous 2.6.32-5 kernel. 'apt-get autoremove' will probably offer to remove it. If not you can do 'dpkg --purge linux-image-2.6.32-5-amd64'. Thanks a lot for your learned and kind help. No problem. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110606141920.go21...@caffeine.csclub.uwaterloo.ca
Re: running CUDA cards
On Thu, Jun 02, 2011 at 04:58:18PM +0200, Francesco Pietra wrote: From the recent network install CD, I have set up a RAID1 software with ext2 /boot in a first raid and root, usr, opt, var, tmp and home ext3, plus swap into a second raid LVM. Installed the 'base system' only for the moment, with sources.list pointing to 'wheezy' (which is now in the state of testing, no more unstable). Only failed to fetch multimedia in spite of requesting the key (timeout). Perhaps I should have installed debian-multimedia_2008.1016_all.deb, or what more recent exists, with dpkg. Not tried. Installed xterm. Created hidden file .Xsession as follows #!/bin/sh xrdb -load$HOME/.Xresources exec xterm into my home, as I am used at computing from the Linux prompt, without calling the X server (I dont' know if this will be the case with CUDA ). Using your kind suggestions for a squeeze installation: Installed nvidia-kernel-dkms. At apt-get install nvidia-glx-dev libcuda1-dev libcuda1 the first two were not available. The first one replaced by libgl1-nvidia-glx libcuda1. The second one replaced by libcuda1. apt-get install libgl1-nvidia-glx libcuda1 also installed libnvidia-ml1 and nvidia-smi. My .bashrc -as obtained from the installation - was only added of alias rm='rm -i'. In a i386 squeeze installation (not in lenny amd64 installations) .bashrc contains VEGADIR=/usr/local/bin/Vega LD_LIBRARY_PATH=/usr/local/bin/Vega export VEGADIR export LD_LIBRARY_PATH At the console command X You have to reboot after installing nvidia-glx to make sure it is NOT using the neuvou kernel driver. Otherwise the nvidia driver gets cranky. the system crashes. while command startx is not recognized. I regret putting these last naive reports, perhaps tired by the attention required by the setting up of RAID1, a procedure that is only repeated every many months and thus not at immediate memory. I didn't think you would actually run X on the machine. You have to setup X to use the nvidia driver then. apt-get install nvidia-xconfig, then run nvidia-xconfig, and that should take care of it. Thanks a lot for advice (the case is for overclocked gaming, thus with powerful 14cm fans). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110602155806.gl21...@caffeine.csclub.uwaterloo.ca
Re: running CUDA cards
On Tue, May 31, 2011 at 05:20:35PM +0200, Francesco Pietra wrote: I have just set up a gaming machine with Gigabyte GA 890FXUD5 AMD Phenom II 10775T 2 x GTX470 GPU cards 4 x 4GB RAM 2 x 1 Tb HD for RAID1 and need to install amd64 to run molecular dynamics using (free for non-commercial use) NAMD software (released binary below or compilation from source). All that is experimental, with little experience and I have no experience whatsoever with CUDA cards. My question is about the version of amd6a to be best used (lenny or squeeze) and what should be added to the typical server installation according to the requirements: Lenny will stop having support soon, so absolutely go with squeeze. The nvidia-glx package in squeeze supports the GTX470 card. Lenny does not. So install squeeze. To install the driver, add 'contrib non-free' to your lines in /etc/apt/sources.list then do: apt-get update apt-get install nvidia-kernel-dkms apt-get install nvidia-glx nvidia-glx-dev libcuda1-dev libcuda1 (1) NVIDIA Linux driver version 195.17 or newer (released Linux binaries are built with CUDA 2.3, but can be built with newer versions as well). squeeze has 195.36.31 so that should work. (2) libcudart.so.2 included with the binary (the one copied from the version of CUDA it was built with) must be in a directory in your LD_LIBRARY_PATH before any other libcudart.so libraries. For example: setenv LD_LIBRARY_PATH .:$LD_LIBRARY_PATH (or LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH) ./namd2 +idlepoll configfile ./charmrun ++local +p4 ./namd2 +idlepoll configfile The libcuda1 package should probably take care of the library I think, but maybe not. wheezy has a lot more cuda packages available, and much newer drivers too, but is of course testing, not stable. THE FOLLOWING CAN BE SKIPPED, unless one is specifically interested in the matter: The +idlepoll in the command line is needed to poll the GPU for results rather than sleeping while idle, i.e. NAMD does not use any non-specified GPU card. Each namd2 process can use only one GPU. Therefore you will need to run at least one process for each GPU you want to use. Multiple processes can share a single GPU, usually with an increase in performance. NAMD will automatically distribute processes equally among the GPUs on a node. Specific GPU device IDs can be requested via the +devices argument on the namd2 command line, for example: ./charmrun ++local +p4 ./namd2 +idlepoll +devices 0,2 configfile -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531155619.ge21...@caffeine.csclub.uwaterloo.ca
Re: running CUDA cards
On Tue, May 31, 2011 at 07:15:03PM +0200, Francesco Pietra wrote: Unlike CPU machines, where the computational software is stable, with CUDA support the situation is highly experimental, changes rapidly and has requirements of recent OS support. New versions of NAMD every few weeks and even night builds. One of the goals is to have even energies computed by GPU. That to say that I would have no objection to install wheezy unless it is too much an adventure. It might well be that a new version of NAMD comes soon with requirements of libraries not available in squeeze. Finally, NAMD would be the only application installed on this dedicated machine so that if dramatic problems occur, there will be little to reinstall. I imagine that amd64 RAID1 support will be at least as good as with lenny. In this case, perhaps, hardware RAID1 would be better but it is too expensive. I plan to change from lenny to squeeze with the CPU workstation. Quantum mechanics unlike classical mechanics has no CUDA support yet (except with very expensive proprietary software, if it works at all). Well most of the time testing is quite usable, so wheezy is not a bad option. It would give you much newer nvidia drivers and cuda stuff easily. RAID1 and such will work exactly the same in all the versions. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110531175016.gg21...@caffeine.csclub.uwaterloo.ca
Re: Fwd: workstation for CUDA
On Mon, May 16, 2011 at 07:17:46AM +0200, Francesco Pietra wrote: I also forgot a most important aspect of CUDA in the choice of the mainboard. Currently, the GPUs carry out only a part - albeit major - of the task (non bonded forces), while bonded forces and PME long-range forces are left to the CPUs. In practice, a CPU to GPU 2:1 ratio is still needed. The situation is not likely to change rapidly due to enormous task of parallelizing with the myriad of loci on GPUs. Perhaps, developers are waiting until GPU-CPU integrated boards are available. GTX 570 cards can be found in single slot versions, which helps a lot for what you want. A number of motherboards with 4 PCIe x16 slots can be found as well. If ou want a 2:1 ratio of cpu to gpu, then probably a dual 6 core xeon or even dual 4 core would be good. A single 8 or 12 core opteron might also be possible to get if anyone makes a board with four slots for video cards. EVGA has a board called the SR-2 which takes dual xeon (up to 6 core each), and has 7 PCIe x16 slots for video cards and such. Putting four single slot GTX 570s in that should not be a problem. It can take at least 24GB of ram. There are a few others like it around. You would need a serious power supply for 4 video cards of course, but that isn't a big deal. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110516164345.gh21...@caffeine.csclub.uwaterloo.ca
Re: libcholmod
On Tue, May 03, 2011 at 04:12:13PM +0100, A J Stiles wrote: Or even better, just put the -dev files in the main library package already. The time when separate -dev packages were a good idea has been and gone a long while since; nowadays, they are doing more harm than good. Those of us making embedded devices would very much like to disagree. Also having the ability to install multiple versions of a library, but only one set of development headers has been a great feature in Debian for many years. So again, bad idea. The -dev packages are not about saving disk space at all. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110503151927.gc21...@caffeine.csclub.uwaterloo.ca
Re: Evolution problem - SQUEEZE/WHEEZY
On Wed, Apr 06, 2011 at 01:18:09AM +0100, Alasdair Campbell wrote: I have recently installed WHEEZY to a separate partion on one of my hard drives. My HOME folder is on another partition and is mounted on /home in /etc/fstab in both WHEEZY and SQUEEZE. Now here is the funny thing - I cannot see any of my evolution vfolders when logged into SQUEEZE, all _new_ messages appear in Inbox and all messages that appeared in my vfolders are not shown. When I reboot into WHEEZY all my vfolders appear, and all my messages appear _except_ the _new_ messages that are shown in SQUEEZE. I am at a complete loss as to why this can be happening. All other files in my /home/USER directory behave exactly the same (notably .bashrc) Can anyone help? I am at my wit's end. When you used the version in wheezy it probably converted the format of the config files in $HOME to a new format, and the old version can't read them anymore. That's always a hazard of sharing a home between different systems. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110405235233.ge...@caffeine.csclub.uwaterloo.ca
Re: 32 or 64 bits for the end user.
On Thu, Mar 24, 2011 at 03:48:26PM -0400, Robert Isaac wrote: For Stable? Historically it's never updated so as to _not_ be vulnerable when Adobe screws up. Do you really want to put someone's spouse through the forced death march that is Sid just for a secure flash plugin? That may be grounds for divorce in some countries. That doesn't seem relevant to whether 32 or 64bit works with flash. That's just a problem with the flash plugin in general. Same package and version exists in stable. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110324202323.gu...@caffeine.csclub.uwaterloo.ca
Re: 32 or 64 bits for the end user.
On Tue, Mar 22, 2011 at 05:10:52PM -0400, Robert Isaac wrote: The current stable flash plugin is 32-bit only which leaves you using either nsplugin-wrapper or a 32-bit browser. There is a 64-bit beta that was released last year that works fine but no one will package it for the usual reasons. What is wrong with http://packages.debian.org/sid/flashplugin-nonfree ? Works for me (as well as flash ever works that is). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110322211632.gs...@caffeine.csclub.uwaterloo.ca
Re: help getting grub to see Windows 7 on second drive
On Fri, Dec 10, 2010 at 11:48:35AM +, Michael Fothergill wrote: Windows of course saw the scanner right off the bat and then scanned some files and rebooted into Debian mounted the Windows disk on the linux tree and ran gscantopdf on the scanned files and worked round my scanning problem. Funny given I have an HP all in one inkjet/scanner thing, that it works automatically with linux, but windows 7 doesn't have a driver for it (XP was the only OS HP supported apparently). -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101210154443.gq12...@caffeine.csclub.uwaterloo.ca
Re: help getting grub to see Windows 7 on second drive
On Fri, Dec 10, 2010 at 04:45:00PM +, A J Stiles wrote: Sort of makes you wonder why the EU haven't already made it a legal requirement for hardware manufacturers to supply driver Source Code, if they want to sell their products in any European country. How much otherwise perfectly serviceable kit do you think is ending up in landfill for want of drivers? Linksys WMP54G cards have no drivers for Windows 7, even though ralink (make of the chip in v4 and v4.1 cards) has windows 7 drivers available (which can even be installed if you force them and do work). Does linksys care? Nope, not one bit. ATI has a long history of not supporting hardware with drivers if it is more than 2 or 3 years old. For that matter the FireGL V3350 cards which are still for sale have no support under linux from ATI anymore. What's with that? OK the drivers were buggy shit when they did support it, but still better than not supported at all. Of course linux users have no problem using the cards at all. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101210185526.gs12...@caffeine.csclub.uwaterloo.ca
Re: dumb question about dual booting debian and Windows 7 on separate drives.....
On Wed, Dec 08, 2010 at 11:43:02AM +, Michael Fothergill wrote: Dear Debian folks, I an running Lenny on an AMD64 box. I have 8GB of RAM on the machine in anticipation of putting Windows 7 on the machine. I know many Debian folks don't bother with Windows but I need it for certain things I do.. I bought an extra SATA drive and hooked it up so now I have two one with Debian on it. My plan is to install Windows on the new drive.. If you installed Windows on the new drive and then installed Debian grub would see the Windows on the other drive and create a boot option for you to fire it up if you wanted to when you boot the PC up. I believe windows won't boot unless it is on the primary harddisk. Linux is much less picky. This is why people usualyl say to install windows first, then install linux. linux knows how to share a machine, windows does not believe in sharing. Making your current debian install move from being the first harddisk to being the second might break things (although all fixable, it is all fstab and bootloader related, unless you happen to be using UUID based fstab and grub in which case everything might just work anyhow). Unfortunately Lenny does NOT use UUIDs normally, while Squeeze appears to default to it. You will want to switch to that first to make the fstab much more flexible about rearranging drives. But if you installed debian first as I have on one disk and then add Windows on the other one then if you boot up the machine it will load Windows and you won't get a choice to fire up Linux (at least I don't expect it). You can certainly have grub know about windows, it tends to detect that automaticly in most cases. I had a piece of software for Windows called Partition Magic which I seem to have lost. If I still had it I could install it on Windows (after installed that OS) and it would see the Linux on the other drive... I could set up its bootloading program and then when the machine rebooted it would give me choice to boot either Linux or the Windows.. Partition magic really isn't worth it anymore. It rarely works with modern large disks. That would be a way to load Linux first and Windows second on two separate drives and still be able to get a choice to load either OS on boot up of the PC.. Just have grub in the MBR of the primary disk with an option for both. Simple and reliable. Except of course there would be other ways because I have sent you this email and if you were kind you might point out some of them. I could cheat and install the Windows and then reinstall Debian and grub would see it but I don't want to do that. I want to keep the old installation. Well without fixing the config to have debian work from what would be the second disk after adding a new one, I don't believe you can get windows to work. How would you modify grub to see a Windows OS that hasn't been installed yet? Could I use the installer in Debian to make Windows partition on the new drive and then install the Windows on it and then grub would see it and boot up seeing both OSes? It is possible I think to modify the bootloader in Windows (without using e.g. Partition Magic) to sniff out the Linux and allow you to choice of booting it when you boot up the PC.. Yes, but it's fragile and not worth doing that way. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101208160609.gp12...@caffeine.csclub.uwaterloo.ca
Re: Sound from a java applet running in iceweasel
On Tue, Dec 07, 2010 at 12:43:42AM -0600, Karl Schmidt wrote: Not sure how to fix this one. The possible source of the problem is iceweasel, alsa, java, amd64.. I can't find much other than other people saying it didn't work. Flash works fine - I understand it talks directly to alsa. I'm seeing that others are talking about using pulseaudio - I’m hesitant to start down yet another audio path. I've got no idea if pulseaudio replaces alsa or works with alsa. Here is a java sound test - can anyone get this to work via iceweasel/squeeze on amd64? Alsa is a sound driver, pulseaudio is not, so it certainly is no replacement for alsa. Best I can tell pulseaudio is a replacement for esd and/or artsd. I can't tell why I would want it or either of the other two on my system. Recently I couldn't get rhythmbox to play sound. Killing (and eventually uninstalling to prevent it restarting) pulseaudio fixed it. Good riddance. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101207164051.gn12...@caffeine.csclub.uwaterloo.ca
Re: Sound from a java applet running in iceweasel
On Tue, Dec 07, 2010 at 11:38:12AM -0600, Karl Schmidt wrote: Interesting - Pulse audio seems to be being pushed as a new sound server There is this from wikipedia http://www.javasonics.com/support/check_play.html I'm not understanding the whole of the sound picture in the Linux world - I thought ALSA was the sound 'system' which included the server function? If it is only the driver part - providing a software interface to the sound hardware that clears up a bit. If ALSA is not a sound server what is alasmixer doing? Alsamixer ajusts the hardware mixer of your sound chip. That's what mixers usually do (until windows vista added virtual mixing in software). But then what are esd and arts, jack? I wish I could find someplace that clearly defined the roles of these sound packages. It appears there is a lot of over lapping functionality. It is not clear if the sound servere or the application should be responsible for setting levels and routing sound to the correct hardware. esd is a sound server to allow multiple applications to share a sound device, and I believe also has some support for audio from remote applications being run in X (not sure about that part). artsd is very similar but kde related instead. jack is mainly for connecting various audio devices together (usually alsa run devices) with low latency. Great for audio editing stuff, not sure if it has much use elsewhere. In the mean time, it appears that java/iceweasel does not know how to talk to alsa or arts? Or am I wrong? Debian has embraced ALSA but how/when will a sane API for sound appear. Well alsa can emulate oss which is the original linux sound interface. Look at alsa-oss package. Were you able to play that test clip? http://www.javasonics.com/support/check_play.html There are many remote radio tuners such as this http://194.29.11.10/ that provide java audio.. I was actually under the impression no one used java plugins on web pages anymore. Now I am disppointed to hear that isn't the case. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101207180259.go12...@caffeine.csclub.uwaterloo.ca
Re: Intel Wifi Link 5100 - halt system on Squeeze
On Sat, Nov 13, 2010 at 04:58:52PM -0300, Felipe Valverde wrote: Definitively the culprit is the new driver. I tried the testing and the unstable driver but they just do not work properly. They will freeze my laptop as soon as I try to connect to a wireless network. My fix is just a band-aid and it can't be considered a good fix, but it works. In order to know if the driver is the problem, I compiled the 2.6.35.7 kernel version a few time ago and works perfectly (I'm using it now), so I think that the problem isn't the driver. Before that, I compiled others version and also works. Another interesting thing is with the same hardware on Ubuntu also works, so, I wonder if the problem is on the way that the kernel was compile for amd64 or something else. On the other hand, when I used the 2.6.32-27 (current kernel for Squeeze) the system is halt most of the time. So... ¿Someone is using the current kernel and drivers from Squeeze repository on a amd64 and have it working well? If upgrading the kernel fixes things, then it does sound like a driver issue. Almost certainly the driver has changed between 2.6.32 and 2.6.35.7. This wouldn't be the first time an update has broken the 5100. It happened once before that a stable point update broke the 5100. I think that was in 2.6.31 or maybe early 2.6.32. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101115165450.gs12...@caffeine.csclub.uwaterloo.ca
Re: Changing from stable to testing.....
On Mon, Oct 25, 2010 at 07:39:52PM +0200, sigi wrote: Hi Whit, last time I tried to dist-upgrade to squeeze, I got stuck in an (for me) unresolvable loop: The system wanted to upgrade the kernel-image and udev in one run - which failed. apt-get always complained, that the kernel-image needs the new udev-package to upgrade - and udev itself needed the new kernel-image... I don't know, if this problem still exists - if yes: you should find a way of not getting into this loop, where no apt-get -f install helped to stop this. I reinstalled lenny after this... ;) Yeah udev needs 2.6.27 or higher, so you have to upgrade the kernel first, then reboot, then do the whole upgrade. I have no idea what the plan for handling the upgrade is officially. Maybe the release notes are supposed to offer some hint. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101025184254.gr12...@caffeine.csclub.uwaterloo.ca
Re: Having trouble establishing IP masquerading
On Sat, Sep 11, 2010 at 12:10:30PM +, Hendrik Boom wrote: I've been IP masquerading for years. But now my Pentium front-end machine has bit the dust, and I'm setting up my server to do the masquerading itself. It's and AMD65 running Debian lenny: hend...@lovesong:~$ uname -a Linux lovesong 2.6.30-1-486 #1 Mon Aug 3 15:05:33 UTC 2009 i686 GNU/Linux hend...@lovesong:~$ I've been more-or-less following the instructions in http://tldp.org/HOWTO/IP-Masquerade-HOWTO/firewall-examples.html but nothing seems to work. I wondered it perhaps the modules weren't being loaded, so I did lsmod. INstead of the modules I requested, whose names started with ip_, I have another set of modules with similar names starting with nf_. Is this relevant? The script I'm using to start IP forwarding is as follows: Personally I really like shorewall for managing iptables. You write a couple of simple shorewall rules, and it takes care of all the details. It is really quite handy. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100913140859.gr2...@caffeine.csclub.uwaterloo.ca
Re: SDIO wifi support?
On Mon, Sep 06, 2010 at 05:39:33PM -0500, Karl Schmidt wrote: I was thinking of getting a card like this for my camera: http://www.amazon.com/Eye-Fi-Class-Wireless-Memory-EYE-FI-8PC/dp/B002UT42UI Having a hard time figuring out if there is support for these in squeeze? Has anyone been down this road? So support for doing what in squeeze? It appears to be meant to put in a supported camera. As for what it does once you put it in a camera, I am not sure. No idea if it requries special software on a PC to receive, or how you configure the wifi settings on the card for the camera. If you are wondering if you could use it as a wifi adapter in a PC with an SD slot, well them most likely the answer is no. I don't think most SD adapters support SDIO. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100907180036.go2...@caffeine.csclub.uwaterloo.ca
Re: rollback after software upgrade
On Mon, Jul 26, 2010 at 06:19:39AM +0200, Michael Dominok wrote: On Wed, 21 Jul 2010 20:07:37 +0300 Vladimir tetl...@gmail.com wrote: Is there a way to rollback the software after standard apt-get (aptitude) upgrade? I use a little script which creates backup of the packages involved before doing the upgrade. I anything goes wrong during install all i have to do is to change into the backup directory and do dpgk -i *. And hope the upgrade did convert any data files to a new incompatible format. In other words, short of a complete system backup, or a snapshot filesystem, it can't be done. Yes you can hack your way around it 99% of the time, but that just isn't always good enough. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100726144809.gs2...@caffeine.csclub.uwaterloo.ca
Re: rollback after software upgrade
On Wed, Jul 21, 2010 at 08:07:37PM +0300, Vladimir wrote: Is there a way to rollback the software after standard apt-get(aptitude) upgrade? No. At least not without a lot of manual work that may or may not work. -- Len oSrensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100721172028.gh2...@caffeine.csclub.uwaterloo.ca
Re: intel i3 processor
On Tue, Jul 20, 2010 at 05:15:47PM +1000, Dean Hamstead wrote: Amd64 is also about more general purposes registers in addition to bigger numbers. Generally speaking anything will benefit from more registers, and if a problem uses the larger int's (or uses a large number library which uses them) you will experience enormous performance gains. More addressable memory helps as well. There is 64bit flash bit adobe dropped it. It can be found if you are happy with the known security problems. 8 years of amd64 and counting. I've even asked our redhat rep when 32bit i686 will be dropped (not any time soon, gar!) i386 has no problem doing 64bit intergers and 64 (and even 80) bit floating point. The difference is in the size of pointers. amd64 has 64bit pointers so each application can use more memory, and it has more general purpose registers (as you said) which helps the compiler optimize better, and it uses SSE for floating point (not x87) which is much faster and more efficient (but drops support for 80 bit floating point, not that anyone cares). Of course the fact you can optimize for amd64 instruction set rather than i486 also makes the compiler happier. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100720143131.ge2...@caffeine.csclub.uwaterloo.ca
Re: intel i3 processor
On Mon, Jul 19, 2010 at 10:28:57AM -0400, Christopher Browne wrote: On Mon, Jul 19, 2010 at 10:08 AM, Siddharth Ravikumar rsiddharth.m...@gmail.com wrote: I am planning to build my own computer . I have choosen to use intel i3 as my processor , I just want to know whether debian amd64 will be the right debian port If am to use intel i3 ? . i have not yet bought the processor , so I would like to know whether 32-bit processor or 64-bit processor is recommended given the fact that I use only GNU/Linux based operating system . There's somewhat more software that runs on IA-32 than on x86_64. The sorts of things that people find missing on x86_64 are: - Adobe Flash Well at the moment 64bit flash is broken but it is possible to install and use. Flash on linux is in general rather bad though. - Possibly Skype - Third party things provided in binary form (e.g. - no sources) If you care about those sorts of applications a lot, then that should certainly influence your decision, probably towards 32 bit. If not, then there's still often not *strong* reason to prefer 64 bit - it's not vastly superior on all kinds of workloads, though there are considerable advantages for applications that can really use a lot of memory. If you want to use more than 3GB ram efficiently, or get the most out of your system, use 64bit. For a bit less hassles, use 32bit. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100719143343.gb2...@caffeine.csclub.uwaterloo.ca
Re: intel i3 processor
On Mon, Jul 19, 2010 at 08:14:17PM +0530, Siddharth Ravikumar wrote: I am actually quiet happy with 32bit , but it looks like the future is going to be 64bit. So if I build my comp this year , I will be using it for the next 3 - 4 years or so . I am under a confusion whether to go for 32bit or 64bit. Well personally I have 64bit on my laptop, my work desktop, and two out of three desktops at home (one is an old athlon so it wasn't an option). So I run 64bit if possible on the hardware. If proprietary binaries are important to you, then you might want 32bit instead. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100719162604.gc2...@caffeine.csclub.uwaterloo.ca
Re: status of skype amd64
On Sat, Jun 26, 2010 at 09:56:15PM -0500, Karl Schmidt wrote: Lennart Sorensen wrote: Until some day skype decides to open their protocol and actually play nice with anyone else, rather than try to build a VoIP monopoly, it simply won't happen. I just tell people to not use skype. :) Everyone else uses SIP. Is there a provider that provides a SIP to land-line jump like skype but using SIP..? Hundreds if not thousands of them. Look up DID service providers. For example: http://www.voip-info.org/wiki/view/DID+Service+Providers I imagine Skype wishes people didn't know they had other options. Skype may be a bit easier to setup given it is an all in one service, but still. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100628185109.gg2...@caffeine.csclub.uwaterloo.ca
Re: how to do science with amd64 lenny
On Fri, Jun 18, 2010 at 02:57:16PM +0200, Dimitris Lampridis wrote: I was about to suggest something similar: 1) Add the deb-src for debian testing in your sources.list 2) apt-get update 3) apt-get source mpich2 4) apt-get build-dep mpich2 5) cd mpich2-1.2.1.1 (or whatever the name of the created folder) 6) dpkg-buildpackage -uc -us 7) cd .. 8) dpkg -i *.deb If you are doing that then you can do: 1) Add the deb-src for debian testing in your sources.list 2) apt-get update 3) apt-get build-dep mpich2 4) apt-get source mpich2 -b 5) dpkg -i *.deb So you first add the source packages of debian testing, you update, you pull the source package of mpich2, then you pull all the required packages to build mpich2, and finally you build it. If all goes well, the deb packages will be produced in the parent folder. There is one catch: in the 4th step, where you pull the build dependencies, it could be that you are missing something in the stable distribution. In that case, you have to pause the mpich2 build process, and first do the same trick for any missing packages. Fortunately my test build seemed to indicate that wouldn't be a problem in this case. At least that's what I saw. I do have a few backported packages installed already so who knows. So, if you are missing some X build dependency, then you should first pull the source of X, its build dependencies, build it, install it and then try again the build-dep command, until it does not complain about anything missing. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100618145538.gf17...@caffeine.csclub.uwaterloo.ca
Re: how to do science with amd64 lenny
On Fri, Jun 18, 2010 at 05:15:09PM +0200, Lothar Ketterer wrote: On Fri, Jun 18, 2010 at 02:57:16PM +0200, Dimitris Lampridis wrote: [...] 6) dpkg-buildpackage -uc -us i suggest to use a non-root account whenever possible. The dpkg-buildpackage command can be run as a normal user by the help of fakeroot or something similar: dpkg-buildpackage -rfakeroot -uc -us Very good point. Then just switch to root for the dpkg -i part. 'dpkg-buildpackage -us -uc -rfakeroot -b' it is then. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100618163550.gj17...@caffeine.csclub.uwaterloo.ca
Re: how to do science with amd64 lenny
On Fri, Jun 18, 2010 at 07:17:26PM +0200, Lothar Ketterer wrote: On Fri, Jun 18, 2010 at 12:35:50PM -0400, Lennart Sorensen wrote: Very good point. Then just switch to root for the dpkg -i part. 'dpkg-buildpackage -us -uc -rfakeroot -b' it is then. I forgot to mention that this only makes sense because apt-get source package doesn't require root permissions and can (should) be called as normal user. Write permissions for the current working directory are necessary, of course. I wonder if apt-get source -b automatically adds fakeroot when not running as root. I should try that. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100618181702.gk17...@caffeine.csclub.uwaterloo.ca
Re: how to do science with amd64 lenny
On Thu, Jun 17, 2010 at 06:05:05PM +0200, Francesco Pietra wrote: Hello: For computational chemistry on the stable amd64 I needed yesterday MPICH2. As the deb package is only in testing, I compiled MPICH2 for stable, but the parallelized program needs python2.6, only available in testing. I doubt I am able enough to compile python. I can't move to testing because I am not allowed to do that not only for the risk of testing distributions for computational work but also because older key computational package do not run on testing. Question: would installing python2.6 on lenny from unstable be safe enough by using apt-pinning? I have no system expert here. I would be responsible for damage to the software. Otherwise, do you know a distribution of linux that overcomes such problems by making some key recent packages available for their stable version? I could suggest to move to that because of recurring problems for us. I would consider moving python2.6 likely more risky than simply moving to testing entirely. No distribution can provide recent packages for stable releases because then it isn't stable anymore. Too many other dependancies end up having to be pulled in in many cases. Either you want stable, or you want current. You can not have both. Now in this case, a question to consider is: Does it actually need python 2.6 or not? If it doesn't then you can probably just compile the one package you want for stable. I just compiled and installed mpich2 (from unstable) on a system running stable, and installed it. No complaint about that. So if it requires python2.6, the package certainly doesn't enforce that. I just got the source package and did: dpkg-source -x mpich2_1.2.1.1-4.dsc cd mpich2-1.2.1.1 dpkg-buildpackage -us -uc -D apt-get install list of whatever packages the above said was missing for building dependancies dpkg-buildpackage -us -uc -b cd .. dpkg -i *1.2.1.1-4*deb I have no idea how to test if it works of course. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100617170424.ge17...@caffeine.csclub.uwaterloo.ca
