[02:39] Hm. indicator-datetime-service appears to have spawned hundreds of threads and has a VIRT size of 8.5GiB. That's odd :) [02:39] \o/ [04:29] Good morning [04:36] Howdie! [05:21] good morning [07:19] good morning everyone [07:20] hey hey chrisccoulson, how are you? [07:22] hi didrocks, i'm good thanks. although, i feel like i've been hit by a bus this morning (too much sun this weekend) [07:22] how are you? [07:25] pitti: How hard would it be for an apport package hook to take the core file apport has collected and strip off the top couple of frames to get the real cause? [07:26] chrisccoulson: ahah, sun, not used to it, isn't it? :) [07:26] chrisccoulson: I'm feeling good, making the gconf -> gsettings transition in gnome-control-center for unity settings [07:26] didrocks, yeah, this was the first dry weekend for a while, so i made the most of it and destroyed our garden ;) [07:26] RAOF: apport actually already does that for a few well-known cases (error messages in glib and libX11) [07:27] pitti: Hm. Because the X server already has a mechanism to dump core on crashes, but it calls abort() rather than dying with the signal that actually caused the problem. [07:28] RAOF: hm, we have had a patch for that for years; did that broke again? [07:28] i. e. that it re-raises the same signal that it caught [07:29] pitti: Yeah, we've got that; it's always seemed a bit flaky. There appear to be a lot of X crashes that don't trigger apport. [07:29] RAOF: so in principle, a package hook can run whatever it wants on the already existing fields, such as Stacktrace and Core dump [07:30] I'm hoping to use the build-in "always dump me a core" stuff and then post-process; this way, the failure mode should be "the bug has an unuseful title" rather than "the bug doesn't get filed" [07:30] RAOF: the current unwinding logic is in apport/report.py, _gen_stacktrace_top() FYI [07:30] but I guess that's not doing what you need ATM [07:31] It's probably pretty close. [07:31] RAOF: so what is the actual problem? X.org doesn't dump core, or the core dumps are useless? [07:31] X.org doesn't dump core. [07:31] but then apport won't help you [07:31] X.org doesn't drop core *with our patch* [07:32] (Sometimes!) [07:32] There's an upstream mechanism to get it to dump core on crashes, though. [07:33] i. e. we should use that instead of our "re-raise" patch? [07:33] I'm hoping¹ that will be more reliable, and then I can post-process the core we get to get the right signal out of it for the bug title. [07:34] ¹: For values of "hoping" which include "am modifying some drivers to SIGSEGV to see if our existing stuff catches it and test". [07:34] Yeah, that's it. Use the upstream support instead of our re-raise patch. [07:38] RAOF: does that do some manual black magic to generate a core file, or just signal-exists properly, so that the kernel writes it? [07:38] Signal exits properly. [07:38] in the latter case, apport will just work, as it is a core dump handler [07:38] *phew* [07:38] Yeah. [07:38] so yes, this sounds like the proper upstream replacement for our patch [07:39] It calls abort(), so it'll not be obvious what signal actually killed the server. [07:39] RAOF: the hook can set report['Title'] and/or a DuplicateSignature [07:39] But that will be extractable from the trace. [07:39] RAOF: hm, that seems rather pointless -- could we perhaps patch that to re-raise the same signal it got, instead of always SIGABRT? [07:40] that would at least be an one-line patch which also sounds upstreamable [07:40] abort() is nothign else than raise(SIGABRT), after all [07:40] Hah. One line? You underestimate the convolutions X has in even its crash paths! [07:41] pitti: Really? I was under the impression that abort() was a bit more than that; specifically, that it'd do the requisite signal fiddling to ensure the process *actually* died as a result? [07:41] you mean it uses the signal number to decide whether it re-installs its own signal handler!? [07:41] that would be really bad and sick, and I can't believe it does that -- you'd get infinite recursion very easily otherwise [07:42] RAOF: it can't ensure that [07:42] RAOF: if you install a signal handler for SIGABRT, it'll just call that [07:42] the only way to ensure that you die is to send SIGKILL [07:43] a process which wants to do stuff when it dies, should register a signal handler [07:43] It has a generic signal handler, which then calls out to the registered handler; there's special code in the crash paths to bail if they get recursively called. [07:43] and when it's caught, do its stuff (logging, etc.), restore the original handler, and re-raise [07:44] restoring the original signal handler is the very first thing it ought to do to ensure it doesn't recurse [07:46] Yeah, that's not what X does (in any of the places where its signal handler gets funned. [07:48] RAOF: so it does not install a signal handler for SIGABRT, and uses abort() as the signal to actually core dump, while all other signals are being caught? [07:49] then we indeed need to fix it in the report [07:49] Pretty much, yes. [07:49] (or fix the hanndler) [07:49] it's stunning that it doesn't intercept and log SIGABRT [07:49] The handler is a surprising amount of effort :) [07:49] after all, this is _the_ signal for catching assertions [07:50] so they wouldn't do any logging for assertions [07:51] They don't assert [07:51] RAOF: btw, if you want to fix this in the package hook, can you please make this conditional on the package name? there are a million symlinks to source_xorg.py also for client apps which should not do that signal name fuzzing [07:51] like source_xterm.py [07:51] Yup. [07:51] thanks [07:51] so, good luck! please let me know if you have questions about how to do thaht [07:52] SIGSEGV, SIGQUIT, SIGILL, SIGFPE, SIGBUS, SIGSYS, SIGXCPU, SIGXFSZ. These are the signals X will catch for you! [07:53] RAOF: how does the server handle assertions then? or doesn't it have any? [07:54] It does have some; it just dies. [07:55] And leaves you with whatever hardware state you happened to be in at that point. [07:58] RAOF: hm, and as it doesn't trigger the logging code, you wouldn't ever know what the assertion actually was, I suppose? [07:58] well, we would now with apport [07:58] but I wonder why upstream chose to implement it in this way [08:00] Because X is a gigantic pile of hysterical rasins just waiting to spontaneously combust. [08:00] this of course is a fully convincing argument :) [08:09] morning! [08:09] hey desktopers [08:09] salut seb128, hey Laney [08:09] salut seb128, ca va didrocks [08:10] hey Laney, how are you? [08:10] yeah great! Spent the weekend camping + volunteering [08:10] the sun came along for the trip, too [08:10] guten morgen pitti [08:11] hey didrocks, Laney, pitti ... how are you? [08:11] seb128: quite fine, thanks! [08:11] seb128: I'm fine, thanks! yourself? [08:11] I'm good thanks! [08:12] * didrocks scratches his head on undefined symbol: gnome_rr_labeler_get_color_for_output got when rebuilding g-c-c [08:12] and not in the version in quantal, there is no static build though? [08:13] ah, seems bug #1011056 [08:13] Launchpad bug 1011056 in gnome-control-center "Display applet will not run (undefined symbol: gnome_rr_labeler_get_color_for_output)" [High,Fix released] https://launchpad.net/bugs/1011056 [08:14] hum, why it's not in bzr? [08:14] * didrocks tries to pull again [08:14] we updated bzr to 3.5.x [08:14] should probably revert that if we're going to stay with 3.4 [08:14] same with gsd [08:14] Laney: hum, we can just have another branch [08:14] and then merge back [08:15] as I'm making the changes for g-c-c and compiz gsettings [08:15] I prefer to not mix with 3.5.x :) [08:15] yes [08:15] i think it's likely we won't take those updates [08:15] yeah [08:15] so i would revert the official branch to 3.4 and push 3.5 somewhere else [08:15] crack-heaven [08:16] ok, so I need to bundle back all changes made as well [08:16] for 3.4 [08:16] * didrocks pushes to lp:~ubuntu-desktop/gnome-control-center/3.5 [08:17] i'll do same for gsd [08:19] go go go :) [08:25] Anyone around that could check https://bugs.launchpad.net/ubuntu/+source/colord/+bug/1021374 ? Crashing at every boot :( [08:25] Ubuntu bug 1021374 in colord "colord crashed with SIGSEGV in cd_device_register_object()" [Medium,Confirmed] [08:35] * didrocks bzr push --overwrite to g-c-c [08:35] moin all! [08:35] hey Sweetshark [08:36] seb128: libreoffice 3.6.0 rc2 finished in proposed and looks good after some basic testing on i386. [08:36] didrocks: heya! [08:36] ok, display switched for gsettings compiz support [08:36] Sweetshark, hey, happy monday! had a good w.e? [08:36] now, backgound panel :) [08:36] * Sweetshark survived falling out of a plane at 4000m altitude on Saturday. [08:36] dupondje, did you try to report it upstream? [08:37] Sweetshark, you do skydiving? [08:37] seb128: ... and the best think about the rc2 package is: it also build on armhf, armel. [08:38] Sweetshark, yeah, it built everywhere and it has been copied to quantal proper [08:38] seb128: not regulary (yet). I did a tandemjump. was much fun. [08:39] seb128: oh, its already copied? way cool! [08:39] seb128: no, been to lazy ... :) should do that indeed [08:39] but I see there is new upstream version also [08:39] so maby we need to test that first :) [08:40] dupondje, try talking to RAOF when he's around, he's the closest from a colord maintainer for Ubuntu [08:41] Sweetshark, yes ;-) [08:41] libreoffice and webkit built everywhere and got copied [08:41] seb128: i'll do, he's maintainer in debian of it it seems :) [08:41] right [08:42] probably wouldn't [08:42] erm... wouldn't be too hard to do a local build of it yourself to test [08:43] true :) this evening maby, when i'm on my quantal pc :) [08:44] https://bugs.freedesktop.org/show_bug.cgi?id=51031 [08:44] Freedesktop bug 51031 in daemon "segfault at cd_device_register_object()" [Normal,New: ] [08:59] hey seb128, how are you? [09:07] didrocks: is this gsettings migration stuff landing soon? Otherwise I'd like to upload gsd with some other fixes [09:14] chrisccoulson, hey, welcome back! I'm good thanks, how are you? [09:16] Laney: today (tomorrow at the latest) [09:16] ok, leaving it then [09:16] Laney: as you wish for gsd, just please don't touch g-c-c :) [09:16] the beast is yours [09:22] versions is stuck? [09:25] no, can't be… [09:25] worked at the first trial [09:25] no compilation errors, everything seems to behave as it should [09:25] for 100+ line diff, I think there is a trap somewhere :) [09:27] Laney, seems so, I'm looking at it [09:35] Laney, should be fixed with the next run, (going to take an hour to run) [09:35] great, thanks [09:36] Laney, robert_ancell messed up one edit, it was hitting an invalid number of argument exception [09:41] seb128, yeah, i'm not too bad thanks. although, a little sore from all the sun at the weekend [09:41] i spent the entire weekend outside [09:41] chrisccoulson, you finally got some summer weather as well? [09:41] chrisccoulson, oh, did you have fun at least? ;-) [09:41] seb128, yeah, it's been quite nice for a couple of days [09:42] oh, no fun. just tidying up the garden [09:42] that sounds like fun :p [09:42] i had to shred a large pile of stuff i cut down a few weeks ago, cut our grass, trim a metre off the top of our hedge and cut back a tree at the bottom of the garden [09:43] it's been quite hectic ;) [09:43] glad to be back to the computer today then? ;-) [09:43] yeah [09:43] ;) [09:47] * didrocks prepares metacity 2.34.3 update [09:49] hi, anybody can have a look on this bug? https://bugs.launchpad.net/ubuntu/+source/brltty/+bug/1022927 [09:49] Ubuntu bug 1022927 in gvfs "Upgrade tests failed: obsolete files left after the upgrade" [High,Confirmed] [09:57] babyface_, I saw it, it's on my todolist but rather low priority, it's a detail [09:58] babyface_, does it create any pratical issue? [09:59] seb128, no. all the upgrade test jobs are marked unstable due to this fail, which looks very ugly ;) [09:59] seb128, so it would be good to solve it asap [10:00] babyface_, that's only a conffile leftover, since when is that an important thing? we have tons of such issues... [10:03] seb128, it blocks the upgrade test, which means this case fails, and the job stops, and the follow-up test can not have a chance to run. [10:03] you should make that test non-fatal [10:03] babyface_, well, fix your tests? [10:04] obsolete conffiles are easy to fix, but it's really not worth stopping the world to do so [10:04] babyface_, it's only a leftover file on upgrade, it's not a red flag stuff [10:07] seb128, yes, I know it's not a big deal, and I will check the test job first, and if I can improve the test job I will, but if not, I will have to get back to you ;) [10:09] babyface_, sure do, but I'm not thrilled by QA making minor issue stoppers in an unilateral way like that, we have enough to do without having to stop everything we are doing to fix bugs no users would notice [10:09] babyface_, it's like if you decided to check manpages for typos and stopping the install on misspelt words ;-) [10:10] babyface_, btw it would be good to let the Ubuntu community know in some way about those sort of tests when they are set up, cleaning conffiles on upgrades are easy to miss thing and I don't think we communicate strongly it's important [10:12] seb128, yes, hehe, I understand what you said, we will communicate more in the future [10:12] babyface_: that should be state "yellow", not "read", isn't it? [10:13] pitti, yes, it's yellow [10:13] that's ok; a lot of them were yellow when we released precise [10:14] for precise -> quantal we ought to aim at "green", but SRUing minor issues like this is a rather huge amount of work for relatively little benefit IMHO [10:14] * pitti -> lunch, bbl [10:14] pitti, yes, I see. thanks pitti [10:28] guys, yellow or red in jenkins doesn't mean much, the fact that a bug hasn't been fixed in more than 10 days says it is not very critical [10:28] not even for us [10:29] seb128: but it needs to be fixed ^^ [10:29] seb128: I am glad it is on your todo for this week [10:31] seb128: if you are unhappy with any of the tests we are running, please send us an email with the rationale and we will look into it, if it is not worth to run something or to look into it when it fails we will gladly remove the test [10:31] seb128: some of our tests may cease to be relevant with time and we need to keep up to date [10:32] gema, hey, I'm not unhappy and I think this test is a good idea, I wish it would have been communicated to the Ubuntu teams though [10:32] gema, out of coming with "please fix that bug asap" for a thing we didn't even know was tested [10:32] seb128: agreed [10:32] seb128: that's a problem in our process [10:32] a good outcome of some tests would be a bug report that can just be rolled into the next release of the package [10:32] they don't all have to stop the world [10:32] Laney: agreed [10:33] Laney: but some failures may hide other problems, so sometimes they need to be fixed for other tests to be able to pass or fail [10:33] it is not this case, though [10:33] right, the current conffile stuff is harmless [10:33] seb128: right [10:33] seb128: but needs to be fixed [10:33] in a reasonable amount of time [10:33] seb128: how much is reasonable is up to us to agree upon [10:34] gema, yeah, agreed, I will fix it today or tomorrow, it's just not a world stopper to put on hold stuff I'm doing atm ;-) [10:34] seb128: this is not about this bug in particular, it is about establishing a workflow that works for both of us [10:34] seb128: thanks, that sounds good :D [10:35] gema, right, we should see about setting priorities, as pitti said conffile issues should be yellow, not red [10:35] gema, I still think it would be good to email ubuntu-devel about those conffile tests if you start flagging them yellow so maintainer to pay attention to the topic [10:35] seb128: unfortunately the way jenkins works yellow and reds cannot be twiked based on what run [10:35] it has its own rules [10:35] seb128: so we have to figure out what's wrong on case by case basis [10:36] seb128: that's a good idea, we'll do that [10:36] seb128: we cannot flag colours, jenkins decides based on how much is failing [10:36] thanks [10:36] oh, ok [10:36] seb128: but we can send an email whenever that test fails [10:36] gema, well, what I meant with "yellow" is that ideally that should block other tests to run [10:37] it's not a blocking issue, it's a warning at most [10:37] seb128: ok [10:37] seb128: thanks for the feedback [10:37] hmmmm, i think i'm never going to take time off work again ;) [10:37] it's too much hassle! [10:38] gema, yw, thanks for taking the feedback in consideration ;-) [10:38] seb128: we are all learning here [10:38] chrisccoulson, stacked under tons of stuff to catch up on? [10:38] seb128: so anything that helps ease both sides is worth a shot [10:38] seb128, i need to figure out how to fix https://bugzilla.mozilla.org/show_bug.cgi?id=775143 quite quickly ;) [10:38] Mozilla bug 775143 in Extension Compatibility "crash in uGlobalMenu::OnOpen when activating HUD in Ubuntu with Firebug" [Critical,New: ] [10:53] bah [10:53] wth mozilla, why adding those grey colored scrollbar to tb! [10:54] the background color was way better when it was subtle [10:54] it's like they made the scrollbars the most important ui part ;-) [10:54] i don't think that was deliberate [10:55] it's not the case in the current nightly anyway ;) [10:55] chrisccoulson, did you see that as well? [10:56] I get the issue on precise since the recent updates [10:56] seb128, i do if i run the current version, but not in nightly (which is what i normally run) [10:56] ok [10:56] let's see, maybe tb 15 will fix that :p === MacSlow is now known as MacSlow|lunch === zyga_ is now known as zyga === MacSlow|lunch is now known as MacSlow [12:46] didrocks, hi, got time to talk about the OneConf Web UI? [12:47] mpt: perfect timing, just finished a long email! :) [12:48] didrocks, I read through the "WebUI" section of your post, but I'm not sure what the use case is [12:48] didrocks, why would someone use a web UI and not use USC directly? [12:49] mpt: you are on your tablet and have ubuntu installed on it, you spot an awesome app that you just installed [12:49] and think "I really should have on my desktop as well" [12:49] you go to the web ui, login, select you desktop [12:50] and select install it [12:50] when you are back on your desktop, you have a credential/a popup telling you "you marked this app for installation, do you want it?" [12:51] didrocks, okay, but couldn't you do all that inside USC? [12:51] mpt: if you are on another machine, you need to remember you wanted to install this app as well [12:52] didrocks, at what part of the process are you being on another machine? [12:52] the first one, 14:49:37 didrocks | mpt: you are on your tablet and have ubuntu installed on it, you spot an awesome app that you just installed and think "I really should have on my desktop as well" [12:53] didrocks, so by "another machine" did you mean the tablet? [12:53] yeah [12:54] didrocks, so how would using a Web interface, instead of USC, help you remember? [12:55] mpt: just because when you are back on your desktop, you get a message/notification telling "you marked this app to be installed on your current device, install now?" [12:55] didrocks, how does that require a Web interface? [12:56] how do you want to remotely mark something for installation? [12:56] (Sorry, there's obviously something big and simple I'm missing) [12:57] didrocks, mpt I bet if you guys set up a hangout, you could talk this through in like 5 minutes [12:57] and you can make it "on air" and public too ;) [12:57] (no pressure, just a suggestion) [12:58] rickspencer3, I am in post-prandial mode and thinking too slowly for that, probably :-) [12:58] http://en.wikipedia.org/wiki/Postprandial [12:59] didrocks, if your use case is you just installed something on your tablet and you want to install the same (or equivalent?) application on your PC, inside USC you'd go into "Sync Between Computers", then "N items on this computer not on 'Didier's PC'", choose the application, and click "Install There" or something like that [13:01] mpt: the difference is that you have to remember when you go on the destination device to install the apps and to see the diff [13:01] but anyway, I think I'll stop proposing oneconf related stuff. It's not like I didn't propose most of those features 3 years ago and that google play implemented them 8 months from now :) [13:02] didrocks, you could have exactly the kind of notifications you're proposing with a local application. (They'd be easier, come to that.) === james is now known as Guest1737 [13:02] Plus the benefit of not having to sign in. [13:03] mpt: what do you mean, you want software-center to have a way to mark "install that app on this device"? [13:03] didrocks, more "install *this* app on *that* device", but yes. :-) [13:03] Then the next time you log in on that device, you get the notification [13:03] mpt: I'm afraid that brings more complexity for the UI compared to a centralized location like https://apps.ubuntu.com/ what do you think? [13:05] didrocks, what I'm suggesting would involve one more button per application in the existing UI. What you're suggesting would involve adding SSO to apps.ubuntu.com, and replicating most of the "Sync Between Computers" UI on the Web. [13:06] mpt: right, I agree, but that would make apps.ubuntu.com a little bit more useful than what it is ;) like seeing your different devices and what are installed on them (there is no place for that right now) [13:06] you only can see a diff right now [13:07] A diff? [13:07] the oneconf view [13:07] like, I want to manage my different devices and want to see clearly what apps are installed on each of them, without getting to each one [13:07] or told another way [13:08] didrocks, making apps.ubuntu.com useful is not an end in itself. If there are several other user goals for which showing your installed software on the Web is a means to that end, that would be more interesting. [13:08] chrome now has the support of seeing what tabs have every chrome browser on different device you install [13:08] it doesn't really show a diff [13:08] sorry, I don't understand that chrome bit [13:08] Do you mean seeing what tabs are open on each device? [13:08] yeah [13:09] didrocks, ok, but is there a Web UI for that? [13:10] ah good, point, no, it's in the app indeed [13:10] but you can have a full list of every tabs in every browsers where you are connected on [13:10] sure [13:10] and can add/remove them remotely [13:10] If there are use cases for "show me everything on my other machine, not just a diff", we could add that [13:12] mpt: I wonder, I think it makes sense to have it, but I can't define a strong use case apart from people want to really know what they have and don't want to make it from "what do I have here +/- the diff" [13:15] didrocks, ok, I'll do some sketches and let you see what you think [13:15] mpt: excellent, thanks! [14:21] right, i'm nearly caught up now! [14:21] just need to pop out and pick up some contact lenses [14:21] bbiab [15:01] mpt, around [15:01] ? [15:01] ogra_, yep [15:01] hey [15:02] i just built myself a new desktop machine with a shiny 3 monitor setup ... and noticed a usability issue [15:03] while i can select in the monitor applet where my unity bar shows up (which screen) i always miss the notifications when reading email on my most left monitor ... they show only on the most right screen [15:03] would be great if notifications were selectable like the unity launcher position for such a case [15:03] notification-follows-mouse? [15:04] well, at least notifications on the screen where my launcher is or so [15:04] (probably ~99% of the time your mouse cursor will be on the screen you're "paying attention to") [15:04] ogra_: it's quite likely that if you have 3 monitors you'll be looking at the one that doesn't have the launcher from time to time... [15:04] indeed [15:04] could also make it come on the screen that has the window with keyboard focus [15:05] * desrt can't think of any other useful heuristics [15:05] well, any solution would be better than the current situation in my case :) [15:05] ogra_, gsettings set com.canonical.notify-osd multihead-mode 'focus-follow' [15:05] * desrt has to wonder why that is not default [15:05] * ogra_ shakes his head ... can'T be ... they thought of that ?!? [15:06] WOW ! [15:06] can we make it the default? :-) [15:06] desrt, I think the reply is "Mirco had no time for notify-osd in recent cycles and nobody else got annoyed enough to look at that" [15:07] * ogra_ hugs seb128 ... thats awesome [15:07] * seb128 hugs ogra_ back [15:07] and yes, we should just make it the default imho [15:09] ogra_, desrt, Laney: hey, we should probably do that [15:10] ++ [15:10] really helps on multiscreen [15:10] rock [15:10] * Laney hands the upload token to ogra_ :-) [15:10] * didrocks goes out to see the dentist, will be back afterward [15:11] didrocks, good luck! [15:12] seb128: thanks, I didn't need to see any dentist for the past 7 years. Julie convinced me that a check would be good at some point. Hopefully, nothing will be revealed :) [15:13] didrocks, oh, good ;-) [15:33] pitti, hi [16:25] Anyone fancy testing dbus 1.6? https://launchpad.net/~laney/+archive/experimental/+packages [16:26] Laney, oh, great, did you change,fix anything over pitti's version which was breaking indicators? [16:27] nah, that seems a bit broken indeed [16:28] am i the only person who hates the new nautilus? [16:28] I get messages, sound but not others like network or redshift [16:28] when checking missing files from a build, i need a little more understanding of how to choose where to install thing.. look at http://paste.ubuntu.com/1106688/ [16:30] chrisccoulson, I hate that they replaced typeahead with that slow broken search [16:30] bcurtiswx, hey [16:31] hi seb128 [16:31] seb128, yeah, that's the first thing i noticed too. i used the typeahead pretty much all the time :( [16:31] i've never used the search before! [16:32] bcurtiswx, you probably want to install the udisk2 backend where the udisk one was ... but it's a bit weird that it's listed as missing [16:32] well, the rules file take care of quite a few of those [16:32] takes* [16:32] but i found it odd it's in the rules [16:33] bcurtiswx, let me check gvfs [16:35] Laney, seems like you are the 3rd person to do the dbus update to hit the indicator issue :-( [16:35] Laney, cf https://launchpad.net/bugs/1014850 [16:35] Ubuntu bug 1014850 in dbus "Update to 1.6.0" [Wishlist,Triaged] [16:36] Laney, you should check on version if stuff have a been with some status before starting on something to avoid dupping work [16:37] seb128: I didn't do it from scratch [16:38] pitti's PPA had a 1.5.x version; I got the newest upstream === zyga is now known as zyga-brb [16:39] Laney, ok, you guys dropped the ubuntu patches there right? [16:39] some of them [16:40] brb, on a call [16:43] mterry, now that you fixed what you broke ;) would you mind looking at bug 1009226 ? [16:43] Launchpad bug 1009226 in update-manager "Precise to Quantal: update-manager UI crashes: can't load DistUpgradeViewGtk (No module named vte)" [High,Confirmed] https://launchpad.net/bugs/1009226 [16:44] jibel, yeah, I was going to look at reproducing that after we got a new dist upgrade tarball. I think if it still is there, the trace will be a bit different, but I'll look at it for sure. /me assigns [16:44] bcurtiswx, yeah, that package is weird, that's because they need to install different stuff on hurd than linux so they use the rules to hack [16:44] o, it's already assigned to a team. [16:44] Still, will look at it [16:45] mterry, it is still there, want a new trace ? [16:46] jibel, I can grab it myself in a sec [16:46] mterry, it is assigned to a team but I am not sure on which plate is update-manager and you've been pretty active on it recently, that's why I asked. === zyga-brb is now known as zyga-afk [16:47] jibel, sure, and I'm a good person for it. :) [16:48] jibel, how far in before you get the trace? [16:48] mterry, right after it asks for a password [16:48] * didrocks back with beautiful tooth :) [16:49] jibel, hmm, didn't get it in my VM... Maybe I have some vte package installed that's not default [16:49] didrocks, hah nice [16:51] hmm.. I don't seem to have anything special. Will create fresh VM to make sure [16:51] mterry, bah, release-upgrade version 0.162 :/ something must be wrong on my side [16:52] oh odd [16:52] mterry, hold on, I'll check first [16:53] my dumb proxy must be playing me tricks again [16:56] bcurtiswx, ok, so the fact that they use a custom rules hack rather than the .install way means dh_install -list-missing is getting confused as well [17:05] seb128, yes i've copied the missing list and deleted the lines that were covered in the rules file and i'm left with 6 [17:05] lol [17:05] chrisccoulson, ? [17:05] http://paste.ubuntu.com/1106769/ [17:05] pressing ctrl+v in nautilus starts a search rather than transferring a file! [17:06] chrisccoulson, ouch! [17:06] chrisccoulson, kenvandine: https://bugzilla.gnome.org/show_bug.cgi?id=680159 [17:06] Gnome bug 680159 in Location Bar "ctrl-V paste the copied file's url in the location bar instead of copying the file" [Normal,Resolved: fixed] [17:06] seb128, thanks [17:06] I should perhaps backport the fix ;-) [17:07] :) [17:12] bcurtiswx, your gvfs update merge request from the other day miss the install of the new recent backend, I guess that's what you are fixing? [17:13] bcurtiswx, otherwise upstream rolled a new gdl tarball if you want to work on that after gvfs, should be an easier one and better case for a library [17:14] mterry, upgrade is in progress, it's all good. I'll let you now if there's something later during the upgrade. Sorry for the noise. [17:14] jibel, awesome [17:30] seb128, yes i'm fixing that, and the gdl will be next [17:49] seb128, is there an easy way to tell where http://paste.ubuntu.com/1106769/ those go ? I've removed anything that was taken care of by the rules file and all the .la and .a files [17:53] seb128: who would be best to contact about this issue with the indicators and global menu and new dbus? [17:58] can we get bug 1026066 fixed in time for Alpha 3? [17:58] Launchpad bug 1026066 in software-properties "software-properties-gtk crashed with ImportError in /usr/lib/python3/dist-packages/aptdaemon/client.py: No module named gobject" [Medium,Fix committed] https://launchpad.net/bugs/1026066 [18:06] * didrocks waves good evening === zyga-afk is now known as zyga [19:02] jbicha, it's fixed in trunk, get mvo or pitti to do an upload tomorrow I guess? [19:02] Laney, do you know what's the issue? dx can help but I guess they will need some background [19:03] bcurtiswx, the recent ones to gvfs-backends, not sure about the .h but that's not new you can ignore it [19:03]