[09:42] <doko> slangasek, infinity: verfication now done for https://launchpad.net/bugs/1311866
[09:42] <ubot93> Launchpad bug 1311866 in gcc-4.8 (Ubuntu Trusty) "update binutils and GCC for trusty" [Wishlist,Fix committed]
[14:10] <hallyn> hi - qemu wily package needs approval of some new binary pkgs
[15:04] <Laney> stgraber: how do I configure release managers in the iso tracker?
[15:09] <Laney> oh, bah, are you off today? :)
[19:03] <hallyn> Laney: is approving the new wily qemu packages something you can do?
[19:04] <infinity> hallyn: I can look.
[19:04] <hallyn> thanks!
[19:05] <infinity> hallyn: libacard (and related) and qemu-block-extra?
[19:05] <infinity> hallyn: I assume/hope these changes are in sync with Debian, not us going out on a limb?
[19:06] <infinity> hallyn: Okay, answered that one myself from the Debian changelog.
[19:07] <infinity> hallyn: Looks like you probably want to merge -5 for the security fixes, though. :P
[19:07] <hallyn> infinity: yeah...  actually i'm assuming mdeslaur wanted to push patches for those, which is why i wnated to get this cleared
[19:07] <hallyn> but i can just merge the next version right now from debian too
[19:08] <infinity> hallyn: Kay, just doing a quick binNEW review here.
[19:11] <infinity> hallyn: Accepted.
[19:11] <hallyn> thanks
[19:11] <hallyn> hm, -5 is not in debian's git
[19:12] <infinity> hallyn: Manual merge and resolve it later? :P
[19:12] <infinity> (Or yell at mjt to push his branch)
[19:13] <hallyn> starting with 2 and then doing 1 :)
[19:34] <hallyn> infinity: pushing the new merge now
[19:35] <infinity> hallyn: Shiny.
[19:35] <infinity> hallyn: Ahh, I see you got mjt to push git. :)
[19:36] <hallyn> yup :)  was a refreshingly simple merge.  (jinx)
[20:36] <mdeslaur> grr...dist-upgrading a freshly installed trusty fails
[20:36]  * mdeslaur will research and file a bug tomorrow
[21:35] <infinity> mdeslaur: There's already a bug.
[21:35] <infinity> mdeslaur: Assuming this is what you're seeing: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1452238
[21:35] <ubot93> Launchpad bug 1452238 in apt (Ubuntu) "Failed to upgrade system from 14.04" [Undecided,Confirmed]
[22:19] <mdeslaur> infinity: ah, yes, that's the issue, thanks
[22:21] <mdeslaur> infinity: I think that's the issue people with brand new Dell XPS 13s are hitting too
[22:22] <mdeslaur> infinity: it's a pretty bad issue...is anyone actively working on it?
[22:27] <infinity> mdeslaur: Other than commenting on the bug, I haven't looked too deeply, but I'm guessing it can be worked around per my last comment.  Would be nice if someone found the time to experiment.
[23:27] <mdeslaur> infinity: ack. adding to my to-do list
[23:27] <mdeslaur> infinity: right after the glibc tzdata regression
[23:28] <infinity> mdeslaur: Oh man, I completely forgot about the tzdata thing.  I'd really like to understand that one.
[23:28] <mdeslaur> infinity: did you see the bug with the reproducer?
[23:28] <mdeslaur> infinity: I have a test build in a ppa with the commit reverted, I need to upload tzdata to it and test further
[23:28] <infinity> mdeslaur: I wonder if it's something as simple as building on a 64-bit system produces unportable results, but 32-bit is fine (given that vivid was when we switched from i386 to amd64 for arch:all)
[23:29] <infinity> mdeslaur: Bug number?
[23:29] <mdeslaur> infinity: nah, I thought about that, but the tzdata where it worked was built on amd64
[23:29] <mdeslaur> infinity: bug 1462052
[23:29] <ubot93> bug 1462052 in glibc (Ubuntu) "timezone handling regression in glibc 2.21" [Undecided,New] https://launchpad.net/bugs/1462052
[23:30]  * mdeslaur uploads tzdata to ppa
[23:30] <infinity> mdeslaur: Oh, I think I pointed you at that commit.  That's not exactly an isolation of the problem. :P
[23:31] <mdeslaur> infinity: I only reverted the zic part of the commit...just for confirmation
[23:32] <mdeslaur> I can't build glibc locally for some reason, the test suite fails, which is why I put it in a ppa
=== wgrant_ is now known as Guest53475
[23:33] <infinity> mdeslaur: Are you building on an overlayfs schroot?
[23:33] <infinity> mdeslaur: There's a test that fails on overlayfs.
[23:34] <mdeslaur> infinity: oh, yeah, I am
[23:35] <mdeslaur> infinity: I'm doing this in between the zillion security updates I work on as my day job, so it's taking a while :P
[23:36] <infinity> mdeslaur: Right.  Well, if reverting that "fixes" it, that's a start, but it's not a reasonable fix.  So, more digging required.
[23:36] <mdeslaur> no, not a reasonable fix at all
[23:36] <mdeslaur> my next step was to see if updating to the latest tzcode fixes it
[23:36] <mdeslaur> there's a lot of fishy things in that commit
=== Guest53475 is now known as wgrant__
[23:37] <infinity> mdeslaur: There are definitely a lot of places where wordsize looks like it could come into play.
[23:38] <mdeslaur> I'm just trying to confirm that commit so I know I'm looking in the right place
[23:38] <infinity> mdeslaur: But it's still weird that it's producing data files that then get misinterpreted on load.
[23:38] <mdeslaur> yeah, quite weird
[23:38] <infinity> mdeslaur: Dumping a working and non working zone and comparing them might be interesting.
[23:38] <mdeslaur> I tried that
[23:38] <mdeslaur> but it's like 100% different :(
[23:39] <mdeslaur> well, actually, I haven't tried dumping the same version of tzdata
[23:39] <mdeslaur> but the one I just uploaded to the ppa will allow me to do just that
[23:39] <mdeslaur> I tried comparing utopic with vivid
[23:39] <mdeslaur> and that was too different
[23:40] <mdeslaur> anyway, more tests tomorrow
[23:40]  * mdeslaur -> away