=== k is now known as Guest27271 [01:01] hi all what is lite updating for UBUNTU === jbicha is now known as Guest32183 === Guest32183 is now known as jbicha_ [01:22] desrt: can you help fix https://bazaar.launchpad.net/~gnome3-team/gnome-control-center/ubuntu/view/head:/debian/patches/revert_git_dont_hide_zoom.patch ? [01:23] I'd like to hide the zoom options from Unity or GNOME Fallback but Unity registers itself on org.gnome.Shell [01:53] jbicha_, just use XDG_CURRENT_DESKTOP? [02:06] maybe, XDG_CURRENT_DESKTOP by itself doesn't currently distinguish between Shell & Fallback === jbicha_ is now known as jbicha [02:19] jbicha, or use dbus to check for the actual zoom interface [02:24] jbicha: uh. unity bug? [02:24] darkxst: thanks, let me try that [02:24] unity should absolutely not be taking org.gnome.shell [02:27] desrt, I think compiz is to blame [02:28] ...as with all the best 'features' of unity :) [02:30] https://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/UnityCore/GnomeSessionManager.cpp#L31 [02:32] Trevinho: ^ [02:41] darkxst: that works === jbicha is now known as Guest48606 === Guest48606 is now known as jbicha_ [06:34] robru: hey! Thanks for the email :) FYI, there was a merge tonight with an additional one (for daily_release: False): http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/revision/419 [06:34] didrocks, heh, ok [06:35] Good morning [06:35] pitti, good morning! [06:35] bonjour pitti, comment ça va? [06:35] hey robru, how are you? [06:36] bonjour didrocks ! je vais bien, merci ! et toi ? [06:36] très bien! soleil et temps agréable ici :) [06:36] pitti, much better finally... and you? ;-) [06:36] je suis en retard aujourd'hui [06:36] nous sommes allés à un concert d'hier soir [06:37] robru: a bit tired still, but fine; what happened to you? [06:37] pitti: quel type de concert? [06:37] didrocks: il pleut à nouveau ici :/ [06:37] argh :/ [06:37] pitti, emergency appendectomey last week. so i am slightly lighter now ;-) [06:37] didrocks: Die Toten Hosen [06:37] robru: ouch [06:38] robru: it was just a question of weight (and taking an extra week of holidays), admit it! :-) [06:38] robru: kidding, welcome back again, happy to see that you feel better :) [06:38] didrocks, no, it was a real medical issue, I swear! [06:38] didrocks, next time I see you I will show you the scars ;-) [06:38] I trust you on this. I don't want to imagine how painful this can be :/ [06:38] ahah [06:39] didrocks, oddly the recovery was more painful than the surgery itself. at the hospital you get really nice drugs, but when you get home you just get crappy drugs ;-) [06:40] oh… I hoped you got some distraction like reading/video games/… to forget about the pain if the medecines are not good enough :/ [06:40] didrocks, oh yeah, it was a week of distractions... I bought myself a ps3 ;-) [06:41] ahah, should be cheaper with the ps4 incoming :) [06:41] yeah, that's what I was hoping for ;-) [06:41] what games did you play with? [06:41] didrocks, I started playing GTA4 for the first time ever, dunno why it took me so long but I've been wanting to play it since forever. Also I tried out Little Big Planet but it seemed more childish than I was expecting. [06:42] ah… GTA4. Played since the 1 and loving the series :) [06:42] little big planet -> never played more than the demo [06:42] didrocks, yeah, I'm a huge fan of the series. I played San Andreas to 100% completion *twice* [06:43] waow, I just played once at each until the end of the main story (but doing a lot of bonuses) :) [06:43] the only thing I don't really compete on is the extra quests like car races or stealing X numbers of cars… [06:44] didrocks, yeah, I am totally OCD about finding every hidden package and doing every side mission. ;-) [06:44] ahah :) [06:44] you are worse than I! [06:44] I'm so bad ;-) [06:44] heh [06:44] robru: I guess if you really like the story side of GTA, you will love this one until the end [06:45] didrocks, yeah, the story seems good so far. nice and gritty. I'm sad that they took away bicycles though! [06:45] ahah, me as well, but it seems to be back on GTA5 \o/ [06:45] * didrocks can't wait [06:45] sweeeeet [06:45] I have to finish Gta4 before I can start 5 ;-) [06:45] heh, indeed! and you have 2 other stories (which were DLC at first) [06:46] one with bikers, and the other around night clubs [06:46] didrocks, oh yeah? does it change the story or should I finish the stock version first? [06:47] robru: finish the stock version first, those 2 are extra stories with other people, and you can cross the main story at some missions. So it's fun to see the same events from some other point of views [06:47] oh, sweet! can't wait for that! [06:47] didrocks, ok, I need to play for an hour before bed. g'night ;-) [06:48] robru: enjoy :) [06:57] GTA5 will arrive just on time, I managed to play through both of the gta4 extra episodes some time ago [07:00] Mirv: loved them as well! especially the story on night clubs === tkamppeter_ is now known as tkamppeter [07:23] moin! [07:23] hey Sweetshark! [07:39] good morning desktopers [07:40] bonjour seb128 [07:40] pitti, salut, ça va ? [07:44] salut seb128! [07:44] didrocks, lut [07:45] bonjour [07:45] ca va [07:47] mlankhorst, salut, ça va bien, et toi ? [07:47] je suis ok [07:48] * mlankhorst watches toes of all the french in here curl up! [07:57] mlankhorst: indeed. Next time you will need to chant the Marseillaise for joining the channel. from memory. [07:58] french don't know what pain is.. https://fr.wikipedia.org/wiki/Pain [07:58] so I can't have hurt them [07:58] :X [07:59] hallo [08:03] Laney, good morning ;-) [08:03] oho, I see the thread! [08:03] hey seb128 [08:04] haha [08:04] jasoncwarner targetted -desktpp and not -devel list though [08:04] that will limit the participants [08:05] true [08:05] i'm sure the word will get out though [08:06] that's likely indeed [08:11] hum [08:11] what is it with things that segfault when you copy over a .so they are using [08:11] when that doesn't happen when the same .so is overwritten by a package [08:12] like I never have xorg segfaulting when updating -intel, but copying the .so with cp made it unhappy [08:12] that happened with compiz, gtk and other stuff in the past [08:12] oh, well, I needed to restart xorg to test the new driver anyway [08:13] it probably unlinks and then puts a new file in [08:13] it->dpkg [08:14] rather than updating it inplace [08:15] Laney, why is that better? ;-) [08:15] does it force the loader to refresh the table pointing to the shared objects? [08:15] if it's mmaped into a process then updating it in place will update the copy the program is using [08:16] oh, that's a good point [08:16] but if you remove it then the new file will have a new inode which doesn't affect the already loaded copies [08:16] that makes sense [08:16] so next time rm + cp ;-) [08:16] Laney, thanks [08:17] np [08:25] sil2100: any idea where would I find that cmake's libexec variable from? [08:29] didrocks, btw, with the crazy landing week you missed your pilot shift ... any way you catch back a bit on that by reviewing the compiz and unity MR from Mirv that are sitting on versions for a while? ;-) [08:29] didrocks, the oneconf one is still there as well :p [08:29] seb128: that's what we discussed yesterday during the meeting [08:29] so yeah, I'll probably do my shift this afternoon or tomorrow morning [08:30] didrocks, ah, sorry, IRC was in ping mode I didn't read everything in your half of the meeting [08:30] didrocks, thanks [08:30] yw :) [08:30] Mirv: hm, never did that before, but I have some ideas, give me a moment [08:32] Mirv: check GNUInstallDirs.cmake from the cmake modules [08:33] Mirv: there is a variable CMAKE_INSTALL_LIBDIR [08:33] Mirv: and CMAKE_INSTALL_LIBEXECDIR [08:33] (since I pasted the wrong thing) [08:38] sil2100: thanks.. I'll try the last one, thanks for that pointer (GNUInstallDirs.cmake)! [08:38] seb128: any quick feedback on the "incompleteinternals" ideas? [08:41] Sweetshark, did you see my email reply? [08:41] Sweetshark, I'm not sure that cleaning of the source package is going to give you that much extra space [08:42] I would assume that it's the builddir and the build objects that take 95% of the space [08:43] * Sweetshark looks for reply ... [08:43] Sweetshark, rene already replied to my reply [08:43] $ cd src && du -hs [08:43] 242M . [08:44] that's not a difference there that is going to make ppa builders happy [08:44] how much is a build using? [08:45] Mirv: I'll be fixing address-book-service in the meantime [08:59] seb128: checking my last local build for estimates [09:01] seb128: 20G workdir/, 4.3G debian/, 4.1G solver, 160M solver/unxlngx6.pro/installation/, 27G . [09:02] Sweetshark, do you know what is the ppa builder disk space limitation? [09:03] seb128: no. I heard something about a 70GB disc limit, put I dont know how that boils down to partitions. [09:04] so you are saying a lo build takes under 30G and you that's enough over what the ppa has in free space? [09:06] seb128: well, this is the size of the tree after the build -- there might be additional peak usage inbetween (e.g. using /tmp etc.) [09:07] well, skipping the tests likely wont help much (see the installation taking only 160MB as we symlink to the other dir wherever possible). but the builds choke exactly there now ... [09:07] infinity, hey, do you know about ppa builders and available space there? how do we get ones that have enough disk to build libreoffice? ;-) [09:16] seb128: some analysis on the example of the writer lib: http://pastebin.ubuntu.com/5757585/ [09:17] Sweetshark, I would like to hear back from infinity there, having 50G of disk space on a buildder doesn't seem the end of the world nowadays... [09:20] simple way to crash gedit: Ctrl + h, replace \n by anything :p [09:22] didrocks, wfm [09:22] didrocks, replaced \n by a space [09:22] seb128: hum I replaced with nothing, let me see on another file [09:23] seb128: Ah! I think I know why we run out of space there. When creating the installation for the subsequenttest, we first create a full copy and then run the ./solenv/bin/linkoo script, which replaces copies with symlinks. So during that time, we indeed have two copies of the libs around and one can assume that solver/unxlngx6.pro/installation/ is ~around the size of solver/unxlngx6.pro/lib bigger (that is 3.8GB). [09:24] didrocks, replaced by nothing works fine (I just created a new document and typed random chars and enter a few time to test) [09:24] hum, still crashing here, but just on that file [09:24] seb128: so for running the subsequentchecks we temporarily increase the build tree from 27GB to something in the 31-32GB range and then go back to 27GB ... [09:24] I'll have a look at the stacktrace [09:24] Sweetshark, that still seems a reasonable disk space to today's standard [09:25] didrocks, thanks, if the file is not private just ubuntu-bug and add the file to the bug? [09:25] seb128: yep. [09:25] seb128: Which is why I was weeping like a willow yesterday ;) [09:28] seb128: note that LibreOffice build depending on ~1/3 of main of course also has an impact. [09:35] seb128: I noticed the background drawing is weird on my nvd7 in true optimus mode, it draws only a 1024x768 rectangle, which is the initial resolution when I have no displays attached. When I light up the internal lcd the background still draws only the top 1024x768, even though my mouse can move over the entire screen.. any idea why? [09:36] mlankhorst, what is drawing the background for you? nautilus? [09:36] yeah [09:36] restarting it helps, but still.. [09:36] not sure, I didn't see any bug about that and things work fine here when docking/undocking/adding monitors [09:38] the internal screen is connected to the intel, but I was setting nouveau up in true optimus mode (toying around with an experimental patch) [09:38] it needs debugging, I think nautilus just gets the screen infos from gdk [09:39] seb128: I think I will just go full berserk on this one for now and disable running the tests on ppa builds ... [09:40] Sweetshark, that's suboptimal but until we hear from the buildds guy I guess that's an option, I will ask on #ubuntu-release [09:42] seb128: thanks [09:49] Mirv: sil2100: sorry, I was maybe unclear, but libexec is /usr/lib/x86_64-linux-gnu/ or /usr/lib/ (rather the first one for multi-arching). There should be no "libexec" in the path [09:49] what does CMAKE_INSTALL_LIBEXECDIR points to? [09:52] didrocks: it points to /usr/libexec [09:53] didrocks: that's why we're using CMAKE_INSTALL_LIBEXECDIR but then override it in debian/rules [09:53] didrocks: I thought the former was for libs, latter if a program in *bin required helper programs [09:54] mlankhorst: for instance, we have /usr/lib/lightdm/lightdm/ for the helpers [09:55] mlankhorst: no "libexec" in path [09:55] yeah [09:55] didrocks: I think this should be changed in the GNU cmake module file for ubuntu [09:55] sil2100: agreed, anyway, we need to override it for multiarching :) [09:55] didrocks: so that CMAKE_INSTALL_LIBEXECDIR returns /usr/lib/ instead of the default /usr/libexec [09:56] didrocks: ACK, for all projects that are affected? [09:56] didrocks: or only dbus-cpp should be multiarched? [09:56] Mirv: ^ [09:56] sil2100: yeah, let's try to put everything that can/needs to be multiarched set up that way [09:56] at least for new components [09:56] then, we'll go over older ones :) [09:57] Mirv: ok, can you multiarch dbus-cpp? I'll do the same for address-book-service then [09:58] * didrocks sees a lot of stacks in manual publication or failures, not sure if people wait on me or dealt with them already [09:59] didrocks: I can deal with that :D But why so many manual publishingz?! [09:59] sil2100: well, looking at it will tell you :) [09:59] sil2100: not sure how we can have everyone looking at it first time in their morning [10:00] for instance, the misc stack is in manual publishing mode for 2 days, despite my ping to cyphermox yesterday (and reviewing a stack when being in manual publish mode takes no more than 5 minutes :/) [10:00] not sure what's wrong… [10:01] I was usually doing that in the morning, somehow got out of sync lately though! I promise to resume that activity - I see some HUD issues though [10:02] hm, funny [10:09] didrocks: after I browse through the changes, you mind if I publish apps, media, misc and platform? (not sure about qa?) [10:10] sil2100: remember if there are packaging changes, just ping me for a double review (it's a kind of sponsoring as the deal is that only people with upload rights should do that manual publication) [10:11] didrocks: ACK [10:11] didrocks: a noob question - is there an easy way of checking all the diffs in a stack? [10:12] didrocks / sil2100: ok, will fix, now to lunch [10:12] sil2100: not really, it's package per package if there is a packaging diff, making an intelligent diff (basically packaging changes + build system changes) [10:12] sil2100: you do see them in the artefacts, right? [10:15] didrocks: artefacts in which job should I see? [10:15] Since normally I browsed LP :| [10:15] oh [10:15] no, it's way easier [10:16] sil2100: http://10.97.0.1:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-3.0publish/ for instance [10:16] I looked at the prepare jobs but hm, no useful artefacts [10:16] if you click on the publish job [10:16] you have publisher.xml [10:16] Ah [10:16] for the reason of the manual publishing [10:16] and you have the .diff for each package with packaging change [10:17] hm, why didn't I see that when I checked the publish job just a moment ago? I think I'm getting blind [10:17] Thanks [10:17] sil2100: http://10.97.0.1:8080/view/cu2d/view/Head/view/Platform/job/cu2d-qa-head-3.0publish/ [10:17] for the qa with multiples packaging change [10:17] for instance [10:17] sil2100: so, you always have the reason in the xml [10:17] and if packaging changes, they are archived [10:17] didrocks: ah, I know why I didn't see that [10:18] ah? [10:18] didrocks: for instance http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/16/ has no .diff, does it mean there was simply no new commits, right? [10:18] seb128: btw running "du -sh /" in my pbuilder gives 103G after the builder (plus the at least ~4GB) that we need more temporarily as discussed [10:18] Sweetshark: no, it means no packaging change :) [10:18] oupss [10:18] sil2100: ^ [10:18] ;) [10:19] sil2100: look at the publisher.xml for the reason: http://10.97.0.1:8080/view/cu2d/view/Head/view/Apps/job/cu2d-apps-head-3.0publish/16/artifact/publisher.xml [10:19] (view source of the xml if you want the line breaks) [10:19] Sweetshark, :-( [10:19] sil2100: that's why I told that manual publishing review shouldn't take more than 5 minutes per stack ;) [10:20] Sweetshark, #ubuntu-releases says there is not a lot they can do for the ppa builders, there are still quite some old machines in the pool and until those are replaced/upgraded you will have builds dispatched on those [10:20] Now that makes sense ;p [10:21] sil2100: and again, the diff is "smart": it just shows packaging diff + all related build tools (autotools, cmake, qmake…) so that you have enough context to see why the packaging eventually changed [10:22] sil2100: so, for media, you can see that you have packaging change and stack dependencies failing: http://10.97.0.1:8080/view/cu2d/view/Head/view/Media/job/cu2d-media-head-3.0publish/lastSuccessfulBuild/artifact/publisher.xml [10:22] (or stacks in manual publishing mode) [10:24] Sweetshark, can you join #ubuntu-release? [10:25] didrocks: ok, checked the misc stack diff, the changes look sane, could you ACK? [10:26] sil2100: packaging diff looks good to me, please publish :) [10:33] didrocks: no packaging changes for the apps stack, and it looks good, so publishing [10:33] great! [10:36] sil2100: we assume there is no ABI break in the dep stack which we can't publish I guess ;) [10:36] (think in case of a doubt to ask upstream) [10:38] ;) [10:39] didrocks: all looks ok, media stack seems ok as well - the deps everywhere are only HUD and platform usually, which are OK (HUD being 'fails-to-build' right now though) [10:39] No ABI break or anything like that [10:39] didrocks: could you take a look at media? The diff looks sane, so I'd like to publish that [10:42] desrt: do you happen to know what became of that "user D-BUS" (as opposed to session and system bus)? [10:42] desrt: is that still actually relevant? [10:44] didrocks: platform looks ok as well packaging-wise, can I publish? No dep-problems [10:50] * sil2100 waits ready with a -P ;) [10:52] didrocks: piing ;p Checked the QA stack as well, looking good so far! [10:52] didrocks: waiting for a green light on: media, platform and qa! [10:52] * sil2100 needs to go to lunch now [10:52] I'll publish when I'm back then [11:05] sil2100: media -> OK, platform -> OK, qa -> OK :) [11:05] sil2100: please do publish when you are back :) [11:08] didrocks (and sil2100): hmm, dbus-cpp still - could I separate the example binaries into a multi-arch package and have the include files in architecture:all package instead? [11:08] Mirv: that sounds a good plan to me (so the arch:all will be multiarch: foreign) [11:09] yes, multi-arch same for the binaries and foreign for the arch:all. [11:09] doing [11:11] Mirv: sorry for being silly, but if you can point me on the spreasheet again for compiz/unity precise, that would be awesome! :) [11:13] didrocks: there you go! [11:13] thanks! === MacSlow is now known as MacSlow|lunch [11:27] mfisch: hey, on bug #1031449, I guess you meant precise? (I declined raring as it's fixed as per commit in it, set fix released for saucy and opened the precise task) [11:27] Launchpad bug 1031449 in rhythmbox (Ubuntu Precise) "rhythmbox leaking memory" [Undecided,New] https://launchpad.net/bugs/1031449 [11:51] cyphermox: larsu: do you have anytime for https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214? [11:57] * didrocks needs to find a pidgin's user [11:58] oh a seb128! [11:58] seb128: FYI, there is a new patch on https://bugs.launchpad.net/ubuntu/+source/pidgin-libnotify/+bug/1175537 [11:58] Ubuntu bug 1175537 in pidgin-libnotify (Ubuntu) "Stuck notifications (unable to clear them)" [Undecided,Triaged] [12:00] didrocks, thanks [12:00] seb128: maybe the third time will be the right one :) [12:00] didrocks, yeah, let's see ;-) [12:01] didrocks: sigh, not that again :-/ [12:02] larsu: good morning! :-) [12:02] didrocks: hey, how are you doing? [12:02] I'm good, thanks! yourself? [12:02] sun is back in France it seems \o/ [12:02] very good thank :) [12:02] * ogra_ thought they are oracle now ... [12:03] seb128: it seems you are quite opposed to the fix for bug #1027086 (I agree with you), should I just remove the sponsor subcriber to remove from the list? [12:03] Launchpad bug 1027086 in vino (Ubuntu Precise) "incorrect schema setting used for authentication-methods in vino server" [Medium,In progress] https://launchpad.net/bugs/1027086 [12:03] didrocks: except that you're destroying my morning with making remember that bug... :P [12:03] ogra_: rohhhh [12:03] :) [12:03] larsu: success \o/ [12:03] (j/k) [12:03] haha [12:03] didrocks, I've no strong opinion either way, if you think the fix is fine sponsor it, otherwise yes just unsubscribe sponsors please [12:04] didrocks, ritz seems to argue that the fix is what upstream is doing as well [12:04] seb128: yeah, I'm still unsure if it worths it for precise [12:05] let's see once ritz is back, unsuscribing for now [12:05] was in a HO and suddenly MIC stopped [12:05] didrocks, seems like some customer cares [12:05] [10558.761127] traps: unity-panel-ser[2300] general protection ip:7f0e04f4b986 sp:7fff8e254370 error:0 in libsoundmenu.so[7f0e04f42000+14000] [12:05] any idea what i have to restart to get away without reboot>? [12:05] didrocks: I'll ping charles about this merge, it's his code and I'll let him make the decision [12:06] asac, not sure, the indicator shouldn't break the device, maybe that's lower in the stack that the bug happened, e.g pulseaudio [12:06] larsu: thanks! [12:06] asac: most of the time, I kill the HO plugin and pulseaudio [12:06] then, opening the HO tab and it's working [12:09] didrocks hi [12:09] hey ritz ;) [12:09] didrocks users would find this less stressful [12:09] hmm... let me see net call [12:10] thx seb128 didrocks [12:10] next call [12:10] the HO man :) [12:10] for vino/dconf key === MacSlow|lunch is now known as MacSlow [12:12] ritz: well, dconf-editor isn't something people should really rely on if they get stressed :) I feel then the warning in vino more annoying that the bug itself [12:13] one will not see any warning until unless the wrong value is keyed in [12:13] in which case, vino would ignore this [12:13] as would most gnome apps [12:14] didrocks , hmm, I assume we would treat this as a bug in all other apps then ? [12:14] or we need to "fix" this warning [12:15] ritz__: right, I think this is what seb128 asked as well [12:18] hmmm [12:23] didrocks, ritz__: well, looking in dconf-editor most apps don't restrict the choice of values, so I guess it's ok to let a string and warn if the value is wrong, in practice only power users go tweak the value directly... [12:26] seb128 agreed. the issue being, this was a bug with vino where choices was listed for dconf key, when it aint supposed to be [12:27] and this allows admins ( who use dconf editor) to work [12:29] can someone check if they can add a new Google account in UOA? [12:30] I get Error:invalid_request [12:30] Invalid response_type: code%26access_type%3Doffline%26approval_prompt%3Dforce [12:30] in saucy ? [12:30] yeah [12:30] yup [12:30] fails for me to [12:30] ta [12:30] kenvandine: ^ know anything about this? [12:31] http://stackoverflow.com/questions/14876204/error-invalid-client-when-following-five-minute-quick-start-for-php [12:32] issue on server side ? [12:47] pitti: why do you want it? :) [12:47] desrt: I don't, but zyga was asking about it in #u-devel, so I'm forwarding here as you aren't there [12:49] Laney, yes... that should be fixed now [12:50] Laney, that was why i added that patch to eds [12:51] Laney, the service file that eds provided was adding that... my worked last week ... [13:02] Laney, i can still add a google account [13:04] laney grep Resp /usr/share/accounts/services/* [13:07] sil2100: back? all published? :) [13:07] didrocks: yep! [13:07] :) [13:07] didrocks: I'm checking the webcreds stack now though [13:07] excellent :) [13:08] Since that one was left [13:08] maybe kenvandine can help? [13:08] I think it's fine, the diff looks good [13:08] ok :) [13:08] http://10.97.0.1:8080/view/cu2d/view/Head/view/WebCreds/job/cu2d-webcred-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_account-plugins_0.11daily13.06.12-0ubuntu1.diff <- could you ACK :) ? [13:09] sil2100: sounds good to me [13:09] sil2100: so then, it's on the red side again? (unity/hud/indicators) [13:10] HUD, indicators, unity and webapps - HUD fails to build, waiting for Wellark or tedg, I see tedg is here so I'll poke him now [13:10] The rest I shall check check [13:10] and check? ;) [13:10] sil2100, yup [13:10] sil2100, i am publishing it now [13:10] kenvandine: publishing webcreds? [13:11] Ok ;) [13:11] tedg: boing [13:11] * tedg puts on his spring-proof suit [13:12] tedg: a hud test is failing, oh noes! It seems like it's bamf related, since armhf passes [13:12] sil2100, The ones from yesterday? those seemed like BAMF to me. At least it's the one throwing up error messages. [13:12] tedg: https://launchpadlibrarian.net/142214118/buildlog_ubuntu-saucy-amd64.hud_13.10.1daily13.06.12-0ubuntu1_FAILEDTOBUILD.txt.gz [13:13] tedg: actually, this time it's failing to build, as there's a unit test failing as well [13:13] tedg: test-application-list [13:13] Hmm, I started getting that error on another branch last night. [13:13] Bother. [13:13] At least that confirms it's a saucy issue and not my branch. [13:13] Maybe there are some changes in bamf lately? [13:14] sil2100, Yes, it's basically rewritten with the migration to gdbus [13:21] tedg: will you take a look? Give me a sign once this is resolved and I will re-run the stack then ;) [13:22] tedg: would be nice to have a HUD release soon, since a lot of stuff has been changing lately [13:22] tedg: hud and unity are rather tightly bound so we can't release one without the other [13:22] sil2100, Sure, but I think this is only an issue with the tests. I don't think it'll fix the stack issues you saw yesterday. [13:23] sil2100, Not really... I mean they only share one API that hasn't changed in over a year. [13:42] Laney, http://paste.ubuntu.com/5758253/ [13:42] Laney, that's a small patch for your background panel (the personal category works with ubuntu-system-settings trunk) [13:42] Laney, I've also dropped the entry since according to the design that panel is an icon in the grid [13:46] attente: ping [13:47] sil2100, pong [13:47] attente: on the indicator stack, it seems we get some u-g-m AP test failures, could you take a look? [13:47] attente: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/94/testReport/ [13:48] sil2100, sure [13:48] Laney, the updates that just landed include [13:48] account-plugins (0.11daily13.06.12-0ubuntu1) saucy; urgency=low [13:48] [ Alberto Mardegan ] [13:48] * Fix Google authentication, which was broken with the lasted QUrl query [13:48] handling in Qt5. [13:48] Laney, that might fix your "can't add google accounts" [13:48] attente: thanks! [13:52] seb128: thanks, will apply that [13:52] I could push my junk branch to something under that team as well [13:52] Laney, I don't think you can do merge request against junk [13:52] no, but then you could commit [13:53] Laney, you should probably just merge it in u-s-s if you want peer reviews for commits, etc [13:53] well, once you are happy enough with the first codedrop [13:53] sure [14:05] sil2100, what autopilot version is jenkins using? [14:06] attente: I would have to check, but I guess the latest one in lp:autopilot [14:07] sil2100, is there anything i can do to better replicate the jenkins test environment? [14:09] attente: it's using autopilot 1.3.1daily13.06.12-0ubuntu1 if anything - you can check the package list if anything [14:09]