=== doko_ is now known as doko
[03:07] <micahg> bryceh: I just a cursory review before, anyone could grab it, I said if I had time, I'd try to sponsor over the weekend
[03:49] <micahg> psusi: idr being asked about the lm-sensors merge, it's generally polite to ask the person who touched it last so as to not duplicate work
[03:55] <psusi> micahg, ohh, I didn't know that.. not done a merge from debian before...
[03:55] <micahg> psusi: yeah, this one wasn't on merges.ubuntu.com which has the notice on the top of the page, it's fine, I hadn't started, just had it on my to do list, glad to have you working on merges :)
[03:57] <psusi> micahg, I just noticed that sensors-detect still wasn't recommending the right module for my motherboard even though I know support for it got added upstream like 8 months ago, so I looked and noticed the ubuntu version was out of date and the debian one was newer so I went for it;)
[04:37] <broder> fyi, in case anybody's curious, here are the dependency_libs lines from all packages .la files that still have a non-empty one: http://paste.ubuntu.com/766579/
[04:41] <micahg> broder: you seem to have multiple entries that are the same on the list
[04:42] <broder> yeah, those are for different architectures
[04:42] <broder> here's one that's explicit: http://paste.ubuntu.com/766587/
[04:43] <broder> (it's only looking at i386 and amd64 because that's all i scan currently for lintian.uw.o)
[05:07] <infinity> doko: Yeah, so on powerpc and armhf, MySQL is still failing way too many tests in the testsuite with 4.6 compared to 4.5.  Unfortunately, it could take some serious effort to find the miscompilations, since the tests are more task-based than code-based, so it's kinda hard to tell at a glance which bits of code are to blame.
[05:07] <infinity> doko: (At least, for someone who doesn't know the code inside out, which I don't)
[05:08] <infinity> doko: Interestingly, on amd64, it fails no tests.  I guess we know what Oracle's test platform is. :/
[05:16] <micahg> infinity: would you mind if I grabbed the synaptic merge from you over the weekend?  you were TIL to drop a spurious dependency
[06:14] <micahg> cjwatson: can I grab reiser4progs from you?
[06:15] <broder> micahg: in the mood to look at sigc++? :)
[06:15] <micahg> broder: yeah, I guess I can do that :)
[06:16] <broder> there's more in that line of bugs, too, if you're interested - bug 902703
[06:16] <ubottu> Launchpad bug 902703 in atkmm1.6 (Ubuntu) "Please convert atkmm1.6 to multiarch" [Wishlist,New] https://launchpad.net/bugs/902703
[06:19] <broder> micahg: also, do you have the url handy for tumbleweed's udd sponsor/sponsoree report thing?
[06:20] <micahg> broder: http://ubuntu-dev.alioth.debian.org/cgi-bin/ubuntu-sponsorships.cgi
[06:20] <broder> thanks
[06:31] <micahg> broder: have you checked any of the reverse depends of the dev package of libsigc++-2.0?
[06:32] <broder> you mean to see if they still work?
[06:32] <micahg> yeah
[06:32] <broder> i've built some of the cairomm example programs with multiarched sigc++ + multiarched glibmm + multiarched cairomm
[06:33] <micahg> ok
[06:44] <micahg> broder: I'm tempted to wait until Sunday night to upload in case there are any issues, is that ok?
[06:44] <broder> that's fine. there's nothing urgent about the transition
=== tkamppeter__ is now known as tkamppeter
=== yofel_ is now known as yofel
[13:40] <mainerror> Hello.
[13:42] <mainerror> I'd like to give bug #893926 a shot but I'm not quite sure which IRC channel to join.
[13:42] <ubottu> Launchpad bug 893926 in eucalyptus (Ubuntu) "Contains traces of UEC" [High,Triaged] https://launchpad.net/bugs/893926
[14:13] <ScottK> mainerror: I'd ask in #ubuntu-server.
[14:18] <mainerror> Thanks ScottK!
[14:18] <ScottK> You're welcome.
[14:48] <infinity> micahg: You generally don't need to ask to hijack my TIL unless it's a package I actively work on. ;)
[15:02] <SpamapS> infinity: re mysql and gcc 4.6, its an open bug in MySQL that a certain code path segfaults when compiled w/ 4.6
[15:03] <SpamapS> doko: ^^
[15:04] <infinity> SpamapS: Which one, and where's the specific bug?  The bug I found earlier doesn't seem quite right.
[15:04] <infinity> SpamapS: (Also, the testsuite is flawless on amd64... I only got extra failures on powerpc and arm, so that might be a pointer to what they're doing wrong)
[15:04] <infinity> (Or to what GCC is doing wrong)
[15:06] <infinity> SpamapS: Ultimately, though, pushing bug to Oracle/MySQL on non-x86 platforms without a patch will just lead to said bugs rotting, in my experience.  If we want it to work on, say, ARM, we'll need to fix it ourselves.
[15:09] <SpamapS> yeah, the bug has no patch, let me look it up.. I thought it was in the changelog
[15:09] <infinity> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614044 ?
[15:09] <ubottu> Debian bug 614044 in src:mysql-5.1 "mysql-5.1-server: fails to build from source" [Grave,Fixed]
[15:10] <infinity> Err.
[15:10] <infinity> That was a Debian bug.  Not awake.
[15:10] <infinity> I swear I had an upstream one in my browser history..
[15:10] <SpamapS> http://bugs.mysql.com/bug.php?id=61509
[15:10] <infinity> http://bugs.mysql.com/bug.php?id=61509
[15:10] <infinity> Heh.
[15:11] <SpamapS> Thats the one that forced using gcc 4.5 ...
[15:11] <infinity> But, here's the thing.  That bug is old, stale, and wrong.
[15:11] <infinity> Since it talks about issues in YaSSL.
[15:11] <SpamapS> http://bugs.mysql.com/bug.php?id=62856
[15:11] <infinity> And the tests we're failing right now aren't.
[15:12] <infinity> http://bugs.mysql.com/bug.php?id=62856 isn't relevant, we still fail tests with that.
[15:12] <infinity> (Our current 5.5 has that patch)
[15:12] <SpamapS> I had the yassl tests fail with 4.6 just like 61509 said
[15:12] <infinity> On which platform?
[15:12] <SpamapS> amd64
[15:12] <infinity> Like I said, I have no tests failing on amd64 now.
[15:13] <infinity> And powerpc and arm are failing... Other tests.
[15:13] <SpamapS> Ok so maybe 4.6 was fixed?
[15:13] <infinity> Completed: All 1692 tests were successful.
[15:13] <infinity> ^-- amd64 build yesterday.
[15:13] <infinity> That said, armhf will still fail > 10 tests with gcc-4.6.
[15:13] <infinity> So, we still have bugs.
[15:14] <infinity> (It fails a few with 4.5 too, mind you, just fails "too many" with 4.6)
[15:15] <SpamapS> infinity: it seems things are quite different now than they were 3 weeks ago when I was working on this, so I don't know if I can offer much insight.
[15:15] <infinity> Fair enough.
[15:16] <infinity> I'm tempted to merge 5.5.19 before I do any more testing.
[15:16] <infinity> But I realy would like to get MySQL using the default toolchain somehow.
[15:20] <penguin42> is there a bug filed against the mysql failing on armhf with 4.6 ?
[15:26] <infinity> penguin42: Not yet, I just did the test build last night.
[15:27] <penguin42> infinity: Does armel work with 4.6 - i.e. is it an arm issue or an armhf specific issue?
[15:27] <infinity> penguin42: Not sure, haven't spun an armel test yet.
[15:28] <penguin42> nod; still failures on 4.6 will probably attract more interest than failures on 4.5
[15:32] <doko> I don't understand multiarch (on armhf):
[15:32] <doko> $ dpkg-architecture
[15:32] <doko> DEB_BUILD_ARCH=armhf
[15:32] <doko> DEB_BUILD_ARCH_OS=linux
[15:32] <doko> DEB_BUILD_ARCH_CPU=arm
[15:32] <doko> DEB_BUILD_ARCH_BITS=32
[15:32] <doko> DEB_BUILD_ARCH_ENDIAN=little
[15:32] <doko> DEB_BUILD_GNU_CPU=arm
[15:32] <doko> DEB_BUILD_GNU_SYSTEM=linux-gnueabihf
[15:32] <doko> DEB_BUILD_GNU_TYPE=arm-linux-gnueabihf
[15:32] <doko> DEB_BUILD_MULTIARCH=arm-linux-gnueabihf
[15:32] <doko> DEB_HOST_ARCH=armhf
[15:32] <doko> DEB_HOST_ARCH_OS=linux
[15:32] <doko> DEB_HOST_ARCH_CPU=arm
[15:32] <doko> DEB_HOST_ARCH_BITS=32
[15:32] <doko> DEB_HOST_ARCH_ENDIAN=little
[15:33] <doko> DEB_HOST_GNU_CPU=arm
[15:33] <doko> DEB_HOST_GNU_SYSTEM=linux-gnueabihf
[15:33] <doko> DEB_HOST_GNU_TYPE=arm-linux-gnueabihf
[15:33] <doko> DEB_HOST_MULTIARCH=arm-linux-gnueabihf
[15:33] <infinity> doko: What's there not to understand?
[15:33] <doko> ahh, you can just confuse dpkg by changing gcc, had a armel snapshot build installed and used
[15:34] <doko> no, not in this paste
[15:40]  * infinity wonders why we needed a bunch of uploads for an ocaml transition we did a month ago...
[15:42] <doko> vector-algorithm sync was needed. doesn't transition to testing, because vector and primitive are too new
[15:42] <infinity> That's haskell.  Though I'm almost as puzzled by those uploads too. :P
[15:42] <infinity> Ilya doesn't seem to be on IRC, or I'd ask him about both.
[15:43]  * infinity shrugs.
[15:45] <infinity> doko: Still planning on a binutils upload today before I merge eglibc?
[15:49] <doko> yes, should stop messing around with clang
[16:26] <doko> Laney, ocamlfind: Not supported in your configuration: ocamlopt
[16:26] <doko> Command exited with code 2.
[16:26] <doko> any idea why this fails on armhf, but not armel?
[16:44] <infinity> doko: Because ocamlopt needs porting.
[16:44] <infinity> doko: I've been talking to upstream about it.
[16:44] <doko> ahh, thanks
[17:24] <htorque> hello everyone! when trying to connect to my wireless AP i'm asked for the root password: http://img.xrmb2.net/images/508877.png
[17:25] <htorque> this happens after installing A1 without connecting to my AP during the installation process. against which package should i file the bug report?
[17:25] <htorque> (sorry if that's the wrong place to ask)
[17:26] <penguin42> htorque: #ubuntu+1 is the place for PP questions; but I'd go for ubiquity for all installation issues - althought hat looks Netowrk manager specific
[17:29] <htorque> penguin42: will try ubiquity then, thanks!
[21:05] <micahg> infinity: thanks
[21:07] <infinity> micahg: In fact, I'd go so far as to say "please, hijack my TILM on anything I'm not actively maintaining". :P
[21:08] <micahg> infinity: ok, will do :)
[21:25] <infinity> doko: Alright, your binutils is installed or accepted on all arches, I'll finish up the eglibc merge this afternoon/evening, so it's built by my Monday morning.
=== gord is now known as Guest35752
=== calc is now known as Guest67285