=== Aww is now known as AWW === AWW is now known as Aww [02:19] highvoltage, does anyone knows if there is a way to run macchanger on my wlan0 interface, before wlan0 is up ? [02:21] prompt32: you'll probably have better success in #ubuntu [02:23] sarnold, i'll try, thanks [05:36] didrocks: morning! it seems doko's attempt at increasing the amount of multi-arch in Qt (https://lists.ubuntu.com/archives/saucy-changes/2013-August/007559.html) is breaking builds [05:36] for example https://launchpadlibrarian.net/147043226/buildlog_ubuntu-saucy-i386.ubuntu-ui-toolkit_0.1.46%2B13.10.20130808-0ubuntu1_FAILEDTOBUILD.txt.gz [05:36] so I think revert would be needed [05:37] Mirv: hey! this is not just an arch mismatch? [05:37] (I just overlook, if you think we should revert, let's revert) [05:37] didrocks: I don't exactly understand what's getting broken in there, can you? [05:38] but it seems something got broken, whatever way it did [05:38] and same for qtubuntu-camera https://launchpadlibrarian.net/147043988/buildlog_ubuntu-saucy-armhf.qtubuntu-camera_0.3.3%2B13.10.20130808-0ubuntu1_FAILEDTOBUILD.txt.gz [05:39] the bug he's trying to address is https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1209239 [05:39] Ubuntu bug 1209239 in qtchooser (Ubuntu) "MultiArch support for QT5 is insufficient for cross building" [Undecided,Confirmed] [05:40] Mirv: hum, did you try to upgrade/install like qt5-qmake locally? [05:40] it reads there "dependencies on qtbase5-dev-tools and qt5-qmake must have an :any suffix." [05:40] didrocks: everything did update correctly this morning for me, so maybe it's those build-depends (on all packages)? [05:41] it's a bit invasive change, even if it'd be correct technically [05:42] hum [05:43] Mirv: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [05:43] we can refind the same issue in what is blocking Qt5 in proposed [05:44] ah, qtbase was uploaded as well [05:44] this issue is clearly: [05:44] qt5-default/i386 unsatisfiable Depends: qtchooser:any [05:44] * didrocks wonders why [05:44] and then, all the cascades is because of that [05:48] grrr, I don't understand [05:52] yeah proposed qtbase update gives the error http://pastebin.ubuntu.com/5961461/ [05:52] goes above me as well [05:53] so, why :any? [05:53] - qt5-qmake (= ${binary:Version}), [05:53] - qtbase5-dev-tools (= ${binary:Version}), [05:53] - qtchooser, [05:53] + qt5-qmake:any (= ${binary:Version}), [05:53] downgrading qtchooser to 26-3ubuntu1 does not allow qtbase upgrade either [05:53] + qtbase5-dev-tools:any (= ${binary:Version}), [05:53] + qtchooser:any, [05:53] argh [05:54] but this is invalid… [05:54] Mirv: yeah, the issue is in qt5 [05:54] Mirv: not sure what he wanted to do with :any [05:54] let me remove that [05:54] Mirv: was his change committed to any vcs? [05:54] ok [05:54] let me see [05:54] or should I just apt-get source + upload? [05:55] didrocks: no, does not seem to be in ubuntu branches nor in ~kubuntu-packagers [05:56] Mirv: ok, let's do 2 things [05:56] Mirv: for unblocking, I'm going to remove the dep on -proposed, ok? [05:56] (build-dep) [05:56] so that you can restart building everything [05:56] didrocks: ok. [05:56] and relaunching the stacks with foo [05:56] just after that, I'm going to upload the fix for Qt [05:58] Mirv: ok, please relaunch the builds [05:58] Mirv: proposed disabled in the tests as well [05:59] * didrocks now goes to fix Qt5 [05:59] didrocks: ok [06:00] hey didrocks [06:00] Mirv: then, do you want me or you to send an email to the ML? [06:00] hey cyphermox [06:05] Mirv: revert uploaded [06:05] (not a full revert, just the :any thing) [06:05] didrocks: I can, although which ML? [06:05] chrisccoulson: hey, you having issues with your funky bluetooth hid2hci keyboard thing on saucy? [06:05] Mirv: the phone one [06:05] ok, will do [06:05] chrisccoulson: seems to me like you should, the bluez udev rule looks to me like it should be just failing [06:05] Mirv: just tell that dailies will be really delayed as we disabled proposed, but rebuild everything [06:06] Mirv: we'll ask for an iso resping [06:06] (do not hesitate to link to the 2 qt version, the faulty one and the fixed one ;)) [06:06] thanks Mirv! [06:12] Mirv: does this looks good to you? https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3 [06:15] didrocks: looks excellent, I think that has been longed for a lot [06:16] Mirv: yeah, until we have an automatic dashboard, it's a good workaround :) [06:16] Mirv: so, filing this in now? maybe let's wait from the rebuild without -proposed first [06:16] Mirv: you are relaunching all stacks failing with "foo" (one you restarted the build)? [06:16] can I help? [06:18] didrocks: added tentative date until which osomon will be contacted instead of bfiller, based on yesterday's note that Bill is on holiday for "two weeks" (not sure which two weeks, but probably this and next) [06:19] didrocks: filling in, yes, and relaunching the failed stacks - so far only media and sdk and now filling in the chart [06:20] Mirv: yeah, I guess this one and next :) [06:21] Mirv: just tell me if I can be of any help [06:21] didrocks: open my head and grab some things from there :) [06:21] ahah, that's part of the issue ;) [06:22] didrocks: any idea how that thing that hit seb128 is now for unity? https://launchpadlibrarian.net/147049488/buildlog_ubuntu-saucy-armhf.unity_7.1.0%2B13.10.20130808-0ubuntu1_FAILEDTOBUILD.txt.gz /system/lib/libGLESv2.so' not found [06:23] didrocks: I'm opening the 'head' job and clicking build now instead of the 'foo' method, which I thought would only run tests and not rebuild the pacakges [06:23] Mirv: hum, previous qtbase brought hybris on the base image [06:23] Mirv: it will force rebuilding the packages [06:24] didrocks: and that's what failed, building the packages? [06:24] as it's what intended by that [06:24] ah, foo does that, if they haven't built? [06:24] ok, basically, if you don't do anything, the build will: [06:24] - scratch the current workspace [06:24] - redownload everything [06:24] - see if anything isn't in distro [06:24] - build from that [06:25] if you file "BUILD_ONLY" [06:25] - it won't scratch the current workspace for that stack [06:25] - it will remove all the components that match BUILD_ONLY list [06:25] - and so, only compare if anything new available and upload that [06:25] the whole stack is tested in both cases [06:25] making sense? [06:26] if you rebuild the whole stack, not a biggie anyway [06:26] (just some CPU cycles lost ;)) [06:27] (doing apps) [06:28] REBUILD_ONLY, you mean? yeah, it seemed to me that eg. in media the only package that had changes was also the only package that failed, so just plain 'build' seemed like doing the right thing except for of course the CPU cycles checking statuses :) [06:28] didrocks: commenting out not working for -proposed: http://10.97.0.1:8080/job/autopilot-saucy-daily_release/814/label=autopilot-intel/console [06:29] for tests [06:29] Mirv: so plain rebuild is fine in that case, yeah ;) [06:29] Mirv: oh, sorry, ok, let me remove the file one sec [06:29] Mirv: done [06:30] Mirv: in that case, for sdk, you can just use "foo" for REBUILD_ONLY, sdk doesn't need to be rebuild now, we're just interested in testing [06:30] * didrocks relaunches media with "foo" [06:31] ok, thanks [06:31] you're doing it for sdk? [06:31] yes [06:31] running [06:31] rebuilding unity-webapps-qml for webapp [06:32] ok, now, let's wait for the result and update the spreadsheet [06:44] I'd hope someone at google would add the links possibility for pieces of text inside a field [06:46] Mirv: you mean, like ellipsis and when you click on it, it expands? [06:47] didrocks: I mean, if I've an URL in a field and other text, the URL would still act as a link [06:47] oh right, sometimes it works, sometimes not [06:47] I never understood the pattern [06:47] oh it works sometimes? then there should be some trick. I know something worked at one point when I copy-pasted from elsewhere [06:47] yeah, sometimes, it's recognized as a link [06:48] that's really weird… [06:48] I tried it now but it didn't help, ie. having clipboard content with html [06:48] =hyperlink() [06:49] or something.. trying [06:50] ah, that's probably also something that only works alone [06:52] right [06:54] didrocks: should media be now able to publish itself automatically, as it depended (and halted) on SDK which now published successfully? [06:55] Mirv: hum, interesting, maybe both were published at the same time? [06:55] Mirv: let me fake SDK publishing [06:55] Mirv: ah, it's because we build SDK after media [06:56] Mirv: so for safety, there is no automatic publishing (like if there is an ABI break) [06:56] not an issue with the sdk as it's a runtime dep [06:56] and there is nothing in the pipe breaking, right? [06:58] no [06:59] ok, so let me fake a publish on sdk [06:59] you will see that then media is running [06:59] and just curious, since I noted that media had halted 20 mins ago because sdk failed to publish, and then 10 minutes ago sdk published successfully [07:00] Mirv: right, so sdk was built after media [07:00] yep, now it published media [07:00] yeah: [07:00] 2013-08-08 06:59:36,179 INFO Considering publishing: media (head) [07:00] 2013-08-08 06:59:36,190 INFO media (head) may be publishable, trying it [07:00] Mirv: basically, it's a safety net [07:00] like imagine, you have indicators in manual publication because of HUD [07:00] which is good [07:01] then, you *rebuild* (not just publish) HUD [07:01] maybe HUD has an ABI break [07:01] and so if we publish HUD and indicators, things will go ugly :) [07:02] so the automated publication is only rolled out if no rebuild was involved in the stack declenching the others [07:02] sorry, not sure I'm clear… [07:05] yes, makes sense [07:10] good morning [07:10] didrocks: during the night there had been yet another packaging request from mhall119, added to the sheet. not really sure about anything else but the url (poppler-qml-plugin), but I assume it'd be wanted to saucy and sdk meta package [07:10] salut jibel [07:10] Mirv: right, sdk stack sounds good to you? [07:11] didrocks: yes, I'm just not sure what has happened some of the other community apps sources, ie are they wanted in daily release or separately [07:11] and has it been some other team uploading those [07:11] I think for the apps, they are click packaging [07:11] so not really in distro [07:11] ah, right [07:11] for the bindings, we are handling those [07:12] (I can be fully wrong ;)) [07:12] so then I remember at least one file manager related QML plugin, I'd need to check where that is flying around [07:12] but yes they should go to the saucy, if they're wanted to be part of the supported platform [07:15] right [07:15] salut didrocks [07:16] Mirv: waow, apps passed the tests! [07:17] Mirv: I think there is nothing blocking on webapps, do you think we should publish it? (force the publication?) [07:18] didrocks, is there any stack left to release after phone and settings? I'd need to restart jenkins to increase the number of slots. It has not been done during the night. [07:18] jibel: I think it will be fine, right Mirv? ^ [07:20] jibel: noooo [07:20] jibel: if you do that publisher and so on won't work [07:20] as it's a new job [07:20] * didrocks cancels [07:21] I canceled [07:21] I don't have anything special ongoing there now [07:22] didrocks: despite the webapps-qml failing tests? [07:22] didrocks: I do know they assume it's a jenkins / test environment issue [07:22] Mirv: yeah, I looked the commits since last release, the changes seems unrelated [07:22] if that's fine, then yes would be great [07:22] Mirv: just to be clear: I won't publish webapps-qml [07:23] (the webapps stack) [07:23] just the apps stack [07:24] didrocks: yeah, I noticed you wrote that apps passed tests and then asked about publishing webapps, so I was unsure what you meant [07:24] Mirv: yeah, the "it" was apps, not webapps, sorry ;) [07:24] funny that gallery-app passed now [07:25] well, Günter had made one commit [07:25] yeah [07:25] it was for that :) [07:25] Mirv: ok, do you mind refreshing the status for all stack (but phone, as we are waiting for it), now? [07:25] ah phone done! [07:25] jibel: you can restart as soon as Mirv finishes to note the status [07:26] didrocks, k, I found another interesting hobby [07:27] didrocks: ok [07:29] didrocks: ok all seems at pause and stack status page up-to-date [07:30] Mirv: \o/ [07:30] big thanks [07:30] jibel: restartttttttt ^ [07:30] Mirv: oh, you should maybe mention the click package issue [07:30] in the "not blocking release" [07:31] the last commit wasn't merged? [07:31] didrocks: yeah I was just about to ask about the click packages [07:31] since I haven't glanced at it before [07:32] "A version (0.1+13.10.20130808-0ubuntu1) is available at the destination for that component but is not in trunk which is still at 0.1+13.10.20130727-0ubuntu1. Ignoring that component for source: unity-scope-click, branch: lp:unity-scope-click, series: saucy. [07:32] didrocks: ok marked it down for now, yes it seems [07:32] " [07:32] didrocks: I've been now trying to write this to you for 10 minutes but I'd need some review/thoughts on lp:~timo-jyrinki/+junk/qtcreator-plugin-ubuntu-common [07:32] Mirv: mention that latest MP isn't merged apparently [07:32] :) [07:32] Mirv: ahah, ok, let me give RAOF the ATI machine for testing Mir [07:32] and then, I'm on it, ok? [07:33] we tested and released Qt Creator update for precise, quantal and raring, and saucy archive upload would depend on getting the -common package in first [07:33] didrocks: that's fine :) [07:33] excellent! [07:33] did we settled on having the source as qtcreator-plugin-ubuntu thought? [07:33] or this is just the branch name being wrong? [07:33] zoltan still hesitated on renaming the source without -common, but I can change that for saucy [07:34] Mirv: yeah, please do, I think it makes sense to prepare for the future [07:34] yeah, changing that [07:34] at least we got rid of the -data binary packages now [07:35] sweet! [07:35] jibel: Mirv: I'm blocking the ati machine right now to have RAOF debugging Mir [07:36] and now I go see about thomi's qtbase patch [07:36] oh, or.. maybe a coffee break, to keep sanity which is usually beneficial [07:38] heh ;) [07:38] Mirv: enjoy! [07:38] proposed reenabled FYI on both test machine and builders [07:40] didrocks, jenkins is bakc [07:40] back [07:40] thanks jibel [07:41] good morning desktopers [07:41] didrocks, with 50 excutors on master which should be enough to trigger all the stacks, if it is not I'll increase it a bit more [07:41] I guess the side effect is only memory consumption [07:41] Salut seb128 [07:42] lut jibel didrocks [07:44] salut seb128! [07:44] jibel: yeah, let's see how it goes [07:45] didrocks, Mirv: I've read the backlog on irclogs.u.c, I'm looking at the unity issue [07:45] seb128: I think it's the same than the settings one [07:45] seb128: FYI, I disabled proposed [07:45] didrocks, I guess some other packages got the libhybris shlibs depends by rebuilding with the broken mir yesterday [07:46] during those builds [07:46] didrocks, no, it's not, unity7 doesn't build-depends on qt [07:46] yeah, it's not the Qt issue for sure [07:46] seb128: thanks for investigating, I'm already under the water :) [07:53] seb128: yes, same error there, thank you for looking at i [07:54] t [07:57] didrocks, Mirv: I'm not convinced that the "rebuild without proposed" is a good thing [07:57] seb128: was the only way to get the thing unblocked timely [07:57] seb128: see my followup email, it's enabled again [07:57] that's going to bring in your build the qtbase which depends on libhybris [07:57] and you might get extra libhybris depends through shlibs [07:57] we are never going to get out of it if we do that [07:58] we can then do a new build today (with the new daemon) [07:58] even forcing some if needed [07:58] I hope it's not going to add libhybris depends to extra components make things harder to untangle [07:58] let's see, the set of components are quite limited [07:58] so it's easy to look at them [07:58] ok [07:59] I didn't want to again block everything for 5 hours for Qt [07:59] especially as upstream is pressuring to get some stuff released [07:59] well, blocking is better than creating extra chaos which is going to take a week to sort out [07:59] but let's see [07:59] seb128: I don't have time to argue on this. I agree, but then, it's not you taking the backfire :) [07:59] see the discussions from yesterday when they want to publish even if tests fail… [08:00] well, you are going to take double backfire when hybris screw us for the next days [08:01] didrocks, shrug, the new https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4859696/+files/qtdeclarative5-ubuntu-ui-toolkit-plugin_0.1.46%2B13.10.20130808.1-0ubuntu1_armhf.deb won a depends on libhybris [08:01] that's what I though [08:01] didrocks, we are putting ourselve down in a hole there :/ [08:02] seb128: you're welcome to retrigger a rebuild once my qtbase is built [08:02] if only people were testing before uploading… Not having qt installable is a shame [08:02] it's going to play whack a mole to rebuild things in right order [08:02] right, I agree with that [08:03] seb128: quite easy, let's wait for things being in the release pocket [08:03] then, we can do an apt-cache rdepends [08:04] and rebuild what's needed [08:04] (even if there is no new commit) [08:04] ok [08:04] that's going to take some 6 hours [08:04] let's see this afternoon [08:04] well, qtbase to build will take that time anyway :p [08:04] right, that's what I was saying [08:04] 6 hours of build + 1 publish cycle [08:05] yep [08:05] we're fine, because what's depending on those components are already in dailies [08:05] so under our control to rebuild [08:06] and we already had powerd and other stuff depending on it, for maybe no good reason [08:06] so, it's time to clean that up [08:11] seb128: but that doesn't explain the unity issue, right? [08:13] didrocks, no, I'm debugging that one next, that's why landing/rebuilding more stuff is making me nervous, new things get the depends [08:14] didrocks, powerd&co might be actually be using it to access android features [08:14] seb128: yeah, I propose we make a list once everything is published in the release pocket [08:15] and go one by one [08:15] I see others which shouldn't already [08:15] so let's take that as an opportunity to clean things up [08:29] Mirv, didrocks: the unity issue is because the compiz rebuild from xnox on monday caught the libhybris depends [08:29] we need to rebuild compiz [08:32] seb128: the rebuild was ages ago, but i guess armhf was stuck FTBFS whilst compiler was getting fixed..... [08:33] xnox, it got published on monday [08:36] yeah: amd64/i386/powerpc build on 2013-07-01|02 whilst armhf finally built on 2013-08-05. [08:52] seb128: locally on armhf I still see that libhybris-common1 is still installed. Is that ok? [08:53] xnox, yes, the -common is fine, it's libhybris itself that divers libelg [08:54] seb128: ok, uploaded a no change rebuild. As far as I remember compiz daily release was stuck, although i guess it would now need manual packaging merge from myself. [08:55] (the version number bumps at least) [08:55] Right so the "update-alternatives: using /usr/lib/arm-linux-gnueabihf/libhybris-egl/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_EGL.conf (arm-linux-gnueabihf_egl_conf) in auto mode" is what we don't want =) [08:55] hopefully the new calxeda nodes should build compiz quickly =) [08:57] xnox, sorry, I just beat you at that no change rebuild I think :p [08:57] seb128: narf =) [08:57] seb128: bets on how long it will take to build? [08:58] xnox, qtbase took 2 hours instead of 6 before [08:59] firefox from 20h40 down to 5h40 [09:01] ogra_, see, it happened :p [09:03] didrocks, what's the deal with qmenumodel? I see it being daily released but it doesn't seem to be in distro yet? [09:04] seb128, heh, yeah [09:05] didrocks, nm, got confused by differeing source/binary package names [09:31] xnox, compiz build down to 37 min (from 1h35 on previous build) [09:32] \o/ [09:39] those speedups are awesome [09:40] I wonder what qtwebkit will be [10:03] Mirv: I relaunched what was depending on the wrong qtbase version [10:03] Mirv: relaunched as well unity as per new compiz ^ [10:18] ok [10:58] Mirv, you should be able to retry unity build, compiz is in saucy [10:59] seb128: ok, the previous one started 50 minutes ago will still result in armhf failure? [11:00] Mirv, let me check [11:00] seb128: it seems to have just finished successfully https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4860368 [11:00] Mirv, great, it just start at the right time [11:01] started [11:01] 13:03 < didrocks> Mirv: relaunched as well unity as per new compiz ^ [11:01] well it was the grand master who selected the timing [11:01] haha [11:01] subject: [ubuntu/saucy] compiz 1:0.9.9~daily13.04.18.1~13.04-0ubuntu3 [11:01] (Accepted) [11:02] Date: Thu, 08 Aug 2013 10:07:08 -0000 [11:02] so timing was just right it seems [11:02] or didrocks was pulling on rmadison to see if compiz was in to push the button :p [11:02] seb128: rmadison is my ennemy, I just checked at the right time I guess :) [11:03] ;-) [11:03] but the ati tests failed a bit, so tests will need to be rerun [11:03] seems you guys updated to poppler-0.24 in saucy, cool :-) [11:04] tsdgeos, yes, since we wanted the qt5 bindings ;-) [11:04] tsdgeos, and it's good to be on the current version [11:05] well, "current stable version" rather [11:06] now i only need to convince you to link it against openjpeg and the hell will freeze :D [11:06] haha [11:06] that's doko/MIR team that needs to be convinced, but yeah, that would be nice [11:07] tried that [11:08] afair the security team blocked on the fact that openjpeg had more CVE than that jpeg2000 library noone uses and noone develops that we ship [11:08] jasper [11:08] that one [11:08] I don't think they block it on because it more or less than the other one [11:09] but the fact that it has a record of having security issues is a problem for them, since they have to support it [11:09] tsdgeos, I'm going to have a look at updating to 1.5 [11:09] then when we can try asking the security guys again [11:09] well, jasper does not have security issues because noone looks inot it :D [11:09] seb128: but i have to agree openjpeg is less than stellar too [11:10] i think poppler regressed with some of the 1.x randomly [11:11] ha, they have a 2.0 out for some time [11:11] yeo [11:12] that's api incompatible though afair [11:12] fedora is still on 1.5 it seems, I wonder if that's for a reason or if they just didn't get to do the update yet [11:12] https://bugs.freedesktop.org/show_bug.cgi?id=58906 [11:12] Freedesktop bug 58906 in general "0.22.0 does not find openjpeg-2.0.0" [Normal,New] [11:13] ok [11:13] better to go for 1.5 rather then [11:13] that's what fedora/debian experimental have === MacSlow is now known as MacSlow|lunch [12:07] ok, it seems sdk and settings are already rebuilding after the new qt got published [12:07] Mirv: I ran them by hand [12:08] Mirv: then, unfortunately, unity tests are not finished yet [12:08] so we'll wait for the tests to finish [12:08] yes, it'll take some time [12:08] more autopilot machines wouldn't hurt [12:10] ok, qtbase in the release pocket [12:18] and no more libhybris in qtdeclarative5-ubuntu-ui-toolkit-plugin_0.1.46+13.10.20130808.2-0ubuntu1_armhf.deb \o/ [12:25] didrocks, great! === MacSlow|lunch is now known as MacSlow [12:30] now, waiting on unity test to finish, I rebuilt manually all the rest in ppa, so just waiting for the tests [12:46] robru: in addition to the new package, can you work on the webapps AP tests failure with upstream? [12:46] as you can see on https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dHFtUmlPOUtCRk8zR2dtaEpIbUVhMmc#gid=3, there is a link [12:46] it's blocking for quite few days [12:47] didrocks, yeah, I pinged vrruiz about that already and he says he's been working on it. I think the problem is that it's alex's bug, but he's on vacation, so victor is struggling with incomplete info. [12:47] robru: any ETA? Can you escalate that to Pat? [12:48] robru: he asked to know everything when we are blocked (and he's the contact in the spreadsheet) [12:48] didrocks, no idea. I can escalate if you want. [12:48] robru: please do :) [12:49] thanks! [12:49] didrocks, you're talking about pat mcgowan, right? [12:49] right [12:49] (he isn't online yet apparently) [12:49] robru: are the packages fixed? at least the cu2d part? [12:49] didrocks, ok, I just pushed updated packages: lines for that MP. can you check that it is the way you want it? [12:49] robru: as we are going to redeploy everything to add the new machine, would be nice to have the right config :) [12:49] ok [12:50] https://code.launchpad.net/~robru/cupstream2distro-config/qtdbus-in-qa/+merge/179159 right? [12:51] robru: approved [12:51] didrocks, sweeeeeete [12:51] didrocks, should I redeploy or are you doing that? [12:52] robru: jibel has to redeploy for the machines, so don't worry :) [12:52] robru: I'm pulling on lillypilly as well [12:52] for refreshing the whitelist [12:53]