Swiss pharmacy
Do you want inexpensive Soma? http://www.dgko.com/p/viks/16 or 160 other drugs: http://www.dgko.com/p/viks you alkaloid me cereus me you berkowitz me castigate me you p's me filmy me you paramedic me gross me you erosive me ophthalmic me you needlework me agway me http://ymil.com/1.php -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32bit chrooted apps can't use OpenGL .
Hello, On Sat, Mar 26, 2005 at 10:25:51PM -0500, Zaq Rizer wrote: Any idea when 2.6.11.X will be available in sid/amd64? kernel-source-2.6.11 entered sid today, so expect kernel-image-2.6.11-amd64 within a day or two. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
[AGAIN] kde 3.4 packages anybody?
From wiki.debian.net: KDE 3.4.0 will not enter sid until sarge is released. Now i _DO_ worry for having an alternative repository.. anyone with 64-bit packages? Regards, Rafael Rodríguez
ASUS - K8N-E Deluxe Install Report (using /debian-installer/2005-03-24)
Debian-installer-version: http://debian-amd64.alioth.debian.org/debian-installer/2005-03-24/monolithic/mini.iso uname -a: Linux owl 2.6.8-10-amd64-k8 #1 Tue Mar 15 17:25:19 CET 2005 x86_64 GNU/Linux Date: March - 27, 2005 Method: netinstall from ftp://mirror.switch.ch/mirror/debian-amd64/pure64 testing main contrib non-f ree and http://debian-amd64.alioth.debian.org/pure64 testing main contrib non-free (some packages were not available from the switch mirror or the network was choppy) Machine: Custom machine, Asus K8N-E Deluxe Motherboard Processor: AMD64 3200+ Memory: 2x512 MB Cordair Xmms Root Device: IDE : /dev/hda1 (secondary devices on /dev/sda /dev/sdb : sata) Root Size/partition table: # file system mount point type options dump pass proc/proc procdefaults0 0 /dev/hda1 / ext3defaults,errors=remount-ro 0 1 /dev/hda6 /home ext3defaults0 2 /dev/hda7 /linux32ext3defaults0 2 /dev/hda8 /windowsvfatdefaults0 2 /dev/hda5 noneswapsw 0 0 /dev/hdc/media/cdrom0 iso9660 ro,user,noauto 0 0 /dev/hdd/media/cdrom1 iso9660 ro,user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 Note : the SATA disks are not mounted yet (WinXP) (mount -t ntfs /dev/sda1 /xproot does the trick) Output of lspci and lspci -n: lspci :00:00.0 Host bridge: nVidia Corporation: Unknown device 00e1 (rev a1) :00:01.0 ISA bridge: nVidia Corporation: Unknown device 00e0 (rev a2) :00:01.1 SMBus: nVidia Corporation: Unknown device 00e4 (rev a1) :00:02.0 USB Controller: nVidia Corporation: Unknown device 00e7 (rev a1) :00:02.1 USB Controller: nVidia Corporation: Unknown device 00e7 (rev a1) :00:02.2 USB Controller: nVidia Corporation: Unknown device 00e8 (rev a2) :00:05.0 Bridge: nVidia Corporation: Unknown device 00df (rev a2) :00:08.0 IDE interface: nVidia Corporation: Unknown device 00e5 (rev a2) :00:0a.0 IDE interface: nVidia Corporation: Unknown device 00e3 (rev a2) :00:0b.0 PCI bridge: nVidia Corporation: Unknown device 00e2 (rev a2) :00:0e.0 PCI bridge: nVidia Corporation: Unknown device 00ed (rev a2) :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] :01:00.1 Display controller: ATI Technologies Inc Radeon R350 [Radeon 9800 Pro] (Secondary) :02:09.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03) :02:09.1 Input device controller: Creative Labs SB Audigy MIDI/Game port (rev 03) :02:09.2 FireWire (IEEE 1394): Creative Labs SB Audigy FireWire Port :02:0b.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) :02:0c.0 RAID bus controller: Silicon Image, Inc. (formerly CMD Technology Inc) SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02) lspci -n lspci -n :00:00.0 0600: 10de:00e1 (rev a1) :00:01.0 0601: 10de:00e0 (rev a2) :00:01.1 0c05: 10de:00e4 (rev a1) :00:02.0 0c03: 10de:00e7 (rev a1) :00:02.1 0c03: 10de:00e7 (rev a1) :00:02.2 0c03: 10de:00e8 (rev a2) :00:05.0 0680: 10de:00df (rev a2) :00:08.0 0101: 10de:00e5 (rev a2) :00:0a.0 0101: 10de:00e3 (rev a2) :00:0b.0 0604: 10de:00e2 (rev a2) :00:0e.0 0604: 10de:00ed (rev a2) :00:18.0 0600: 1022:1100 :00:18.1 0600: 1022:1101 :00:18.2 0600: 1022:1102 :00:18.3 0600: 1022:1103 :01:00.0 0300: 1002:4e48 :01:00.1 0380: 1002:4e68 :02:09.0 0401: 1102:0004 (rev 03) :02:09.1 0980: 1102:7003 (rev 03) :02:09.2 0c00: 1102:4001 :02:0b.0 0c00: 1106:3044 (rev 80) :02:0c.0 0104: 1095:3114 (rev 02) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [E] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[O] Reboot: [O] Comments/Problems: When detecting the network HW (embedded nForce 3 controler), I had only 2 NIC detected, the two firewire ports (as eth0 and eth1). I had to exit from the installer, execute a shell command: #modprobe forcedeth and then back into the installer. I was wondering why the initial kernel didn't have the forcedeth module instaled or whether it was a problem with the detection of the nForce 3 controler. Another thing that is a bit annoying, and that may be due to my own lack
Re: ASUS - K8N-E Deluxe Install Report (using /debian-installer/2005-03-24)
On Sun, 27 Mar 2005 15:19:02 +0200, Remi Butaud [EMAIL PROTECTED] wrote: Debian-installer-version: # This entry automatically added by the Debian installer for a non-linux OS # on /dev/sda1 title Microsoft Windows XP Professional root(hd1,0) savedefault makeactive chainloader +1 The device.map file seems ok (hd0) /dev/hda (hd1) /dev/sda (hd2) /dev/sdb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32bit chrooted apps can't use OpenGL .
Frederik Schueler wrote: Hello, On Sat, Mar 26, 2005 at 10:25:51PM -0500, Zaq Rizer wrote: Any idea when 2.6.11.X will be available in sid/amd64? kernel-source-2.6.11 entered sid today, so expect kernel-image-2.6.11-amd64 within a day or two. Kind regards Frederik Schueler Oh, excellent, I see that now. Thanks Frederik! -- Firefox is both more secure and more modern than IE [Internet Explorer], and it comes packed with user-friendly features the Microsoft browser can't touch. -- Walt Mossberg, The Wall Street Journal. Find out what all the fuss is about: Get Mozilla Firefox. http://www.getfirefox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [AGAIN] kde 3.4 packages anybody?
Rafael Rodríguez wrote: From wiki.debian.net: KDE 3.4.0 will not enter sid until sarge is released. Now i _DO_ worry for having an alternative repository.. anyone with 64-bit packages? Regards, Rafael Rodríguez Have you tried installing from source? -- Firefox is both more secure and more modern than IE [Internet Explorer], and it comes packed with user-friendly features the Microsoft browser can't touch. -- Walt Mossberg, The Wall Street Journal. Find out what all the fuss is about: Get Mozilla Firefox. http://www.getfirefox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [AGAIN] kde 3.4 packages anybody?
I may think that unless debian accept the proposal of kept officially the work in the 4 more used arquitectures we all will be living that delays in gnome or kde. I've been using ubuntu Hoary in a laptop some time now and it has gnome 2.10 already and it's really stable, and so there's kubuntu for the kde lovers with kde 3.4 almost full done http://www.ubuntulinux.org/wiki/KubuntuKDEStatus So if you wanna live like a desktop user using debian you might want give it a try, you know there's a amd64 port :), install hoary and then apt-get install kubuntu-desktop :) Juan A. Zaq Rizer escribi: Rafael Rodrguez wrote: From wiki.debian.net: KDE 3.4.0 will not enter sid until sarge is released. Now i _DO_ worry for having an alternative repository.. anyone with 64-bit packages? Regards, Rafael Rodrguez Have you tried installing from source?
Re: [AGAIN] kde 3.4 packages anybody?
Zaq Rizer [EMAIL PROTECTED] writes: Have you tried installing from source? I'm currently compiling the stuff from source and will probably set up a binary repository (probably unsigned packages, so use at your own discretion). I'll let you know later where. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32bit chrooted apps can't use OpenGL .
If you don't mind building a package or using the stock kernel, you should be able to get the 7167 drivers going without too much issue. In summary: * start with a stock source tree of 2.6.11, configured for your box * install the nvidia-kernel-source package with apt * build and install the binary modules package * install the nvidia-glx package with apt At this point, your 64-bit setup should run fine. To use GL inside the 32-bit chroot, you need to install the nvidia-glx package there as well, but you're going to run into a dependency problem (or you're going to have to build the nvidia-kernel-2.6.11 package inside the chroot, which is what you've run into). A quick fix to this is, inside the chroot: cd /tmp apt-get source nvidia-glx cd nvidia-graphics-drivers-1.0.7167 vi debian/control (remove nvidia-kernel-#VERSION# from the Depends: line for nvidia-glx) dpkg-buildpackage -rfakeroot -us -uc sudo dpkg --install nvidia-glx_1.0.7167-1_i386.deb I think the process raises an interesting question about support for chroots in general. It seems like it would be helpful to differentiate between Depends and something like Kernel-Depends, since in general you'll never be able to actually satisfy Kernel-Depends for packages inside of the chroot (which is to say, since you're not running those modules, you're just using up disk space). A fairly simple work-around would be to have packages like nvidia-graphics-drivers build a dummy nvidia-kernel-chroot package that provided the nvidia-kernel-#VERSION# package, but I don't know if that would be palatable to the non-chrooting community at large. Cheers, tony Zaq Rizer wrote: There's a lot of unfortunate back story to this, but I'll spare you all and give you the current-day situation, as it stands, after a fresh complete reinstall: Because I cannot install the latest (7167) nvidia drivers via the method listed in the HOWTO on alioth, I've attempted installing them via nvidia's own installer. It worked just fine, although it warned me that I should be running 2.6.11+. Then about two hours later, I found out as X crashed in a flaming ball of death. So, I rolled back to 6629 (using nvidia's own drivers). These work perfectly, as they did before. However. In the 32bit chroot, I have installed 7167 via apt-get install, because, as far as I can tell, there is no way to install 6629 from nvidia's own installer (because it complains that it's an amd64 system, even while in the chroot) and the only version available in my unstable 32bit chroot is 7167. So in lieu of installing 2.6.11 (which I'll probably end up doing, but I've gotten rather happy with debian-provided kernels) what other options do I have? Any idea when 2.6.11.X will be available in sid/amd64? Thanks, Zaq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
kernel-image-2.6.11-amd64 packages
Hello list, I am currently uploading the first release of kernel-image-2.6.11-amd64 to alioth. If your system needs the tg3 network driver, you should NOT INSTALL these packages until kernel-source-nonfree-2.6.11 and the resulting nonfree-modules packages are ready, wich will contain tg3 and other drivers with firmware currently not shipped by debian 2.6 kernels. Again: the tg3 module was moved to another package wich is not ready yet. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: [mythtv] Freezes on 64bit when starting recordings or LiveTV
On 27/03/2005 Isaac Richards wrote:
On Sunday 27 March 2005 05:59 am, Adam Egger wrote:
Ok, I've found an old patch from Kyle Rose to replace all
pthread_rwlock_* calls with a mix of pthread_mutex_* and
pthread_cond_*:
http://www.gossamer-threads.com/lists/mythtv/users/107232?search_string=pth
read_rwlock;#107232
Isaac, is it a bad solution to replace them permanently in RingBuffer.cpp?
Yes. That patch isn't correct, and I'm not going to stop using standard
functionality just because it's broken on one little-used platform. I'm
fairly sure people are using native 64-bit stuff elsewhere, so it's just
seems like Debian's behind as usual.
i upgraded the patch for mythtv 0.17 anyway, as i don't want to wait for
debian/pure64 to fix the glibc.
here it is, for all the people that like to run mythtv 0.17 on
debian/unstable pure64.
bye
jonas
diff -ru mythtv-0.17.orig/libs/libmythtv/RingBuffer.cpp
mythtv-0.17/libs/libmythtv/RingBuffer.cpp
--- mythtv-0.17.orig/libs/libmythtv/RingBuffer.cpp 2005-03-27
14:59:20.0 +0200
+++ mythtv-0.17/libs/libmythtv/RingBuffer.cpp 2005-03-27 15:00:11.396760584
+0200
@@ -490,14 +490,17 @@
numfailures = 0;
commserror = false;
-pthread_rwlock_init(rwlock, NULL);
+pthread_mutex_init(hammerlock, NULL);
+pthread_cond_init(hammercond, NULL);
+readers = 0;
+writers = 0;
}
RingBuffer::~RingBuffer(void)
{
KillReadAheadThread();
-pthread_rwlock_wrlock(rwlock);
+unlock();
if (remotefile)
{
delete remotefile;
@@ -525,7 +528,7 @@
void RingBuffer::Reset(void)
{
wantseek = true;
-pthread_rwlock_wrlock(rwlock);
+write_lock_wait();
wantseek = false;
if (!normalfile)
@@ -552,7 +555,7 @@
numfailures = 0;
commserror = false;
-pthread_rwlock_unlock(rwlock);
+unlock();
}
int RingBuffer::safe_read(int fd, void *data, unsigned sz)
@@ -616,12 +619,43 @@
return ret;
}
+void RingBuffer::read_lock_wait()
+{
+pthread_mutex_lock(hammerlock);
+while (writers 0)
+{
+pthread_cond_wait(hammercond, hammerlock);
+}
+readers++;
+pthread_mutex_unlock(hammerlock);
+}
+
+void RingBuffer::write_lock_wait()
+{
+pthread_mutex_lock(hammerlock);
+while (readers 0 || writers 0)
+{
+pthread_cond_wait(hammercond, hammerlock);
+}
+writers = 1;
+pthread_mutex_unlock(hammerlock);
+}
+
+void RingBuffer::unlock()
+{
+pthread_mutex_lock(hammerlock);
+if (readers 0) readers--;
+else writers = 0;
+pthread_cond_signal(hammercond);
+pthread_mutex_unlock(hammerlock);
+}
+
#define READ_AHEAD_SIZE (10 * 256000)
void RingBuffer::CalcReadAheadThresh(int estbitrate)
{
wantseek = true;
-pthread_rwlock_wrlock(rwlock);
+write_lock_wait();
wantseek = false;
fill_threshold = 0;
@@ -653,7 +687,7 @@
if (fill_min == 0)
fill_min = -1;
-pthread_rwlock_unlock(rwlock);
+unlock();
}
int RingBuffer::ReadBufFree(void)
@@ -793,7 +827,7 @@
readaheadpaused = false;
-pthread_rwlock_rdlock(rwlock);
+ read_lock_wait();
if (totfree readblocksize !commserror)
{
// limit the read size
@@ -901,7 +935,7 @@
}
availWaitMutex.unlock();
-pthread_rwlock_unlock(rwlock);
+ unlock();
if ((used = fill_threshold || wantseek) !pausereadthread)
usleep(500);
@@ -1012,7 +1046,7 @@
int RingBuffer::Read(void *buf, int count)
{
-pthread_rwlock_rdlock(rwlock);
+read_lock_wait();
int ret = -1;
if (normalfile)
@@ -1068,7 +1102,7 @@
{
if (stopreads)
{
-pthread_rwlock_unlock(rwlock);
+ unlock();
return 0;
}
@@ -1087,7 +1121,7 @@
if (stopreads)
{
availWaitMutex.unlock();
-pthread_rwlock_unlock(rwlock);
+ unlock();
return 0;
}
}
@@ -1118,7 +1152,7 @@
}
}
-pthread_rwlock_unlock(rwlock);
+unlock();
return ret;
}
@@ -1126,11 +1160,11 @@
{
bool ret = false;
int used, free;
-pthread_rwlock_rdlock(rwlock);
+unlock();
if (!tfw)
{
-pthread_rwlock_unlock(rwlock);
+unlock();
return ret;
}
@@ -1139,7 +1173,7 @@
ret = (used * 5 free);
-pthread_rwlock_unlock(rwlock);
+unlock();
return ret;
}
@@ -1147,11 +1181,11 @@
{
int ret = -1;
-pthread_rwlock_rdlock(rwlock);
+unlock();
if (!tfw)
{
-pthread_rwlock_unlock(rwlock);
+unlock();
return ret;
}
@@ -1200,7 +1234,7 @@
availWaitMutex.unlock();
}
-pthread_rwlock_unlock(rwlock);
+unlock();
return ret;
}
@@ -1217,7 +1251,7 @@
long long RingBuffer::Seek(long long
Re: 32bit chrooted apps can't use OpenGL .
On Sun, 27 Mar 2005 07:45:52 -0800 tony mancill [EMAIL PROTECTED] wrote: A fairly simple work-around would be to have packages like nvidia-graphics-drivers build a dummy nvidia-kernel-chroot package that provided the nvidia-kernel-#VERSION# package, but I don't know if that would be palatable to the non-chrooting community at large. % cat nvidia-kernel-dummy Section: misc Priority: optional Standards-Version: 3.5.10 Package: nvidia-kernel-dummy Version: 1.0 Maintainer: Me [EMAIL PROTECTED] Provides: nvidia-kernel-1.0.7167 Architecture: all % equivs-build nvidia-kernel-dummy [...] then, in ia32 chroot: % sudo dpkg -i nvidia-kernel-dummy_1.0_all.deb [...] % sudo apt-get install nvidia-glx -- Me -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Simple downgrade steps
I'd appreciate it if someone with a bit more know-how could recap the basic steps and most common problems with downgrading, both from gcc-3.4/4.0 to pure64 sid, as well as from pure64 sid to pure64 sarge. I managed two sid - sarge downgrades without too much hassle, but the many instructions in the mailing list history were a bit contradictory. Perhaps this kind of information could be added to the HOWTO as well? Also, does anyone have any idea if the maintainer is planning a newer version of DFS with more recent kernels? I tried emailing the developer but so far, without response. /v\ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [AGAIN] kde 3.4 packages anybody?
I did manage to compile _most_ of kde3.4, however kdemultimedia would'nt compile _no how_ for me. I would be interested if you could Kalle forward the output of dpkg -l to me, so I can figure out which packages I'm missing? and, of course your binary repository url of course. 8?P My current problem, with my _mostly_ compiled kde3.4, is how to integrate my compiled binaries into the standard debian file system. If anyone knows of a how-to I would love to study it. This would be of great interest to me. Thanks, Chris W. On March 27, 2005 06:21 am, Kalle Kivimaa wrote: Zaq Rizer [EMAIL PROTECTED] writes: Have you tried installing from source? I'm currently compiling the stuff from source and will probably set up a binary repository (probably unsigned packages, so use at your own discretion). I'll let you know later where. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Software at a reasonable price
Have a nice daySome Non-Productive Affixes The second question we must answer in this chapter is how new meanings develop. To find the answer to this question we must inves-tigate the inner mechanism of this process, or at least its essential features. Let us examine the examples given above from a new angle, from within, so to speak.
Re: kernel-image-2.6.11-amd64 packages
On 27/03/2005 Frederik Schueler wrote: I am currently uploading the first release of kernel-image-2.6.11-amd64 to alioth. the sources fail to build for me with the attached .config: --- # fakeroot make-kpkg --initrd --append-to-version -1-amd64 kernel_image [...] CC drivers/scsi/sg.o LD drivers/scsi/built-in.o ld: drivers/scsi/qla2xxx/built-in.o: No such file: No such file or directory make[3]: *** [drivers/scsi/built-in.o] Error 1 make[2]: *** [drivers/scsi] Error 2 make[1]: *** [drivers] Error 2 make[1]: Leaving directory `/usr/src/kernel-source-2.6.11' make: *** [stamp-build] Error 2 --- the same .config builds clean with kernel-source-2.6.10. bye jonas # # Automatically generated make config: don't edit # Linux kernel version: 2.6.11-1-amd64 # Mon Mar 28 03:56:34 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y # # General setup # CONFIG_LOCALVERSION= CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_LOG_BUF_SHIFT=14 CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_FUTEX=y CONFIG_EPOLL=y # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODULE_FORCE_UNLOAD=y CONFIG_OBSOLETE_MODPARM=y CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y CONFIG_MICROCODE=m # CONFIG_X86_MSR is not set # CONFIG_X86_CPUID is not set CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y # CONFIG_SMP is not set CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_NUMA is not set # CONFIG_GART_IOMMU is not set CONFIG_DUMMY_IOMMU=y CONFIG_X86_MCE=y CONFIG_X86_MCE_INTEL=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y # CONFIG_ACPI_SLEEP is not set # CONFIG_ACPI_AC is not set # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=m CONFIG_ACPI_VIDEO=m # CONFIG_ACPI_FAN is not set CONFIG_ACPI_PROCESSOR=m CONFIG_ACPI_THERMAL=m # CONFIG_ACPI_ASUS is not set CONFIG_ACPI_IBM=m # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_CONTAINER is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set # CONFIG_PCI_MSI is not set CONFIG_PCI_LEGACY_PROC=y CONFIG_PCI_NAMES=y # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PC-card bridges # # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_UID16=y # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (MTD) # # CONFIG_MTD is not set # # Parallel port support # CONFIG_PARPORT=y CONFIG_PARPORT_PC=m CONFIG_PARPORT_PC_CML1=m # CONFIG_PARPORT_SERIAL is not set CONFIG_PARPORT_PC_FIFO=y # CONFIG_PARPORT_PC_SUPERIO is not set # CONFIG_PARPORT_OTHER is not set CONFIG_PARPORT_1284=y # # Plug and Play support # # CONFIG_PNP is not set # # Block devices # CONFIG_BLK_DEV_FD=y # CONFIG_PARIDE is not set # CONFIG_BLK_CPQ_DA is not set # CONFIG_BLK_CPQ_CISS_DA is not set # CONFIG_BLK_DEV_DAC960 is not set # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_CRYPTOLOOP=m CONFIG_BLK_DEV_NBD=m CONFIG_BLK_DEV_SX8=m # CONFIG_BLK_DEV_UB is not set CONFIG_BLK_DEV_RAM=y CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_LBD=y # CONFIG_CDROM_PKTCDVD is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y
Re: kernel-image-2.6.11-amd64 packages
El lun, 28-03-2005 a las 04:04 +0200, Jonas Meurer escribi: On 27/03/2005 Frederik Schueler wrote: I am currently uploading the first release of kernel-image-2.6.11-amd64 to alioth. the sources fail to build for me with the attached .config: the same .config builds clean with kernel-source-2.6.10. Did you update the config to the newer kernel release? make oldconfig should help. -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: kernel-image-2.6.11-amd64 packages
I do make menuconfig, don't touch anything and just exit saving changes ;) Javier Kohen escribi: El lun, 28-03-2005 a las 04:04 +0200, Jonas Meurer escribi: On 27/03/2005 Frederik Schueler wrote: I am currently uploading the first release of kernel-image-2.6.11-amd64 to alioth. the sources fail to build for me with the attached .config: the same .config builds clean with kernel-source-2.6.10. Did you update the config to the newer kernel release? "make oldconfig" should help.
Re: 32bit chrooted apps can't use OpenGL .
tony mancill wrote: If you don't mind building a package or using the stock kernel, you should be able to get the 7167 drivers going without too much issue. In summary: * start with a stock source tree of 2.6.11, configured for your box * install the nvidia-kernel-source package with apt * build and install the binary modules package * install the nvidia-glx package with apt At this point, your 64-bit setup should run fine. To use GL inside the 32-bit chroot, you need to install the nvidia-glx package there as well, but you're going to run into a dependency problem (or you're going to have to build the nvidia-kernel-2.6.11 package inside the chroot, which is what you've run into). A quick fix to this is, inside the chroot: cd /tmp apt-get source nvidia-glx cd nvidia-graphics-drivers-1.0.7167 vi debian/control (remove nvidia-kernel-#VERSION# from the Depends: line for nvidia-glx) dpkg-buildpackage -rfakeroot -us -uc sudo dpkg --install nvidia-glx_1.0.7167-1_i386.deb I think the process raises an interesting question about support for chroots in general. It seems like it would be helpful to differentiate between Depends and something like Kernel-Depends, since in general you'll never be able to actually satisfy Kernel-Depends for packages inside of the chroot (which is to say, since you're not running those modules, you're just using up disk space). A fairly simple work-around would be to have packages like nvidia-graphics-drivers build a dummy nvidia-kernel-chroot package that provided the nvidia-kernel-#VERSION# package, but I don't know if that would be palatable to the non-chrooting community at large. Cheers, tony Zaq Rizer wrote: There's a lot of unfortunate back story to this, but I'll spare you all and give you the current-day situation, as it stands, after a fresh complete reinstall: Because I cannot install the latest (7167) nvidia drivers via the method listed in the HOWTO on alioth, I've attempted installing them via nvidia's own installer. It worked just fine, although it warned me that I should be running 2.6.11+. Then about two hours later, I found out as X crashed in a flaming ball of death. So, I rolled back to 6629 (using nvidia's own drivers). These work perfectly, as they did before. However. In the 32bit chroot, I have installed 7167 via apt-get install, because, as far as I can tell, there is no way to install 6629 from nvidia's own installer (because it complains that it's an amd64 system, even while in the chroot) and the only version available in my unstable 32bit chroot is 7167. So in lieu of installing 2.6.11 (which I'll probably end up doing, but I've gotten rather happy with debian-provided kernels) what other options do I have? Any idea when 2.6.11.X will be available in sid/amd64? Thanks, Zaq Hmm... So 2.6.11-9 found its way into sid sometime tonight. I was surprised, but I don't know why. Still won't build here: /usr/bin/make EXTRAVERSION=-9-amd64-k8 \ ARCH=x86_64 oldconfig make[1]: Entering directory `/usr/src/kernel-headers-2.6.11-9-amd64-k8' HOSTCC scripts/kconfig/mconf.o scripts/kconfig/mconf.c:91: error: static declaration of 'current_menu' follows non-static declaration scripts/kconfig/lkc.h:63: error: previous declaration of 'current_menu' was here make[2]: *** [scripts/kconfig/mconf.o] Error 1 make[1]: *** [oldconfig] Error 2 make[1]: Leaving directory `/usr/src/kernel-headers-2.6.11-9-amd64-k8' make: *** [stamp-kernel-configure] Error 2 Note to everyone: As I was writing out this email, I removed gcc-4.0 and then re-tried the compilation, and that worked fine. I was using the following command, from the howto: CC=gcc-3.4 make-kpkg --append-to-version -9-amd64-k8 modules_image Apparently CC=gcc-3.4 did not suffice in this case (or something else was going awry) but I had downgrade to 3.4 fully to get the .deb to build. Regards, Zaq -- Firefox is both more secure and more modern than IE [Internet Explorer], and it comes packed with user-friendly features the Microsoft browser can't touch. -- Walt Mossberg, The Wall Street Journal. Find out what all the fuss is about: Get Mozilla Firefox. http://www.getfirefox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32bit chrooted apps can't use OpenGL .
Zaq Rizer wrote: tony mancill wrote: If you don't mind building a package or using the stock kernel, you should be able to get the 7167 drivers going without too much issue. In summary: * start with a stock source tree of 2.6.11, configured for your box * install the nvidia-kernel-source package with apt * build and install the binary modules package * install the nvidia-glx package with apt At this point, your 64-bit setup should run fine. To use GL inside the 32-bit chroot, you need to install the nvidia-glx package there as well, but you're going to run into a dependency problem (or you're going to have to build the nvidia-kernel-2.6.11 package inside the chroot, which is what you've run into). A quick fix to this is, inside the chroot: cd /tmp apt-get source nvidia-glx cd nvidia-graphics-drivers-1.0.7167 vi debian/control (remove nvidia-kernel-#VERSION# from the Depends: line for nvidia-glx) dpkg-buildpackage -rfakeroot -us -uc sudo dpkg --install nvidia-glx_1.0.7167-1_i386.deb I think the process raises an interesting question about support for chroots in general. It seems like it would be helpful to differentiate between Depends and something like Kernel-Depends, since in general you'll never be able to actually satisfy Kernel-Depends for packages inside of the chroot (which is to say, since you're not running those modules, you're just using up disk space). A fairly simple work-around would be to have packages like nvidia-graphics-drivers build a dummy nvidia-kernel-chroot package that provided the nvidia-kernel-#VERSION# package, but I don't know if that would be palatable to the non-chrooting community at large. Cheers, tony Zaq Rizer wrote: There's a lot of unfortunate back story to this, but I'll spare you all and give you the current-day situation, as it stands, after a fresh complete reinstall: Because I cannot install the latest (7167) nvidia drivers via the method listed in the HOWTO on alioth, I've attempted installing them via nvidia's own installer. It worked just fine, although it warned me that I should be running 2.6.11+. Then about two hours later, I found out as X crashed in a flaming ball of death. So, I rolled back to 6629 (using nvidia's own drivers). These work perfectly, as they did before. However. In the 32bit chroot, I have installed 7167 via apt-get install, because, as far as I can tell, there is no way to install 6629 from nvidia's own installer (because it complains that it's an amd64 system, even while in the chroot) and the only version available in my unstable 32bit chroot is 7167. So in lieu of installing 2.6.11 (which I'll probably end up doing, but I've gotten rather happy with debian-provided kernels) what other options do I have? Any idea when 2.6.11.X will be available in sid/amd64? Thanks, Zaq Hmm... So 2.6.11-9 found its way into sid sometime tonight. I was surprised, but I don't know why. Still won't build here: /usr/bin/make EXTRAVERSION=-9-amd64-k8 \ ARCH=x86_64 oldconfig make[1]: Entering directory `/usr/src/kernel-headers-2.6.11-9-amd64-k8' HOSTCC scripts/kconfig/mconf.o scripts/kconfig/mconf.c:91: error: static declaration of 'current_menu' follows non-static declaration scripts/kconfig/lkc.h:63: error: previous declaration of 'current_menu' was here make[2]: *** [scripts/kconfig/mconf.o] Error 1 make[1]: *** [oldconfig] Error 2 make[1]: Leaving directory `/usr/src/kernel-headers-2.6.11-9-amd64-k8' make: *** [stamp-kernel-configure] Error 2 Note to everyone: As I was writing out this email, I removed gcc-4.0 and then re-tried the compilation, and that worked fine. I was using the following command, from the howto: CC=gcc-3.4 make-kpkg --append-to-version -9-amd64-k8 modules_image Apparently CC=gcc-3.4 did not suffice in this case (or something else was going awry) but I had downgrade to 3.4 fully to get the .deb to build. Regards, Zaq Quick follow up: OpenGL games (e.g. Quake3 and Enemy Territory -- but *not* Doom3 [??]) run like total crap now. They run, but at about half what they should -- almost as if it's using the CPU instead of the GPU. -- Firefox is both more secure and more modern than IE [Internet Explorer], and it comes packed with user-friendly features the Microsoft browser can't touch. -- Walt Mossberg, The Wall Street Journal. Find out what all the fuss is about: Get Mozilla Firefox. http://www.getfirefox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 32bit chrooted apps can't use OpenGL .
El lun, 28-03-2005 a las 00:29 -0500, Zaq Rizer escribi: OpenGL games (e.g. Quake3 and Enemy Territory -- but *not* Doom3 [??]) run like total crap now. They run, but at about half what they should -- almost as if it's using the CPU instead of the GPU. Maybe some direct rendering option was disabled when you updated your kernel config? I recommend you use make oldconfig instead of make menuconfig/save/quit. I used to do the latter, but it's really difficult to see what changed (and sometimes options are renamed or replaced), while the former asks you about every new question (usually, not too many between stable releases). However, you should check the obvious places... dmesg, game logs, video driver logs, video driver forums, etc. -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente
Re: 32bit chrooted apps can't use OpenGL .
Javier Kohen wrote: El lun, 28-03-2005 a las 00:29 -0500, Zaq Rizer escribi: OpenGL games (e.g. Quake3 and Enemy Territory -- but *not* Doom3 [??]) run like total crap now. They run, but at about half what they should -- almost as if it's using the CPU instead of the GPU. Maybe some direct rendering option was disabled when you updated your kernel config? I recommend you use make oldconfig instead of make menuconfig/save/quit. I used to do the latter, but it's really difficult to see what changed (and sometimes options are renamed or replaced), while the former asks you about every new question (usually, not too many between stable releases). However, you should check the obvious places... dmesg, game logs, video driver logs, video driver forums, etc. This isn't a vanilla kernel - 2.6.11-9 is in sid/amd64 now. I simply used that. All log files are clean (I checked them first), it's just bad performance...I guess I should be happy the games run at all now, and maybe it will pan out in the coming days. -- Firefox is both more secure and more modern than IE [Internet Explorer], and it comes packed with user-friendly features the Microsoft browser can't touch. -- Walt Mossberg, The Wall Street Journal. Find out what all the fuss is about: Get Mozilla Firefox. http://www.getfirefox.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [AGAIN] kde 3.4 packages anybody?
Chris Wakefield [EMAIL PROTECTED] writes: I did manage to compile _most_ of kde3.4, however kdemultimedia would'nt compile _no how_ for me. Yeah, there's a bug for the 64-bit machines in the source. I made a trivial fix for it and I hope that it works (at least it compiles). Comment out the two typedef's in lines 32 and 34 in mpeglib/lib/input/cdromAccess.cpp. and, of course your binary repository url of course. 8?P Still compiling, wait until tonight (GMT) :) My current problem, with my _mostly_ compiled kde3.4, is how to integrate my compiled binaries into the standard debian file system. If anyone knows of a how-to I would love to study it. This would be of great interest to me. You want to take the pkg-kde project's source packages for Debian and build them (that's what I'm doing). You definitely do NOT want to start with the original KDE source tarballs. -- * Sufficiently advanced magic is indistinguishable from technology (T.P) * * PGP public key available @ http://www.iki.fi/killer * -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
