[00:05] bah, how did my coreutils merging turn into a coreutils NMU? [00:30] slangasek: That happens to me more often than I like. [00:30] Though not with coreutils so far... === bdmurray_ is now known as bdmurray [00:57] Alright, tex* stuff finally all published and settled, first mass-give-back of the release under way. === smb` is now known as smb === Guest77193 is now known as yofel === yofel is now known as Guest53016 === Guest53016 is now known as yofel_ === lool- is now known as lool === doko_ is now known as doko [11:06] 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] tumbleweed: done [11:10] at [11:10] ta even === chuck_ is now known as zul === jbicha is now known as Guest36751 [11:27] tumbleweed: are you planning to educate ubuntu-activity about quantal? :-) [11:46] cjwatson: it'll get there eventually. The data comes from UDD in Debian [11:48] ok === knome_ is now known as knome === agateau is now known as zagateau === zagateau is now known as agateau === _bjf is now known as bjf [16:23] infinity, uploaded openjdk-7 to -proposed. should be copied to quantal [16:24] doko: To quantal-proposed? [16:24] * infinity waits for it to show up. [16:24] pp [16:24] Oh. Kay. [16:25] Is there an SRUish bug for it? [16:25] bug 993380 [16:25] 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] doko: Danke. === yofel_ is now known as yofel === slangase` is now known as slangasek [20:29] 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] bjf: I think it's a bit early to expect that to work consistently, but I'll take a peek [20:34] slangasek: i thought the new mantra was that the archive is always installable [20:34] 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] bjf: looks like it's related to a rename of libatk-adaptor-schemas [21:06] slangasek: do i just need to wait a few days (or more) for things to settle? [21:06] I think that's generally advisable here [21:07] because fixing this doesn't guarantee there won't be more [21:07] slangasek: any guess how long? post uds ? [21:07] yeah [21:17] doko: Erk, did you actually test that the new armel toolchain was ARMv5? [21:17] doko: /usr/bin/gcc-4.7 in this armel chroot is definitely v7... [21:17] And Thumb2. [21:17] ? [21:17] http://paste.ubuntu.com/963311/ [21:18] infinity, --with-arch=armv5t --with-float=soft [21:19] doko: Sure, but the binary itself isn't v5... So, something's obviously gone wrong. [21:19] Oh, I wonder if this is binutils' fault. [21:21] at some point, I'll dig up my xscale hardware ... [21:22] Yeah, it's binutils. [21:22] http://paste.ubuntu.com/963316/ [21:23] ^-- See GCC producing the right output, the linking stage breaks it. [21:24] I'll look at this tomorrow, not now [21:24] * infinity wishes he'd looked at this before we autosynced the world. [21:25] infinity: does that output actually say anything about the insns used? Seems to me it's declarative only [21:26] slangasek: It shouldn't actually break anything, no, given that gcc is producing the same interim objects. [21:26] and I'm not sure we care about whether binutils *says* the binary is v7, as long as the code is v5t [21:26] 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] I have a feeling I'm about to find out. [21:32] infinity, maybe upload eglibc built for v5? the crt.o files are still built for v7 [21:32] doh [21:32] in this case, shared libs should be ok, but I didn't check [21:34] infinity: do you have time to do that today? [21:34] Oh, hrm. [21:34] I'll look at it now [21:34] 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] Or doko can. :P [21:36] ahh, and the armhf gcc still defaults to v7 with -mfloat-abi=soft, but I assume this is a minor nit [21:37] That would be nice to fix, maybe, but yeah, not a big deal. [21:37] 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] So, whatever. [21:38] yes, but the .o files really should be v5 [21:38] Oh, perhaps. [21:38] but this gets me into more configuration mess [21:38] Yeah, who's idea was hf/sf multilib anyway? ;) [21:39] whose, even... English is hard. [21:39] 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] infinity, you miss the armel build on armhf. currently fixing this [21:41] Oh, well, that would fix itself if the multilib compiler did the right thing, I assume. [21:41] 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] fixed ubuntu-meta uploaded [22:07] 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] doko: Hrm? That makes no sense. [22:09] doko: All the kernels they build are for armv7 hardware. [22:10] doko: They should be identical between armel and armhf. [22:10] ogasawara: Ignore doko's above request. :P [22:14] infinity, why? [22:14] ahh, ok, maybe we should build an xscale kernel then ... [22:15] 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] 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] How has armel not failed the same way already? [23:41] still building [23:41] Yeah, but it's done the native libc pass. [23:42] so, are we officially devolving arm for quantal? [23:42] *armel [23:42] micahg: See -devel === jbicha is now known as Guest99314 === Guest99314 is now known as jbicha1 [23:49] doko: some wrong combination of options somewhere? Debian obviously manages to spit out a build that doesn't require that register :) [23:49] slangasek, debian is 2.13, imo not comparable [23:50] man [23:50] ok [23:50] I keep forgetting we haven't built 2.15 *at all* yet in Debian [23:52] started a local build, will look at it tomorrow [23:59] 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?