#ubuntu-ports 2006-01-09
<fabbione> jb-home: glibc 2.3.6 is GO on spar
<fabbione> sparc
<fabbione> at least it did build :)
#ubuntu-ports 2006-01-10
<case_> hi there
<case_> i've just finished the installation of ubuntu on my sunblade 100. Not without some error messages, but it works. good job :)
<shinmen> case_, What video card on yours?
<case_> ATI
<case_> 0000:00:13.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27)
<shinmen> case_, prom version?
<case_> the framebuffer console is a little bit "fuzzy"...
<case_> good question, i don't know
<case_> how can i check that ?
<shinmen> case_, Ohh. Same here. I just haven't seen any reports about that at lkml.
<case_> same thing on debian if i recall well... just... the debian installer is going crasy here before installing anything :)
<case_> so, hurray for ubuntu :)
<shinmen> case_, Sound working? (Haven't tried that yet... I just reinstalled mine yesterday...)
<case_> haven't tried too
<case_> haven't tried with any OS anyway...
<shinmen> :)
<shinmen> I works with 2.4. 2.4.23-rc1 the last one to have worked... Damn Alan Cox...
<shinmen> But haven't tried in 2.6.
<case_> hum... no lkm starting with snd ... i fear we won't use our sparc as a media center anytime soon :)
<case_> (well, no lkm *loaded*)
#ubuntu-ports 2006-01-11
<shinmen> Hmm.. I'll play with it in a couple of hours.
<shinmen> case_, BTW, don't hold you're breath over the smart card reader of the floppy :)
<case_> :)
<jb-home> Wow, traffic in this channel.  I didn't think it ever happened. =)
<case_> jb-home: my mistake, i'm sorry :)
<jb-home> *lol*
<tuhl> not so many people here :-)
<fabbione> right :)
<fabbione> but it takes away noise from -server :)
<fabbione> and you can discuss more quietly ;)
<tuhl> zUbuntu will be a server based variant
<fabbione> tuhl: yes. considering zSeries can't fit under my desk :)
<daq4th> ok, what about the build-system? launchpad-buildd seems not to be available for the general public ...
<tuhl> there migth be a pUbuntu aswell
<tuhl> as I mentioned there will be some additional packages to make it the best distro on zSeries
<tuhl> VM is a very intersting technology
<daq4th> and maybe some additions within initscripts ....
<fabbione> i strongly suggest 2 things
<daq4th> 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
<tuhl> it should be possible to do some sysadmin jobs form the Linux side
<fabbione> make your changes as generic as possebile for general integration
<daq4th> sure
<fabbione> or make them as specific as possible to be able to keep them isolated from the other arches
<fabbione> otherwise there will be problem to mesh standard ubuntu with you
<fabbione> and viceversa
<tuhl> fabbione: of yourse
<tuhl> course
<fabbione> daq4th: you will discuss the buildd with infinity tomorrow :)
<fabbione> daq4th: there are several vars to keep into account.
<fabbione> <- sparc porter
<tuhl> we will do that
<tuhl> you did the sparc port?
<fabbione> 98% of it
<tuhl> I will get a T1000 soon
<fabbione> nice toy
<fabbione> but linux can't run on it yet
<tuhl> from Sun Germayn
<tuhl> Germany
<tuhl> Do you have experiences with Mono on SPARC?
<fabbione> there is no Mono on sparc
<fabbione> not on linux at least
<tuhl> ok 
<fabbione> you can run mono on slowlaris
<tuhl> it is Solaris
<tuhl> you are right
<case_> ping?
<shinmen> pong
<case_> :)
<case_> i'm trying to compile some stuff in 64bits mode on my ubuntu-sparc64, but i have some troubles
<shinmen> case_, What are you trying to?
<case_> i'm trying to compile pov-ray with CFLAGS="-m64" CXXFLAGS="-m64"
<case_> in pov-ray, there is c sources and C++ sources
<case_> the c compiles with -m64 without any complaint
<case_> but the C++ is another story
<shinmen> case_, Any real advantage in having pov-ray in 64 bit userspace?
<case_> (in 32bits it compiles just fine)
<case_> shinmen: that's what i want to know :) 
<shinmen> '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.
<case_> yes i know that (well, that 64bits support is most of the time usefull when you need more than 4Gb of memory)
<case_> but a friend of mine think that double precision floating point will benefit too...
<case_> so, urban legend you say ?
<shinmen> Well, it could help some aplications, but only a hand full. Pov-ray could be a nice candidate.
<shinmen> case_, Error?
<case_> a brunch of : /usr/include/c++/4.0.2/iosfwd:45:29: error: bits/c++locale.h: No such file or directory
<case_> (and others headers too)
<shinmen> case_, Does /usr/include/c++/4.0.3/sparc64-linux-gnu/bits/c++locale.h exist?
<case_> no
<case_> i only have a 4.0.2 directory, and no sparc64-linux-gnu directory
<case_> just sparc-linux-gnu
<shinmen> Hmm... this is an u80 with dapper... I shutdown my box at home a couple of ours ago.
<case_> i was looking for somthing like libstdc++ 64 but found nothing...
<case_> lokking for, in apt-cache....
<shinmen> alvaro@quassar:~$ dpkg -l|grep 64 |grep ^ii|wc -l
<shinmen> 9
<shinmen>  (including an smp kernel)
<case_> case@soylent:~$ dpkg -l|grep 64 |grep ^ii|wc -l
<case_> 7
<case_> (without an smp kernel)
<shinmen> $ dpkg -S c++locale.h
<shinmen> libstdc++6-4.0-dev: /usr/include/c++/4.0.3/sparc-linux-gnu/bits/c++locale.h
<shinmen> libstdc++6-4.0-dev: /usr/include/c++/4.0.3/sparc64-linux-gnu/bits/c++locale.h
<case_> dpkg -S c++locale.h
<case_> libstdc++6-4.0-dev: /usr/include/c++/4.0.2/sparc-linux-gnu/bits/c++locale.h
<case_> that's the problem
<shinmen> Gonna try it here. U80 with 3 procs...
<case_> I ... hate ... you! :)))
<case_> ok so i'll probably have to upgrade to a draper, no?
<shinmen> case_, Let me try it here first... if it won't work here, I'll save you a bit of trouble.
<case_> rigth, thanks
<shinmen> np.
<shinmen> Done compiling.
<shinmen> $ file unix/povray
<shinmen> 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
<shinmen> case_, Please let me know how the benchmarks go.
<case_> \0/
<case_> great, so i have to update to dapper
<shinmen> case_, I could send you the binaries if you'd like.
<case_> thanks but it's cleaner that way
<shinmen> Ok. And you should trust other people's binaries.
<shinmen> (Aldo I'm the splack developer if anyone has a real urge for trusting my binaries :)
<case_> :)
<case_> wow, splack, i wasn't aware of that... seems realy cool
<shinmen> 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.
<shinmen> bbl
<case_> cu
* case_ prays and reboots
<case_> of course, i've broken SILO >_<
<shinmen> Ouch.
<case_> i've booted on the install cd and i've now a shell, but i dont' find my /dev/hda...
<case_> wow... i've just fixed one of the worst dependency mess i've ever seen... (ok ok, i'm not that experienced ;))
<shinmen> :)
#ubuntu-ports 2006-01-12
<case_> just to say that there were no kernel installed because of a dependancy conflict
<case_> but i'm not out of trouble, silo is still in bad shape...
<case_> damned! fixed! \0/
<case_> shinmen: here are the results of the pov bench:
<case_> $ time povray /usr/local/share/povray-3.6/scenes/advanced/benchmark.pov
<case_> real    44m28.475s
<case_> user    43m29.669s
<case_> sys     0m6.518s
<case_> $ time povray64 /usr/local/share/povray-3.6/scenes/advanced/benchmark.pov
<case_> real    40m1.559s
<case_> user    39m8.325s
<case_> sys     0m5.708s
#ubuntu-ports 2006-01-14
<shinmen> case_, 4 min out of 40. Well, that is a lot of time is you think of it in times of having a big fat cluster doing renders.
<case_> shinmen: yes, i think it's worth the cost :)
#ubuntu-ports 2007-01-12
* netjoined: irc.freenode.net -> brown.freenode.net
<fabbione> hey tmarble 
<tmarble> hi fabbione!
#ubuntu-ports 2009-01-06
<NCommander> Wow
<NCommander> cool, another channel for my AJOIN list!
<jbailey> NCommander, Fun.  What will you port to? =)
<NCommander> all of them!
<NCommander> bahahahah
<persia> All of them?
<NCommander> Every architecture shall have an Ubuntu port!
<persia> 685c02?
<jbailey> Who needs a PMMU? =)
<persia> What experimental ports are in progress?  I've heard whispers of m68k and mips, but nothing too complete for either.  Anything else?
<jbailey> None as far as I know.  I hadn't heard of m68k or mips.  Arm seems likely.
<persia> arm seems fairly complete: only a few hundred packages left to go.
<persia> http://qa.ubuntuwire.com/ftbfs/ says about 800.
<persia> m68k seems oft-rumoured, but I've not seen code.
<persia> mips has some skeletal code I've seen, but I think not enough of a team yet.
<persia> I know one guy in Osaka who wants a SH port, but I don't think he'll finish it.
<jbailey> The problem with arm/mips/m68k is that those targets probably don't want a full desktop.
<jbailey> Ubuntu isn't well suited to that at the moment.
<persia> Dunno about MIPS or m68k.
<persia> I'd run Ubuntu UMPC on my Zaurus if 1) the processor was one of the arm-supported kernels, and 2) I hadn't broken the battery leads a few months ago.
<persia> I think I read about a MIPS netbook as well.
<persia> Right: the Belco Alpha 400
#ubuntu-ports 2010-01-11
<TheMuso> lamont: I noticed that davis is back on dapper. what needs to happen for lucid so we can get the ppc boxes running a recent LTS?
<lamont> TheMuso: we need a stable kernel
<lamont> Apple Xserve vs >= hardy is not stable
<TheMuso> hrm ok
<lamont> TheMuso: when eglibc regressed on dapper kernels, we took a stab at the karmic kernel... it failed to be stable.
<TheMuso> lamont: How is it not stable?
<lamont> TheMuso: crashes in filesystem space (mostly OOPSes, iirc), throws random SIGSEGVs, etc.
<lamont> Not sure what it is about the Apple Xserves, but they haven't liked anything since hardy... not sure about edgy-gutsy, either
<lamont> since we ran dapper until hardy came out, then hardy one place for about a day or two, then punted.
<TheMuso> lamont: Hrm ok.
<lamont> and we have now confirmed that karmic is in the same boat
<TheMuso> Kinda sucks, because I have ppc64 hardware that runs karmic and doesn't miss a beat.
<lamont> I got a good 10-12 minutes into simultaneous builds of linux, gcc-4.4, and eglibc before it paniced
<TheMuso> ouch
<lamont> well, it oopsed shortly before that, then died several seconds later
<TheMuso> Hrm ok. We need to get something sorted soon if ppc is to survive the next year or so.
<TheMuso> i.e get the kernel sorted.
<lamont> ah, come on, it still has 17 months of support... :-p
<lamont> but yeah, a working Xserve kernel for lucid would be most lovely
