=== jbailey [n=jbailey@modemcable169.10-56-74.mc.videotron.ca] has joined #ubuntu-toolchain [12:58] doko: Around? [12:59] jbailey: not really, but what's up` [12:59] ? [12:59] doko: I think I want to make glibc on hppa build with gcc-4.2. We're then planning a big build. [01:00] Should we move gcc-defaults to 4.2 for us as well to give you more info? [01:00] It fixes more than it regresses, it seems, so I'd like to go ahead with it. [01:00] well, maybe you should consider moving to gcc-4.2 for hppa only, that would not affect supported archs at all [01:01] Sorry, that's what I mean. [01:01] sure, just upload a new gcc-defaults [01:01] 'k. There's no repo for it? [01:02] no, not really. I'll have to setup a separate branch in svn.debian.org [01:02] Sounds good. Do you want me to make the glibc change just in the repo and wait for you to upload, or do you mind if I upload? [01:03] please do the upload and checkin, I have not plans for a glibc update at the moment [01:03] doko: lovely, thanks. [01:04] lamont: Any last requests? === doko heads to bed now [01:05] doko: g'n, thx! [01:08] jbailey: rock on! [01:08] and tell me, since I'll have to manually kick the build(s) [01:08] as in package and version :) [01:08] lamont: Will do. [01:08] Leif is almost asleep [01:09] so i'll get started shortly === anibal [n=anibal@debian/developer/anibal] has joined #ubuntu-toolchain === Keybuk [n=scott@quest.netsplit.com] has joined #ubuntu-toolchain === Halcy0n [n=halcy0n@pdpc/supporter/active/Halcy0n] has joined #ubuntu-toolchain [12:23] meh, why does dpkg-architecture not include the vendor field in the default output? [01:02] we've never used it [01:04] we might want to use it for lpia. [01:04] do you think anything would break if I added it? [01:09] nothing should break [01:09] as long as you use the same variable names [01:09] adding DEB_*_*_VENDOR= should be fine [01:09] I've done far worse things to dpkg-architecture in the past [01:10] I added the DEB_*_ARCH_OS and DEB_*_ARCH_CPU and that didn't break anything [01:11] though you probably don't need DEB_*_ARCH_VENDOR since that would involve creating i386-linux-intel type Debian arch strings [01:11] it's enough to have DEB_*_GNU_VENDOR and change DEB_*_ARCH_CPU based on that [01:11] DEB_BUILD_ARCH=lpia [01:11] DEB_BUILD_ARCH_OS=linux [01:12] DEB_BUILD_ARCH_CPU=lpia [01:12] DEB_BUILD_GNU_CPU=i386 [01:12] DEB_BUILD_GNU_VENDOR=intel [01:12] DEB_BUILD_GNU_SYSTEM=linux-gnu [01:12] DEB_BUILD_GNU_TYPE=i386-intel-linux-gnu [01:12] or something [01:15] yeah, that's what I was thinking. [01:15] (apart from making vendor = lpia, but that's a detail) [01:15] pondering if I should have a vendortable, in the spirit of ostable and cputable [01:19] no [01:19] ostable and cputable are the two sides of the "linux-i386" type strings that dpkg uses [01:19] linux-i386 being the proper, long name of i386 [01:19] so where should the vendor string be encoded then? [01:19] s/encoded/recorded/ [01:19] fix cputable [01:20] so the i386 Debian CPU name is based off both the cpu and vendor parts of the triplet [01:20] and lpia likewise [01:20] otherwise you could, I guess, have something like [01:20] lpia i386 lpia [01:21] in a vendortable; saying that if the config.guess vendor bit is "lpia", and the Debian CPU is "i386" then the Debian CPU becomes lpia [01:21] I'd just add a extra field to cputable though [01:21] yeah, I guess I can do that. [01:21] since it's been documented that awk '{print $1}' of that is the full list of Debian CPU names [01:21] and you'd want lpia to be in that list [01:22] i386 i486 (i[3456] 86|pentium) [01:22] lpia i486 (i[3456] 86|pentium) lpia [01:22] (extra field matches against vendor part?) [01:22] they might have to be the other way around, I think it's first match wins [01:22] it's stuffed into a hash [01:22] and it should then try to do a best-match, probably [01:23] is it? [01:24] ah, remember, dpkg-architecture is backwards [01:24] $cputable{$1} = $2; [01:24] $cputable_re{$1} = $3; [01:24] it does push @cpu, $1; [01:24] though [01:25] there's also some m4 in dpkg's build scripts [01:26] m4/arch.m4 [01:26] ah, that uses dpkg-architecture now [01:26] interesting [01:42] hmm, I wonder if I should have a default vendor name for arches where none is specified === jbailey [n=jbailey@modemcable169.10-56-74.mc.videotron.ca] has joined #ubuntu-toolchain [02:48] doko: Hey - why does gcc-defaults insist on installing packages as part of build-deps? [02:49] jbailey: "installing packages"? [02:49] We don't have a functional gij on hppa yet, which is causing us a bit of grief. [02:49] It looks like the rules file doesn't need anything more than build-essential. [02:50] right, the b-d's on the base packages are there so that the gcc-defaults package is not built before all dependencies on an arch are available [02:50] Ah, okay. [02:50] Hmm [02:53] but just drop the b-d on gcj-4.1-base, it doesn't work [02:53] 'kay. [02:53] Thanks. I'll squeeze this in during a break later. I think I otherwise got all of the adding 4.2 stuff right. === tmarble [i=tmarble@nat/sun/x-fb0bbe1e38ee70f8] has joined #ubuntu-toolchain === tmarble [n=tmarble@user-38q4et6.cable.mindspring.com] has joined #ubuntu-toolchain === infinity [n=adconrad@cerberus.0c3.net] has joined #ubuntu-toolchain === doko_ [n=doko@dslb-088-073-090-217.pools.arcor-ip.net] has joined #ubuntu-toolchain === Keybuk [n=scott@wing-commander.netsplit.com] has joined #ubuntu-toolchain