[04:04] <pitti> Good morning
[07:03] <sil2100> thomi: ping
[07:17] <popey> hmm. how do you manually attach a /var/crash/..crash report to a bug?
[07:17] <RAOF> Attach it as a file?
[07:17] <pitti> you don't
[07:17] <pitti> please, don't
[07:17] <popey> I have unpacked it, so have a bunch of files which may or may not be useful to the bug report?
[07:18] <popey> oh.
[07:18] <popey> is there nothing useful in there?
[07:18] <pitti> at least not the core dump
[07:18] <popey> there's no core dump
[07:18] <popey> and my bug is private
[07:18] <pitti> there might be some logs etc. which may be useful, but attaching a raw coredump into a bug makes things really hard for a triager
[07:18] <pitti> popey: oh, python crash?
[07:18] <popey> http://paste.ubuntu.com/5666792/
[07:18] <popey> rhythmbox
[07:18] <popey> thats all that it contains
[07:19] <popey> i woke to find it crashed and a dialog on my screen saying "Sorry the program 'Rhythmbox' closed unexpectedly
[07:19] <popey> Your computer does not have enough free memory to automatically analyse the problem and send a report to the developers"
[07:19] <pitti> ah, then it's useless anyway, as the core dump is too big and thus wasn't saved
[07:19] <pitti> but I get that crash, too
[07:19] <pitti> everytime a song ends, RB crashes in saucy
[07:19] <pitti> (if it's that crash)
[07:20] <popey> no, this is if it's left not playing overnight
[07:22] <popey> should I leave rb running overnight via gdb then get a backtrace the next day? Might be more useful?
[07:22] <seb128> good morning desktopers
[07:24] <didrocks> salut seb128!
[07:24] <seb128> lut didrocks ;-)
[07:25] <pitti> bonjour seb128, ça va ?
[07:26] <seb128> pitti, salut, oui, très bien (en dehors de la pluie), et toi ?
[07:26] <pitti> seb128: ça va bien ! (et encore soleil ici :) )
[07:27] <didrocks> pitti: fais attention, seb128 va t'envoyer de la pluie
[07:27] <didrocks> c'est ce qu'il s'est passé ici :(
[07:27] <didrocks> méchant seb128 :p
[07:28] <seb128> roooh
[07:36] <jibel> good morning
[07:38] <didrocks> hey jibel!
[07:40] <didrocks> seb128: FYI, I'm uploading that change: http://bazaar.launchpad.net/~webapps/webapps-applications/trunk/revision/534, it's going to be in binNEW
[07:41] <didrocks> seb128: the goal was to add a -dev package where every webapps script will depend upon (it's using a linter script with gjs which is in universe and the scripts are in universe)
[07:41] <jibel> salut didrocks
[07:41] <didrocks> so we can keep -common binary in main
[07:41] <didrocks> and have this new -dev binary in universe
[07:41] <seb128> didrocks, ok, makes sense
[07:42] <didrocks> seb128: just a preventive ping if you can review as I want to be able to run the webapps stack quickly then to get that sorted out :)
[07:42] <didrocks> seb128: thanks!
[07:42] <seb128> didrocks, will do
[07:42] <seb128> yw
[08:08] <Laney> morning!
[08:09] <seb128> Laney, hey, how are you?
[08:09] <Laney> strangely tired, but fine thanks
[08:09] <Laney> you?
[08:09] <seb128> I'm good thanks
[08:11] <seb128> shrug, I forgot about that
[08:11] <seb128> with the new glib, unity-panel-service segfault every time you close a win...
[08:12] <seb128> cyphermox_, ^ we need that libdbusmenu fix from charles merged and uploaded
[08:12] <seb128> didrocks, ^ for info
[08:12] <seb128> going to be fun for saucy users until it is :/
[08:13] <Laney> hmm, i don't see that
[08:14] <Laney> but anyway if it's that important then we can just upload it
[08:14] <seb128> Laney, it's not the end of the world, the service respawn, you just see the menubar be relocated to the app for a second and then be masked again
[08:14] <seb128> then you get apport to nag you
[08:15] <didrocks> seb128: we can just run libdbusmenu. If the indicator guys didn't want us to disable daily release because they are going to break trunk :/
[08:15]  * Laney is in the middle of being spammed by apport
[08:15] <Laney> arghghgh
[08:15] <seb128> new glib seems to also make tb unhappy
[08:15] <seb128> chrisccoulson, ^ did you notice?
[08:15] <chrisccoulson> seb128, i haven't upgraded yet
[08:15] <chrisccoulson> unhappy in what way?
[08:17] <seb128> chrisccoulson, http://paste.ubuntu.com/5666939/
[08:17] <didrocks> seb128: https://launchpad.net/ubuntu/saucy/+queue please ;)
[08:18] <chrisccoulson> seb128, g_menu_item_set_detailed_action ?
[08:18] <chrisccoulson> what code is calling this?
[08:18] <seb128> chrisccoulson, seems to come from libmessaging-menu
[08:19] <chrisccoulson> ah
[08:19] <seb128> so maybe a messaging menu issue
[08:20] <seb128> f***
[08:21] <seb128> chrisccoulson, tb lost my config/account :-(
[08:21] <seb128> when I start it now it gives me the "welcome to tb, do you want a new email"
[08:22] <seb128> didrocks, NEWed
[08:23] <didrocks> seb128: thanks!
[08:23] <seb128> didrocks, re: libdbusmenu, let's wait for cyphermox_, he put the merge on hold because there was a debug printf left in the MR
[08:23] <didrocks> right
[08:24] <chrisccoulson> seb128, what's in ~/.thunderbird and ~/.thunderbird/profiles.ini ?
[08:24] <seb128> $ ls ~/.thunderbird/
[08:24] <seb128> appreg            Crash Reports                  profiles.ini
[08:24] <seb128> baistreq.default  messagingmenu@mozilla.com.xpi
[08:25] <seb128> $ profiles.ini
[08:25] <seb128> [General]
[08:25] <seb128> StartWithLastProfile=1
[08:25] <seb128> [Profile0]
[08:25] <seb128> Name=default
[08:25] <seb128> IsRelative=1
[08:25] <seb128> Path=baistreq.default
[08:28] <Laney> I keep getting facebook "Success" pages opening in my browser
[08:28]  * Laney suspects UOA
[08:28] <seb128> that again?
[08:28] <Laney> again?
[08:28] <seb128> we had that last cycle at some point
[08:32] <Laney> seb128: can you reproduce it?
[08:32] <Laney> go to add a facebook account in UOA
[08:33] <seb128> I've on configured
[08:33] <Laney> yeah, just try to add a new one
[08:33] <Laney> happens the same for me anyway
[08:35] <seb128> Laney, can you ping mardy on #ubuntu-devel about it?
[08:35] <Laney> oui
[08:35] <seb128> 'ci
[08:35] <seb128> Laney, but yeah, it opens in firefox rather than embedded for me as well
[08:36] <seb128> Laney, I suspect fb server side changes
[08:37] <Laney> yeah, found this https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+bug/1132030
[08:37] <ubot2> Launchpad bug 1132030 in gnome-control-center-signon (Ubuntu) "Facebook account setup opens in external browser, unusable" [Undecided,Fix released]
[08:38] <seb128> Laney, that was the one from last time
[08:38] <Laney> yup
[09:19] <seb128> Laney, didrocks, chrisccoulson: just for info:
[09:19] <seb128> https://bugs.launchpad.net/indicator-messages/+bug/1180302
[09:19] <ubot2> Launchpad bug 1180302 in indicator-messages (Ubuntu) "hit SIGTRAP errors after glib 2.37 update" [High,New]
[09:20] <seb128> desrt_, larsu_: ^ hey, please have a look if you can, tb fails to start in saucy, issue with new glib/libmessaging-menu
[09:20] <seb128> well "fails to start", it hit that when I receive new messages, but it might be config dependant
[09:20] <seb128> desrt_, larsu_: it hits that error:
[09:20] <seb128> g_menu_item_set_detailed_action: Detailed action name 'mailbox:///home/user/.thunderbird/idprofile.default/Mail/pop.orange.fr/Inbox' has invalid format
[10:11] <Laney> seb128: would it be alright to promote libgee-0.8?
[10:11] <seb128> Laney, want to make it the default version?
[10:11] <Laney> not really, just updating libdmapsharing which deps on this series
[10:11] <seb128> wfm
[10:11] <seb128> we should make it default
[10:12] <seb128> but I want to check with mhr3 if that's ok with them before
[10:12] <Laney> it's got a renamed pcfile
[10:12] <Laney> so actual source changes to rdeps
[10:16] <Laney> seems like it's only for the testsuite anyway here, not at runtime
[10:33] <Laney> seb128: right, uploaded - it will depwait so promote when you're ready please
[10:35] <seb128> Laney, cool, will do in a bit
[11:08] <seb128> Sweetshark, hey, do you have a saucy libreoffice upload planned soon?
[11:11] <cyphermox_> good morning
[11:11] <cyphermox_> seb128: sorry, my intent wasn't clear
[11:11] <seb128> cyphermox_, hey
[11:11] <seb128> cyphermox_, how are you?
[11:11] <cyphermox_> I do mention there are debug stuff left in; but I don't usually block merges on that unles it was just a printf ;)
[11:11] <cyphermox_> not bad, not bad
[11:12] <cyphermox_> bright and early this morning :)
[11:12] <seb128> cyphermox_, nice
[11:12] <Sweetshark> seb128: why?
[11:12] <seb128> cyphermox_, well, new glib landed and unity-panel-service goes segfault everytime you close a win
[11:13] <seb128> cyphermox_, so we somewhat need that libdbusmenu to land in saucy sooner rather than latter if we can ;-)
[11:13] <Sweetshark> seb128: AFAIK there will need to be one as the foundation guys will break LO brutally with gcc and boost updates ...
[11:13] <cyphermox_> seb128: if the tests pass I'm happy to land it ;)
[11:13] <seb128> Sweetshark, because there is a poppler transition waiting to start and libreoffice will need a no-change-rebuild (or any other kind of upload)
[11:15] <Sweetshark> seb128: so, upstream releases are still a bit off. the gcc/boost stuff will happen first.
[11:15] <Sweetshark> seb128: xnox tweaked around with that in Oakland, I havent checked the current state there yet ...
[11:16] <seb128> Sweetshark, what about uploading 4.0.3 in saucy?
[11:16] <seb128> Sweetshark, did anyone try if that builds in saucy or did it get hit by toolchain changes already?
[11:22] <Sweetshark> seb128: not tried yet. It will shure be hit by the toolchain changes.
[11:23] <Sweetshark> seb128: there is little difference between 4.0.2/.3 wrt that.
[11:23] <seb128> shrug
[11:23] <seb128> so that poppler transition will be blocked on libreoffice to build with the new toolchain
[11:23] <seb128> is that something you are working on atm?
[11:34] <Sweetshark> seb128: no, I only came across that by accident. xnox is doing that on some private archives. We essentially agreed that xnox would upload a fixed LO with the toolchain changes and I would then merge them into the debian-SCM.
[11:34] <seb128> xnox, ĥey ;-)
[11:49] <dpm> hey seb128, regarding the https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind bp you were pinging me about yesterday, I don't think I'll be able to attend to the rescheduled session, as I need to be on the appdev track. But in any case, I think I was added to the blueprint by mistake
[11:50] <dpm> I know nothing about printing and I'm not sure how I could contribute to the discussion
[11:50] <seb128> dpm, hey, no worry, Till added the subscribers, I was just trying to get people to join if anyone was interested since nobody was there
[11:50] <seb128> dpm, ok, fair enough
[14:24] <xnox> Sweetshark: seb128: yeah, it started building but eventually failed. need to look more into it.
[14:25] <seb128> xnox, please let me know before uploading once you get it done
[14:26] <seb128> xnox, we have a poppler transition to do and it will need a no change rebuild from libreoffice to pick the new soname
[14:26] <seb128> xnox, so I would like to get poppler in first
[14:50] <dobey> Laney: hey, might you have a suggestion on how to actually test the software-center fix for upgrade to 13.04?
[14:54] <Laney> dobey: hmm, not so much, short of trying some dist-upgrades and hoping you can show that you could hit it before and not after
[14:54] <Laney> at least it should be possible to observe that it drops off with the new versions on errors
[14:56] <dobey> switch all the archives to raring on quantal, enable raring-proposed, and do dist-upgrade?
[14:58] <Laney> something like that
[14:59] <Laney> assuming you get the bug without the raring-proposed bit
[15:00] <dobey> did python-gi with the Breaks: for aptdaemon make it into -updates yet?
[15:01] <Laney> no, that needs to happen with s-c
[15:03] <dobey> hrmm?
[15:11] <Laney> you Break the older software-centers too
[15:12] <dobey> right
[15:12] <dobey> and that's also still in -proposed
[15:12] <dobey> so without -proposed, i expect the issue to happen more often than not (esp. given the e.u.c numbers)
[15:24] <hyperair> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1173886 <-- could someone tell me the reasoning behind hardcoding the colour of the nautilus tile?
[15:24] <ubot2> Launchpad bug 1173886 in nautilus (Ubuntu) "Wrong background colour for nautilus icon in Unity launcher" [Undecided,New]
[15:24] <hyperair> before i get to work purging said patch
[15:25] <seb128> because the automatically picked color was not working well and nobody had time to do the proper fix which is to include that color info with the icon theme
[15:25]  * hyperair facepalms
[15:26] <hyperair> you know, if you shipped some icon metadata along with the specific icon that hinted to unity what the tile should be, that's one thing, but this is rather ridiculous.
[15:27] <hyperair> now i either have to 1) live with it, 2) run a patched nautilus, 3) dpkg-divert the desktop file, or 4) fork the desktop file into ~/.local/share/applications
[15:27] <seb128> read the comments on bug #1081691?
[15:27] <ubot2> Launchpad bug 1081691 in Ayatana Design "Launcher - Update the icons used for the Software Centre, Nautilus, and Software Updater" [Medium,Fix committed] https://launchpad.net/bugs/1081691
[15:28] <seb128> see e.g my comment #23
[15:29] <seb128> but it's only a color and most users don't change their icon theme
[15:29] <seb128> so it's a pretty minor issue and optimize for the most common case
[15:30] <hyperair> i can't help but wonder how many users actually customize their desktop theme..
[15:30] <seb128> a small % for sure
[15:30] <seb128> we don't even provide an ui to do that
[15:30] <seb128> we being GNOME or Unity
[15:31] <hyperair> we don't provide a ui to do that == let's trample all over the dconf settings because we don't give a f___
[15:31] <TheMuso> I get the feeling that all OSs are generally moving away from allowing customization. Hell one can't really customize IOS beyond text size for accessibility reasons...
[15:32] <hyperair> seb128: also i can't help but note the distinct lack of response to #23.
[15:32] <seb128> right
[15:32] <seb128> I agree to patch those icons as a workaround for raring
[15:32] <seb128> but only that
[15:33] <hyperair> okay, at least we live with a temporarily broken solution.
[15:33]  * hyperair sighs
[15:33] <hyperair> how about sticking metadata into the icons themselves to tell unity what colour it should use?
[15:33]  * hyperair wonders if anyone has tried that.
[15:38] <hyperair> ah, i see that icon metadata was mentioned in bug #962120
[15:38] <ubot2> Launchpad bug 962120 in Unity "Launcher - Add API to allow apps to override the Launcher tile colourisation with a colour of their choosing" [Medium,Fix released] https://launchpad.net/bugs/962120
[15:38] <hyperair> but https://bugs.launchpad.net/ayatana-design/+bug/962120/comments/4 picked the .desktop approach instead
[15:38] <hyperair> gekker, eh..
[15:38]  * hyperair polishes the kitchen knife
[15:47] <Sweetshark> xnox: thx. can I help out there somehow, or is it a mess to get that environment set up?
[15:49] <xnox> Sweetshark: it's not a mess =) but I should push "my current state of the art somewhere"
[16:06] <desrt_> Laney: rumour has it i owe you a beer :)
[16:07] <desrt> (for tricking seb)
[16:07] <Laney> the anti-thunderbird crew
[16:08] <desrt> larsu already cooked a fix
[16:08] <desrt> it's trivial
[16:08] <Laney> some mangling of the id?
[16:09] <desrt> that's what he was going to do
[16:09] <desrt> then i reminded him that he's using the wrong API in the first place
[16:09] <Sweetshark> xnox: yes, please do ;)
[16:09] <desrt> the detailed action parsing only applies if you use an API that takes detailed action names
[16:09] <desrt> which he should not have been doing, since there is no possibility of a target
[16:11] <desrt> it would have caused problems before if someone used an action with a '::' in the name
[16:11] <desrt> but now it's fixed properly
[16:14] <Laney> great
[16:16] <larsu_> Laney, cyphermox, seb128: patch is here: https://code.launchpad.net/~larsu/indicator-messages/lp1180302
[16:16] <desrt> see https://bugzilla.gnome.org/show_bug.cgi?id=700398
[16:16] <ubot2> Gnome bug 700398 in gapplication "Warn about detailed_action parameters" [Enhancement,New]
[16:16] <seb128> larsu_, great, thanks
[16:16] <desrt> this bug is about the trap that larsu fell into
[16:17] <seb128> larsu_, I'm in a vUDS session atm but will try as soon as it's over
[16:17] <desrt> seb128: bonjour de montréal!
[16:18] <seb128> desrt, bonjour de france ;-)
[16:18] <desrt> oh.  you're visiting france today? ;)
[16:24] <larsu_> seb128: tested on cyphermox's machine. Thunderbird is still rnuning..
[16:25] <cyphermox> as opposed to crashing without touching anything, yeah, it's improved
[16:26] <larsu> :)
[16:28] <Laney> cyphermox: can you get it uploaded to saucy?
[16:30] <cyphermox> yes, will do it
[16:31] <Laney> bonus
[16:33] <cyphermox> moo?
[16:44] <desrt> seb128: so.... this g_error() in GMenu should have been a g_critical()
[16:44] <desrt> but......
[16:44] <desrt> i want fatal criticals
[16:44] <desrt> but.......
[16:44] <desrt> only for developers
[16:44]  * larsu blames this whole bug on desrt now!
[16:44] <desrt> so i have an idea i want to bounce off of you
[16:44] <desrt> which is that we turn criticals fatal only if we find glib.h is installed
[16:44] <desrt> ie: if you install -dev packages, you get fatal criticals
[16:45] <desrt> this is a good way to ensure our developers are fixing problems properly while not hurting "normal users"
[16:53] <desrt> could also base it on the -dbg/-dbgsyms package being installed
[17:00] <seb128> desrt, sorry, I was in an hangout
[17:00] <seb128> desrt, well, devs can optin easily by setting an env variable
[17:00] <desrt> seb128: but nobody does.... we need a good 'automatic' hook
[17:01] <seb128> there is no good automatic
[17:01] <desrt> another possibility that i consider: if your session crashes as the result of a fatal critical, we give you the option to login again with fatal criticals disabled
[17:01] <desrt> so that people don't get 'stuck'
[17:02] <seb128> like making your shell or im client or email client not start is going to make you not able to get work done and you are not the one who is going to fix those in most cases
[17:02] <desrt> well
[17:02] <desrt> look at what happens today
[17:02] <desrt> i use g_error() because everyone ignores criticals
[17:02] <desrt> then _everyone_ suffers
[17:02] <seb128> everyone running unstable
[17:02] <larsu> you shouldn't have used g_error...
[17:02] <seb128> which is probably close from the set of those having -dev installed
[17:03] <desrt> larsu: i shouldn't have to contend with a log file full of ignored criticals
[17:03] <desrt> seb128: not toward the end of the cycle...
[17:03] <desrt> seb128: i'd still support an opt-out
[17:03] <desrt> G_DEBUG=not-fatal-criticals or so
[17:03] <desrt> so people could easily work around
[17:03] <desrt> anyway... cyphermox wants lunch now
[17:03] <seb128> I think it's a social issue more than a technical one
[17:04] <desrt> time to go :)
[17:04] <seb128> the people who care should opt in
[17:04] <desrt> seb128: i agree.
[17:04] <seb128> desrt, enjoy!
[17:04] <desrt> but ya... bye :)
[17:06] <larsu> from desrt: the people who don't care, are the ones who cause the problems. And then the people who do care, and opt-in, are not the best people to fix the problems
[17:06] <larsu> if everybody was automatically opted in, then there wouldn't be a problem
[17:06] <seb128> larsu, a discussion to have over beer
[17:07] <seb128> larsu, I blame you and desrt for not doing opt-in, it's a bug in your code, you should have noticed it :p
[17:07]  * seb128 hides
[17:07] <seb128> larsu, and go for lunch before you all starve in front of your keyboards ;-)
[18:05] <desrt> seb128: it's an integration problem -- nobody's fault and everybody's fault, as usual
[18:19] <didrocks> robru: did you poke the archive admins about reviewing the packages in NEW?
[18:19] <didrocks> robru: https://launchpad.net/ubuntu/saucy/+queue
[18:20] <robru> didrocks, nope... in a vuds session though brb
[18:20] <didrocks> seb128: you can't talk, do you have time? they should be easy ^
[18:20] <didrocks> :)
[18:20] <seb128> didrocks, suuuure
[18:20] <seb128> ;-)
[18:20] <didrocks> thanks!
[18:28] <seb128> didrocks, hum, first on I review (unity-webapps-googleplusgames), copyright has:
[18:28] <seb128> "Files: */*.png */*.svg
[18:28] <seb128> Copyright: various
[18:28] <seb128> License: trademark-controlled"
[18:28] <seb128> which is weird
[18:28] <seb128> since the source has no such files
[18:28] <didrocks> seb128: I guess this is for robru ^
[18:28] <seb128> could be
[18:28] <didrocks> seb128: it's all robru's, I think he's going to fix all those ;)
[18:28] <seb128> I guess that's not a stopper
[18:29] <didrocks> yeah, it's weird
[18:32] <seb128> hum, -amazon lacks a COPYING (not blocker)
[18:33] <seb128> -yandexmusic
[18:33] <seb128> Files: debian/*
[18:33] <seb128> Copyright: 2012 The friendly pkgme.net robot
[18:33] <seb128> License: public-domain
[18:33] <seb128>  
[18:33] <seb128> lol ;-)
[18:35] <seb128> same for -wordpress
[18:40] <didrocks> I think robru isn't done with webapps yet :p
[18:43] <seb128> right
[18:43] <seb128> didrocks, accepted indicators-client though
[18:43] <didrocks> seb128: thanks!
[18:43] <seb128> yw
[18:45] <seb128> ok, newing the webapp ones, the issues I listed before are not stoppers but would be nice to fix
[18:45] <seb128> robru, ^
[18:48] <robru> seb128, didrocks: don't look at me! this is how I inherited it from alex-abreu
[18:48] <didrocks> robru: we are *staring* at you!
[18:48] <alex-abreu> noooo
[18:48] <alex-abreu> robru, don't do finger poiting :)
[18:48] <alex-abreu> pointing
[18:49] <robru> seb128, which apps did you find had copyright files that referenced files that don't exist?
[18:49] <robru> just googleplusgames?
[18:49] <seb128> robru, no, the 5 I just newed
[18:49] <seb128> I guess the copyright is all coming from the same original source
[18:49] <alex-abreu> robru, seb128 we should review those and update the license indeed
[18:50] <alex-abreu> seb128, yeah, it was done a bit too fast there
[18:51] <alex-abreu> robru, I think that's why (at the time) I didn't include some webapps ... (e.g. g+ games)
[18:51] <robru> alex-abreu, this should be your motivation to fix them all ;-)
[18:51] <alex-abreu> *my* ? :) ... yeah send me a list and I can have a quick look
[18:52] <seb128> cyphermox, how is the indicator-messages landing going?
[18:52] <alex-abreu> feel free to share the "burden"
[18:52] <cyphermox> just about done
[18:53] <seb128> cyphermox, \o/
[18:53] <cyphermox> seb128: it's standard jenkins/autopilot delayu
[18:53] <cyphermox> as soon as it fails I'll publish
[18:54] <seb128> cyphermox, no worry, I'm just making sure it lands today so people have their email client back to be working tomorrow
[19:10] <cyphermox> yes, I want to land today but I didn't want to disable autopilot in case we could actually have successful results eventually
[19:10] <cyphermox> it looks like ATI might not fail this time
[19:10] <cyphermox> so I'm just waiting to see what the results will be
[19:10] <cyphermox> seb128: ^
[19:12] <seb128> cyphermox, ok, as long as it's built by tomorrow morning I'm happy ;-)
[20:49] <mterry> ChrisTownsend, so I'm testing your Ubuntu One patches to duplicity for inclusion in saucy/raring
[20:50] <mterry> ChrisTownsend, they don't seem to change anything.  I still get 500 errors
[20:51] <ChrisTownsend> mterry: Well, it doesn't address the real problem of why errors are occurring, it just gives it a chance for the retries to actually work by resetting the file pointer back to the beginning of the file.
[20:51] <ChrisTownsend> mterry: I'm not sure why the errors occur.
[20:52] <ChrisTownsend> mterry: Before, the retries would always fail because of the file pointer.
[20:52] <mterry> ChrisTownsend, OK.  But you made it sound like usually retrying will allow DD to continue, but I'm still reliably getting the error.  This is on GET requests
[20:53] <ChrisTownsend> mterry: I was reliably getting 404 Bad Request errors on retry.  Now it works mostly better, but I have seen the retries even fail on occasion.
[20:53] <ChrisTownsend> mterry: So my fix supposedly addresses those 404 errors by resetting the file pointer and resending out a good request.
[20:54] <ChrisTownsend> mterry: Perhaps we should still have the U1 team involved on why other errors are occurring???
[20:55] <mterry> ChrisTownsend, maybe... but I still suspect it's something we're doing client-side, since only 13.04 shows the bug
[20:56] <mterry> ChrisTownsend, maybe we're signing the oauth stuff bad or something like that
[20:56] <ChrisTownsend> mterry: Hmm, yeah.  About 95% of the time now, I can get through a backup now where before, it would always fail.
[20:57] <ChrisTownsend> mterry: So you said you see 500 errors and not 404's?
[20:57] <ChrisTownsend> mterry: Probably more than one bug on this one.
[20:58] <mterry> ChrisTownsend, mine are 500s yeah
[20:58] <mterry> ChrisTownsend, will look into it my 500s
[20:59] <ChrisTownsend> mterry: That's a generic Internal Server Error which is different than what I was chasing.
[20:59] <ChrisTownsend> mterry: Cool, let me know if I can help anymore.
[21:51] <sil2100> thomi: ping!
[21:51] <sil2100> thomi: hi!
[21:51] <sil2100> thomi: so, actually even after merging in my branch, there are still around 10 failures in autopilot
[21:51] <sil2100> thomi: https://code.launchpad.net/~autopilot/autopilot/more_ap_ap_test_fixes/+merge/164037
[21:52] <sil2100> Here's a branch in progress that we can co-work on, the description has the path to the latest AP run with my merges merged in
[21:52] <sil2100> thomi: you think you could find some time to look at those fixes, add them to this branch and maybe even get it all reviewed?