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