[00:01] please accept boost1.49.0 after that's build and published I will upload boost-mpi-source1.49 (probably tomorrow) [00:01] and once glibc & that propagates into release we can open =/ [00:02] thanks [00:02] done [00:03] was not expecting you doko =)))) [00:14] ScottK, pykde4 now buillds [00:15] doko: Excellent. Then I suspect the difference between local and remote was you had ubuntu1 which was missing the pyqtconfig breakage I introduced in ubuntu2 (and fixed in ubuntu3). [00:36] good night everyone [00:36] xnox: 'night! [00:36] see you Sunday [00:37] slangasek: sure =) Sunday +1 hour ;-) [00:39] bdmurray: bugbot++ (bug #1071951) [00:39] Launchpad bug 1071951 in plymouth (Ubuntu) "package plymouth 0.8.2-2ubuntu2.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Invalid] https://launchpad.net/bugs/1071951 [00:47] xnox / slangasek: Thanks for the quick boost fix. [00:59] added wxwidgets and light-themes to the -proposed queue. now five packages wait for being accepted. [01:01] Grr, who overzealously demoted glibc-doc-reference to universe? [01:01] * infinity fixes. [01:02] Maybe we need to make component-mismatches start to understand proposed, since transitiony things will be happening there. [01:17] ^-- Updating the three packages that have strict libc6 deps due to naughtily using internal symbols. [01:18] s/internal/private/ [01:18] I should probably sleep sometime this weekend. [01:18] infinity: so where are you right now, anyway? London, or Copenhagen? [01:19] slangasek: London. I fly out Sunday morning. [01:19] slangasek: More specifically, in Andy's living room. [01:19] ah, so you have one more night to enjoy the expensive beer before flying out to join us for expensive beer [01:19] Something like that, yes. :P [01:19] Though, tonight I had free gin. [01:20] woohoo [01:29] Hrm, werid. Shouldn't update_excuses tell me why eglibc can't promote (as update_output does) instead of just smiling and saying "oh no, it's totally a valid candidate, la la la"? [01:33] Anyhow, all fixed now, and yay for it forcing a transition to happen properly instead of leaving it broken. [01:33] cjwatson: Huzzah ^ [01:34] infinity: what exactly do you want to see on _excuses? [01:34] _excuses tells you whether it passes the preliminary, package-local checks to be considered a candidate for the second pass [01:34] slangasek: I dunno. I thought it was meant to say "updating this will make the following uninstallable: dante-client, libdsocksd0, libnss-db, libsocksd0, libsocksd0-dev, unscd"? [01:35] nope, because that information only becomes available to it in the second pass [01:35] slangasek: Or is that the fancy grep-excuses output that slaps _excuses and _output together? [01:35] and only packages that are self-consistent are included in the second pass [01:35] grep-excuses may do some fancypants combining, yes [01:36] Yeah, I'm probably so used to interacting with update_* via the pretty display on the PTS that I've forgotten what the raw files look like, that's all. [01:38] Any objections to letting glib2.0 and pcre3 in now that eglibc's published all over? [01:39] I don't have any objections, but I'm not sure I'm sufficiently well-informed for my opinion to count here [01:39] (And then, soon, the world, but those two feel sufficiently low-level enough to get a pass on being next in line) [01:39] slangasek: Well, we're close enough to autosyncing at this point that it likely doesn't matter anyway. But I also have an ulterior motive of wanting to see glib2.0 pass its testsuite on all 5 arches, since it has a rather violent one. [01:40] infinity: right; I was interpreting the question from the POV of "are we close enough to opening that we can slip these in" [01:40] and I think you know better than I do whether that's the case ;0 [01:40] ;) [01:40] slangasek: Oh. Yeah. We are. Was more a question of if anyone had seen any "oh god, no" mentions earlier that I missed. [01:41] I'll probably just flush the queue once glib looks good. [01:41] Well, flush the proposed bits. [01:41] Might fetch and reupload all that release stuff. [01:43] * infinity wonders why the pcre version grew an epoch. [01:43] wow, really? [01:44] pcre3 (8.30..-2) unstable; urgency=low [01:44] http://packages.debian.org/changelogs/pool/main/p/pcre3/current/changelog [01:44] Yeah. [01:44] That was a curious attempt to... Do... Something. [01:44] to bump the version number following a .really-$prevver NMU [01:44] and then failing at dpkg --compare-versions, it seems :) [01:45] Silly. [02:08] infinity: hmm, rejects? [02:08] is that expected as part of auto-redirecting to -proposed? [02:09] slangasek: No, this is expected as part of me forcefully "redirecting" stuff that was uploaded before the redirect code landed. :P [02:09] ok [02:09] I figure it's a small enough set that the few early mergers will come ask. [02:09] You being one of them. [02:09] ;) [02:10] the early merger gets the confusing email [02:10] kirkland: Ignore the rejects, they got reuploaded to -proposed. [02:39] slangasek: Hrm. What do you know of the autohinter? [02:39] slangasek: Is it dumb as rocks? [02:40] infinity: whispers and tales; it post-dates my involvement with the britney code. what's up? [02:40] slangasek: Just trying to sort out if eglibc is going to need a manual shove. It seems to be failing to get any love. [02:40] looking [02:41] the one thing about it, as discussed with xnox earlier, is that the autohinter gives no feedback whatsoever about sets of packages that are almost-but-not-quite ready [02:41] In this case, eglibc (+rdeps) should have been ready in the last two passes. [02:41] Unless I missed something. [02:41] infinity: the autohinter tried it, see bottom of update_output [02:41] it failed due to powerpc-specific problems [02:42] (which had not been shown earlier because britney doesn't bother showing you problems for other archs while i386 is still broken) [02:42] Oh, that line relates to the above? That wasn't entirely obvious. [02:42] yep [02:42] * infinity goes to look at gcl/ppc and see how it relates to glibc.. [02:42] let's all blame aj for the idiosyncratic output :) [02:45] Ahh, indeed, gcl on PPC appears to have the same private linking issue. Curious. [02:45] And same with python-pypsignifit [02:45] * infinity fixes. [02:46] We need to get Apple to hire AJ as a UI designer. [02:55] Laney: webkit 1.10.1 doesn't appear to have an MRE; how does this fit the SRU guidelines? [02:56] Laney: the only linked bug report is about an arm-specific change to debian/rules [05:54] Any objection to me accepting the opendkim sync since it's a ~security related issue and I want to get the SRU/backports started. [05:55] ScottK: a sync to quantal, not to raring? [05:57] slangasek: sync to raring is in queue. [05:57] (has been since yesterday) [05:57] ah - if it's the raring one you mean, no objections [05:58] I just want to make sure the sync'ed tarball hits the archive first. [05:58] Yes. Thanks. [06:00] Laney: bug #1044322 isn't covered by the GNOME MRE (it's a patch added in the package), and there's no SRU test case etc; please fix when you have a chance- [06:00] Launchpad bug 1044322 in glib2.0 (Ubuntu Quantal) "indicator-messages-service crashed with assert in g_menu_exporter_name_vanished()" [Medium,In progress] https://launchpad.net/bugs/1044322 === doko_ is now known as doko [11:13] * infinity fixes the seeds to germinate stops trying to put libc-bin in universe... [11:13] s/to/so/ [11:50] cjwatson: I assume you're LEGOLanding right now, but if not, we should be good to start autosyncs, methinks. [11:51] doko: Any outstanding issues you've seen, or do you want to press send on your opening announce you've had queued up for days? :P [11:51] infinity, x32, fixing eglibc and preparing packages [11:52] doko: We can bootstrap x32 any time. Elaborate on "fix eglibc". [11:52] when I'm ready [12:14] infinity, you did remove the Vcs headers for Ubuntu in the merge [12:22] doko: That implies they were there in the previous version (they weren't). [12:23] doko: Anyhow, I'm in the process of moving the whole mess (for both us and Debian) to git. Just working on the source package for now is fine. But, I'll ask again, what needs "fixing" in eglibc? [12:23] which is strange, hmm [12:24] doko: Did you just mean enabling x32 and bootstrapping it? [12:24] no, I'm currently testing [12:32] infinity: slangasek: well when auto-hinting was required it _did_ appear in the britney output file. But I didn't quite understand but it was like "trying with autohints" combinations. [12:33] infinity: slangasek: there should be past logs available on that host that you can read for you pleasure =) [12:33] s/you/your/ [12:34] Autohinting doesn't imply any action being required, hence the auto. [12:34] But yeah, the output's less than intuitive. [12:36] infinity: autohinting is always shown in the logs on that host. [12:36] infinity: it's just if no autohints were generated, none are shown on the public web-pages. [12:37] infinity: see proposed-migration/logs/ [12:37] xnox: I know. ;) [12:37] ah =) [12:38] it was news to me. I guess I'm green and not acquainted with britney yet. [12:39] I'm not a britney expert, by any means, but I used to stare at its output in Debian long ago, and it's coming back to me. [12:39] infinity, did you try building gcc with the new eglibc packages? [12:40] ftbfs [12:40] doko: I didn't test-build gcc with the final upload, no. What's the FTBFS? [12:40] http://paste.ubuntu.com/1309478/ [12:41] Looks a whole lot like a missing include. [12:45] no, features now emits an explicit preprocessor warning [12:45] which let's the configure mis-detect things [12:45] configure:3817: gcc -E conftest.c [12:45] In file included from /usr/include/limits.h:26:0, [12:45] from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:169, [12:45] from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/syslimits.h:7, [12:45] from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:34, [12:45] from conftest.c:10: [12:45] /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] [12:46] Ahh, yes. That warning. [12:47] That's actually breaking unclever configure scripts? They shouldn't be looking at warnings... [12:47] it's the standard AC_CHECK_HEADER check [12:48] so I assume this will happen for most packages [12:49] Is it using -Werror during configure or something? [12:49] But yeah, we could patch out that warning. [12:53] configure:4967: checking for limits.h [12:53] configure:4967: gcc -E conftest.c [12:53] In file included from /usr/include/limits.h:26:0, [12:53] from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:169, [12:53] from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/syslimits.h:7, [12:53] from /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/limits.h:34, [12:53] from conftest.c:10: [12:53] /usr/include/features.h:330:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp] [12:53] configure:4967: $? = 0 [12:53] configure: failed program was: [12:53] | /* confdefs.h */ [12:53] | #define PACKAGE_NAME "" [12:53] | #define PACKAGE_TARNAME "" [12:53] | #define PACKAGE_VERSION "" [12:53] | #define PACKAGE_STRING "" [12:53] | #define PACKAGE_BUGREPORT "" [12:53] | #define PACKAGE_URL "" [12:53] | #define STDC_HEADERS 1 [12:53] | /* end confdefs.h. */ [12:53] | #include [12:53] configure:4967: result: no [12:53] I don't think we want to "fix" autoconf at this point [12:54] http://sourceware.org/bugzilla/show_bug.cgi?id=13979 <-- Was the upstream bug that led to the commit. [12:54] sourceware.org bug 13979 in libc "A warning should be issued if FORTIFY_SOURCE is requested but not enabled" [Normal,Resolved: fixed] [12:54] But yeah, revert that commit and see how it goes. [12:55] http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=05c2c9618f583ea4acd69b3fe5ae2a2922dd2ddc [12:55] so, yes commenting out this line fixes it [12:55] Alright. [12:56] Well, did you want to do the x32 bootstrap right now too? Uploading an eglibc/gcc pair with a bootstrap seeded would do the trick. === Ursinha_ is now known as Ursinha === Ursinha is now known as 36DACCO59 === Ursinha-afk is now known as 31NACBS8Z [12:57] I'll commit the revert of that commit to Debian and Ubuntu, if you're satisfied that it DTRT for you. [12:57] or ... adjust the gcc-default patch to only add it when optimizing [12:58] That would probably be more correct, but some people might be defining it themselves. [12:59] Well, I suppose if they are, that's what the warning is for, to be fair. [13:00] *shrug* I'm open to fixing it in both places, though the eglibc warning is clearly correct, I can see the argument that it's correctness that could cause a lot of annoyance. === 36DACCO59 is now known as Ursinha [13:27] I just noticed a nice side effect of uploading to -proposed is that now bugs get closed when I package is built, not when it's uploaded which to me seems more logical. [13:43] doko: So, are you going to fix gcc to DTRT here? I'm less concerned about the x32 bootstrap as (a) it's not a priority, and (b) we don't actually have kernel support for it right now, but we can certainly do the x32 bootstrap soon. [13:51] infinity, it's not that important that it needs to go in within the next hour. yes, I'm testing a fix [13:52] doko: Excellent. === Ursinha is now known as Ursinha-afk [22:32] infinity, gcc-4.7/eglibc now building on armel/armhf/powerpc. amd64 and i386 need one manual bootstrap. binaries for these builds can be found at [22:33] deb http://people.canonical.com/~doko/tmp/install-{amd64,i386} ./ [22:34] the gcc-4.7 build failures on armel, armhf, powerpc will be fixed once eglibc is built on these archs [22:35] doko: Hrm. I thought we weren't doing the bootstrap this weekend. [22:35] doko: (I also didn't think we were reverting that commit, in favour of just fixing gcc instead, but meh) [22:37] there will break too much without it, and no gcc will bootstrap without it [22:37] next time, just make sure that gcc still builds with an updated glibc ;-P [22:37] doko: And you didn't document the ln changes in sysdeps/ ... Was the s/-s/-sf/ actually necessary? (I didn't see any header breakage) [22:38] re-run the binary target [22:38] doko: Ahh. [22:38] and yes, there are other ln -sf calls [22:38] Alright, well, I guess we get to bootstrap right now. :P [22:39] the x32_RUN_TESTSUITE thing doesn't work as intended, but there's another consistency check before running the testsuite [22:39] The testsuite will fail miserably on the buildds, so here's hoping it doesn't run. [22:40] I did check it here [22:40] up to you if you disable the tests with nocheck for the bootstrap [22:47] infinity, is the missing -xmx32 in debian too? [22:47] -mx32 [22:48] Oh, whoops. Yep. I'll commit your changes to Debian in a sec. [22:48] Or you can, I suppose. [22:48] ok, I'll notice daniel about it [22:48] no [22:49] No? Kay, I'll do it. :P [22:53] afk now [22:55] infinity, once this is built, maybe we should rebuild everything which did get built against eglibc 2.16 (except gcc-4.7) [22:56] all libreoffice builds were started with 2.15, so that doesn't need an update [22:56] doko: If we can find evidence in build logs of features being turned off, maybe. [22:56] cheaper to just rebuild [22:57] basically I wouldn't trust any autoconf built package [23:04] doko: http://paste.ubuntu.com/1311032/ [23:04] Err, I should move that patch addition down to the doko block in the changelog. [23:05] doko: Otherwise, look good to you? [23:05] +#x32_RUN_TESTSUITE = no [23:05] this doesn't seem to work as intended [23:05] Oh. As in, not at all? :P [23:06] + * Fix building x32 miultilib libraries, by correctly passing -mx32. [23:06] typo [23:06] I was trying to be authentic! [23:07] elif [ $(call xx,RUN_TESTSUITE) != "yes" ]; then \ [23:07] echo "Testsuite disabled for $(curpass), skipping tests."; \ [23:07] echo "Tests have been disabled." > $(log_results) ; \ [23:07] else \ [23:07] then you would have used your version of the revert-bz13979.diff ;-P [23:07] You'd think that would work... [23:07] it didn't [23:08] according to the build log [23:08] Special. [23:08] I didn't care, because it did work anyway