#ubuntu-toolchain 2005-07-04
<jbailey> lamont__: What are you rambling about?
<lamont__> jbailey: doing the hppa archive-event
<lamont__> hence rebootstrapping gcc-*
<jbailey> Has the fix for hppa-hpux gone into 4.0.1 now?
<lamont__> dunno
<lamont__> this is g{cc,++}-3.4
<jbailey> Yeah, but for the rest of the archive, it would probably make sense to wait for that.
<lamont__> that is, gcc-defaults points to 3.4 on hppa now. (1.24)
<jbailey> Err, just because of the function pointer bit?
<lamont__> yes
<jbailey> Or is this to get past the everything-sucks-on-4.0 stage?
<lamont__> just because pinters are completely b0rked
<lamont__> pointers, even
<lamont__> the everything-sucks thing is just a perk
<lamont__> the pointer bug in 4.0 renders every .deb suspect
<jbailey> In another day or two that bug will be fixed on 4.0
<jbailey> http://gcc.gnu.org/ml/gcc/2005-06/msg01192.html
<lamont__> well then I'd better hurry and get through the sucky stage.. :)
<jbailey> Yup. =)
<lamont__> or at least put the gcc-default binaries on hold. :-)
<jbailey> That would probably be better. =)
<lamont__> lol
<lamont__> binutils built.  now for glibc
<jbailey> lamont__: Have comendered(sp?) a nice 8-way PA system? =)
<lamont__> _2_ hours.  sigh
<lamont__> I have an A500 that I'll be commandeering tomorrow
<lamont__> (likewise, sp??)
<lamont__> 2-way, 8GB RAM
<jbailey> You seem to have it right.
<lamont__> sadly, the buildd's run UP kernels, since they work better...
<jbailey> I thought recent PA kernels were supposed to behave better.
* jbailey shuts down spare machines in prep for the rolling blackouts.
<lamont__> jbailey: they're much better, but.. :-(
<jbailey> Is there risk of memory corruption leading to wrong-code generation, or just hangs and crashes?
<lamont__> it tends to generate random segv's, from what I've seen
<lamont__> but only under semi-heavy memory-pressure
<lamont__> does -1ubuntu7 (glibc) have hppa tests disabled?
<jbailey> lamont__: Looks like, yes.
<jbailey> I haven't done an -1u8 yet since we asked me to reenable it.
<lamont__> kewl... will build faster. :-)
<lamont__> Total 2 package(s) in state Building.
<lamont__> Total 5 package(s) in state Installed.
<lamont__> Total 6091 package(s) in state Needs-Build.
<lamont__> :-(
<doko> lamont__, no need for doxygen if you build with -b -B
<lamont__> doko: ah, coolness.
<lamont__> but it builds fast. :-)
<lamont__> s/builds/built/
* jbailey wanders off for a little bit.
<lamont__> doko: with g++-3.4, nothing should need libstdc++5 any more, correct?
<doko> lamont__: correct
<lamont__> ok.  I'll just make it hard to upload anything that Depends: libstdc++5 :-)
<doko> well, the stuff that needs libstdc++5, doesn't build on hppa. like OOo1
<lamont__> hehe
<lamont__> and let us not forget gcc-3.3 :-)
<lamont__> basically, I'll just make the automated uploader bounce anything that mentions libstdc++5, and then manually figure out what it really means
<lamont__> some of that can get uploaded, the bulk just needs to be built in the right order
<doko> with the last batch of uploads I dropped the libstdc++5 rdepends from 880 to 530. at least on i386.
<lamont__> nice
<lamont__> this is more just me trying to make sure that I'm not accidentally building out-of-order.
<lamont__> glibc is in install target.  coolness
<lamont__> and then comes 24 hours to build all 3 versions of gcc :(
<lamont__> doko: what's the minimum set of gcc-* to build?  3.4 and 4.0?  (do I really need the current gcc-3.3, or can I let the one from hoary [3.3.5-8ubuntu2]  get used?)
<doko> lamont__: the one from hoary should be ok, although I don't plan any further gcc-3.3 uploads now. 3.3 is currently synced from Debian and I don't plan to update that one for a while. the next 3.3 uploads will just drop support for languages like java, treelang, objc, 
<lamont__> ok.
<lamont__> I'll let gcc-3.3 eventually catch up, then
<lamont__> X.o.r.g..................................
<doko> I'm innocent :-)
<lamont__> you build-depend on it.  That's enough. :-(
* lamont__ tries ignoring breezy's arch: all packages for the momenbt
<doko> lamont__, for a bootstrap, you can disable java and ignore all the X b-d's
<lamont__> pb is that I want to actually build the real source.
<lamont__> after all, I have hoary/main
* lamont__ cheers - gcc-3.4 is actually unpacking source to build... build-deps met
<lamont__> with luck, it'll even build
<lamont__> doko: would be nice if you hollered before uploading gcc-* this week - I'd like to let these builds finish and upload before I have to start new ones.
<fabbione> morning
<lamont> Total 6 package(s) in state Installed.
<lamont> Total 6091 package(s) in state Needs-Build.
<lamont> fabbione: I think sparc is ahead. :-(
<fabbione> lamont: doh!
<fabbione> i guess you are restarting with gcc-3.4?
<lamont> yeah
<fabbione> well actually sparc has a bigger problem
<lamont> saddest part of it is that 33% of that 6 packages Depend: libstdc++5
<fabbione> breezy libc6 is triggering a bug in gcc
<fabbione> and the kernel miscompile
<lamont> (dpkg and doxygen) - I'll need to rebuild them eventually, but there's a new dpkg in debian (albeit FTBFS)
<lamont> ew.  poor sparc
<fabbione> so sparc has 3/4 of the archive.. but no kernel :)
<lamont> hppa has almost .1% of the archive. :-)
<fabbione> how are you going to cope with the g++ transition?
<lamont> g++-3.4 is libstdc++6
<fabbione> will you do it later? or are you swutching only gcc- ?
<lamont> so I get the transition
<fabbione> ah ok
<lamont> the later switch from 3.4 to 4.0 is not an abi event
* lamont is most happy that 3.4 exists
<fabbione> yeah that's right
<lamont> but must get to bed
<fabbione> ehhe
<lamont> with luck, I'll have 3.4 and 4.0 by morning, and can semi-unleash the beast.
<fabbione> it sounds like i am the "GO TO BED" alarm clock in here ;)
<lamont> yeah - that's the one... :-)
<fabbione> ahah
<fabbione> good night lamont
<lamont> the other thing I'd like to get is a list of all the packages that I need to build before I can build xorg, so that I can queue those up
<fabbione> i think it will just go DepWait now
<fabbione> so it shouldn't be too difficult
<fabbione> but take into account daniels is going to upload/if he didn't already
<fabbione> some extra crack soon
<fabbione> (i can't check.. my server crashed and secondary MX flushing)
<lamont> fabbione: no, the issue is that things Conflict with older packages from xorg, so it's an ugly failure, not a pretty auto-depwaited thing
<fabbione> oh
<fabbione> crap
<lamont> fabbione: but I got the list from daniels, so life is better.
<fabbione> ehhe
<elmo>  * glibc_2.3.5-1ubuntu7 builds:
<elmo> [...] 
<elmo>       but no longer builds:
<elmo>         o 2.3.5-1ubuntu4: libc6-sparcv9
<elmo> fabbione: deliberate?
<fabbione> elmo: yeps
<fabbione> we are killing sparc32 support
<fabbione> sparc32 is going the same way as m68k
<fabbione> doorstep use basically
<fabbione> elmo: did you have any time to setup logs@ ?
<elmo> meh, no, let me try and do that now
<fabbione> elmo: ok :)
<doko_> lamont-away: gcc-3.4_3.4.4-3ubuntu1 will FTBFS on hppa.
<jbailey> Oy, Fabio. =)
<fabbione> hey jbailey 
<jbailey> Do I owe you anything still, or should I dive back into my task list.
<jbailey> ?
<fabbione> jbailey: a fix for glibc so i can compile the kernel? ;)
<fabbione> i was told that also gentoo is hitting the same problem as we do
<Mithrandir> jbailey: did you get your fix tested yesterday?
<fabbione> nah go ahead with your list :)
<fabbione> there is nothing in my list for you today :P
<jbailey> Mithrandir: I didn't - there was some cool things in parliament yesterday and so I spent my evening glued to news sites rather than working.
<jbailey> (And a chunk of the day...)
<fabbione> anyway i am off for the next hour/today
<fabbione> i had enough 
<fabbione> catch you later guys
<jbailey> g'n Fabio.
<Mithrandir> this vax is sloooooooooow
<Mithrandir> jbailey: ok, tell me if you want me to power up my box.
<jbailey> Mithrandir: In about 30 minutes okay?
<jbailey> +Is
<Mithrandir> jbailey: sure, I just have to extend my hand to press the power button. :-)
<Mithrandir> it's booting now
<jbailey> Thanks.
<doko> jbailey: did you have a chance for the ecj-bootstrap upload?
<jbailey> doko: No, wasabi's box crashed before I fetched it, and he said that he had an ecj.1 for me in his other package.
<jbailey> Also, the ant he had posted was corrupted.
<jbailey> java-common was fine, though, so I did upload that.
<jbailey> I pinged him in #ubuntu-java a few minutes ago, I'm hoping to get this all done while he's still at home and has access to the box.
<doko> ok, fine
<lamont-away> ../../src/gcc/cppdefault.c:75: error: `LOCAL_INCLUDE_DIR' undeclared here (not in a function)
<lamont-away> WTH?
<lamont>  -DLOCAL_INCLUDE_DIR=\"/usr/local/include\"
* lamont scratches his head
<jbailey> lamont: Run it through with gcc -E -dD into a file, and I can take a look for you.
<lamont> gcc/hppa64-linux-gnu/3.4.5/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/] *|/..|g'`/include/c++/3.4.5\" -DGPLUSPLUS_TOOL_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/] *|/..|g'`/include/c++/3.4.5/hppa64-linux-gnu\" -DGPLUSPLUS_BACKWARD_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../..`echo /usr | sed -e 's|^/usr||' -e 's|/[^/] *|/..|g'`/include/c++/3.4.5/backward\" -DLOC
<lamont> AL_INCLUDE_DIR=\"/usr/local/include\" -DCROSS_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../../hppa64-linux-gnu/sys-include\" -DTOOL_INCLUDE_DIR=\"/usr/lib/gcc/hppa64-linux-gnu/3.4.5/../../../../hppa64-linux-gnu/include\" -DTARGET_MACHINE=\"hppa64-linux-gnu\"  \
<lamont>   -c ../../src/gcc/cppdefault.c -o cppdefault.o
<lamont> ../../src/gcc/cppdefault.c:75: error: `LOCAL_INCLUDE_DIR' undeclared here (not in a function)
<lamont> build directory is purged - I'll rebuild it once gcc-4.0 finishes dying
<jbailey> If you have to rebuild anyway, can you do it on j5k?
<jbailey> That way I can poke into your build env.
<lamont> yeah - but then I have to create said build environment
<lamont> or do you already have a hoary chroot there?
<jbailey> I had a breezy one I think.
<jbailey> I suspect for this build, though, it wouldn't make that big of a different.  Dunno for sure.
<lamont> given that we tossed the entire breezy hppa world.....
<lamont> may just be easier to create access for you on this machine...  wanna email me an ssh key?
<fabbione> hey lamont 
<lamont> morning fabbione 
<lamont> ah, libcairo.  sigh
<doko> <doko> lamont-away: gcc-3.4_3.4.4-3ubuntu1 will FTBFS on hppa.
<doko> lamont: ^^^
<lamont> doko: GAH!
<lamont> I need a buildable gcc-3.4....
<elmo> doko: dude, I think you need to add some conflicts to gcc
<elmo> almost all my buildds got fucked by partial upgrades of gcc and not g++
<doko> lamont: chinstrap:~doko/multiarch-include.dpatch
<doko> elmo: how does it fail?
<elmo> doko: c++ compiler can not create excutable, or massive include file fuckage
<elmo> see e.g. the apt build log for ssparc
<doko> where can I get the log?
<doko> ahh, Debian?
<elmo> yes, sorry, wildly and abusively OT
<doko> hmm, buildd only has a log of a sucessful build
<elmo> blink?
<doko> 0.6.38 (sparc) (latest build at Jun 29 05:45: maybe-successful)
<elmo> http://buildd.debian.org/build.php?&pkg=apt&ver=0.6.38&arch=sparc&file=log
<elmo> follow the link of version num
<elmo> http://buildd.debian.org/fetch.php?&pkg=apt&ver=0.6.38&arch=sparc&stamp=1119821334&file=log&as=raw
<doko> ahh, yes, that's the changed internal gcc_lib_dir (/usr/lib/gcc-lib/...)
<doko> so, basically, I would have to add conflicts in cpp-3.3 to all previous versions of gcc-3.3, gobjc-3.3, g77-3.3, g++-3.3, gnat-3.3, treelang-3,3, gpc-3.3
<doko> interesting.
<elmo> or Breaks: if we had that
<doko> hmm, I did promise lamont not to upload gcc-3.3 again ;-)
<elmo> oh, don't do it again in a hurry, or I suspect ryan will fly over to kick your ass
<elmo> but I think we should fix it at some point
<elmo> most buildds are or will be fixed anyway
<lamont> doko: feel free to upload 3.3
<elmo> feel free not to
<elmo> :P
<lamont> hehe
<lamont> doko: if the 3.4 build works for me on hppa, should I upload the source?
<doko> lamont: no, elmo surely wants the dont-break-the-stupid-buildd patch there as well ;)
<lamont> yeah
<lamont> doko: I just need to drop that into debian/patches?  or add it's name to something as well
<lamont> ?
<doko> just drop it in, it's a corrected patch.
<lamont> replaces the one there... got it.
<lamont> doko: so there will be a -3ubuntu2 or such sometime soonish?
<doko> lamont: yes
* lamont grumbles at doko for uploading ardour -1build1 when -1 was FTBFS everywhere
<doko> lamont: tell me, where I can get this information (besides scanning the build logs) ...
<lamont> archive.ubuntu.com/ubuntu/pool/universe/a/ardour/
<lamont> :-)
<lamont> OTOH, -1build1 is far better than -1ubuntu1 :-)
<doko> lamont: when do you want a gcc-3.4 -3ubuntu2 upload? 
<lamont> anytime is fine
<lamont> I
<lamont> I'll let -3ubuntu1hppa1 finish building, and use that locally to let things run.
<doko> ok, finishing a test build here.
<lamont> given hppa's gcc-defaults.... do I need to build gcc-4.0 before I open the floodgates?  (No hppa debs from gcc-4.0 in my archive)
<lamont> hrm... actually, gcc-4.0 uses gcc-3.4 to build, correct?
<doko> no, do you have an libgcc2 and libstdc++6?
<lamont> no libgcc2
<doko> you need that one. it's built from the gcc-4.0 sources ...
<lamont> libstdc++6_4.0.0-8ubuntu3_hppa.deb
<lamont> that work for you?
<doko> yes, I think so.
<lamont> I'll run with that then
#ubuntu-toolchain 2005-07-05
<fabbione> morning
<lamont-away> doko: Moved gcc-3.4_3.4.4-3ubuntu1hppa1 to upload-breezy
<lamont-away> that's with your PATH hack, and the good patch
<lamont> Unresolved Dependency: cpp Depends: cpp-3.4 (>= 4.0.0-7) (breezy/main/hppa)
* lamont grumbles at doko
<lamont>  Package: gpc
<lamont>  Depends: cpp (>= 4:4.0.0-2), gpc-2.1-3.4, gcc-4.0 (>= 3.4.3)
<lamont> hrmpf
* lamont decides to ignore that one.
* lamont uploads gcc-defaults_1.25
* lamont works on iterating over xorg until it builds
<jbailey> g'm all
<Riddell> doko or anyone: could you review this http://dev.kubuntu.org.uk/~jr/kubuntu/wv2.diff
<doko> Riddell: the files in debian/ are not renamed, the name in the shlibs file needs to be changed
<Riddell> doko: fixed patch up
<doko> Riddell: no, the package name in the shlibs file is wrong
<Riddell> oops, sorry
<Riddell> doko: ok, third try now
<doko> looks ok, although there is a Makefile in the diff now.
<fabbione> elmo: any luck with logs@ ?
<elmo> working on it, just talked to lamont
<fabbione> oh ok :)
<fabbione> i am off for a shower :)
<fabbione> and dinner...
<fabbione> i will ping you tomorrow again :P
<lamont> fabbione: with luck, it'll be happy by then.. :0)
<desrt> 'sup guys.  is ppc biarch toolchain in breezy yet?
<elmo> yes
<jbailey> desrt: Yes, awhile ago.
<desrt> rocking
<desrt> any word on the kernel?
<jbailey> Any particular kernel?
<desrt> ppc64
<jbailey> Also done awhile ago.
<desrt> my life is complete.
<jbailey> Will you die now?  If yes, I'm sure I could break part of it to keep you around.
<jbailey> I'd hate to have someone dying on my concience.
<desrt> :)
<desrt> this is enough to keep me around for a while
<jbailey> Oh good.
<desrt> if anything you've saved me from committing suicide faced with the prospect of another manual kernel cross-compile
<desrt> jbailey++
* desrt headscratch
<desrt> so i have this nice kernel running and linux-headers-2.6.12-3-powerpc64-smp installed
<desrt> but whenever i go to build something it uses gcc-3.4 and seems to be trying to build a 64bit kernel in 32bit mode
<desrt> (ie: building a module out-of-tree)
<jbailey> Make sure you add -m64 to the command line.
<desrt> nod.  it definitely builds 64bit code... just the linux-headers-2.6.12-3-powerpc64-smp package seems to be misconfigured
<jbailey> Best to try #ubuntu-kernel
<desrt> thanks.
<fabbione> desrt: that can be possible..
<fabbione> that the header package isn't correct...
<fabbione> i hounestly forgot to check it
<desrt> fabbione; eek.
<desrt> fabbione; lemme try installing the full source
<fabbione> desrt: if you can kindly mail me the details of what you are trying to do, it would be very nice
<fabbione> i don't have a ppc64 at home to play with
<jbailey> fabbione: Got a sec for chatting?
<fabbione> and doing tests is quite of a problem for me
<fabbione> jbailey: sure
<fabbione> for you always
<desrt> fabbione; fabbione@ubuntu.com?
<jbailey> fabbione: After I move, I can give you access to mine easily.
<fabbione> desrt: yes that would be perfect
<desrt> fabbione; i can also give you access here if you like
<fabbione> jbailey: nice :)
<fabbione> desrt: see the problem is that to install/uninstall stuff i need basically root access :)
<desrt> fabbione; that's fine
<desrt> fabbione; it's a fresh box that i installed yesterday and just moved hoary->breezy.  i don't care about it very much :)
<fabbione> desrt: well i don't like to use "users" machines, but if you want you can send me an account info with the mail
<fabbione> and i can look at what you are doing
<fabbione> so i can see what's wrong with the headers
<desrt> ok.  first i'll see if i can get it working with the full sources
<fabbione> sure
<desrt> oh wait.  there exist no fully-preconfigured source packages that correspond to the built kernel images, do there?
<desrt> fabbione; do you have an ssh key somewhere?
<fabbione> desrt: there is the source.. you can grab the config from /boot
<fabbione> desrt: sure i can send it to you
<desrt> fabbione; it looks like there are some Makefile modifications here...
<fabbione> desrt: uh?
<desrt> like $(CROSSCOMPILE)gcc changed to gcc-3.4
<fabbione> desrt: yes. that's correct... we force gcc-3.4
<fabbione> because it's the minimum that can compile ppc64
<desrt> right.. but will just copying in the .config change that?
<fabbione> nope
<desrt> k.  i'll just diff the Makefiles to see if there's anything else
<desrt> fabbione; please send your key
<fabbione> desrt: i need your email address at least?
<desrt> desrt@desrt.ca
<zul> whats with all these canadians
<desrt> :)
<fabbione> eheh
<desrt> that's one heck of a long key :)
<fabbione> dont' confuse the gpg key with the ssh one
<fabbione> one it's only the signature
<fabbione> so you can verify the mail is coming from me
<desrt> ok.  try to ssh to copacetic.mcmaster.ca
<fabbione> The authenticity of host 'copacetic.mcmaster.ca (130.113.70.8)' can't be established.
<fabbione> RSA key fingerprint is fe:7c:e5:9a:8b:aa:17:39:5e:6a:08:64:32:53:f2:19.
<desrt> uh.  i guess that's right :)
<fabbione> yeah i am in
<desrt> ok.  the ppc64 box is called gorecki
<fabbione> but you are running 2.6.10 there...
<fabbione> ah i need another op?
<desrt> ya.  gorecki is behind the firewall
<fabbione> Failed to add the host to the list of known hosts (/home/fabbione/.ssh/known_hosts).
<desrt> your password on gorecki is 'secret'
<desrt> oh.  sorry.
<fabbione> amen ok :)
<fabbione> you left .ssh as root
<desrt> yes.  fixed now.,
<desrt> you should be able to sudo on gorecki
<fabbione> root@gorecki:~ # 
<desrt> excellent :)
<fabbione> i would say it works...
<fabbione> desrt: can you send me now the info of what needs to be done via email?
<fabbione> it's like 10pm here
<desrt> ok
<fabbione> and i plan to crash in not too long from now :)
<desrt> btw: it works much better when i use the source
<desrt> so it must be a problem with the headers package
<fabbione> desrt: it is possible.. yes.. as i said before :)
<desrt> will email info.
<desrt> thanks :)
<fabbione> desrt: thanks for the cooperation
<desrt> no problem.
#ubuntu-toolchain 2005-07-06
<lamont> jbailey: you around?
<lamont> doko: ping
<lamont>   gij: Depends: gij-3.4 (>= 3.4.3) but it is not installable
<lamont>   libgcj4-dev: Depends: gcj-3.3 (>= 1:3.3.5-8ubuntu2) but it is not going to be installed
<lamont>                Depends: libgcj4-common (>= 1:3.3.5-8ubuntu2) but it is not going to be installed
<lamont> do we expect that from hppa?
<doko> lamont: looks ok, don't know what is wrong. sorry, I'm too tired. I'm currently uploading a 4.0 with PR22051 fixed.
<lamont> doko: ok.
<lamont> doko: gij-3.4 does not exist, for starters...
<lamont> doko: hold off on changing the defaults for hppa back to 4.0 for a little bit - if it's OK with you, I'll plan on uploading a new gcc-defaults once I've done some testing.
<doko> lamont: hppa is your call ..
<lamont> doko: thanks
<lamont> unicode.c:19:26: linux/string.h: No such file or directory
<lamont> \
* lamont grumbles at jbailey
<jbailey> lamont: The whole header is wrapped with an #ifdef __KERNEL__ and doesn't have any definitions in it...
<jbailey> The leading comment is: /* We don't want strings.h stuff being user by user stuff by accident */
<lamont> jbailey: hfsplus, fwiw
<lamont> and then there's: /usr/include/linux/socket.h:10: error: redefinition of `struct sockaddr'
<lamont> /usr/include/linux/socket.h:17: error: redefinition of `struct linger'
<jbailey> Is this on hppa?
<jbailey> hfsplus includes socket stuff?
<jbailey> Sounds like the program is a mess.
<jbailey> Can you email it to me?  I'll fix it on Tuesday / Wednesday.
* doko grumbles at lamont not syncing packages (i.e. dhcp3)
<lamont> jbailey: that was iproute
<lamont> jbailey: I'll send you some mail, yes.
<jbailey> lamont: Cool.  I can chew through them pretty quickly and try to get the patches in upstream.
<lamont> fabbione: _2_ buildd's now chunking along on hppoa
<fabbione> morning
<desrt> fabbione; word.
<fabbione> hey desrt 
<desrt> found a couple of other issues with the actual kernel
<desrt> basically, some options are off that should be on
<fabbione> can you be more specific?
<desrt> mouse button emulation and openfirmware tree under /proc
<fabbione> i think they are built as module
<fabbione> but if you can tell me the CONFIG_ option it's easy to check
<desrt> looking.
<desrt> ok.  the mouse button emulation is definitely missing, but for a good reason
<desrt> it depends on ADB support which is (quite reasonably) disabled
<fabbione> ok
<desrt> it gives an error on startup.. no big deal
<fabbione> error or warning?
<desrt> warning
<desrt> missing sysctl variables
<fabbione> ok
<desrt> the other one is a bit more serious since it prevents yaboot from working
<fabbione> mostlikely possible.. not everything has been ported to 64bit yet
<fabbione> hmmm.. i understood there was no reason to use yaboot..
<desrt> this definitely works on ppc64.  i've done it before
<fabbione> can you still tell me option so i can check with others?
<desrt> k. gotta find it :)
<fabbione> thanks :)
* fabbione blames GTK for not shipping a ppc64 in this direction
<desrt> what am i supposed to use instead of yaboot?
<fabbione> desrt: no idea... 
<fabbione> i don't own a ppc
<desrt> :)
<fabbione> i ask around usually what is the best thing to do
<desrt> fair enough :)
* desrt raises an eyebrow
* lamont --> bed
<desrt> fabbione; ok.  the device tree is enabled, but broken
<fabbione> broken how?
<desrt> root@gorecki:/proc/device-tree# ofpath /dev/sda2
<desrt> ofpath: /proc/device-tree is broken.  Do not use BootX to boot, use yaboot.
<desrt> ofpath: The yaboot HOWTO can be found here: http://www.alaska.net/~erbenson/doc
<desrt> (having booted using yaboot)
<desrt> i'm gonna google a bit
<fabbione> ok..
<fabbione> are you sure it's not just a warning?
<desrt> quite sure
<fabbione> if you booted with yaboot, it somehow means that the device-tree is there
<desrt> it needs to know the openfirmware device path of the harddrive
<desrt> (in order to load the kernel image from it)
<fabbione> so how did you booted before?
<desrt> after i installed the ppc64 image i ran yaboot from inside the 32bit kernel
<desrt> (which works fine)
<fabbione> hold on a sec..
<fabbione> hmm ben is not around...
<fabbione> i will ask him when he shows up
<desrt> ok.  i'm still looking into it
<fabbione> desrt: you could try to look at device-tree with a 32bit kernel and compare the diff with a 64?
<desrt> fabbione; doing that now
<fabbione> perhaps it is easy to spot
<desrt> ofboot works by grepping the output of ls -l | ^lr (ie: looking for readable symlinks)
<desrt> the ppc32 kernel is full of symlinks... none in the 64bit one
<fabbione> hmmm interesting
<fabbione> ok i will ask him
<fabbione> doko: ping?
<desrt> fabbione; ok, basically the check performed by ofpath is stupid
<desrt> fabbione; if i disable the check (or change it to check for the presence of directories instead of links) then yaboot is fine
<fabbione> desrt: can you test the same change on 32bit kernels?
<desrt> hm.  ok
<fabbione> if that change works, i see no problem in pushing it in the archive
<fabbione> if it was checking for symlinks there might be a reason that we don't know
<desrt> works fine
<desrt> well, in the event that it doesn't find symlinks it aborts
<desrt> anyway.. the fix is positively trivial
<desrt> line 674 of /usr/sbin/ofpath
<fabbione> ofpath is part of yaboot?
<desrt> change ^lr to ^d
<desrt> yes
<fabbione> (on i386 is a bit less trivial to check ppc packages ;))
<desrt> also change at line 432
<fabbione> that checks look completely dumb
<desrt> it just checks if there's any files that have ls -l output starting with lr (ie: symlinks...)
<desrt> yet it works perfectly fine without the presence of these symlinks
<desrt> i guess it just assumes that if the device tree is present it will always have symlinks in it
<desrt> (oops)
<fabbione> ok i will ask Kamion to double check.. he is the ppc guy
<desrt> rockin'
<fabbione> given that i can't test it locally
<fabbione> no problem :) thanks a lot for the debugging :)
<desrt> thanks for your swift reply :)
<fabbione> :)
<desrt> http://kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.12
<desrt> commit 5f64f73957f6cae3222f97f2599199ee562f7f3f
<desrt> Author: Benjamin Herrenschmidt <benh@kernel.crashing.org>
<desrt> ^^ see this
<fabbione> oh benh :)
<fabbione> the same ben i was going to ask ;)
<desrt> ya.  i know :)
<desrt> benh did some particularly heroic stuff in the kernel right around the time i got my ibook :)
<fabbione> yeah he still does :)
<fabbione> and he hangs here on freenode
<fabbione> if he did that.. i am confident in doing the change :)
<desrt> so it's really a 2.6.10 vs 2.6.12 issue, i guess... not ppc32 vs ppc64
<fabbione> yeps
<desrt> probably means a new version of yaboot will be released soon anyway
<fabbione> probably.. in the meantime let's fix it :)
<desrt> sounds good to me
<fabbione> yaboot (1.3.13-3ubuntu3) breezy; urgency=low
<fabbione>   * ofpath: fix checks of /proc/device-tree:
<fabbione>     According to commit 5f64f73957f6cae3222f97f2599199ee562f7f3f
<fabbione>     in 2.6.12:
<fabbione> 
<fabbione>     [PATCH]  ppc32/ppc64: cleanup /proc/device-tree
<fabbione>     [....] 
<fabbione>     - Do not create symlinks for the short name and unit address parts of a
<fabbione>       node.  These were never really used, bloated the memory footprint of
<fabbione>       the device-tree with useless struct proc_dir_entry and their matching
<fabbione>       dentry and inode cache bloat.
<fabbione>    ofpath always assumed the presence of symlinks to verify a valide
<fabbione>    /proc/device-tree. Change them to verify presence of directories instead.
<fabbione>    Patch and tests kindly done by Ryan Lortie.
<fabbione>  -- Fabio M. Di Nitto <fabbione@ubuntu.com>  Fri, 01 Jul 2005 07:46:39 +0200
<desrt> rocking.  when will that be on the archives?
<fabbione> in about one hour if it build properly...
<desrt> the infra you guys have going is seriously cool :)
<fabbione> let me see if i can test build it first
<fabbione> yaboot didn't get an upload in ages
<desrt> so how did you swing a powermac (promise) from gtk?
<fabbione> nah i was just kidding :)
<desrt> oh :)
<fabbione> everything that doesn't work is GTK's fault ;)
<desrt> hah.
<desrt> ok.  i thought that was sort of weird :)
<desrt> we bought about 20 dual G5s at work half a year ago
<desrt> the work all you guys are doing on the toolchain and kernel to get ppc64 supported is vastly appreciated
<fabbione> :)
<fabbione> hmm it doesn't build with gcc-4.0
<desrt> precious little does :P
<fabbione> meh sorry i was talking about yaboot
<desrt> that's what i understood
<desrt> oh wow.  this code is special :)
<desrt> it looks like the guy implemented KMP strstr() using intentionally-obfuse code
<desrt> anyway.. it's just one problem and it's pretty easy to fix in a disgusting way :)
<desrt> line 79 of lib/strstr.c should read "shloop: 0;  }" :)
<fabbione> oh yeah
<fabbione> uploaded now....
<desrt> hopefully this one works out a bit better
<fabbione> it will hit the archive in approx 1 hour
<fabbione> i hope it won't break compiled with gcc-4.0 :)
<desrt> i did a build here with the 2 patches and dpkg -i'd the .deb
<desrt> seems to be working
<fabbione> did you boot with it?
<desrt> nope :)
<desrt> it's the long weekend.  dare me to? :)
<fabbione> up to you :)
<desrt> actually.  i have a G5 beside me
<desrt> i'll try on it
<fabbione> rocking
<desrt> uh.  i patented "rocking"
<desrt> pay up or cease and desist
<fabbione> ehehe
<fabbione> ok back to userland now...
<fabbione> gotta fix some stuff today
<fabbione> desrt: enjoy the long we btw :)
<desrt> surely will :)
<fabbione> i will come back to you for the headers stuff soon...
<fabbione> today is userland work :)
<desrt> :)
<desrt> ya.. this channel is called -toolchain, after all
<desrt> <just testing yaboot now... had to upgrade to breezy>
<desrt> works in 32bit mode
<desrt> and 64.  doesn't look like gcc4 hurt it too badly
<desrt> i'm off to sleep now.  have a good day :)
<fabbione> good night :)
<doko> fabbione: pong
<fabbione> doko: mind if i upload OO2??
<fabbione> missing at least one B-D on libxkbfile-dev
<doko> hmm, I'll add it, have a new milestone here finally. 
<fabbione> doko: ok.. i am completing a test build on i386
<fabbione> (saw the failure on sparc)
<fabbione> and i will let you know if more is required
#ubuntu-toolchain 2005-07-07
<lamont> Total 351 package(s) in state Installed.
<lamont> Total 5443 package(s) in state Needs-Build.
<lamont> Total 67 package(s) in state Uploaded.
<lamont> getting there
<fabbione> :)
<fabbione> there is something wrong with gnome-alsamixer..
<fabbione> sparc and ia64 keeps giving it back
<fabbione> it's really weird
<fabbione> because it has been built before
<fabbione> lamont: regarding the NEW.. i think it was also due to the ABI change...
<fabbione> doko: i confirm that adding that b-d makes it go at least on i386
<doko> fabbione: ok
<doko> lamont: gcc-4.0 4.0.0-12 has PR22051 fixed.
<lamont> unknown/gnome-alsamixer_0.9.6-1: Needs-Build [-:uncompiled] 
<lamont> fabbione: ^^^
<lamont> unknown is main, but it's not really there...
<lamont> iz override edit for elmo
<fabbione> <lamont> iz override edit for elmo
<fabbione> <fabbione> lamont: look at your build-logs
<fabbione> <fabbione> it has been built and suddenly needs build again
<fabbione> <fabbione> + i get error fetching the sources... it's weird..
<fabbione> <fabbione> but it's saturday and building gcc-4.0 that won't finish before
<fabbione>            tomorrow anyway ;)
<fabbione> bah damn efnet
#ubuntu-toolchain 2005-07-09
<lamont> mframe.m: In function 'mframe_decode_return':
<lamont> mframe.m:1579: warning: pointer targets in passing argument 2 of 'NSGetSizeAndAlignment' differ in signedness
<lamont> mframe.m:1711: internal compiler error: in assign_stack_temp_for_type, at function.c:605
<lamont> woot
<lamont> gnustep-base ICE
<lamont> (ppc)
<lamont> interesting... ISTR ICE there before on either hppa or ia64, gcc-3.x
<fabbione> morning
<lamont> elmo: could you locate glibc_2.3.5-1ubuntu7_hppa and tell me what I did wrong that it's not in the archive??? (iz NEW, maybe???)_
<elmo> Rejected: libnss-dns-udeb_2.3.5-1ubuntu7_hppa.udeb: can not overwrite existing copy already in the archive.
<elmo> guess it was uploaded too soon - try again?
<lamont> ok.  re-uploading
<lamont> note that the .debs don't seem to have actually been removed from the archive (at least initially) - could that be the issue?
<lamont> Packages didn't list things that had .debs in the archive..
#ubuntu-toolchain 2005-07-10
<fabbione> morning
<doko> lamont: time to make 4.0 the default on hppa again?
<lamont__> doko: once gcc-4.0 is built and in the archive for hppa with the fix, go ahead and bump gcc-defaults.  it'll take a bit before I actually build/upload gcc-defaults with the change, but I'll coordinate that with the buildd chroots.
#ubuntu-toolchain 2006-07-03
<chmj> join #firefox 
#ubuntu-toolchain 2006-07-06
<doko> mdz: hppa NPTL: IMO doing nothing, but just naming the problem is some kind of implementation status as well. I did move it now to outstanding issues
<jbailey> doko: hmm?
<doko> jbailey: IIRC we did acknowledge the problem, and put it aside at the devmeeting
<jbailey> doko: I just saw nptl, and don't have context.
<jbailey> So I'm trying to figure out what you're talking about and how I can help. =)
<doko> jbailey: the toolchain-roadmap, see mdz's comment on the whiteboard. (although I already removed the inline comment)
<jbailey> Right, I see it.
<jbailey> FWIW, Carlos is going to commit his current NPTL stuff this week.
<jbailey> I had a chance to get some face time with him last weekend.
<jbailey> And I now have parisc gear.
<jbailey> So I can't see the end of the tunnel, but I'm definetly in it now. =)
<jbailey> Keybuk: You willing to do a couple reviews?
<Keybuk> sure
<jbailey> I wound up editting a bunch of the toolchain specs, so I'm not comfortable saying I reviewed them too. =P
<jbailey> Keybuk: https://launchpad.net/distros/ubuntu/+spec/edgyplusone-toolchain-roadmap
<jbailey> Keybuk: https://launchpad.net/distros/ubuntu/+spec/java-roadmap
<doko> Keybuk: https://launchpad.net/distros/ubuntu/+spec/native-java-gcj
<jbailey> I need to grab food, I'll check in a bit later on the status.
* jbailey heads home.
<jbailey> (text message if there's something urgent you need answered)
<Keybuk> I might get you to voip phone me when you're home ... need to check whether this headset is useful or not
#ubuntu-toolchain 2006-07-07
<ogra> does anyone know if there is a fix in the works for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367856 ?
<ogra> (i cant merge electricsheep)
<fabbione> i can reproduce that one with our gcc on x86
<fabbione> try to do this:
<fabbione> add to the LDFLAGS an explicit path to the filename that contains the symbol
<fabbione> (just for debugging)
<ogra> will try
<fabbione> powerpc-linux-gnu-gcc  -Wall -g -O2   -o mpeg2dec_onroot  mpeg2dec_onroot.o getopt.o ../libmpeg2/libmpeg2.a ../libvo/libvo.a   -lSM -lICE  -lX11  -lXext -lXv libcpuaccel.a -lpng /usr/lib/libfoo.a
<fabbione> for example
<fabbione> but you need to know where the symbol is
<fabbione> if that fix works it's something common to the gcc we have
<fabbione> it looks like that -lfoo doesn't really work properly on all -L paths
<fabbione> but i am not 100% sure
<fabbione> try to change also the optimization stuff and see if that change
<fabbione> like -O2 -> //
<fabbione> or -O0
<ogra> since i have no clue where the symbol is, i'll start with -OO
<ogra> err -O0
<ogra> -O0 works fine :)
<Sean-Michael> Man, there anyway to scroll rss and or live bookmarks across youre desktop?
#ubuntu-toolchain 2007-07-07
* Starting logfile irclogs/ubuntu-toolchain.log
<jbailey> doko: Around?
<doko> jbailey: yes
<jbailey> doko: Mind work-related chatter, or would you rather relax?
<doko> just found the cause for the binutils test failures, see my posting to the binutils ML
<jbailey> nice!  I'll look in the archives, I'm not subscribed.
<doko> the dynamic linker name was substitured by ^A (expanded from \1 on amd64 by dash) :-(
<doko> so what's up?
<jbailey> Hah, nice.  Glad I was useful on that. =)
<jbailey> I'm just building gij on hppa to see what's causing it to puke.  sablevm works, so I know that it's not classpath.
<jbailey> And part of me was wondering about the transition to openjdk for arches where it's available.
<doko> jbailey: you need gcj to build it, and a port to parisc. bdale told me at debconf that it's unlikely to get the parisc/hpux specific bits from HP
<jbailey> from what I read in tromey's blog, it looks like porting the non-hotspot jvm is not that hard.
<jbailey> But I had more been thinking that more and more arches are going to get openjdk bits, and I suspect that it should become the default where possible.
<jbailey> At that point, I'm not sure there's any point in building the -gcj bits (except where we just inherit that love from Debian)
<jbailey> The gij-default decision was from when we thought Sun was joking about a free license. =)
<doko> sure, whatever we can get faster, would be better.
<jbailey> doko: Hey, is there a trick to make it so that I just build gij with the system compile and not bother building gcc first?
<doko> jbailey: you need to build gcc/java/jc1 first, maybe configure with --disable-bootstrap to avoid building the bootstrap compiler? didn't try this with 4.2 ...
<jbailey> Cool, thanks.
<jbailey> I was just hoping to make ccache useful.
<jbailey> =)
<doko> jbailey: do you have the gutsy hppa repository somewhere online?
#ubuntu-toolchain 2010-07-05
<jbailey> jussi, pong
<jussi> jbailey: is this channel still in use?
<jbailey> Not noticeably.
<jbailey> Doko still logs into it.
<jbailey> I don't follow Ubuntu development enough these days to know if anyone other than he is doing toolchain stuff.
<jbailey> I vaguely doubt it.  Hiring a toolchain person would've been news.
<jbailey> In practice, between me, lamont, and doko on this channel most questions could probably be answered, though.
<jussi> jbailey: yeah, you were the only one on the access list though. I had staff add the ubuntuirccouncil account. 
<jussi> perhaps if we forward the channel to #ubuntu-devel and we can unforward it if it becomes necessary?
<jbailey> jussi, What problem are you trying to solve?
<jussi> jbailey: we have a logged channel without a topic, without an access list. 
<jbailey> I'm slightly miffed that you didn't bother just emailing me to say "Hey, please add ubuntuirccouncil"
<jbailey> I don't care about the result so much as that you didn't bother chatting first.
<jbailey> jussi, Why is that a problem?
<jussi> jbailey: we a creating channels page which explains how channels in the ubuntu namespace should be set up. also, we have been asked by canonical to add an entrymsg to all logged channels (for legal reasons). 
<jussi> jbailey: I apologise for not waiting longer after pinging you before contacting staff. 
<jbailey> jussi, All good.  Just something to keep in mind when dealing with people. =)
<jbailey> So, in the end this channel could either exist or not.
<jbailey> If it's forwarded to #ubuntu-devel, I won't hang out on it.
<jussi> jbailey: Ive no problem with it existing, but if it does, it should have a topic
<jbailey> The channel was created because those of us who care about the toolchain don't need to chat often, but when we do, it's nice to not have to piece out the conversation from other threads.
<jbailey> We have certain policies here, like that it's OK to paste any amount.
<jbailey> So often logs and such would get pasted.
<jussi> jbailey: sure. if you could add those items to the topic so all know that, it would be great. 
* jbailey changed the topic of #ubuntu-toolchain to: Werd-up, yo.  Toolchain conversations happen here.  Paste away.
<jussi> Ive set an entry message as per what canonical have asked us to, you can see it by exiting and rejoining the channel. 
<jbailey> jussi, Fab.  Easy enough.
<jussi> jbailey: thanks a lot for your help. Once again, sorry for not waiting longer - we usually would converse with the owner first. 
<jbailey> lamont, Want to be an owner of this channel?
<lamont> sure, layon
<jussi> jbailey: may I also suggest setting chanserv guard on? that way the topic is not lost if everyone exits the channel. 
<lamont> I mean, that's 2 conversations in less than 6 months in this channel... :-D
<jussi> :D
<jbailey> jussi, Chanserv guards annoy me because ,m like now, I have to figure out where it's talking to me.
<jbailey> I don't think we ever all leave, though.
<jussi> right, just a suggestion :)
<jbailey> Between LaMont and Ubuntulog, we're pretty set.
<jussi> In anycase, ill leave you all to your silence. :) Have fun!
<jbailey> "Hello darkness, my old friend..."
<jussi> hehe
<jussi> laters
