[00:04] <ecinx3> i can't find the power adapter to my switch :(
[01:36] <jjesse> evening
[02:59] <ScottK> Anyone packaging bluedevel 1.0.2?
[03:04] <ScottK> Oh, nevermind.
[04:45] <rbelem> clear
[04:45] <rbelem> oops
[04:47] <afiestas> rbelem_: ping
[04:48] <rbelem_> afiestas, pong
[04:48] <afiestas> rbelem_: http://paste.ubuntu.com/569918/
[04:48] <afiestas> I'm using Kubuntu Natty
[04:49] <rbelem_> hum...
[04:50] <rbelem_> afiestas, do you have samba installed?
[04:50] <afiestas> samba-common and samba-common-bin
[04:50] <rbelem_> afiestas, should i replace the kWarning by kDebug
[04:51] <afiestas> is that a question?
[04:51] <rbelem_> afiestas, if you open dolphin
[04:51] <rbelem_> afiestas, yup
[04:51] <afiestas> well it depends if it is critical or not, if networkmanagement/filesharing is installed and samba is missing... then it should be a warning imho
[04:52] <afiestas> also, you may want to check if samba is installed at build time, even if it is not needed to build the package (runtime-dependency)
[04:52] <afiestas> also, kdenetwork/filesharing/simple is an empty folder (did you forget to remove it?)
[04:52] <rbelem_> afiestas, are you using the kdelibs and kdenetwork packages or git?
[04:53] <rbelem_> afiestas, i made a git rm simple
[04:53] <afiestas> the packages
[04:53] <rbelem_> afiestas, then git svn dcommit
[04:54] <rbelem_> afiestas, i thought that cmd would remove the dirs too
[04:54] <afiestas> well, git-svn afaik is not a supported way of doing things :p be careful when using it
[04:54] <afiestas> commited (the file deletion)
[04:54] <rbelem_> afiestas, :-)
[04:55] <rbelem_> afiestas, the dolphin samba fileshare plugin only works with samba installed
[04:58] <afiestas> rbelem_: so, kdenetwork/filesharing can be build without samba but (atm) can't work without it?
[04:58] <afiestas> I said atm since samba is the only supported protocol right now
[04:58] <afiestas> rbelem_: shoudl advanced folder be removed too?
[04:59] <rbelem_> afiestas, yup
[04:59] <rbelem_> afiestas, it displays a message if samba is not installed
[05:02] <rbelem_> afiestas, i just forwarded to you a mail i sent to dfaure
[05:02] <rbelem_> afiestas, some files that are deprecated
[05:04] <afiestas> rbelem_: so, svn rm advanced; svn commit ? (just to be totally sure D)
[05:04] <rbelem_> yup
[05:05] <rbelem_> :-)
[05:10] <afiestas> rbelem_: so apart from samba-common and samba-common-bin what do I need?
[05:10] <afiestas> also, would the kdenetwork/filesharing changes be backported to Natty?
[05:10] <rbelem_> afiestas, the samba pkg
[05:11] <rbelem_> afiestas, yup
[05:12] <rbelem_> afiestas, i will ask Riddell if he will do the packport else i ll do
[05:13] <afiestas> nice :p
[05:13] <afiestas> can't wait
[05:14] <rbelem_> :-D
[05:15] <rbelem_> afiestas, i will work these days to make the kcm
[05:15] <afiestas> I just implemented the sharing stuff in bluedeivl kdm
[05:15] <afiestas> *kcm
[05:16] <rbelem_> afiestas, nice :-)
[05:16] <afiestas> and I'm adding a KPropertiesPlugin right now (we should unified them somehow in the future)
[05:18] <rbelem_> afiestas, when is 4.7 freeze?
[05:18] <afiestas> April iirc
[05:19] <afiestas> http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule
[05:19] <afiestas> May 12 is the hard freeze
[05:19] <rbelem_> afiestas, hum... we have time to unify :-)
[05:20] <afiestas> yes, we need to have that meeting to write down what we're missing (stuff like KFIleItem overlay) and start to work on it
[05:22] <rbelem_> afiestas, will we have different icons for each fileshare method?
[05:22] <rbelem_> or just one?
[05:22] <afiestas> mm, dunno
[08:14] <afiestas> agateau: ping
[08:14] <agateau> afiestas: pong
[08:14] <afiestas> *non agateau question:
[08:15] <afiestas> is there any PPA to get kdepim  master or at least last 4.6 beta?
[08:15] <afiestas> agateau: I'm testing the globalmenu integration in firefox/thunderbird
[08:15] <afiestas> and it seems to do not work under KDE :/
[08:15] <afiestas> dunno if it is because of our implementation or because the firefox plugin sucks :p
[08:15] <ulysses> https://launchpad.net/~kubuntu-ppa/+archive/experimental maybe
[08:18] <agateau> afiestas: I haven't tried it yet. What's the name of the package?
[08:19] <afiestas> agateau: http://askubuntu.com/questions/21373/how-can-i-get-firefox-to-work-with-the-global-application-menu
[08:20]  * agateau installs
[08:23] <afiestas> agateau: during this week I will start to think how to integrate the "Action Search" into kdelibs properly, once pushed I'd like to apply the same concept to the globalmenu plasmoid
[08:23] <afiestas> if you like the idea
[08:24] <afiestas> http://www.afiestas.org/improving-kde-applications-help-menu-actions-lookup/ <-- that thing I mean
[08:24] <agateau> afiestas: mmm the necessary work in dbusmenu-qt to support this as not been done :(
[08:25] <afiestas> agateau: well, we're not exporting all actions, but at least we're exporting the menubar
[08:25] <agateau> afiestas: I mean the line edit won't work with dbusmenu
[08:25] <afiestas> so in theory I should be able to apply almost the same code
[08:25] <agateau> afiestas: appmenu firefox extension works fine here btw
[08:26] <agateau> afiestas: but there is a pending dbusmenu update which could break it, I may be lagging
[08:26] <afiestas> my idea was to implement it directly into globalmenu-plasmoid (not by exporing the lineedit)
[08:26] <agateau> afiestas: not sure I like that
[08:28] <afiestas> agateau: oks
[08:29] <afiestas> I'm installing *dbusmenu* maybe I was missing some dep
[08:30] <afiestas> nope, still not working :/
[08:32] <agateau> afiestas: it is highly possible latest dbusmenu-glib broke it, ted told me he would push a new version on friday, which features a new signal I need to add to dbusmenu-qt
[08:34] <afiestas> agateau: okz, I will uninstall the thunderbird/firefox extension atm
[08:36] <afiestas> agateau: another small issue I have, when plasma is launched and there are some applications already, the menubar of that apps is not correctly exported (or painted)
[08:37] <afiestas> the toplevel items are showed, but the menus are empty
[08:37] <afiestas> gedit is not even trying to export the menu... maybe I'm missing some dep :/
[08:38] <afiestas> dpkg -l | grep dbusmenu : http://paste.ubuntu.com/569963/
[08:41] <agateau> afiestas: for gtk apps you need the appmenu-gtk package
[08:46] <afiestas> agateau: still gedit is not exporting anything
[08:46] <afiestas> maybe I need some env variable?
[08:47] <agateau> "afiestas: it is highly possible latest dbusmenu-glib broke it, ted told me he would push a new version on friday, which features a new signal I need to add to dbusmenu-qt"
[08:47] <agateau> same problem I guess
[08:47] <afiestas> ooks, won't say anything more until you have time to test it with the latest dbusmenu-glib :p
[09:40] <bambee> morning
[13:42] <Riddell> hi rbelem, how confusing to have a share dialogue also in kdelibs!
[13:42] <rbelem> Riddell, crazy stuff
[13:43] <rbelem> Riddell, looked everywhere before going to kdelibs
[13:44] <Riddell> rbelem: will you remove it from git?
[13:44]  * rbelem is checking if dfaure answered his mail
[13:45] <rbelem> Riddell, i'm not sure, maybe remove the entire file :-D
[13:45] <rbelem> Riddell, we do not need that anymore, as far as i tested
[14:05] <rbelem> Riddell: all those ui stuff in kio does make libkio bigger than it should be?
[14:07] <Riddell> I only see two, I doubt they add significantly to it
[14:11] <rbelem> Riddell: do you know dfaure irc nick?
[14:11] <Riddell> "dfaure" :)
[14:11] <Riddell> not online today it seems
[14:11] <rbelem> :-(
[14:12] <Riddell> I don't think kfilesharedialog.cpp can be removed, it's part of the kdelibs API :(
[14:12] <Riddell> I think this will do in the packaging for now, just to hide it http://paste.kde.org/5520/
[14:13] <Riddell> but I don't know what the best answer is for kdelibs upstream, maybe the same and a big "deprecated" at the top
[14:15] <rbelem> Riddell: let's return in the top of the constructor :-D
[14:15] <rbelem> Riddell: oh... the API...
[14:16] <rbelem> Riddell: how could we deprecate that?
[14:17] <rbelem> Riddell: adding a method show and move the line properties->setFileSharingPage(d->m_vBox); to there?
[14:18] <Riddell> using KDE_DEPRECATED I think
[14:18] <Riddell> we don't want it to show ever, it's useless code now
[14:18] <rbelem> Riddell: hum... and fix who is calling it
[14:19] <Riddell> I think the only thing using it would be code you've removed from kdenetwork
[14:20] <rbelem> but someone else is calling it too
[14:20] <Riddell> something else is using kfilesharedialog.cpp ?
[14:21]  * rbelem is grepping the code for KFileSharePropsPlugin
[14:22] <Riddell> I doubt it, I can't see why that class would be in kdelibs at all
[14:22] <rbelem> found it! kdelibs/kio/kfile/kpropertiesdialog.cpp
[14:23] <rbelem> Riddell: i think that it should live somewhere than kio
[14:23] <rbelem> the files that i opened date 2001
[14:24] <rbelem> lot's of old code
[14:28] <Riddell> bambee: a couple more issues with language-selector there
[14:28] <rbelem> Riddell: http://paste.kde.org/5523/
[14:28] <bambee> Riddell: I saw that on launchpad
[14:28] <rbelem> Riddell: that is the piece of code to be removed
[14:28] <bambee> I'll fix issues this evening
[14:29] <Riddell> bambee: thanks :)
[14:29] <bambee> Riddell: btw when language-selector-kde will be merged probably we could change it in kubuntu-desktop dependencies ?
[14:30] <bambee> Riddell: thanks for your time ;)
[14:30] <bambee> (kubuntu-desktop depends on language-selector-qt actually)
[14:30] <Riddell> bambee: yes we'll need to change that, it's not hard
[14:30] <bambee> ;)
[14:33] <rbelem> Riddell: should i use KDE_DEPRECATED for each method?
[14:33] <rbelem> Riddell: can i use that for the entire class?
[14:33] <bambee> btw, I did not found it but... does "kdebug" exist in python ?
[14:34] <Riddell> rbelem: I'm not too sure about the syntax, it's the whole class which should be deprecated but you'd probably need to ask or search for the exact syntax
[14:34] <bambee> (nothing in doc nor in python console using completion)
[14:34] <Riddell> rbelem: it'll need those ifndif KDE_NO_DEPRECATED too I guess
[14:34] <bambee> probably I'm wrong...
[14:34] <Riddell> bambee: seems kdebug isn't in pykde indeed, which is strange, it's useful to have debugging you can turn on/off at runtime
[14:34] <rbelem> oki
[14:35] <bambee> Riddell: exactly... it's strange
[14:35] <bambee> ok
[14:45] <rbelem> Riddell: just commited the fix
[15:07] <rbelem> Riddell: did you notice that device notifier applet does not eject the device just umount?
[15:09] <Riddell> rbelem: I did not, but I don't tend to use CDs much except for distro installs
[15:18] <Riddell> rbelem: packages are working!
[15:19] <Riddell> rbelem: I think the properties dialogue should close when it calls packagekit install, else it just stays there offering to install samba
[15:19] <markey> http://www.linuxuser.co.uk/opinion/banshee-canonical-and-how-to-earn-an-honest-living-in-open-source/
[15:19] <markey> article by Jos Poortvliet
[15:19] <Riddell> clearly an unbiased source :)
[15:19] <markey> on the Amazon music store debacle
[15:19] <markey> well, come on
[15:19] <markey> what Canonical is doing there is ridiculous
[15:20] <markey> if they try that with Amarok, I will get very very angry
[15:20] <markey> you don't want that
[15:21] <Riddell> I'd be against doing it in Amarok of course
[15:21] <Riddell> but Canonical does have to make a living, it's unfortunate when that conficts with upstream
[15:22] <rbelem> Riddell: that's true... I will fix that
[15:22] <Riddell> rbelem: also i think I'll e-mail the packagers list to tell them they may need to change that if they don't use KPackagekit
[15:24] <rbelem> groovy :-)
[15:27] <rbelem> Riddell: i updated the ksambashare patch. Do you think should i add the latest commit to it?
[15:29] <Riddell> rbelem: updated where?
[15:30] <rbelem> Riddell: in my machine only
[15:30] <rbelem> :-D
[15:31] <Riddell> rbelem: I'm not clear what you're doing, updating the kubuntu packaging or git or what?
[15:32] <rbelem> sorry
[15:32] <rbelem> Riddell: updating the package ksambashare patch
[15:33] <Riddell> rbelem: I already updated it in bzr
[15:34] <rbelem> Riddell: some stuff were missing
[15:34] <Riddell> oh?  like what?
[15:34] <rbelem> Riddell: the includes/KSambaShareData
[15:35] <Riddell> oh aye
[15:36] <Riddell> well go ahead and add anything missing and a changelog and commit
[15:36] <Riddell> I've updated kdenetwork too
[15:38] <rbelem> cool :-)
[15:38] <rbelem> Riddell: do I have access to the bzr repo?
[15:38] <rbelem> checking...
[15:40] <Riddell> rbelem: should do, I think you're in ~kubuntu-members
[15:41] <rbelem> Riddell: and the latest change to remove the duplicated share tab? Should i add to ksambashare patch?
[15:41] <rbelem> i mean the debian/patches/kubuntu_77_ksambashare.diff
[15:42] <Riddell> it's in debian/patches/kubuntu_78_hide_old_file_share.diff
[15:42] <Riddell> let me commit
[15:42] <Riddell> comitted
[15:42] <rbelem> cool :-)
[15:42] <rbelem> Riddell: i'm in kubuntu-ninjas only
[15:43] <Riddell> tsk, you'll have to apply for kubuntu membership then :)
[15:44] <Riddell> I can merge any changes you have
[15:44] <rbelem> :-D
[15:45] <rbelem> oki
[15:49] <rbelem> Riddell: is this the right repos lp:ubuntu/kde4libs?
[15:50] <Riddell> rbelem: lp:~kubuntu-members/kdelibs/ubuntu
[15:51] <Riddell> although the one you mentioned should be much the same thing, that's the magic archive made out of what we upload
[15:52] <rbelem> Riddell: thx
[15:57] <rbelem> Riddell: usr/include/KDE/KSambaShareData and usr/include/ksambasharedata.h are missing in debian/kdelibs5-dev.install
[16:00] <Riddell> hmm, that might be a problem for compiling
[16:00] <Riddell> rbelem: want to add and I'll merge?
[16:03] <rbelem> Riddell: the patch of patch :-D http://paste.kde.org/5534/
[16:04] <rbelem> Riddell: could you add? :-D
[16:07] <rbelem> Riddell: includes/CMakeLists.txt is missing KSambaShareData
[16:07] <Riddell> rbelem: yep
[16:08] <rbelem> Riddell: and the KSambaShareData file is not there too
[16:09] <rbelem> the contents is just #include "../ksambasharedata.h"
[16:45] <Riddell> rbelem: uploaded!
[17:18] <ochozero9> anyone knows a program that can simulate a desing made in quartus? and output a waveform?
[17:24] <Riddell> ochozero9: we package KDE here, I don't know what a desing is
[17:24] <ochozero9> design*
[17:25] <ochozero9> it's okay,, you never know if someone knows
[17:42] <rbelem> thx Riddell :-)
[19:08] <bambee> Riddell: I'm not sure but... your crash was originally caused by a missing argument (silly mistake which is fixed)... and then there is another crash exactly in the same method (commit) which is apparently caused by python itself
[19:08] <bambee> "Fatal Python error: PyEval_AcquireThread: non-NULL old thread state"
[19:09] <Quintasan> >Python
[19:09] <bambee> my question is : does pyKDE4 is really thread safe using libpython ?
[19:10] <Quintasan> apachelogger: ^
[19:10]  * Quintasan hides
[19:10] <Quintasan> Grrr, where the hell is sheytan
[19:10] <bambee> actually commit() does the following:  allocate a new lock, acquire it, then start a new thread
[19:10] <bambee> (it did not touch commit() )
[19:10] <bambee> s/it/I/
[19:10] <kubotu> bambee meant: "(I did not touch commit() )"
[19:20] <apachelogger> *shrug*
[19:20] <apachelogger> I do not see the point of the question
[19:21] <apachelogger> as sip only wraps the C++ objects in a pyth0rn layer there is little to no threat from threads
[19:22] <apachelogger> that is, whenver the c++ function is thread-safe the pyth0rn one ought to be too as the pyth0rn one just calls the c++ one and that lives in a Qt thread context altogether
[19:25] <bambee> apachelogger: you forgot this module kpythonpluginfactory/kpythonpluginfactory.cpp
[19:26] <apachelogger> well
[19:26] <bambee> kpythonpluginfactory uses the GIL and libpython directly
[19:26] <apachelogger> that one does supposedly not wrap a c++ object
[19:26] <apachelogger> thus if the thing is not threadsafe it is not threadsafe :P
[19:27] <bambee> mhhh... very interesting answer :P
[19:27] <apachelogger> rule of thumb: unless the documentation says somethign is thread-safe it is not thread-safe
[19:27] <apachelogger> same goes reentraness


[07:20] <rogpeppe1> mornin' all
[07:23] <huwshimi> rogpeppe1: Morning
[07:23] <rogpeppe1> huwshimi: hiya
[10:44] <rick_h_> morning all
[10:44] <rick_h_> https://github.com/juju/cmd/pull/2 rogpeppe1 frankban kind of cool, pull request on that already
[10:44] <rogpeppe1> rick_h_: yeah. just looking at it
[10:47] <frankban> rick_h_: nice!
[10:55] <rick_h_> frankban: if you get a sec can you look at the latest brew error for quickstart?
[10:55] <frankban> rick_h_: link?
[10:55] <rick_h_> https://github.com/Homebrew/homebrew/pull/30070
[10:55] <rick_h_> http://bot.brew.sh/job/Homebrew%20Pull%20Requests/11953/version=mavericks/console in particular
[10:58] <frankban> rick_h_: yeah, that's the error from last Friday. We should change the test section of the formula to something like
[10:59] <frankban> system "#{HOMEBREW_PREFIX}/bin/juju-quickstart", "--version"
[10:59] <frankban> rick_h_: so using the dashed juju-quickstart
[10:59] <rick_h_> frankban: oh, sorry. I thuoght it was newer since then
[10:59] <rick_h_> frankban: ignore me then, my bad.
[10:59] <frankban> rick_h_: np
[12:28] <bac> hi frankban, i reviewed your branch.  thanks.
[12:28] <frankban> bac: thanks!
[12:35] <frankban> bac: landed
[13:22] <jcsackett> morning all.
[13:40] <frankban> rick_h_: do you remember the address of the production charmstore?
[13:41] <rick_h_> frankban: https://store.juju.ubuntu.com/charm-info?charms=cs:precise/juju-gui
[13:41] <frankban> rick_h_: thanks
[13:49] <bac> frankban, rick_h_: homebrew jenkins is happy.  all i did was change the minimal test from 'juju quickstart --version' to 'juju-quickstart --version'.
[13:50] <frankban> bac: \o/
[13:50] <bac> both work on a live system.  unsure why their minimal jenkins CI fails
[13:50] <bac> https://github.com/Homebrew/homebrew/pull/30070
[13:50] <frankban> bac: because in your system you have a configured juju home
[13:50] <bac> frankban: but --version should cause it to hop out early, no?
[13:51] <frankban> bac: there is a juju-core bug which prevents arguments to be passed to plugins if a default environment cannot be found
[13:51] <bac> frankban: oh really?  well that sure explains a lot
[13:52] <frankban> bac: for that reason, in their platform --version is never passed, and quickstart correctly starts the interactive session
[13:52] <bac> mystery solved
[13:56] <bac> rick_h_: i'm moving the brew acceptance card back to tracking and not review since it is out of our hands and relying on brew upstream.
[14:31] <rick_h_> bac: awesome thanks, sorry was on the phone. Awesome that jenkins is now happy
[14:32] <rick_h_> jujugui luca jujucharms.com updated and released woot
[14:32] <kadams54> Yay!
[14:32] <luca> rick_h_: ace, good job everyone!
[14:34] <rick_h_> jujugui interesting http://arstechnica.com/information-technology/2014/06/new-internet-explorer-developer-channel-gives-devs-a-taste-of-whats-to-come/
[14:35] <kadams54> Nice
[14:53] <rick_h_> jujugui call in 8
[15:00] <rick_h_> jujugui call in 1
[15:00] <rick_h_>  jcsackett
[15:08] <kadams54> luca: can you point me to the dropbox folder with all the machine view workflow designs? Having a hard time tracking the link down right now.
[15:08] <rick_h_> kadams54: it's in google docs
[15:09] <kadams54> rick_h_: ah yes, so it is
[15:10] <luca> kadams54: which work flows are you looking for in particular? and do you want wireframes or visuals?
[15:12] <kadams54> luca: everything… and visuals. Assuming the stuff in Google Docs is up-to-date, it looks like what I need.
[15:12] <bac> rick_h_: i still have no travel auth
[15:12] <luca> kadams54: all visuals in google docs should be up to date
[15:13] <rick_h_> bac: yea me either. I've got a 1-1 with mramm today and I'll bring it up
[15:13] <rick_h_> jujugui who has gotten auth ?
[15:13] <bac> rick_h_: oh, ok.  based on your comment to move forward i assumed people had
[15:13] <rick_h_> bac: oh, did you not get hte email to file a request?
[15:14] <bac> rick_h_: yes, i did that
[15:14] <bac> rick_h_: just no auth to actually book
[15:14] <kadams54> Based on what I see in the spreadsheet, I think hatch is the only one who's been auth'd to book.
[15:14] <rick_h_> yep, ok will bug mramm in our 1-1 today
[15:14] <kadams54> I have the flights in there that I'm going to request once I get auth, but they're subject to change.
[15:15] <luca> kadams54: I’ve shared the juju universe flows out with you, it shows you how everything fits together. Machine view is pretty comprehensive in their.
[15:16] <kadams54> luca: Great. Trying to make sure we're not missing any of the flows.
[15:16] <luca> kadams54: cool, thanks
[15:17] <rick_h_> kadams54: https://drive.google.com/a/canonical.com/#folders/0B7XG_QBXNwY1aVh1cC0wU0JRaW8 is the dropbox stuff that you're thinking of
[15:17] <kadams54> Figured as much…
[15:17] <rick_h_> cool
[15:19] <luca> rick_h_: created a new bug: https://bugs.launchpad.net/juju-gui/+bug/1330520
[15:19] <_mup_> Bug #1330520: When dragging a unit drop zones should be clearly marked. <juju-gui:New> <https://launchpad.net/bugs/1330520>
[15:20] <luca> rick_h_: woah, whats mup?
[15:20] <rick_h_> luca: rgr ty much
[15:20] <rick_h_> luca: watches for bug # and such to provide helpful links
[15:20] <rick_h_> luca: so you can do #1330529
[15:20] <rick_h_> luca: oh hmm, maybe  #1330520
[15:20] <luca> test #1330520
[15:20] <_mup_> Bug #1330520: When dragging a unit drop zones should be clearly marked. <juju-gui:New> <https://launchpad.net/bugs/1330520>
[15:20] <_mup_> Bug #1330520: When dragging a unit drop zones should be clearly marked. <juju-gui:New> <https://launchpad.net/bugs/1330520>
[15:21] <rick_h_> will it'll load the bug details
[15:21] <luca> that’s cool
[15:21] <rick_h_> yea
[15:21] <rick_h_> luca: on the designs there's a lack of 'add to bare metal'?
[15:22] <luca> rick_h_: you can add that
[15:22] <rick_h_> luca: ok
[15:31] <hatch> rick_h_ kadams54  yes I've authed and booked
[15:33] <jcsackett> rick_h_, kadams54: +1 on the mramm needs to auth travel.
[15:41] <hatch> jcsackett if you don't want to use Y.later with periodic you can use https://developer.mozilla.org/en-US/docs/Web/API/window.setInterval there will be no difference in execution, just don't have to rely on YUI if you don't want
[15:44] <rick_h_> hmmm, /me sees timeout relatedish stuff and gets nervous
[15:44] <hatch> rick_h_ async all the things!!!!
[15:45] <hatch> :P
[15:45] <rick_h_> yea, but async and tests that pass all the time seems to be the oopsie
[15:46] <hatch> well I suppose the good part to using Y.later is that it can be stubbed out to make it synchronous for the tests
[15:46] <rick_h_> all good, you guys know what you're up to. Just caught a whiff :P
[15:47] <hatch> oh I'm with you on that one - there was a reason the state stuff is all synchronous now :D
[15:48] <rick_h_> frankban: reminder that today is your qa day. If you get a chance maybe do a pass through the brew stuff or something to do a bit of qa.
[15:49] <rick_h_> hatch: you're on deck tomorrow.
[15:49] <hatch> righton
[15:49] <jcsackett> if async doesnt work you're not using enough.
[15:49] <jcsackett> :p
[15:49] <rick_h_> that's promises :P
[15:50] <frankban> rick_h_: sure, I'll do it, thanks
[15:51] <rick_h_> frankban: thanks, I will one day figure out how to remember to check qa day before the standup.
[15:51] <hatch> :D
[15:53] <hatch> luca hey I just looked at your Machine_View_Drop_States pdf an have one technical concern
[15:54] <luca> hatch: shoot
[15:54] <hatch> luca if we have to change 1000's of machines dom elements when the user starts to drag there could possibly be a performance issue there
[15:55] <luca> hatch: thats an interesting concern which we don’t think about :P
[15:55] <rick_h_> hatch: yea, we might have to do some management of the viewable area
[15:55] <hatch> haha, well that's why you have us :D
[15:55] <hatch> luca there are potentially ways we can mitigate that but it would be great if you could maybe look into alternate approaches to this
[15:55] <rick_h_> hatch: I think we can move forward with the interaction, and maybe look at optimizaitons of viewable area, css single dom updates, etc
[15:56] <rick_h_> hatch: as long as we don't change dimensions of the existing containers a show/hide situation should be pretty quick.
[15:57] <luca> rick_h_: hatch is it all ok?
[15:57] <hatch> yeah - I'm just worried that at scale there could be a delay. We may have to do some viewable-area stuff anyways for the current implementations at real scale
[15:58] <rick_h_> hatch: but if we can do simple show/hide stuff I htink browsers take care of the viewable area for us. There's potential at least.
[15:58] <hatch> yeah - I'm thinking that we might have to render/destroy elements as we scroll depending on the size of the env
[15:59] <rick_h_> hatch: yea, we'd not want to do that
[15:59] <rick_h_> hatch: but we've got an overall perf issue to investigate as well
[15:59] <hatch> yeah
[15:59] <rick_h_> hatch: but at some point, when your environment is 1000 machine, are you doing to want to drag/drop a service in the GUI and find that #835?
[15:59] <rick_h_> or just cli it
[16:00] <hatch> luca ok I've been convinced that we can do it then look at ways to fix it if it's a problem :)
[16:00] <hatch> rick_h_ yeah that's a good point
[16:00] <rick_h_> lol
[16:00] <rick_h_> hatch: yea, good to be aware of for sure
[16:00] <luca> lol
[16:00] <luca> thanks guys
[16:01] <hatch> luca ok ONE more question
[16:01] <hatch> :)
[16:01] <hatch> in a small env, when the user is dragging, they may want to see what services are on the machines already and the specs of it? before dropping
[16:01] <hatch> maybe we change the name of the machine to be "Add to machine XXX" instead of changing the whole token?
[16:03] <hatch> ^ luca
[16:32] <kadams54> Anyone know what hotel we'll be staying at in London?
[16:33] <rick_h_> kadams54: not confirmed yet, what's up?
[16:33] <kadams54> Shopping for a chip-and-pin card; most of the US ones seem to be travel-related loyalty cards for airlines or hotels.
[16:34] <rick_h_> kadams54: ah yea. last time we were here: https://www.google.com/maps/place/citizenM+hotel+London+Bankside/@51.5054283,-0.0994532,19z/data=!4m6!1m3!3m2!1s0x487604c3abe490a3:0xfe2b1e24d4edbed9!2sCanonical+Group+Limited!3m1!1s0x0:0x81fe4478ab140a51
[16:34] <rick_h_> kadams54: I will say I had issues with cards. Soemtimes I could use it once and then not again
[16:34] <rick_h_> but managed to get by ok without a chip/pin card so far in all our travels
[16:34] <rick_h_> though couple of times had to deal with local cash and work with others on the team
[16:35] <rick_h_> london was ok with swipe cards, best place of many we've been to
[16:35] <kadams54> Yeah… I wasn't a big fan of my experience in Montreal for Pycon, so I'm ready to just make the jump.
[16:35] <kadams54> My bank will be offering them this year, but not soon enough for the trip.
[16:40] <kadams54> Right now this looks like the best option for me: http://www.cashpassport.com/http://www.cashpassport.com/
[16:40] <kadams54> er
[16:40] <kadams54> http://www.cashpassport.com/
[16:53] <hatch> hmm there is a hadoop charm from charmers that's failing on charmworld
[16:54] <hatch> this is the link https://manage.jujucharms.com/api/3/charm/trusty/hadoop-0
[16:54] <hatch> ^ lazyPower
[16:54] <hatch> it's showing up in the 'New' results
[16:54] <lazyPower> hatch: yeah, why is this borked?
[16:54] <lazyPower> http://i.imgur.com/I3L2bIA.png
[16:55] <lazyPower> metadata isnt loading, icons missing
[16:55] <lazyPower> it passes proof
[16:55] <hatch> hmm bac can you provide any insight into ^
[16:55] <hatch> the manage link returns "no_such_charm"
[16:56] <lazyPower> whaaaaa
[16:56]  * lazyPower scratches head
[16:56] <lazyPower> did i do something stupid during the promulgation process maybe?
[16:56] <hatch> probably :P
[16:56] <hatch> honestly I have no idea ;)
[16:56] <lazyPower> i mean, i'll own it. I probably did something dumb
[16:56] <lazyPower> thats toatally within my realm of capabilities
[16:57] <hatch> rick_h_ any idea how to investigate this issue? ^
[16:58] <rick_h_> hatch: in a meeting, not sure atm. Can peek later or ask jcsackett or bac for assistance
[16:58] <lazyPower> jcsackett: ping
[16:58] <hatch> ok np
[16:58] <lazyPower> jcsackett: i think i did something stupid...
[16:59] <hatch> lazyPower lets just say you DID do something to put it into this state, the process should be simplified in a way in which it's not possible :)
[16:59] <hatch> it's a very odd state imho heh
[17:00] <lazyPower> hatch: looking at my bzr refs, everything is 1:1 with previous promulgations
[17:00] <rick_h_> lazyPower: https://store.juju.ubuntu.com/charm-info?charms=cs:trusty/hadoop
[17:00] <rick_h_> lazyPower: can you juju publish it?
[17:01] <rick_h_> lazyPower: rev0 seems odd
[17:01] <rick_h_> lazyPower: but yea, maybe the /interesting url is loading bad charms
[17:01] <rick_h_> lazyPower: please file a bug
[17:01] <lazyPower> ack. i just ran juju publish
[17:02] <rick_h_> lazyPower: ok, sometimes juju publish points out an error that we've missed in  charmworld
[17:03] <lazyPower> cs:~charmers/trusty/hadoop-0 - its returning what i would expect
[17:03] <lazyPower> inc. bug
[17:03] <frankban> rick_h_: quickstart QA seems ok on osx, Unfortunately I've found an old HP Cloud env to no longer work. Filed bug 1330553 and created a card
[17:03] <_mup_> Bug #1330553: Align quickstart to the latest HP Cloud configuration options <juju-quickstart:Triaged> <https://launchpad.net/bugs/1330553>
[17:03] <rick_h_> frankban: rgr, ty much
[17:03] <rick_h_> qa day strikes again! :)
[17:04]  * jcsackett returns from lunch, tries to catch up on pings.
[17:05] <jcsackett> lazyPower: what exactly is the problem? the trusty/hadoop-0 should be promulgated, but isn't in charmworld?
[17:05] <rick_h_> jcsackett: it's showing as a new charm in /interesting, but isn't in charmworld to be able to load
[17:05] <rick_h_> https://jujucharms.com/trusty/hadoop-0/
[17:06] <frankban> :-)
[17:06] <hatch> jujugui lf a quick review/qa https://github.com/juju/juju-gui/pull/389
[17:07] <lazyPower> jcsackett: right. Is it heresy if i run charm promulgate over what should be promulgated already to ensure it wasn't an intermittant connectivity issue during the promulgation?
[17:07] <lazyPower> this would then be retargeted @ charmtools vs charmworld
[17:07] <jcsackett> lazyPower: i don't know if it would be heresy, tbh.
[17:08] <jcsackett> lazyPower: but it does look sort of...partially promulgated, in that gui is looking along the wrong path. eg, http://comingsoon.jujucharms.com/~charmers/trusty/hadoop-0/ *does* find it.
[17:09] <lazyPower> so partially meaning it has been read as a promulgation or as just a bzr push or combination of both?
[17:09] <lazyPower> this is where my knowledge of the store goes grey, i dont really understand the guts of the process server-side
[17:09] <rick_h_> jcsackett: I wonder if rev 0 is getting cast as a false value or something odd
[17:09] <jcsackett> lazyPower: yeah...the store bits are outside my knowledge as well. :/
[17:10] <rick_h_> lazyPower: can you push another rev and get that to 1?
[17:10] <lazyPower> rick_h_: sure
[17:10] <jcsackett> rick_h_: it's weird, actually, look at the URL when you hover over the token vs what you dispatch to when you click it.
[17:10] <jcsackett> rick_h_: why is GUI eating the ~charmers?
[17:10] <rick_h_> jcsackett: because it's promulgated, it's not supposed to be required
[17:11] <jcsackett> rick_h_: ok, but gui doesn't know its promulgated--this may be ingest error. charmworld doesn't list as promulgated either. i'm +1 on update rev and "re promulgate." unless there's a way to unpromulgate and then redo it.
[17:11] <rick_h_> jcsackett: yea
[17:13] <lazyPower> rick_h_, jcsackett - pushed to rev1 && promulgated again
[17:13] <jcsackett> lazyPower: and now we wait for ingest.
[17:14] <hatch> jujugui anyone available for a qa and review on https://github.com/juju/juju-gui/pull/389 it's just a small code removal branch, more are coming
[17:16] <jcsackett> hatch: looking.
[17:17] <hatch> thx
[17:22] <jcsackett> rick_h_, lazyPower: figured out the problem, according to heartbeat, charmworld hasn't ingested since yesterday.
[17:22] <rick_h_> jcsackett: interesting, wonder how the charm was in the 'new' in interesting
[17:23] <jcsackett> rick_h_: it was new yesterday--pushed up on the 13th.
[17:23] <rick_h_> gotcha
[17:23]  * jcsackett hopes it's reproduced on a server we control...
[17:24] <rick_h_> jcsackett: yea, we need to ping webops then to get it restarted or something. Get a hole of the app.log and app-exceptions.log
[17:24] <rick_h_> hold bah
[17:25] <jcsackett> rick_h_: yup.
[17:28] <lazyPower> jcsackett: well thats clever. Thanks for the heads up jcsackett. i hope this re-promulgate didn't just tank the process
[17:28] <lazyPower> lmk if thats the case, I'll unprom and restart
[17:28] <jcsackett> lazyPower: doubt it. process was kicked before you did it.
[17:29] <Makyo> jujugui running to old house over lunch, back in a few.
[18:31] <lazyPower> jcsackett: doesn't appear to have fixed itself over lunch.
[18:32] <jcsackett> lazyPower: no indeed. i'm still digging into it, but no fix yet.
[18:32] <lazyPower> ack. thanks for taking a look.
[18:32] <jcsackett> rick_h_: is there a way to just kick ingest? been so long since i poked at it i don't know if there is.
[18:33] <rick_h_> jcsackett: it's a process running by supervisor and needs to be running/restarted there
[18:34] <lazyPower> https://bugs.launchpad.net/charmworld/+bug/1330582  -- i left this behind to track progress if its not as simple as kicking ingest
[18:40] <jcsackett> rick_h_: do we have any objection to just having them start/stop supervisor and worker on production and seeing if we're good?
[18:40] <rick_h_> jcsackett: that's fine, I just want to make sure we do get the logs from the app and supervisor for the last ingest timeframe to see if there's anything we can address.
[18:40] <rick_h_> jcsackett: but running > *
[18:41] <jcsackett> app and app-exception have nothing.
[18:42] <rick_h_> jcsackett: then yea, if it's not ingesting did supervisor kill/not restart or something?
[18:42] <jcsackett> rick_h_: that i don't know; i can't find a copy of a log with supervisor info to request, and i can't get into QA to double check logs. do we have docs on logs?
[18:45] <jcsackett> i also can't find the difference between start/stop supervisor and start/stop worker, which bugs me since i added it way back when and the failure to doc is mine.
[18:45] <jcsackett> always hate it when the person i should be mad at is me. :p
[18:59] <hatch> yeah that guys sucks sometimes
[18:59] <hatch> he is totally unable to take constructive criticism....lol
[19:14] <bac> jujugui: could someone review changes just to the quickstart README file? https://codereview.appspot.com/109050044
[19:14] <hatch> sure
[19:14] <bac> hey hatch there was a canadian warship in port down here this weekend.  loading up on rum, i guess.
[19:15] <hatch> bac maybe you're Canadian now? ;)
[19:15] <bac> nah, they couldn't have gotten past our mighty fort
[19:15] <hatch> lol
[19:16] <bac> or if they did, they would've succumbed to dysentery.  that's the way it always played out.
[19:16] <hatch> haha, playing some Oregon Trail?
[19:16] <bac> no, that literally is the story of every invasion since 1650
[19:16] <hatch> oh haha ok then
[19:18] <hatch> bac so I understand why you would include the pip instructions, I'm just not sure why anyone would do that if they also require brew
[19:18] <bac> wow, the markdown preview in atom is nice
[19:19] <hatch> be sure to turn off the tracking - they send all of your filenames to the mothership
[19:19] <bac> hatch: i started to go into that but didn't.  it could be useful if, for instance, a newer version were on pypi that hadn't made it into the brew repository yet.
[19:19] <jcsackett> lazyPower: with bac's help looks like we got ingest going again--i'll check on your hadoop charm soon to see if it updates.
[19:19] <bac> that is not an unusual occurence since we control pypi but have to wait on approval for brew
[19:19] <lazyPower> jcsackett: ack. thanks again!
[19:19] <rick_h_> bac: hatch or other platforms that use pypi (linux platforms)
[19:20] <hatch> true true ok thx bac
[19:20] <hatch> rick_h_ this is only under the OSX instructions
[19:20] <bac> hatch: well, it does occur for the ubuntu instructions too
[19:20] <hatch> right
[19:20] <bac> but not the brew/pip part
[19:20] <hatch> lgtm'd
[19:21] <bac> hatch: i did turn off the tracking.  but just in case i call all of my files github-sux.rst
[19:21] <hatch> LOL
[19:26] <bac> thanks hatch
[19:30] <hatch> np
[19:40] <rick_h_> jujugui running to the post office and will pick up the boy on my way back. I'll be around some tonight if you need anything, but afk for a bit.
[19:42] <jcsackett> lazyPower: new ingest has completed, that hadoop charm still looks goofed. :/
[19:50] <lazyPower> :|
[19:57] <lazyPower> jcsackett: well, i'm at a loss. should I unpromulgate it for now and pin it as a follow up?
[19:58] <lazyPower> my normal source of info is out today on swap.
[20:12] <arosales> Hello Juju GUI folks
[20:12] <hatch> afternoon arosales
[20:12] <bac> hi
[20:13] <arosales> so everyone loves your quickstart :-)
[20:13] <arosales> and who wouldn't
[20:13] <hatch> :-)
[20:13] <hatch> thanks
[20:13] <arosales> but the only docs, I know of are, http://blog.mitechie.com/2014/03/17/juju-quickstart-and-the-power-of-bundles/
[20:13] <bac> ah, i knew there'd be a but
[20:13] <hatch> lol!
[20:13] <arosales> Is there some docs we could move into juju.ubuntu.com/docs
[20:14] <arosales> :-)
[20:14] <hatch> arosales it's definitely an issue that's been raised, if you wouldn't mind sending an email to the peeps mailing list rick can queue it up
[20:14] <hatch> he is out atm
[20:14] <arosales> hatch: will do
[20:15] <hatch> awesome thanks, I'd also love to see some docs in the juju docs
[20:15] <bac> arosales: there is the readme but it is only a starting point: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/README.rst
[20:15] <arosales> hatch: do you prefer juju-gui-peeps or juj-gui?
[20:16] <hatch> probably peeps
[20:16] <jcsackett> lazyPower: i would unpromulgate it for now, and pin for follow up.
[20:16] <arosales> bac we should be able to translate the blog post and readme into a managable juju.u.c/ doc page
[20:16] <jcsackett> lazyPower: it seems like the actual store isn't updating--i'm unsure who to go to about that.
[20:16] <rick_h_> arosales: what happened to the docs jcastro wrote for juju.ubuntu.com/docs?
[20:17] <arosales> rick_h_: did he write docs?
[20:17] <rick_h_> arosales: originally he wrote the docs when we first released quickstart so we didn't add any
[20:17] <hatch> oh he's back :)
[20:17] <rick_h_> arosales: we had a card to do so but he landed some
[20:17] <rick_h_> :P
[20:17]  * rick_h_ clones docs
[20:17]  * arosales looking .  . ..
[20:19] <arosales> if he did he didn't put link it to https://juju.ubuntu.com/docs/getting-started.html  where it ideally should be
[20:19] <bac> arosales: there is some mention on https://juju.ubuntu.com/docs/charms-bundles.html
[20:19] <arosales> castro! ;-)
[20:19] <rick_h_> hmm, https://juju.ubuntu.com/docs/charms-bundles.html#local-deploy-via-command-line is all I can find now but I swear he had large chunks of docs
[20:19] <rick_h_> I recall having the card to do the work and moving it to done because jcastro beat us to it
[20:20] <arosales> I think all jcastro did was the bundles deploy docs
[20:20] <arosales> :-(
[20:20] <rick_h_> arosales: ok, we'll add a card to flesh out some more. I know there were some references removed because quickstart didn't work on all OSs
[20:20] <rick_h_> arosales: but didn't realize how wiped it had been I guess
[20:20] <arosales> rick_h_: ok do you want to send a mail to the juju-gui or juju-gui-peeps list
[20:21] <arosales> I'll also put a card on our board for jcastro to sync with you on juju quickstart being on the getting started page.
[20:21] <rick_h_> arosales: I guess sure. We'll have the readme, but if you've got specific goals for docs at certain places please email or file a bug so we can make sure we address it properly
[20:21] <arosales> rick_h_: really needs a blend of http://blog.mitechie.com/2014/03/17/juju-quickstart-and-the-power-of-bundles/ and http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/README.rst
[20:22] <arosales> examples, screen shots, user walkthrough
[20:22] <rick_h_> arosales: ok, but that seems like a dedicate page vs appending to the getting-started?
[20:22] <arosales> but the content is there given things haven't changed
[20:23] <arosales> rick_h_: well we should at mention, he if you want to use our tool to help you get stated hit <this_link>
[20:23] <arosales> and make that prominent
[20:23] <arosales> s/he/hey/
[20:23] <rick_h_> I wonder if we can talk jcastro into making getting started on windows a diff section, then linux/osx can be quickstart centric
[20:23] <rick_h_> arosales: ok, we'll see what we can come up with and iterate on it
[20:24] <arosales> we should also ask is quickstart the recommended way for users to actually get started on Juju
[20:24] <rick_h_> arosales: I know that's jcastro's vision but without osx/windows he backtracked
[20:24] <arosales> I would say yes, but perhaps folks also want manual steps, which we can provide, but we should be promoting quickstart
[20:24] <rick_h_> arosales: but sure thing, valid question.
[20:24] <arosales> right now we don't even mention it
[20:24] <rick_h_> rgr
[20:24] <arosales> rick_h_: I"ll put a card on the board
[20:25] <rick_h_> arosales: cool thanks for bringing it up. We can definitely do better
[20:27] <arosales> got a ping on "juju is apt-get for the cloud, but I still need help getting started."
[20:27]  * arosales thought of quick start which led me here
[20:28] <rick_h_> yea, that was kind of the goal of quickstart. simply the getting started part
[20:28]  * rick_h_ is following backlog conversation that led to this in #juju
[21:13] <hatch> jujugui looking for a review and qa on another code removal branch https://github.com/juju/juju-gui/pull/390
[21:13] <kadams54> hatch: looking
[21:14] <hatch> thanks
[21:14] <hatch> rick_h_ any preference on what I should jump on next
[21:14] <hatch> ?
[21:16] <rick_h_> hatch: looking
[21:17] <rick_h_> hatch: the charm details hidden by default? Last IL cleanup in maint
[21:17] <hatch> cool on it
[21:18] <rick_h_> hatch: hopefully nice and easy, then would love you and Makyo to ponder on the ghost stuff, ghost delete relation card, ghost config card
[21:19] <hatch> yeah that sounds good - has there been any discussion about the ecs stuff moving to core or was the pushed off to next cycle? We want to make sure the api's are at least somewhat compatible :)
[21:19] <rick_h_> yea, no ecs stuff this cycle
[21:20] <hatch> sounds good
[21:28] <rick_h_> kadams54: :P hey that cruft was important hard stuff :P
[21:28] <rick_h_> and ty hatch for removing the evils
[21:28] <kadams54> rick_h_: no doubt, no doubt. But now it's just unused code :-(
[21:29] <kadams54> Dusty bunnies of what had been.
[21:29] <rick_h_> kadams54: just givin you a hard time about calling my old stuff cruft :P
[21:30] <hatch> lol
[21:30] <hatch> now if we could just get design to quit changing their minds :P
[22:59] <huwshimi> Morning
[23:07] <hatch> morning huwshimi
[23:07] <huwshimi> hatch: Hey
[23:20] <huwshimi> hatch: If you get a chance would you mind casting an eye over https://github.com/juju/juju-gui/pull/385 to see if my changes are ok?
[23:22] <hatch> oh right - I think there was something that needed doing
[23:22] <hatch> one sec
[23:26] <hatch> huwshimi just a single comment - after looking at it again I saw what you were doing so just added a comment request
[23:26] <huwshimi> hatch: Thanks