[02:48] <daker> hhh
[13:17] <cjohnston> mhall119: the new errors almost look like it could be coming from being iframed at connect.linaro.org
[13:40] <mhall119> ugh
[13:43] <cjohnston> mhall119: do you see anything; http://summit.ubuntu.com/uds-r/
[13:50] <mhall119> I see lots of things, anything in particular?
[13:53] <cjohnston> mhall119: http://ubuntuone.com/59F4PWNhP8kBYPZzmvSR4r
[13:53] <cjohnston> im not getting it everywhere
[13:53] <cjohnston> just on chrome
[13:54] <mhall119> shift-refresh, I think it's using cached css
[13:54] <cjohnston> i guess so
[13:54] <cjohnston> all better


[03:11] <ozanichkovsky> I have problem with loading LTSP client (Mounting /rofs on /root/rofs failed: Invalid argument)
[03:11] <ozanichkovsky> Is there anybody that can help me?
[03:26] <KillerPacMan> can somebody help me with an install of ubuntu?
[04:06] <johnny> ogra, what happens to the edubuntu chatroom after it's only an addon cd?
[16:53] <keit1> hi, i have ubuntu and xubuntu desktops on my machine, and was considering adding edubuntu. what would be the safest way?
[16:54] <keit1> or would it make more sense to simply add the packages i find useful to ubuntu
[21:04] <achandrashekar> Hello...I know its the weekend, but was hoping for some insight with setup related issues. I am trying to setup a lab which direly needs ldap authentication to manage accounts. Unfortunately I am running to into a klog daemon boot issue, which keeps my setup from moving forward. Can someone that is using ldap assist??
[21:06] <johnny> the people who know.. are not here :)
[21:06] <johnny> i told you this before :)
[21:06] <johnny> of course.. if i had that kinda setup, i would help
[21:07] <johnny> but i cannot afford it
[21:08] <achandrashekar> yeah...i appreciate it Johnny. I appreciate all the help provided thus far. It was "wishful" thinking that some of those people might be here during the weekend.
[21:08] <achandrashekar> ;)
[21:09] <johnny> i plan on getting such a setup one day..
[21:09] <achandrashekar> Ill be playing heavily with my setup today..So, the hope is, that Ill get it working. Ill post my findings if it works out.
[21:10] <achandrashekar> What I will do is likely NOT use the scripts provided by the samba-ldap script on their website and do it by hand.
[21:10] <achandrashekar> see if that works out.


[01:09] <Luie> hi
[01:09] <Luie> does anyone here mind answering a noob questino about ubuntu for me
[01:09] <Luie> *question
[12:13]  * MengXingHun is away: ^^^今天玩Linux游戏，暂不接客^^^^.....
[13:13] <jussi> MengXingHun: please dont do that.
[15:02] <joona> Hey, anyone here?
[15:12]  * MengXingHun is away: ^^^今天玩Linux游戏，暂不接客^^^^.....


[05:01] <Kilos> o/
[13:14] <pavlushka> Hello everyone :)
[13:33] <Kilos> hi pavlushka
[13:33] <u-la-la> Greetings! Kilos
[13:33] <Kilos> u-la-la hi
[13:33] <u-la-la> evening
[13:33] <pavlushka> Hello Kilos :)
[13:34] <Kilos> u-la-la coffee on
[13:34]  * u-la-la flips the salt-timer
[13:38] <u-la-la> Coffee's ready for Kilos!
[13:38] <Kilos> u-la-la ty
[13:38] <u-la-la> You are welcome my friend


[15:24] <hank> daily "unknown" update: still busted
[16:03] <ebarretto> hank, apparently the oval cve generation is quietly died on 8th of june, we will be investigating it. That's why you are still seeing the unknown
[16:12] <hank> ah, okay
[16:14] <hank> thanks
[19:44] <hank> looks like it's fixed, ty ebarretto et. al.


[17:32] <bdmurray> cjohnston: ^
[17:32] <cjohnston> I'm guessing the other cj, bdmurray ?
[17:33] <bdmurray> yes the one with a w - cjwatson
[17:34] <cjohnston> heh
[17:36] <cjwatson> ta
[17:37] <cjwatson> bdmurray: you didn't need to correct precise to precise-proposed :)
[17:38] <cjwatson> Laney: rejecting your software-center upload, but only in favour of bdmurray's which includes it
[17:38] <Laney> aye aye
[18:17] <Laney> I don't really know anything about udebs - how would I go about finding out why gtk+3.0 doesn't want to migrate?
[18:17] <Laney>     * i386: libgtk-3-0-udeb, libvte-2.90-9-udeb
[18:17] <cjwatson> Probably because the udeb is built with wayland support and the rest of wayland isn't udebificated
[18:17] <Laney> this upload was to disable that
[18:18] <Laney> and the wayland one did migrate
[18:18] <cjwatson> well, they have dependencies like any other package
[18:18] <cjwatson> those dependencies are only allowed to be satisfied by other udebs (i.e. */debian-installer/binary-*/Packages.gz)
[18:20] <infinity> Nah, it's because the udeb depends on libc6-udeb (>= 2.17)
[18:20] <infinity> It'll migrate shortly.
[18:20] <infinity> Why the udeb dependencies don't seem to use .symbols, I don't know.
[18:20] <cjwatson> Ah yes, it's made clear(ish) by _excuses
[18:20] <cjwatson> "Depends: gtk+3.0 eglibc"
[18:20] <Laney> ah, yeah, didn't look there
[18:20] <infinity> Are udeb deps not generated by dpkg-shlibdeps?
[18:21] <infinity> Cause the non-udeb packages depend on, like, libc6 (>= 2.4) or something.
[18:21] <cjwatson> They are, or should be
[18:21] <infinity> Seems silly that the udebs are much stricter.
[18:21] <cjwatson> But there's special udeb support in shlibdeps, and maybe glibc doesn't set it up quite right
[18:21] <infinity> Anyhow, mostly a non-issue, it'll migrate soon enough.
[18:22] <infinity> It's possible glibc has no idea how to do that correctly, yes. :P
[18:22] <Laney> Policy 8.6 says "Libraries with a corresponding udeb must also provide a shlibs file, since the udeb infrastructure does not use symbols files."
[18:22] <infinity> s/glibc has/I have/
[18:22] <cjwatson> Ah, heh
[18:22] <infinity> Right.  No symbols.  Check.
[18:22] <cjwatson> Probably nobody cares much
[18:22] <infinity> Hence the strict dep.
[18:22] <infinity> Not world-ending.
[18:22] <cjwatson> Since we don't need partial upgrade handling for udebs or anything
[18:23] <infinity> Laney: Anyhow, should migrate in this cycle, dante/armhf just lagged a tag.
[18:24] <Laney> Aye, ta.
[19:33] <smagoun> Hi, can we sneak a new gnome-settings-daemon into precise-updates? The package has been sitting in precise-proposed for >1 month. There is 1 bug listed in the SRU; I verified it today. Bug 1034090
[19:33] <ubot2> Launchpad bug 1034090 in gnome-settings-daemon (Ubuntu Precise) "Hotkeys not functional after upgrade to quantal's xorg (new xinput version)" [High,Fix committed] https://launchpad.net/bugs/1034090
[19:53] <infinity> smagoun: We're not past letting things into updates, don't worry.
[19:54] <smagoun> infinity: oh, I know. I will break out the big guns when I get really desperate: a free XPS 13 for each bug resolved :P
[19:55] <infinity> smagoun: Don't want one.
[19:55] <infinity> smagoun: Entice me with something with a Lenovo logo.
[19:55] <smagoun> infinity: X1 carbon?
[19:55] <infinity> smagoun: T430s, or a Carbon X1, maybe?
[19:56] <vanhoof> infinity: T40p
[19:56] <vanhoof> =P
[19:58] <micahg> infinity: I see my two SRUs never were accepted, I'm guessing it's too late, I guess I don't mind too much
[20:00] <infinity> micahg: Not too late, but if they're not installation/media/first-impression critical, it's not a big deal either way.
[20:01] <micahg> yeah, not needed for 12.04.2, I'll remove the milestones I added
[20:01] <davmor2> infinity: you want ideapad y580 you know you do
[20:02] <infinity> davmor2: Pretty sure I don't.
[20:02] <infinity> There aren't many laptops that are an upgrade to my T420s.
[20:02] <infinity> The T430s being one of the few. :P


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


[21:54] <Fallen> bdmurray: paride has a higher trust level, see https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ . From Matrix, popey has made it a wiki post, which allows TL2 to edit, which both others have.
[22:40] <bdmurray> Fallen: Thanks! Do you know what the alternative to a "wiki post"?
[22:41] <Fallen> For being able to edit other people's posts? Setting a higher trust level.
[22:41] <bdmurray> You said popey made it a wiki post what was it previously?
[22:41] <bdmurray> a personal post????
[22:43] <Fallen> Ah ok, sorry, misunderstood. I didn't actually see it before, but yes, the other type of post is simply a normal individual post. TL4 folks can edit other people's posts. If you want a post that is editable by many then a wiki post is the way to go
[22:43] <bdmurray> Understood, thanks!
[22:43] <Fallen> If you have TL3 you can turn posts into wiki posts