#ubuntu-toolchain 2007-09-24
* Starting logfile irclogs/ubuntu-toolchain.log
<doko> lamont: could you take care about the expat/expat-tcl8.3 syncs?
<arthur-> doko: http://people.dunnewind.net/arthur/doko/gdc-4.1_0.24-4.1.2-16d1_multi.changes ;-)
<doko> arthur-: sorry, not that much time this week, I'll have a look later this week
<arthur-> doko: ok, never mind
<lamont> doko: well, actually, I need to fix the expat-tcl8.3 ftbfs... and the expect sync has been requested.
<lamont> seems tcl8.3 vs 8.4 was non-trivial for things that import lots of internal crap...
<lamont> do we need expect-tcl8.3 any more?
<doko> lamont: your call, it was once needed for hppa to get reliable test results
<lamont> yeah -it masked a bug that has been fixed
#ubuntu-toolchain 2007-09-27
<arthur-> p/w 19
<lamont> doko: I have a gcc patch for you...
<lamont> er, glibc
<lamont> well, I will once I port it..
<lamont> (I heard a rumor you have a glibc upload in the works...)
<doko> lamont: ok, please commit to the repo
* lamont will have to find the repio
<lamont> repo, even
<lamont> doko: please add entries similar to the following to debian/control:
<lamont> XS-Vcs-Browser: http://git.debian.org/?p=users/lamont/util-linux.git
<lamont> XS-Vcs-Git: git://git.debian.org/~lamont/util-linux.git
<lamont> and, uh, where is the repo?
<doko> sftp://bazaar.launchpad.net/~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package/
<lamont> bzr?
* lamont watches bzr slowly churn checking out the repo
<Mithrandir> bzr+ssh is a bit faster than sftp, fyi
<lamont> so bzr+ssh://....
<lamont> ?
<Mithrandir> yeah
<lamont> doko: my test build is running ( at least an hour before it gets to where -1ubuntu7 failed).  If you're impatient in the meantime, picking up chinstrap:/home/lamont/local-private-futex-lamont.diff won't hurt
<lamont> who knows, maybe my clone of the repo will finish by then :-)
<doko> lamont: not today anymore
<lamont> ah.  bzr clone finised
<lamont> finished
<lamont> doko: care if I upload -1ubuntu8 with just my change?
<lamont> one line patch to ports/sysdeps/hppa/nptl/tls.h, assuming there's nothing else
<lamont> doko: and are you including changelog as part of the commits?
<doko> lamont: yes, but no specific format
<lamont> I'm assuming that the checkout did the right thing, and that what I have is a debian directory
<lamont> given that...  There are a few diffs between the unpacked source I downloaded (-1ubuntu7) and the bzr tree...
<lamont> Only in glibc-debian/control.in: libc0.3
<lamont> Only in glibc-debian/control.in: libc6
<lamont> Only in glibc-debian/control.in: libc6.1
<lamont> Only in glibc-debian/: include
<lamont> Only in glibc-2.5-package/: locales.NEWS.Debian
<lamont> Only in glibc-2.5-package/patches: ia64
<lamont> Only in glibc-2.5-package/patches: s390
<doko> ignore the ones in control.in, the other ones should be empty directories
<lamont> the last 3 being empty stuff
<lamont> ignore as in "we don't care if my upload has them or not" or what?
<lamont> ah, and include is probably because I have a build going where I rsync'ed glibc-2.6.1/debian from
<doko> probably
<lamont> do you have gcc-4.{1,2} uploads planned this week?
<doko> lamont: yes
<lamont> ok
#ubuntu-toolchain 2008-09-22
<munckfish> Hi, I'm trying to create powerpc cross compiler out of intrepids gcc 4.3.2 sources and I've hit problem.
<munckfish> When it compiles the 64bit version of libgcc it's looking to link with libc6
<munckfish> but can't find it
<munckfish> the build seems to be configured to look for it under /usr/powerpc-linux-gnu/lib/
<munckfish> which is correct for the 32 bit libc
<munckfish> but the 64 bit lib is under /usr/powerpc-linux-gnu/lib64/
<munckfish> I'm hunting through the build scripts trying to understand how they work
<munckfish> but I'm really not sure where the "right" place would be add in the extra search directory 
<munckfish> can anyone help?
<munckfish> The build log is here: http://ubuntu.munckfish.net/files/gcc-4.3-4.3.2-2008-09-22-1034.log
<jbailey> A native port will use /lib for that.
<jbailey> So, if you're building a cross compiler, the toolchain will look in /lib
<jbailey> If you're building a biarch compiler, it will seek to lib64.
<munckfish> jbailey: I am building biarch. The thing is it's not looking in lib64 and I believe it should
<munckfish> I building to target powerpc which is biarch with powerpc64
<jbailey> Hmm.
<jbailey> Oh wait, what's the main system?
<jbailey> ppc
<jbailey> or something else?
#ubuntu-toolchain 2008-09-23
<doko> is this the so called ppu target?
<munckfish> doko: Hi. No not ppu
<munckfish> At the moment I'm just trying to build powerpc/powerpc64 cross compiler
<munckfish> so I can compile the powerpc64-smp kernel on x86
<doko> did you see debian/Readme.cross?
<munckfish> doko: Yes that's what I'm following
<munckfish> I've pulled across all the arch specific deps needed using apt-cross (although I had to fix some stuff to get that to work on Ubuntu)
<munckfish> I've managed to build binutils fine
<munckfish> I've got both the required 32 and 64 bit libs all installed under /usr/powerpc-linux-gnu/* by dpkg-cross
<munckfish> doko: if you've done this before and it worked for you just say and I'll head back to the drawing board
<munckfish> otherwise I need to find out why it's not including /usr/powerpc-linux-gnu/lib64/ on the linker search path too
<doko> no, never looked at this myself. closed thing was to build the cell-gcc packages. anyway, patches welcome ;)
<munckfish> doko: ok understood I'll plug away till I find the problem
<munckfish> thx
<jbailey> doko, If he's doing x86->ppc biarch, I think it's correct that it wouldn't do lib64.
<jbailey> The implementation of --with-sysroot still confuses me.  I keep wishing they had done it as if a partition were mounted into the filesystem.
<jbailey> So treat all symlinks as magical from that point, etc.
<jbailey> doko, Don't we have biarch packages for libx11 on amd64?  I thought we did.
<jbailey> Oh, I see.  ia32-libs-dev doesn't get built for us.  Hrm.
#ubuntu-toolchain 2009-09-23
<seb_kuzminsky> i'm trying to compile a subset of Hardy from source, then debootstrap the result
<seb_kuzminsky> it's working pretty well, but...
<seb_kuzminsky> i'm confused by Priorities
<seb_kuzminsky> in the official ubuntu repo, many binary packages have Priorities that differ from the Priorities of their source packages
<seb_kuzminsky> when i compile a source package (in a hardy pbuilder), the resulting .debs have Priorities that differ from the Priority of the official .debs
<seb_kuzminsky> for example, ubuntu-minimal.deb has "Priority: important" in the ubuntu.com repo
<seb_kuzminsky> but the control file in the matching ubuntu-meta source package has "Priority: optional", and so do the .debs i build from it
<seb_kuzminsky> so debootstrap doesnt pull it in by default :-(
<seb_kuzminsky> what am i doing wrong?
