#ubuntu-toolchain 2005-10-06
<jbailey> doko!
<jbailey> doko: Do you need anything else from me on that patch?
<doko> no, it's uploaded
<jbailey> Cool.
#ubuntu-toolchain 2006-10-06
<fabbione> doko_: ping?
<doko_> fabbione: pong
<fabbione> doko_: assuming i want to bootstrap a new architecture (supported by gcc), where can i change the default settings? like -mcpu -mtune and set -64 by default?
<doko_> sparc64-linux?
<fabbione> kinda
<fabbione> it's just for pure fun
<fabbione> but i don't want to spend a lifetime digging into each package
<doko_> there are configure parameters --with-tune and --with-arch (--with-cpu), but these don't work well with biarch
<doko_> it's in debian/rules2
<fabbione> nah i don't want bi-arch.. just pure64
<fabbione> ok thanks
<doko_> well, then configure for sparc64-linux, and use gcc -m64 as the stage1 compiler
<fabbione> ok thanks
<doko_> use of the --with-tune --with-arch should be unproblematic then. not sure where you find the correct system headers; maybe you need som part of the multiarch-include stuff
<fabbione> that's what i am looking at
<fabbione> because i am not sure how make is going to react if i add a sparc64 arch
<fabbione> given the amount of conversions and mappings between sparc/sparc64
<doko_> or just build a cross toolchain, thiemo did update a script, some mail sent to debian-gcc ...
<fabbione> doko_: that's an option too, but if i will do something, i might as well do it the debian way and get all the patches saved and ready for upload
<fabbione> Keybuk: how bad can dpkg break if i temporary disable selinux support?
<Keybuk> fabbione: not at all?
<fabbione> Keybuk: ok.. i am just trying to build dpkg at 64bit on sparc but there is no selinux64 yet
<fabbione> dpkg -p dselect |grep Depends
<fabbione> Depends: lib64gcc1 (>= 1:4.1.1-12), lib64ncurses5 (>= 5.4-5), lib64stdc++6 (>= 4.1.1-12), libc6-sparc64 (>= 2.4-1), dpkg (>= 1.13.1)
<fabbione> scary :)
<fabbione> but it works
<fabbione> GCC_TARGET=sparc64 ./debian/rules printarch
<fabbione> DEB_TARGET_ARCH: sparc64
<fabbione> DEB_TARGET_ARCH_OS: linux
<fabbione> DEB_TARGET_ARCH_CPU: sparc64
<fabbione> DEB_TARGET_ARCH_CPU: sparc64
<fabbione> DEB_TARGET_GNU_SYSTEM: linux-gnu
<fabbione> TARGET_ALIAS: sparc64-linux-gnu
<fabbione> TP: sparc64-linux-gnu-
<fabbione> TS: -sparc64-linux-gnu
<fabbione> doko_: ^^
<fabbione> clearly it doesn't fix the packaging issues, but that should be enough to start building gcc i guess
<fabbione> Keybuk: if i am not mistaken to add sparc64.deb to dpkg it's enough to add it to the cputable and archtable, right?
<fabbione> or do i need more hacking?
<Keybuk> adding it to cputable would break sparc
<Keybuk> there is no archtable
<Keybuk> there's debian/archtable, but that's just documentation
<Keybuk> you'd have to remove the assumption that sparc64 == sparc
<fabbione> why would it break sparc? i don't know all dpkg internal.. so it might sounds like a lame question
<fabbione> is that assumption coded somewhere?
<Keybuk> in cputable
<fabbione> sparc           sparc           sparc(64)?
<fabbione> sparc64         sparc64         sparc64
<Keybuk> that wouldn't work
<Keybuk> you need to remove the "(64)?" from the first line
<fabbione> so the sparc(64)? should be just sparc
<Keybuk> right
<fabbione> yeah
<fabbione> would that be enough?
<Keybuk> and that would cause the sparc64 dpkg to only install sparc64 debs
<Keybuk> and the sparc dpkg to only install sparc debs
<fabbione> ok perfect
<Keybuk> what does config.guess say on a sparc64 with a 32-bit userland?
<Keybuk> (try it now)
<Keybuk> ./config/config.guess
<Keybuk> (who moved that?!)
<fabbione> it's building.. just one sec i will tell you
<fabbione> ./config/config.guess 
<fabbione> sparc64-unknown-linux-gnu
<fabbione> BUT
<fabbione> be aware that i am forcing -m64 to CFLAGS and CXXFLAGS
<fabbione> let me try without
<fabbione> yeps
<fabbione> the same
<fabbione> Debian `dselect' package handling frontend version 1.13.22 (none-sparc64).
<fabbione> hmmm
<fabbione> that none-sparc64 doesn't look good :)
* fabbione is a bit lost
<doko_> fabbione: maybe look at the ppc64 port on alioth
<fabbione> doko_: i think i am just using the wrong approach.. i need to understand where to start
<fabbione> i find it hard to believe that they didn't patch gcc at all
<fabbione> dpkg-deb: building package `dpkg' in `../dpkg_1.13.22ubuntu7sparc64_sparc64.deb'.
<fabbione> there we go
<fabbione> much better :)
#ubuntu-toolchain 2006-10-08
<fabbione> doko:
<fabbione>    * Configure with --disable-libssp on architectures that don't
<fabbione>      support it (hppa, ia64).
<fabbione> ???
<fabbione> i am running edgy on ia64...
<fabbione> isn't a bit dangerous to change gcc options in the last minute?
<fabbione> (screw hppa that's not there... but ia64 is..)
<fabbione> anyway... movie time :)
<doko> fabbione: no, if you run the testsuite, then you'll see that -fstack-protector isn't recognized even *if* you configure --enabled-libssp
#ubuntu-toolchain 2007-10-03
* Starting logfile irclogs/ubuntu-toolchain.log
<doko> lamont: libgcc2 is built by gcc-4.0, not gcc-3.4
<lamont> doko: right.  don't be confused by the 'workaround launchpad' uploads (aka 'trigger build for hppa')
* lamont really gone to lunch now
<arthur-> doko: is it ok if madcoder upload gdc for unstable too?
<doko> arthur-: sure, if it's not rejected again by ftp-master ;p
<doko> arthur-: please could you prepare a gdc package for gutsy tomorrow?
<arthur-> doko: sure
<doko> thanks
<arthur-> doko: I fixed the lintian warnings but madcoder did upload before :p
<arthur-> doko: if I send you a SVN diff tomorrow, could you check it in?
<arthur-> (for gdc)
<doko> sure
<arthur-> thanks
<arthur-> good night ;-)
#ubuntu-toolchain 2007-10-04
<lamont> doko_: is icedtea-java7 bound for gutsy for sure, or might it wind up being hardy?
<lamont> and how many architectures did you give me enough to bootstrap on?
<doko> lamont: amd64, i386, lpia, pending review from cjwatson
<lamont> doko: ok.  once the source is in the archive, I can actually work on bootstrapping it.
<lamont> doko: if you're bored, feel free to look at the mlton build failures for 20070826-1... ICE * 2
<doko> lamont: maybe not now ...
<lamont> doko: it's on my "What Evah" list.  I really don't care one bit about it
<lamont> doko: will icedtea-java7 be main or universe?
<doko> lamont: universe
<lamont> good
<lamont> then it doesn't need to make a special trip through universe on its way to main or some such...
<lamont> :-)
<doko> or maybe multiverse, depends on cjwatson's analysis, but I'd say universe
<lamont> (my bootstrapping archive is in sources.list.universe, you see...)
<lamont> ah, good point... I'll add the bootstrap archive to sources.list.multiverse too
<doko> lamont: is gutsy buildd chroot debootstrapple now?
<lamont> doko: gutsy/hppa is _INSTALLABLE_
<lamont> note that without people.u.c/~lamont/hppa/gutsy-stage0, you won't be able to resolve most build-dependency graphs
<lamont> if you find packages that you need, that aren't in the ports.u.c archive, and launchpad.net has no build record for hppa/gutsy, holler
<lamont> doko: there's a little bug in launchpad, you see... it'll be fixed for hardy.
<lamont> in the meantime, some packages didn't get build records when we lit up hppa... the workaround for gutsy is to upload a new copy
* lamont is in the middle of doing 30+ of those
<lamont> which will get us network install and pretty much the entire toolchain
<lamont> I decided that I didn't care about gcc-3.3 (which is one of the aflicted)
<arthur-> doko: upload to gutsy would be a merge of gdc -17 upload if it were uploaded, can I call it -17ubuntu1 then? (fakemerge)
<arthur-> doko: http://people.dunnewind.net/arthur/lutin/gdc-4.1_0.25-4.1.2-17ubuntu1.dsc
<arthur-> sleep time, goodnight
#ubuntu-toolchain 2007-10-05
<arthur-> doko: I've updated the source package, please re-dget it
<doko> arthur-: not today
<doko> sorry
<arthur-> doko: np, have a nice day
#ubuntu-toolchain 2007-10-06
<doko> lamont: any hint on the build failures on ia64 and hppa?
<lamont> for which?
<doko> lamont: almost any
<doko> do you get emails about build failures?
<lamont> gutsy?
<lamont> no - I have to go look at the website, unless I was the uploader
<lamont> I know that the kernel is ftbfs on ia64, which leads to some of them.
<lamont> and gtk-2.0 hadn't built before several packages tried to build --> ftbfs
<doko> lamont: see fontconfig for example, I didn't look yet what is missing
<lamont> fontconfig is successfully built on all 7 architectures...
<doko> lamont: sorry, see wvstreams, vte, metacity, gtk-sharps2
<lamont> lack of gtk+2.0
<lamont> ia64 is all queued to retry, hppa is still building gtk+2.0
<lamont> then I'll give everything back
<doko> strange, but this doesn't explain the build failures on sparc yet
<lamont> I haven't looked at spark yet.
<lamont> anyway, afk for a few hours
<arthur-> doko: if you didn't check gdc patch yet, can I send you a new one with some minor fixes?
<doko> arthur-: sure, I'll ping you before upload anyway
<arthur-> doko: thanks a lot
<arthur-> doko: and see http://experimental.ftbfs.de/build.php?arch=&pkg=gdc-4.1 :-)
<arthur-> built with libphobos on arm, good new
<arthur-> lamont: if I give you a .dsc for gdc-4.1, could you please try to build it in a hppa/sid chroot?
<lamont> arthur-: sure
#ubuntu-toolchain 2009-09-30
<ramrad01> hi
<ramana> hi
