[00:01] will coordinate with infinity on the subject first thing in the morning then as well. [00:01] stgraber mentioned bug 986806 which might be a regression from the work on encrypted home; will investigate tomorrow [00:01] Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [Undecided,New] https://launchpad.net/bugs/986806 [00:02] (probably specific to encrypted home) [00:03] * skaet nods [00:06] also, I now have an LP test that reproduces bug 887185, so I'm working on fixing that [00:07] Launchpad bug 887185 in launchpad "ArchivePermission allows duplicated rows" [Critical,Triaged] https://launchpad.net/bugs/887185 [00:07] since that ideally ought to be rolled out by the time we initialise Q [00:09] good luck with figuring out the fix. [00:10] ok, no respins for now, we'll discuss tomorrow morning the timing of the next set of respins [00:10] g === kees_ is now known as kees [00:30] ugh. kernel oops [00:55] hggdh, get the details in a bug immediatley please. apw should be coming on line soon, and will be here with us in London, to help figure it out. === xnox is now known as jnlx === jnlx is now known as xnox_xnox [01:15] Fix for 887185 (well, at least the urgent bits of it) is making its way through EC2 now, so with any luck should be able to get it deployed on Wednesday [01:15] maybe Tuesday with a strong following wind [01:18] skaet: bug 987052 [01:18] Launchpad bug 987052 in linux "WARNING: at /build/buildd/linux-3.2.0/kernel/softirq.c:159 local_bh_enable_ip+0x7a/0xa0()" [Undecided,Confirmed] https://launchpad.net/bugs/987052 [01:18] That was worth a late night, since the extra eight hours or so will matter :-) [01:18] skaet: end result is system became completely unresponsive [01:19] Thanks cjwatson. :) [01:19] * cjwatson spies jetlag [01:19] hggdh, not good. [01:19] * skaet notes that cjwatson is right [01:20] apw, bjf, ogasawara ^ could you please look at this as soon as one of you comes online. [04:10] Good morning [04:10] skaet: the rebuilds you pinged about already happened on the weekend AFAICS, right? [04:30] at least http://reports.qa.ubuntu.com/reports/ogasawara/weatherreport.html says that all packages are current [04:30] err, images [04:36] pitti: AFAIK there's no immediately pending rebuilds, although we do know we'll need to respin everything at some point because Nobody remembered to set OFFICIAL="Release" in debian-cd until now. [04:37] cjwatson mentioned it earlier. [04:37] indeed [04:38] I wonder if there is anything in precise-proposed which ought to get wrapped into the rebuild then [04:38] like compiz, dkms, maas-provision [04:49] server will need a respin once mass gets accepted regardless (so mass-provision is no rush) [04:50] The current maas package in the archives has dependencies that the security team said were no-go for Main. [04:50] (mass-provision will go on the server CD and cobbler will go off to Universe) [05:18] pitti, lets plan on discussing in the channel in 3 hours (when more folks are on line, which of the opportunity targets we feel comfortable including in the respin. [05:20] * skaet notes that the weather report, probably needs updating to reflect that Ubuntu Studio transitioned from an Alternate to a DVD this cycle... [05:20] skaet: agreed [05:23] skaet: have posted a comment to 987052 [05:24] Thanks ogasawara. :) [05:25] ogasawara, who maintains the weather report these days? [05:25] skaet: I do, was just about to look at the ubuntu studio bit [05:26] ogasawara, coolio. Thank you. Its late though, that is certainly not urgent. We can work around. [05:28] skaet: it's a quick fix to point to the new manifest location. [05:28] ogasawara, coolio. what ever [05:28] is easiest [05:28] * skaet hates keeping reminders if its fastest to just do it rather than write a reminder. ;) [05:32] pitti, if things are calm right now, could you fit in a pass on https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuDesktop? Want to make sure we've got the right features highlighted for the release, and get started on adding in the key bugs. [05:33] if you're working on bugs though, the ReleaseNotes can certainly wait. [05:36] skaet: oh, can do; I already brushed it up last week, but I'll have another pass [05:37] great! thanks pitti. :) Its likely to be a WIP until release day... ;) [05:38] * skaet --> gets breakfast, l8r [06:03] skaet: I'm fixing a few spelling/grammar/wording issues, and I remove the update-manager -d instructions (as at the time of release the -d won't be necessary any more) [07:16] good morning [07:16] * stgraber gets everything setup here for g+, back in a few minutes [07:27] do we have an official hangout place? I grabbed an USB webcam now (as my laptop is closed under my desk, and the integrated camera won't do much good) [07:27] but I have some trouble telling g+ about which cam to use [07:28] pitti: skaet said we'd, I'm going to create one if I don't have a reference to it in my e-mails [07:30] pitti, stgraber - go ahead and create a site for now, we may consolidate later, once we get the hardware set up. Choose a good name for it ;). [07:31] I need to figure out with Pete if we should consolidate qa-meeting in with it, or leave them as separate G+ sessions. [07:31] Will be heading in to office in 30 minutes or so, and setting up then. [07:31] skaet: remember that we have a 10 participants limit in g+ hangouts [07:32] stgraber, good point. ok, separate it is. [07:48] * skaet -->office, biab [08:08] could someone do another round of removals from precise stuff that was removed from unstable? That way I can just file bugs if I see anything left [08:09] Yes, I was about to start that [08:09] cjwatson: thank you :) [08:09] Oh, a general p-r run you mean [08:09] OK, I guess so, though I'd tend to be pretty conservative [08:09] cjwatson: is there output of what has Ubuntu diffs and has been removed? [08:10] hello cjwatson [08:10] cjwatson: nm, I know the answer to that :) [08:12] micahg: Er, you could run p-r yourself in dry-run mode I guess [08:12] I forget how upset it gets if you don't have ftpmaster shell access [08:13] I was thinking of ubuntuwire [08:13] Ah [08:14] after the p-r run, I can go through an see if there's anything that needs an update to remove old stuff [08:36] micahg: In progress now. A lot of things relate to other package reorganisations that haven't happened yet in Ubuntu, so I'm being pretty cautious. [08:37] cjwatson: I can appreciate that, thanks, I'm hopefully going to sleep shortly, will try to pick off a few at a time over the course of the day from what's left [09:20] Hi! [09:23] I have a small request... there is a compiz patch in -proposed that has been pushed in recently [09:24] It works, everything is fine - but it's a workaround for a problem we noticed, since we didn't yet have a good fix [09:24] But on Friday, we actually found the root cause of the problem and fixed it the right way [09:25] So I wanted to know if it would be possible to exchange the workaround for compiz that's already in -proposed for the 'final' fix [09:26] sil2100: We kinda like things being fixed correctly. [09:28] sil2100: this -proposed version will not go into the final release anyway [09:28] pitti: ah, so it's anyway target for SRU-0? [09:29] infinity: this final, non-workaround fix is much better, since it has no performance implications [09:29] infinity: since it fixes a typo someone made long long time ago ;) [09:29] sil2100: so yes, it's perfectly reasonable to replace the upload with a better one [09:30] pitti: excellent, I'll ping ogra_ to port the gles patch if possible to the new distro version [09:30] pitti: thanks! [09:39] skaet, I'm looking at the ISO tracker, for the rows that are green, does it mean those ISOs are good to release? [09:39] for exable Ubuntu amd64 has a green 6/6 [09:39] ? [09:39] wow, Ubuntu is installling so much faster now that I closed g+ :) [09:40] rickspencer3: they'll all need a rebuild to be tagged as final images [09:40] rickspencer, not quite, it means that all the tests have passed, and we could if there were no other issues known. Its part of the story, but not all of it. [09:40] how can I tell which ones are good to go? [09:40] stgraber, skaet ^ ? [09:40] rickspencer3, http://pad.ubuntu.com/ubuntu-release [09:41] AFAIK none of them have the official tag set, so they all need at least a cd rebuild if not livefs rebuild [09:41] gives the issues we're monitoring for respin. [09:41] [18] is the "Release" respin stgraber is referring to. [09:42] I see two 18s there :P [09:43] so they all need to be respun and then retested via the ISO tracker? [09:43] rickspencer3, yes. [09:44] skaet: might be worth adding a note in the tracker header again if not disable them all. [09:46] stgraber, yes. [09:46] pitti: Can maas be accepted please, and maas-provision be pocket copied from -proposed please? [09:47] Daviey: sure [09:47] thanks [09:47] Daviey: want to do the releasing yourself, for practicing, or not now? [09:48] pitti: the hat now? [09:48] what*? [09:48] Daviey: pad updated for maas, re-labeled to "20" (as "18" already existed) [09:48] Daviey: sru-release -r precise maas-provision [09:48] pitti: I'm not in ~ubuntu-archive, frustratingly. [09:48] Daviey: can run it for you, I just wondered if you wanted to [09:48] Daviey: ah, ok [09:49] I would like to do it myself, yes :). [09:49] skaet: didrocks is kindly looking over tge MIR's for horizon. NOT SPIN RELATED. [09:50] * didrocks emphases in "kindly" :p [09:50] cjwatson: reviewing gfxboot, this just changes *.po files? I don't see an actual string change in any code there? [09:51] can we do something with esteid-browser-plugin one way or the other please? [09:51] wait for python-coverage, maybe additional changes are needed ^ [09:51] pitti: surely, there will be needed for another upload, can you reject it for now? [09:51] didrocks: coverage? [09:51] pitti: there's a *.pot file there too. The actual string is in debian-cd [09:51] didrocks: seems Daviey just uploaded it to change the version for the ubuntu delta [09:51] pitti, infinity, note that updating the gles patch on top of the compiz change will take another day for linaro and me to update everything again [09:52] pitti: yeah, there is no LICENSE/COPYING file [09:52] oh sorry [09:52] that's fine, BSD-2 [09:52] cjwatson: ah, so it takes the strings from there; thanks [09:52] * didrocks tries to see where it's specified that it's BSD-2 on the package [09:53] Daviey, didrocks. Thanks. (and appreciate the clarification ;) ) [09:55] skaet, cjwatson: Unable to reproduce bug 986806 here [09:55] Launchpad bug 986806 in ubiquity "swap not activated after choosing 'use whole disk'" [High,New] https://launchpad.net/bugs/986806 [09:56] stgraber, ok. we'll aim to release note. Its recoverable. Would you please add a release note project to the bug? [09:56] (so we don't loose it.) Important to tell folks how to recover. [09:58] skaet: well, I don't know what the problem is post-install so I don't know how to fix it ;) [09:58] stgraber, fair enough. Some of the folks in the room were just discussing it. [09:58] skaet: can be any of missing swap in /etc/fstab, non-encrypted swap trying to be mounted as encrypted swap or just non initialized swap partition [09:59] skaet: having another look at the log provided by the user to try and see if there's a clue I didn't see initialiy [10:02] skaet: oh, I think I found a clue, will do another test install now. Seems to be related to low-memory environment [10:03] install was done with < 512MB of ram, which created a zram device that might have caused the encrypted swap script some troubles [10:04] cjwatson: sounds possible? ^ [10:04] cjwatson: relevant part of the log being: http://paste.ubuntu.com/942285/ [10:08] stgraber: possible, but I thought I fixed ecryptfs-setup-swap to ignore zram [10:08] right, so that should just have been ignored? [10:08] I did explicitly test that [10:08] yeah, I remember seeing that code... test install running here with 480MB to see exactly wha happens [10:08] *what [10:09] zram seems indeed to be ignored, but then we get that extra log entry: [10:09] Apr 22 08:38:12 ubuntu ubiquity: WARNING: Commented out your unencrypted swap from /etc/fstab [10:09] that I don't get on a > 512MB install [10:10] Odd, you should, I think [10:10] pitti: skaet: python-coverage looks good to me with this upload, acking the MIR. If you accepted it to -proposed an then move it to the release pocket, I'll do the promotion to main [10:10] or maybe you want to override directly when copying from proposed to the release pocket? [10:10] That should be commenting out the swap entry on the hard disk, not zram [10:11] didrocks: accepted to -proposed [10:11] didrocks: yes, I can do that [10:12] pitti: ok, just set the bug report as fix committed, please change the status to released once… released ;) [10:12] didrocks: yep, will do; thanks [10:13] skaet: lunch time here, I'll be back for the hangout. I have a test install running for the encrypted swap install so I'll know more at the meeting [10:13] Thanks stgraber [10:14] * cjwatson slogs through all the removals from the Cambridge Debian BSP in March [10:21] * cjwatson laughs at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662179 [10:21] Debian bug 662179 in ftp.debian.org "RM: pouetchess -- RoQA; unmaintained, RC buggy" [Normal,Open] [10:21] "5 years after the maintainer promised to fix a chess program [10:21] which ends the game on check, it's time to stop pretending [10:21] that it can be described as a chess program." [10:23] (Why does ubot2 think that bug's open? Silly thing) [10:26] ppc build fix [10:31] fine by me [10:32] cheers [10:35] slangasek, I did check -lucid and -oneiric updates with your upload, and they both do work for me === brendand_ is now known as brendand [10:51] So are we good to respin now? [10:53] Oh, maas needs to go to release, copying that now [10:54] cjwatson: so I got an Ubuntu install with the same log as the reporter but I still have a working swap. Doing another install on top of that to see if that triggers it then [10:54] ok [10:54] (I don't see why it'd but well, that's what the reporter described) [10:58] So IMO it's ETA ~30mins until we can start respins [11:04] OK, I basically can't hear anything at all on G+ [11:04] It's very jumpy sound [11:04] I think if we want to have a productive sync with remote participants we'd be better off with IRC [11:07] IRC ++ [11:07] cjwatson, stgraber - anything left to wait for from your perspective, or are we good to go? [11:07] pitti- anything from your radar? [11:07] maas needs to publish to release [11:07] * skaet has gone to IRC [11:07] skaet: I just finished another test install for the ecryptfs issue [11:07] I can't hear a word from the office, and the video is just a slideshow [11:07] skaet: I'm looking at the result now [11:08] After that I don't have anything at the moment [11:08] It's amazing really.. We can produce an operating system, but a phone call is too much of a challenge :) [11:08] ok stgraber, you're my trigger then. :) [11:08] Daviey, we can produce an operating system, G cannnot produce a phone call [11:08] skaet: VM booting now :) [11:09] utlemming, you'll need to respin the cloud images to pick up the "Release" setting (it was omitted by accident on last Thursday's interesting) [11:09] What are the issue numbers on the pad referring to? [11:09] skaet: um [11:09] [18] [11:09] CONF.sh [11:09] skaet: utlemming's cloud image generation code doesn't use debian-cd, so I don't see why that would matter to him [11:09] He may have something independent [11:10] * Daviey checks [11:10] skaet, cjwatson: right, can't reproduce the issue even on low memory doing two installs on top of each other [11:10] * Daviey stops checking for the moment. [11:10] OK, let's chalk it up to cosmic rays for now? [11:11] skaet, cjwatson: so if that thing is reproducable, it's difficult enough that it likely won't affect a lot of systems and so shouldn't be RC [11:11] cjwatson, Daviey thanks! [11:11] stgraber, ack. ok, will start queueing up the rebuilds. [11:13] skaet: commented in the bug asking for everything that'd help to debug this and marked incomplete, so I think we're done with that one for now [11:15] thanks stgraber, ok, going ahead with the desktop rebuilds [11:16] Daviey, I'll start the alternates and server as soon as we're sure publishing is clean [11:16] infinity, as soon as you've added the timestamps, ping me and we'll start the arm ones off. [11:17] phone> FWIW we found in the foundations installer sprint that mumble was in practice more usable for leaving on all day [11:18] yeah, video is not all that important here [11:19] yeah and doesn't use half of your CPU. Though I think Millbank would still need a decent microphone [11:19] * cjwatson reaches April in this removals sync-up [11:19] keeping up with the Debian FTP team <- hard [11:20] cjwatson: can you ensure you don't end up removing qtnx? I know that last time pitti did the removal sync with Debian that dropped it from the archive even though I use it and fix it when it break. [11:23] I don't recall it coming up, but I'm running from the start of the year so if it was removed from Debian before that it won't come up [11:24] cjwatson: maas seems published in release pocket now? [11:24] * skaet is marking iso tracker that respins comming... [11:24] Daviey: publisher is still running [11:24] I'm watching the log [11:24] ok [11:25] LP tells you it's published at the start of the relevant publisher run [11:25] cjwatson: last time it was removed from the ubuntu archive was on the 6th of February, according to the Debian bug, it was removed in Debian on the 17th of December, so should be good then [11:25] stgraber: yep, won't be a problem [11:27] hmm... we're double checking WUBI right now... [11:27] maas is done [11:27] cjwatson: thanks [11:27] skaet: what about it? [11:29] cjwatson, trying to figure out GPL issue resolved with ev [11:29] seems to be some doubt [11:29] skaet: Steve and I agreed that it should not be a showstopper [11:30] skaet: (a) It's not clear that we've ever got it particularly right for Wubi so it's not really a regression, (b) we can fix it with non-image changes [11:30] we're fine on wubi [11:30] the wubi revision we have signed and in place is the most recent bzr revision [11:31] I raised it here because I only noticed it recently and because it came up in the context of another bug, not because it was a release showstopper [11:31] as colin confirmed, he and steve don't consider the gpl issue a release blocker [11:31] so there's no need to respin wubi images [11:31] thanks ev, cjwatson. :) [11:31] skaet asked me to write all that here [11:31] :) yup [11:32] * skaet trying to get this virtual thing effective, and make sure room conversations are echo'd here. ;) [11:40] skaet: I moved the Edubuntu page from https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/EdubuntuDesktop to https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/Edubuntu so that the name is similar to that of the other flavours and fixes some broken links in the process [11:42] heya, can we still have linaro-image-tools package updated in universe? [11:44] fabo: yes [11:45] fabo: unseeded universe isn't frozen yet though UI and feature freeze apply [11:46] fabo: [11:46] fabo: UnseededUniverseFinalFreeze is tomorrow at 21:00 UTC [11:47] stgraber: ok, thanks [11:50] thanks stgraber! thought I'd caught them all, but it appears not. :) [11:51] ^ full rebuild has started, should be emerging on the iso tracker from now on. [11:51] skaet: there also was a broken link to the kernel config /Spec/ instead of /Specs/, spotted by one of the Edubuntu guys, fixed too :) [11:51] awesome. Please thank the guy that spotted it from me. :) [11:52] skaet: any reason why Upgrade is disabled? I'm not aware of anything being broken there [11:52] good point [11:53] * stgraber is always sad to get an e-mail from the auto-upgrader telling him 8 hours of testing couldn't be reported because the builds are disabled ;) [11:55] micahg: OK, first pass at that finally done, so feel free to report anything else that bothers you [11:56] Also, phew, that was a lot of removals [11:56] Not many with FTBFS bugs attached though [11:56] were you doing removals from unstable or testing? [11:56] s/doing/tracking/ [11:58] and by accident I ended up including WUBI in the builds - will be reverting back to the already tested one. [12:00] ack, I don't *think* any of the rebuild triggers affect Wubi preinstalled images? [12:01] cjwatson: I think dkms does but that's just a dependency fix so we don't NEED it [12:02] $ GET http://cdimage.ubuntu.com/wubi/current/i386.manifest | grep dkms [12:02] $ GET http://cdimage.ubuntu.com/wubi/current/amd64.manifest | grep dkms [12:02] $ [12:03] oh, ok :) [12:03] ah, I guess dkms is usually in /pool so on the desktop media but not on the preinstalled images === jdstrand_ is now known as jdstrand [12:28] infinity: any word on what to do with gnat-4.6 outdates? [12:31] cjwatson: doko claimed he'd look at it. [12:32] OK [12:35] doko: Did you get anywhere with gnat-4.6 (turning off multilib on armel)? [12:35] cjwatson: We *could* remove all of armel's gnat-4.6 rdeps, but given that we didn't get it ported to armhf in time, that's kinda one of the few potential use-cases for multiarch on armel/armhf. :P [12:37] Daiey / cjwatson: Erm, was maas-provision meant to be in main? [12:37] I didn't touch that [12:37] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [12:38] It was. [12:38] I assume this invalidates the current server spins being done. :P [12:39] Might want a fix-committed MIR then. [12:39] It would do. [12:39] The only question is about the apparmor profile. [12:39] That needs fixed first. [12:39] https://bugs.launchpad.net/ubuntu/+source/cobbler/+bug/950193/comments/6 [12:39] Launchpad bug 950193 in maas-provision "[FFe] [MIR] maas-provision" [High,In progress] [12:39] (see the mir bug) [12:39] So that's now critical path. [12:40] forked-daapd FTBFS on armel/armhf because libdispatch misbuilds with a sufficiently new dpkg-dev, and on top of that it fails to build in three different way. [12:40] I am trying to raise Daviey on this issue. I don't know why it was shipped disabled by default. I guess I could've been more clear... [12:40] *ways [12:40] But I think I've got it disentangled now. [12:41] Oh, sorry, two different ways. :-P [12:41] Daviey: Can you sort out the maas-provision issue with jdstrand ASAP? [12:45] added a note to the pad about this [12:46] speculatively made Ubuntu ARM Server trigger on a fix for this as well as Ubuntu Server; please correct me if I'm wrong [12:47] cjwatson: Seems right. [12:47] cjwatson: Did you remove gnat-4.6/armel binaries already? outdate seems to not list them... [12:47] No [12:47] Oh, outdate probably doesn't list armel. [12:47] La la la. [12:47] Try testing-ports/... [12:47] All of cobbler can be demoted. [12:47] * infinity nods. [12:48] I really wish we didn't split main/ports for britney. [12:48] ScottK: I was sort of loosely waiting until maas-provision could be promoted [12:48] maas already doesn't depend on cobbler and the only reason maas-provision exists is because cobbler isn't suitable for main. [12:49] We've got plenty of time, I guess. [12:49] ew @ libkqueue [12:49] fails to build with a hang in the test suite, only on amd64/i386 [12:50] Is the stack of mismatches related to horizon meant to impact the server CD? Does anyone know? [12:50] Oh, and apparently only on buildds, not locally. [12:50] ScottK: No, it's in supported-misc-servers so not on the CD. [12:50] OK. [12:51] So we don't need to wait for that. [12:51] And libkqueue has the same maintainer as libdispatch. Bless me, Father, for I have sinned. [12:52] (At least, I assume I must have done.) [12:53] cjwatson, it inevitable, the list of possible sins is so very large [12:54] Oh, bleh, tulip is GLES + QT issues. [12:55] I might just disable the test suite on sufficiently old kernels. [12:56] cjwatson: Just build it on one of the new buildds. [12:56] Maybe if I disable it on <<2.6.32, and then we'll find out later if a buildd upgrade to lucid fixes it. [12:56] cjwatson: They're precise. [12:56] Oho [12:56] OK, I'll try that [12:59] cjwatson: And that appears to have worked. \o/ [13:00] infinity: I've been gradually removing OODs from GLES/Qt issues (there are still lots). tulip has an Architecture: all build-dep, but hey, that's uninstallable on armhf anyway. Shall I just kill it on armel? [13:00] Hooray for brute force and ignorance [13:00] cjwatson: Yeah, I was going to remove it. [13:00] cjwatson: Go for it. [13:01] Done [13:02] (It should have been removed in oneiric, it was out-of-date there too) [13:02] Oh well. [13:02] Now if anyone understands maven, I could use help with the wagon build failure [13:02] infinity: I've deduced that OOD hasn't been clear since before lucid [13:02] cjwatson: srsly? [13:02] Since I've been removing binaries that should have been superseded in lucid [13:02] Ugh. [13:02] I think karmic was the last time [13:02] Right, this needs to be a more proactive thing, methinks. [13:03] Would be less effort if we did it more than once every 2 years. :P [13:03] Yes. One reason I want to kill it dead for precise. [13:03] It should be part of +1 maint. [13:03] Ooo, axiom's build failure on PPC is special. [13:04] Dear http://people.canonical.com/~ubuntu-archive/testing/precise_outdate.txt, I don't believe you [13:05] cjwatson: You don't? [13:05] Oh, _all [13:05] Duh [13:05] cjwatson: Yeah, that's only main. :P [13:05] Sorry, wrong direction in my browser's back/forward queue ... [13:05] ;) [13:07] Adri2000, i've updated the README.files. [13:07] cjwatson: FFe for an axiom sync, the newer version builds everywhere on Debian (well, except mips...) [13:07] cjwatson: ? [13:08] cjwatson: No rdeps, except for some science-* metapackages. [13:09] Do you have the upstream changelog handy? [13:10] * infinity looks. [13:10] libdispatch, why do you mock me [13:11] https://launchpadlibrarian.net/102903313/buildlog_ubuntu-precise-armhf.libdispatch_0~svn197-3ubuntu1_FAILEDTOBUILD.txt.gz clang isn't just stuffed on armhf, is it? [13:11] I don't like the look of those BFD assertions [13:13] Also, libdispatch/powerpc builds iff it *isn't* built on sulfur. [13:13] cjwatson: In theory, clang works on armhf. I'm not sure how heavily it's been tested... [13:14] (Log's gone, I'm afraid, but it was SIGILLing.) [13:14] cjwatson: If it's sigilling on sulfur, then it's incorrectly building in altivec. [13:15] cjwatson: Which would fail on my PPC machines at home too. [13:15] Wouldn't surprise me. What's the right flag to fix it? [13:15] cjwatson: (adare/ross are Apple G5s, sulfur is a POWER5) [13:15] -mno-altivec? [13:15] Could be. [13:15] Not sure. :/ [13:15] There's no mention of altivec in the source. [13:16] I suppose llvm/clang itself could be doing it. [13:16] Well, altivec being a guess, but I think that's generally where a G5 and POWER5 differ, ISA-wise. [13:16] But it would also mean those bianries would fail on G4, G3, etc. [13:17] Not really sure I can be bothered to fix it now. armhf is getting in the way though. [13:17] Pretty sure at least some G4s had altivec. [13:17] Some did. [13:17] Differing generatoins, though. [13:17] Like SSE. [13:18] Anyhow, nothing in the PPC archive should have altivec. Maybe an instruction scanner at some point would be nice. [13:18] http://llvm.org/bugs/show_bug.cgi?id=11924 [13:18] llvm.org bug 11924 in Frontend "clang makefile assumes all powerpc systems have altivec" [Normal,New: ] [13:19] At a guess [13:21] cjwatson: oo, sounds likely. [13:21] I'll make a note of that for an SRU. [13:21] So it's clang itself, not libdispatch [13:22] Check. [13:22] I'll fix llvm on PPC later. [13:22] But the armhf thing, hrm. [13:22] (Well, if we end up needing to upload for armhf, we could do PPC at the same time) [13:23] BFD_ASSERT (in_attr[Tag_ABI_HardFP_use].i == 0); [13:23] The assertion is that if Tag_FP_arch is set to 0 then Tag_ABI_HardFP_use must also be set to 0 [13:24] Which means that something here is producing an SF binary. [13:24] This is all in configure tests with fairly basic compiler options. [13:25] configure:2632: clang -g -O2 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro conftest.c >&5 [13:25] cjwatson: Right, so either clang is wrong, or something it's linking to is... [13:25] (precise-armhf)cjwatson@scheat:~$ cat t.c [13:25] int main(int argc, char **argv) { return 0; } [13:25] (precise-armhf)cjwatson@scheat:~$ clang t.c -o t [13:25] /usr/bin/ld.bfd.real: BFD (GNU Binutils for Ubuntu) 2.22 assertion fail ../../bfd/elf32-arm.c:11477 [13:25] I'm going to vote for clang [13:26] Poop. [13:26] * infinity has a look. [13:26] Gotta love compiler test cases you can fit into IRC. [13:29] * infinity wonders how/why this worked a few months ago... [13:31] You didn't change the triplet or something did you? [13:31] No. [13:31] Just the linker path, which shouldn't relate. [13:31] * cjwatson -> out for a bit [13:35] cjwatson, infinity: will have to wait until tonight. didn't setup dyndns, working from mwhudson's place today with dholbachj === barry` is now known as barry_ === barry_ is now known as barry [14:33] Daviey: uploaded maas-provision to precise-proposed [14:36] jdstrand: Is this one good enough to promote? [14:37] infinity: How do I reliably tell whether an object file is SF or HF? [14:38]