Re: How to package SuperCollider (or, whats the deal with multiarch)
[EMAIL PROTECTED] (Lennart Sorensen) writes: On Wed, Dec 14, 2005 at 11:17:30AM +0100, Mario Lang wrote: So I guess the final answer is either we figure out a preprocessor based patch which makes the necessary adjustments for 64bit archs, and leaves the code basically the same for 32bit archs, or we don't package SC for 64-bit archs. Some defines that are set differently on different archs might work. I haven't looked at the code long enough to find where this whole thing is defined in the source code. source/headers/lang/PyrSlot.h Once I find it I might consider trying something silly with it. -- Have fun, Mario pgponhXjCXpqj.pgp Description: PGP signature
Re: Flash (Re: OpenOffice-2.0.)
v0n0 [EMAIL PROTECTED] writes: I have repacked some 32bit debs. You can now try it from my repository, but please read notes on my website first! Nice, thanks. Here are two bugs I found: Setting up mozilla-firefox-32 (1.0.7-1.32b1) ... Updating mozilla-firefox chrome registry...E: Registration process existed with status: 1 E: /usr/lib/mozilla-firefox-32/extensions/installed-extensions.txt still present. Registration might have gone wrong. mv: tiedoston /usr/lib/mozilla-firefox-32/defaults.ini tilaa ei voi lukea: Tiedostoa tai hakemistoa ei ole dpkg: error processing mozilla-firefox-32 (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: mozilla-firefox-32 And then later, if I ignore the problem above: kaylee ~ % mozilla-firefox-32 /usr/lib/mozilla-firefox-32/firefox-bin: /lib32/tls/libc.so.6: version `GLIBC_2.3.4' not found (required by /usr/lib/mozilla-firefox-32/firefox-bin) -- * 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]
kernel-2.6.14: Did I miss some info ?
Hello all, yes, I followed the discusion about nvidia-kernel and kernel-2-6-14. And yes, I know that there are problems. But is there a general problem with the kernel-sources ? Look at my additionals please. Did I miss some informations ? I wonder, why all these modulles cannot be compiled any more (as they did with version 2.6.12). But compiling crashes also for the following sources: ipw2100 hostap ieee80211 This seems to me a general problem, does it ? (strangewise ndwiswrapper compiled fine) Best regards Hans This is my output: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel-2.6.14: Did I miss some info ?
On Thu, Dec 15, 2005 at 11:03:14AM +0100, Hans wrote: yes, I followed the discusion about nvidia-kernel and kernel-2-6-14. And yes, I know that there are problems. But is there a general problem with the kernel-sources ? Look at my additionals please. Did I miss some informations ? I wonder, why all these modulles cannot be compiled any more (as they did with version 2.6.12). Well on i386 I can compile 7174-4 with 2.6.14 on i386 (athlon 700) and it works perfectly. Maybe amd64 has a problem that is different, since I haven't tried that version on 2.6.14 on amd64. I only keep the old version since I have a TNT2. I know 8xxx nvidia driver compiles with 2.6.14 just fine. But compiling crashes also for the following sources: ipw2100 hostap ieee80211 The 2.6. kernel recently got some ipw/ieee80211 code added to it which now causes conflicts with the external code. This seems to me a general problem, does it ? (strangewise ndwiswrapper compiled fine) I think 2.6.15 might break ndiswrapper but I haven't quite followed the arguments that involved some things breaking on lkml. It might just have been hypothetical breakage if a certain suggested change went in. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
chroot, autofs, and bind
Hi We want to set up some amd-64 machines in an i686 environment. To do so, we would like to follow the approach witch a chrooted 32-bit environment on the 64-bit machines as discribed in the amd-64 HowTo .Especially, one needs to have access to the data in the /home-directory under the chroot also, which can be solved using a bind-mount. However, in our situation the /home directory is mounted from a server using autofs. Bind-mounting an autofs-imported filesystem is not a great idea, since this leads inevitably to kernel crashes (we are using kernel 2.6.12 and automount 4.1.4_beta2). At the moment, we have the following workaround: mounting the autofs-exported /home not into the native 64-bit environment, but into the 32-bit chroot, instead. The /home in the 64-bit environment is a symlink pointing to /home in the chroot. Is this workaraound reliable? Are there better solutions? And no, at the moment we have to use the autofs. Many thanks in advance Martin Schmid Martin Schmid [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
