[00:05] <slangasek> bah, how did my coreutils merging turn into a coreutils NMU?
[00:30] <infinity> slangasek: That happens to me more often than I like.
[00:30] <infinity> Though not with coreutils so far...
[00:57] <infinity> Alright, tex* stuff finally all published and settled, first mass-give-back of the release under way.
[11:06] <tumbleweed> can someone reject cntlm 0.91~rc6-0ubuntu2.1 from precise-proposed, please (that version was inappropriate, corrected upload is in the queue too)
[11:09] <cjwatson> tumbleweed: done
[11:10] <tumbleweed> at
[11:10] <tumbleweed> ta even
[11:27] <cjwatson> tumbleweed: are you planning to educate ubuntu-activity about quantal? :-)
[11:46] <tumbleweed> cjwatson: it'll get there eventually. The data comes from UDD in Debian
[11:48] <cjwatson> ok
[16:23] <doko> infinity, uploaded openjdk-7 to -proposed. should be copied to quantal
[16:24] <infinity> doko: To quantal-proposed?
[16:24]  * infinity waits for it to show up.
[16:24] <doko> pp
[16:24] <infinity> Oh.  Kay.
[16:25] <infinity> Is there an SRUish bug for it?
[16:25] <doko> bug 993380
[16:25] <ubot2> Launchpad bug 993380 in openjdk-7 "openjdk-7 on ARM still defaults to JamVM, but should default to the ARM assembler interpreter" [High,Confirmed] https://launchpad.net/bugs/993380
[16:26] <infinity> doko: Danke.
[20:29] <bjf> if i search and replace quantal for precise in sources.list, do an "apt-get update;apt-get dist-upgrade" it wants to remove ubuntu-desktop
[20:32] <slangasek> bjf: I think it's a bit early to expect that to work consistently, but I'll take a peek
[20:34] <bjf> slangasek: i thought the new mantra was that the archive is always installable
[20:34] <slangasek> well, yes, but realistically we need to make allowances for the first week or so while we're sorting out the mass-autosync
[21:05] <slangasek> bjf: looks like it's related to a rename of libatk-adaptor-schemas
[21:06] <bjf> slangasek: do i just need to wait a few days (or more) for things to settle?
[21:06] <slangasek> I think that's generally advisable here
[21:07] <slangasek> because fixing this doesn't guarantee there won't be more
[21:07] <bjf> slangasek: any guess how long? post uds ?
[21:07] <slangasek> yeah
[21:17] <infinity> doko: Erk, did you actually test that the new armel toolchain was ARMv5?
[21:17] <infinity> doko: /usr/bin/gcc-4.7 in this armel chroot is definitely v7...
[21:17] <infinity> And Thumb2.
[21:17] <doko> ?
[21:17] <infinity> http://paste.ubuntu.com/963311/
[21:18] <doko> infinity, --with-arch=armv5t --with-float=soft
[21:19] <infinity> doko: Sure, but the binary itself isn't v5... So, something's obviously gone wrong.
[21:19] <infinity> Oh, I wonder if this is binutils' fault.
[21:21] <doko> at some point, I'll dig up my xscale hardware ...
[21:22] <infinity> Yeah, it's binutils.
[21:22] <infinity> http://paste.ubuntu.com/963316/
[21:23] <infinity> ^-- See GCC producing the right output, the linking stage breaks it.
[21:24] <doko> I'll look at this tomorrow, not now
[21:24]  * infinity wishes he'd looked at this before we autosynced the world.
[21:25] <slangasek> infinity: does that output actually say anything about the insns used?  Seems to me it's declarative only
[21:26] <infinity> slangasek: It shouldn't actually break anything, no, given that gcc is producing the same interim objects.
[21:26] <slangasek> and I'm not sure we care about whether binutils *says* the binary is v7, as long as the code is v5t
[21:26] <infinity> slangasek: Unless ld does some extra wank that would break things.
[21:26]  * slangasek nods
[21:26]  * infinity isn't sure precisely what ld does there.
[21:26]  * infinity isn't sure he wants to know.
[21:27] <infinity> I have a feeling I'm about to find out.
[21:32] <doko> infinity, maybe upload eglibc built for v5? the crt.o files are still built for v7
[21:32] <slangasek> doh
[21:32] <doko> in this case, shared libs should be ok, but I didn't check
[21:34] <slangasek> infinity: do you have time to do that today?
[21:34] <infinity> Oh, hrm.
[21:34] <doko> I'll look at it now
[21:34] <infinity> slangasek: if it's just a rebuild, sure, but let me poke the rules and see if there's an explicit configure that needs unconfiguring.
[21:34] <infinity> Or doko can. :P
[21:36] <doko> ahh, and the armhf gcc still defaults to v7 with -mfloat-abi=soft, but I assume this is a minor nit
[21:37] <infinity> That would be nice to fix, maybe, but yeah, not a big deal.
[21:37] <infinity> I don't really see it as a cross-compiler to armel anyway, but literally a way to produce non-hardfp binaries on your hardfp system.  Which is v7 anyway.
[21:37] <infinity> So, whatever.
[21:38] <doko> yes, but the .o files really should be v5
[21:38] <infinity> Oh, perhaps.
[21:38] <doko> but this gets me into more configuration mess
[21:38] <infinity> Yeah, who's idea was hf/sf multilib anyway? ;)
[21:39] <infinity> whose, even... English is hard.
[21:39] <infinity> doko: Unless I'm missing it, I don't see an explicit arch configure in eglibc, so I assume it just needs a no-change rebuild with the current compiler?
[21:40] <doko> infinity, you miss the armel build on armhf. currently fixing this
[21:41] <infinity> Oh, well, that would fix itself if the multilib compiler did the right thing, I assume.
[21:41] <infinity> But I'll leave this to you and go back to my other compilers, since you seem to be all over it. :P
[21:54] <slangasek> fixed ubuntu-meta uploaded
[22:07] <doko> ogasawara, please could you check if the kernel build uses any -march or -mcpu flags on armel, and if yes, change these to armv5t?
[22:09] <infinity> doko: Hrm?  That makes no sense.
[22:09] <infinity> doko: All the kernels they build are for armv7 hardware.
[22:10] <infinity> doko: They should be identical between armel and armhf.
[22:10] <infinity> ogasawara: Ignore doko's above request. :P
[22:14] <doko> infinity, why?
[22:14] <doko> ahh, ok, maybe we should build an xscale kernel then ...
[22:15] <infinity> doko: We should definitely build a kernel for some v5 platform down the road, yeah, when we know what that should be. :P
[22:17]  * infinity wouldn't be against building a kernel for the RPi either, but not much point until the userspace is decidedly more rebuilt than it currently is.
[23:38] <doko> infinity, slangasek: https://launchpadlibrarian.net/103954882/buildlog_ubuntu-quantal-armhf.eglibc_2.15-0ubuntu11_FAILEDTOBUILD.txt.gz :-/
[23:40]  * infinity raises an eyebrow.
[23:40] <infinity> How has armel not failed the same way already?
[23:41] <doko> still building
[23:41] <infinity> Yeah, but it's done the native libc pass.
[23:42] <micahg> so, are we officially devolving arm for quantal?
[23:42] <micahg> *armel
[23:42] <infinity> micahg: See -devel
[23:49] <slangasek> doko: some wrong combination of options somewhere?  Debian obviously manages to spit out a build that doesn't require that register :)
[23:49] <doko> slangasek, debian is 2.13, imo not comparable
[23:50] <slangasek> man
[23:50] <slangasek> ok
[23:50] <slangasek> I keep forgetting we haven't built 2.15 *at all* yet in Debian
[23:52] <doko> started a local build, will look at it tomorrow
[23:59] <infinity> Like i said, it's fine on armel native, it's the armhf-armel cross that breaks, so maybe it's something not being turned *off* by turning on armv5t?