[12:07] Hmm.. I'll play with it in a couple of hours. === jb-home [n=jbailey@modemcable139.249-203-24.mc.videotron.ca] has joined #ubuntu-ports [12:08] case_, BTW, don't hold you're breath over the smart card reader of the floppy :) [12:08] :) [12:12] Wow, traffic in this channel. I didn't think it ever happened. =) [12:13] jb-home: my mistake, i'm sorry :) [12:13] *lol* === lamont [n=lamont@mix.mmjgroup.com] has joined #ubuntu-ports === daq4th [n=darkness@netstation-005.cafe.zSeries.org] has joined #ubuntu-ports === tuhl [n=tuhl@p5498BF29.dip.t-dialin.net] has joined #ubuntu-ports [03:27] not so many people here :-) [03:27] right :) [03:28] but it takes away noise from -server :) [03:28] and you can discuss more quietly ;) [03:28] zUbuntu will be a server based variant [03:29] tuhl: yes. considering zSeries can't fit under my desk :) [03:29] ok, what about the build-system? launchpad-buildd seems not to be available for the general public ... [03:29] there migth be a pUbuntu aswell [03:30] as I mentioned there will be some additional packages to make it the best distro on zSeries [03:31] VM is a very intersting technology [03:31] and maybe some additions within initscripts .... [03:31] i strongly suggest 2 things [03:31] i dont know how much of that stuff is derived from debian and how much they did for the 2.6 kernel stuff on zSeries [03:31] it should be possible to do some sysadmin jobs form the Linux side [03:31] make your changes as generic as possebile for general integration [03:32] sure [03:32] or make them as specific as possible to be able to keep them isolated from the other arches [03:32] otherwise there will be problem to mesh standard ubuntu with you [03:32] and viceversa [03:32] fabbione: of yourse [03:32] course [03:33] daq4th: you will discuss the buildd with infinity tomorrow :) [03:33] daq4th: there are several vars to keep into account. [03:33] <- sparc porter [03:33] we will do that [03:33] you did the sparc port? [03:34] 98% of it [03:34] I will get a T1000 soon [03:34] nice toy [03:34] but linux can't run on it yet [03:34] from Sun Germayn [03:34] Germany [03:35] Do you have experiences with Mono on SPARC? [03:35] there is no Mono on sparc [03:36] not on linux at least [03:36] ok [03:36] you can run mono on slowlaris [03:36] it is Solaris [03:36] you are right === lamont__ [n=lamont@mib.fc.hp.com] has joined #ubuntu-ports === tuhl [n=tuhl@p5498BF29.dip.t-dialin.net] has joined #ubuntu-ports [10:24] ping? [10:28] pong [10:29] :) [10:30] i'm trying to compile some stuff in 64bits mode on my ubuntu-sparc64, but i have some troubles [10:30] case_, What are you trying to? [10:31] i'm trying to compile pov-ray with CFLAGS="-m64" CXXFLAGS="-m64" [10:31] in pov-ray, there is c sources and C++ sources [10:31] the c compiles with -m64 without any complaint [10:31] but the C++ is another story [10:32] case_, Any real advantage in having pov-ray in 64 bit userspace? [10:32] (in 32bits it compiles just fine) [10:33] shinmen: that's what i want to know :) [10:34] 'cause it's like a sort of a FAQ.. I've seen it in debian, splack and gentoo. People think that having stuff in 64 bit userspace will make them run them faster, but only a handfull of aplications take advantage of it, and it's mainly when they are going to use a huge ammount of memory. And I do mean huge. [10:36] yes i know that (well, that 64bits support is most of the time usefull when you need more than 4Gb of memory) [10:37] but a friend of mine think that double precision floating point will benefit too... [10:38] so, urban legend you say ? [10:39] Well, it could help some aplications, but only a hand full. Pov-ray could be a nice candidate. [10:40] case_, Error? [10:41] a brunch of : /usr/include/c++/4.0.2/iosfwd:45:29: error: bits/c++locale.h: No such file or directory [10:41] (and others headers too) [10:42] case_, Does /usr/include/c++/4.0.3/sparc64-linux-gnu/bits/c++locale.h exist? [10:43] no [10:43] i only have a 4.0.2 directory, and no sparc64-linux-gnu directory [10:43] just sparc-linux-gnu [10:44] Hmm... this is an u80 with dapper... I shutdown my box at home a couple of ours ago. [10:44] i was looking for somthing like libstdc++ 64 but found nothing... [10:44] lokking for, in apt-cache.... [10:45] alvaro@quassar:~$ dpkg -l|grep 64 |grep ^ii|wc -l [10:45] 9 [10:45] (including an smp kernel) [10:46] case@soylent:~$ dpkg -l|grep 64 |grep ^ii|wc -l [10:46] 7 [10:46] (without an smp kernel) [10:48] $ dpkg -S c++locale.h [10:48] libstdc++6-4.0-dev: /usr/include/c++/4.0.3/sparc-linux-gnu/bits/c++locale.h [10:48] libstdc++6-4.0-dev: /usr/include/c++/4.0.3/sparc64-linux-gnu/bits/c++locale.h [10:49] dpkg -S c++locale.h [10:49] libstdc++6-4.0-dev: /usr/include/c++/4.0.2/sparc-linux-gnu/bits/c++locale.h [10:49] that's the problem [10:50] Gonna try it here. U80 with 3 procs... [10:50] I ... hate ... you! :))) [10:50] ok so i'll probably have to upgrade to a draper, no? [10:51] case_, Let me try it here first... if it won't work here, I'll save you a bit of trouble. [10:52] rigth, thanks [10:52] np. [10:59] Done compiling. [11:00] $ file unix/povray [11:00] unix/povray: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), for GNU/Linux 2.4.18, dynamically linked (uses shared libs), not stripped [11:01] case_, Please let me know how the benchmarks go. [11:03] \0/ [11:04] great, so i have to update to dapper [11:05] case_, I could send you the binaries if you'd like. [11:05] thanks but it's cleaner that way [11:05] Ok. And you should trust other people's binaries. [11:06] (Aldo I'm the splack developer if anyone has a real urge for trusting my binaries :) [11:07] :) [11:13] wow, splack, i wasn't aware of that... seems realy cool [11:15] Dumped project... I changed where I work, and the guys from the old job (or anyone else for that matter) haven't shown interesnt in keep it going so I only have a personal up to date repository. [11:15] bbl [11:15] cu === case_ prays and reboots [11:37] of course, i've broken SILO >_< [11:39] Ouch. [11:40] i've booted on the install cd and i've now a shell, but i dont' find my /dev/hda... [12:00] wow... i've just fixed one of the worst dependency mess i've ever seen... (ok ok, i'm not that experienced ;)) [12:01] :)