[06:13] <lordievader> Good morning.
[06:20] <Mirv> mornings
[07:03] <Mirv> sitter: mornings. we're still blocked by not having plasma-workspace ubuntu2 uploaded, which blocks kglobalaccel, which blocks me building the three packages I'd like
[07:03] <Mirv> I kicked a couple of rebuilds during the weekend and it seems this is the last step for kf5 5.7.0
[07:04] <Mirv> but I didn't dare to go to your staging and start uploading a package from there, even though I found it :)
[07:08]  * sitter beats Riddell with a stick
[07:13] <soee> good morning
[07:16] <sitter> Mirv: [ubuntu/vivid-proposed] plasma-workspace 4:5.2.0-0ubuntu2 (Accepted)
[07:17] <Mirv> sitter: thank you! and it just turned out our Train (CI) is dead at the moment due to disk space so I'll anyway have an hour or two do to builds in the PPA
[07:18] <sitter> ^^
[07:18] <soee> since few days in vivid: libdebconf-kde1 : Depends: debconf-kde-data (= 1.0.1-0ubuntu1) but it is not installed
[07:18] <sitter> high tech continous integration system stopped by not having enough empty buckets to put things into xD
[07:19]  * sitter has a similar problem on kci but doesn't know why, all builds delayed by 4 hours on the launchpad build step for some reason
[07:20] <sitter> someone needs to port kubuntu-web-shortcuts
[07:25] <sitter> soee: sudo apt-get -o Debug::pkgProblemResolver=true dist-upgrade
[07:27] <soee> sitter: nothing more than i paste before http://paste.ubuntu.com/10251689/
[07:27] <sitter> what the
[07:27] <soee> i can do force overwrite and it will work though
[07:27] <sitter> soee:  sudo apt-get -o Debug::pkgProblemResolver=true -f install
[07:28] <sitter> paste the output
[07:28] <sitter> then run upgrade again
[07:28] <sitter> paste the output
[07:28] <sitter> sounds a bit odd though
[07:29] <sitter> perhaps it's because the lib is multiarch:same but the data doesn't have multiarch declared at all
[07:29] <soee> sitter: http://paste.ubuntu.com/10251699/
[07:29] <sitter> AHA
[07:29] <soee> several people reported it and thers a bug on launchpad
[07:33] <sitter> no one reads bug reports
[07:33] <sitter> ever
[07:33] <sitter>   Uploading debconf-kde_1.0.1-0ubuntu2_source.changes: done.
[07:33] <sitter> Successfully uploaded packages.
[07:33] <sitter> soee: ^
[07:33] <sitter> should be built in an hour or so
[07:41] <soee> sitter: cool, thank you :)
[07:51] <sitter> Mirv: so, I am getting qt 5.4 this week? :)
[07:54] <Mirv> sitter: hopefully still today, yes...
[07:55] <sitter> \o/
[08:10] <sitter> dh: unable to load addon kubuntu-l10n: Can't locate Debian/Debhelper/Sequence/kubuntu_l10n.pm in @INC (you may need to install the Debian::Debhelper::Sequence::kubuntu_l10n module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.20.1 /usr/local/share/perl/5.20.1 /usr/lib/x86_64-linux-gnu/perl5/5.20 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.20 /usr/share/perl/5.20 /usr/local/lib/site_perl .) at (eval 11) line 2.
[08:10] <sitter> whoopwhoop
[08:10] <sitter> who broke that?
[08:11] <tsdgeos> sitter: Riddell: sgclark: any idea why kf5globalaccel is stuck in proposed?
[08:12] <sitter> tsdgeos: because someone didn't upload plasma-workspace
[08:12] <sitter> should be resolved soonishy
[08:12] <sitter> uploaded it an hour ago
[08:12] <tsdgeos> k
[08:13] <sitter> shadeslayer: you broke the l10n stuff in pkg-kde-tools >.<
[08:18] <Mirv> tsdgeos: I'll rebuild the 3 packages as soon as kf5globalaccel migrates and then theoretically we should be all set to publishing Qt 5.4 in a few hours
[09:10] <sitter> now I am suspicious
[09:11] <sitter> wgrant: thoughts on this error https://launchpadlibrarian.net/197807925/upload_6982693_log.txt there also was an earlier occurance on a different source https://launchpadlibrarian.net/197798731/upload_6982099_log.txt
[09:12] <wgrant> sitter: Things are slightly on fire. That error means it's uploaded successfully but tried to upload again. You can ignore it, I'll be fixing the build status later.
[09:12] <sitter> ok thanks
[09:12] <sitter> 'slightly on fire' sounds like fun xD
[09:12] <valorie> fire extinguisher is on the wall over there
[09:32]  * sitter scratches his head and wonders why he has no recollection of uploading software-properties qt5
[09:40] <Riddell> sitter: what did I do to deserve being beaten with a stick?
[09:40] <sitter> Riddell: you didn't upload plasma-workspace
[09:40] <sitter> I even explicitly told you to not forget it >.<
[09:41] <sitter> qt5 port -> [ubuntu/vivid-proposed] usb-creator 0.2.65 (Accepted)
[09:43] <sitter> Riddell: is kdesu with sudo working yet?
[09:43] <sitter> and on that note is kdesudo still seeeded?
[09:47] <Riddell> kdesudo isn't seeded but e.g. muon-updater depends on it
[09:49] <sitter> muon-updater Oo
[09:49] <sitter> man
[09:50] <sitter> ./libmuon/backends/ApplicationBackend/ApplicationNotifier.cpp:    QString kdesudo = QStandardPaths::findExecutable("kdesudo");
[09:50] <sitter> why is everything so shit
[09:54] <tsdgeos> Mirv: they're in
[09:59] <sitter> Riddell: have you filed a bug about that?
[10:00] <Mirv> tsdgeos: I know, builds are ongoing in the PPA, and watch build job in CI (which is now fixed again)
[10:01] <Riddell> sitter: about hardcoding kdesudo? I don't think so
[10:04] <soee> sitter: your fix for debconf-kde-data works nice, thanks again
[10:13] <sitter> cool
[10:13] <sitter> Riddell: I am actually not even sure how that is supposed to be solved
[10:13] <sitter> kdseu is as weird as kdesudo
[10:14] <sitter> IMO the cleanest solution would be to supply a desktop file that uses x-kde-suid to get kdesu
[10:14] <sitter> notable advantage being that we can simply krun it without having to QProcess in muon manually and it abstracts the sudoing away from muon
[10:15] <Riddell> yep
[10:15] <sitter> e.g. if the upgrader were to become a polkit client the sudo bit only needs removing in the desktop file not 300 code locations
[10:28] <Riddell> Sick_Rimmit: did you get anywhere with kdevelop? or did you say you'd do that this week?
[10:34]  * Riddell uploads libkdeedu
[11:01] <Sick_Rimmit> Riddell: Hi, I am working on that this week, will start tomorrow eveing ( Tues )
[11:01] <Riddell> groovy
[11:01] <Riddell> now where's manchicken with his digikam update?
[11:19]  * Mirv spams vivid-changes list
[11:19]  * mitya57 hugs Mirv
[11:20] <Sick_Rimmit> Do we have a problem with the Print manager ?
[11:20] <Mirv> mitya57: has the fever gotten any lower now?
[11:20] <Sick_Rimmit> I can't find it anywhere on the menu's
[11:20] <Riddell> Sick_Rimmit: yes, it's for kdelibs4
[11:21] <mitya57> Mirv: a bit better now, yes
[11:21] <Sick_Rimmit> dpkg says its installed, but I can't some to invoke it, (perhaps I don't know the command........
[11:21] <Mirv> mitya57: good!
[11:21] <Riddell> Sick_Rimmit: the frameworks port needs tested then co-ordinated with the guy who ported it (lukas I think) to move it into trunk so it'll be released with the frameworks version
[11:21] <Sick_Rimmit> Ah OK, is it in the pipe for porting ?
[11:21] <Riddell> it's ported, just needs released
[11:21] <Sick_Rimmit> OK
[11:22] <Sick_Rimmit> That's good, we can release without printers, that would be a proper fo pah!
[11:22] <Riddell> I still think a printer is required, alas many geeks do not
[11:23] <Sick_Rimmit> Oh boy really!!
[11:23] <Riddell> Sick_Rimmit: I bought a printer to use at the office here in barcelona and got no end of stick for not just using my phone for anything
[11:23] <Riddell> then vhanda had to print thing off for the paperwork the spanish need and he came crawling on his knees to me
[11:23] <Sick_Rimmit> Riddell: Well that's ridiculous, perhaps even stupid
[11:24] <Sick_Rimmit> I'm working in an office with 30 folks, with a shared printing pool.
[11:24] <Sick_Rimmit> If I can't print from Kubuntu Plasma 5, that looks pretty poor
[11:25] <Sick_Rimmit> Anyone else says we don;t need printers, you point them at me Riddell
[11:25] <Sick_Rimmit> :-)
[11:27] <Sick_Rimmit> So I've had to create a PDF open in Firefox, and use its Cups Printer function to print to the pool.
[11:27]  * Sick_Rimmit face palm
[11:31] <Riddell> Sick_Rimmit: you can still run it with   kcmshell4 kcm_printer_manager
[11:32] <Sick_Rimmit> Riddell: Ah right OK, I wll make a note of that
[12:13] <BluesKaj> Hi folks
[12:15] <Riddell> yay kdepim compiling
[12:17] <soee> :)
[12:17] <soee> hiho BluesKaj
[12:18] <BluesKaj> Hi soee, Riddell
[12:19] <Riddell> kubotu: newversion partition-manager 1.2.0
[12:19] <soee> BluesKaj: good news - Plasma 5.2.1 should be released this thursday :)
[12:19] <kubotu> Package partition-manager doesn't exist yet!
[12:19] <Riddell> kubotu: newversion partitionmanager 1.2.0
[12:20] <kubotu> https://bugs.launchpad.net/bugs/1422340
[12:21] <BluesKaj> soee, ok, any changes worth noting ?
[12:21] <Riddell> yay libkdeedu is accepted!
[12:21] <Riddell> sgclark: ↑
[12:23] <soee> BluesKaj: i think most important are those that fixes some freezes, avoids propagation of teh same proccess etc. so we should have more stable Plasma now
[12:23] <soee> BluesKaj: if you think about some new components etc. they will show up in Plasma 5.3
[12:24] <BluesKaj> soee, like themes ?
[12:29] <soee> BluesKaj: oh that i don't know, ask Riddell, i think this weekend he will talk with plasma devs about features that 5.3 release should have
[12:30] <Riddell> this week actually, they're arriving now
[12:30] <Riddell> any requests?
[12:30] <soee> Riddell: yes - color picker widget :D
[12:31] <Riddell> soee: where?
[12:31] <soee> Riddell: plasmoid so we can place it in panel
[12:31] <BluesKaj> copy and paste without having to leave the source file open, Riddell, for one
[12:32] <soee> this one in KDE4 was most frequently used by me
[12:33] <Riddell> BluesKaj: well that's a bug and probably quite a fiddly one or it would be fixed already
[12:33] <BluesKaj> Riddell, ok thanks
[12:41] <BluesKaj> oh another is the power management settings, no matter what the computer locks the screen and drops to the login , altho some processes do continue
[12:41] <BluesKaj> after about 5 mins
[12:43] <BluesKaj> of inaction, has anyone encountered that?
[12:43] <soee> what about the logout bug - if you want to logout, plasma quits and system does nothing - stays with black screen
[12:46] <BluesKaj> soee, haven't seen that one
[12:50] <soee> BluesKaj: so logout works fine for you ?
[12:53] <BluesKaj> yes soee, so far at least
[12:54] <soee> Riddell: what i would like to have 'stable' in 5.3 are Activities, atm. they are very buggy and don't work. There is also related kwin bug i have reported where we can't assign app to single activity, in window rules we have only option 'All activities'. So if there is any chance to get it fixed and have usable activities, would be cool
[13:46]  * mitya57 uploads okteta with fixed symbols to unblock qt 5.4
[13:47]  * Riddell spots https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.4.0+dfsg-4ubuntu2
[13:49] <Riddell> I'll need to recompile frameworksintegration and a bunch of plasma stuff
[13:50] <mitya57> Riddell: that's already done
[13:50] <Riddell> ooh nice
[13:51] <Riddell> but also stuff like kwin and plasma-workspace which I believe has #ifdefs for qt 5.4 fixes
[13:52] <mgraesslin> correct, kwin has ifdefs for 5.4
[13:54] <Mirv> sitter: Riddell: hey, could you fix symbols for okteta which is failing autopkgtests? https://jenkins.qa.ubuntu.com/job/vivid-adt-okteta/lastBuild/ARCH=amd64,label=adt/consoleText (or override)
[13:54] <Mirv> Riddell: plasma-workspace, frameworkintegration and kdelibs4support recompiles are in archives
[13:54] <mitya57> Riddell: Yes, I think we only uploaded packages that were using private headers (and thus depending on qtbase-abi-5.x.x)
[13:54] <Mirv> + the kdelibs4support which sitter uncovered to be "strange" :)
[13:55] <mitya57> Mirv: https://launchpad.net/ubuntu/+source/okteta/4:14.12.2-0ubuntu2
[13:55] <Mirv> mitya57: \o/ :D
[13:55] <Mirv> mitya57 is faster than light, even when in fever
[13:56] <BluesKaj> I also miss the quicklaunch widget
[13:59]  * ScottK <-- packaging the kf5 version of partionmanager
[14:01] <shadeslayer> neat! :D
[14:01] <BluesKaj> quicklaunch like so, on the left beside the kicker http://wstaw.org/m/2015/02/16/snapshot1.png
[14:03] <soee> so this week we should have QT 5.4 + Plasma 5.2.1 right ?
[14:06] <shadeslayer> probably
[14:06] <mitya57> oh no, okteta ftbfs
[14:08] <mitya57> looks like I need to wait for builds to finish on all architectures to do a proper symbols update
[14:08] <mitya57> Mirv: ^
[14:08] <ScottK> Done.
[14:13] <Mirv> mitya57: ok
[14:19]  * sitter still fails to comprehend why the symbols are there to begin with
[14:20] <Riddell> ScottK:
[14:20] <Riddell> ScottK: thanks
[14:20]  * Riddell on konversation
[14:20] <sitter> Riddell: we are landing kf5.8 one would suppose, so I guess we'll just have a full qt5.4 rebuild in ~2 weeks?
[14:20] <Riddell> sitter: and plasma 5.2.1 I suppose so we'll rebuild that
[14:21] <sitter> frameworks?
[14:21] <Riddell> what about frameworks?
[14:21] <sitter> I meant rebuild all frameworks against qt5.4 :P
[14:21] <sitter> workspace we obviously get sooner
[14:22]  * sitter hungry; afk looking for an orange
[14:30] <sitter> gir1.2-git2-glib-1.0
[14:30] <sitter> dat name
[14:33] <Riddell> so eloquent
[14:33] <sitter> Riddell: who do I annoy about libgit2?
[14:34] <Mirv> mitya57: now all 6 archs finished
[14:35] <Riddell> sitter: whoever uploaded libgit2-glib-1.0-0
[14:35] <Riddell> or whoever cared about gitg
[14:35] <Riddell> so I guess some unity/gnome types
[14:37] <Riddell> sitter: d_ed says he's included some stuff from canonical into telepathy-qt5 and wonders if there's more stuff that's blocking him to release so we can upgrade
[14:38] <sitter> dunno
[14:38] <sitter> everything is on fire
[14:38] <sitter> everywhere
[14:38] <mitya57> Mirv: I see, will do another upload now
[14:48] <mitya57> Mirv: uploaded
[14:49] <sitter> Riddell: doesn't even have a fix upstream for the build fail
[14:56] <Riddell> sitter: what doesn't?
[14:56] <sitter> libgit2-glib
[14:56] <Riddell> right, that's why I gave up too
[14:57] <sitter> I also don't understand why it ftbfs
[14:57] <sitter> oh wait
[14:58] <sitter> >.<
[14:58] <sitter> we have 0.0.22 upstream latest is 0.22.0!
[15:00] <sitter> automake: error: cannot open < gtk-doc.make: No such file or directory
[15:00] <sitter> inf(head -> desk)
[15:01] <sitter> .gitignore:/gtk-doc.make
[15:01] <sitter> docs/reference/Makefile.am:include $(top_srcdir)/gtk-doc.make
[15:01] <sitter> I think this entire library construct is just meant to piss me off
[15:13] <sitter> release upgrader still needs qt5 port landing
[15:13] <sitter> also I think I have a merge request somewhere for that
[15:13] <sitter> https://code.launchpad.net/~kubuntu-packagers/ubuntu-release-upgrader/qt5/+merge/229620
[15:18] <Mirv> mitya57: probably succeeds now, only armhf building anymore. we'll see if migration now succeeds in ca. 1h
[15:22] <Riddell> kf5 konversation uploaded!
[15:28] <Riddell> sitter disappeared!  where does he go?!
[15:42] <Riddell> ooh sitter returned!
[15:48] <sitter> not for long
[16:48] <mitya57> Yay, Qt 5.4 migrated!
[16:52] <Mirv> \o/
[16:54] <Riddell> #
[16:54] <yofel> wheee
[16:55] <Riddell> ooh? https://launchpad.net/ubuntu/+source/qtbase-opensource-src still showing 5.3.2+dfsg-4ubuntu9  in vivid release
[16:56] <mitya57> Riddell: that's because it's "pending", not yet "published"
[16:56] <mitya57> https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.4.0+dfsg-4ubuntu2/+publishinghistory
[17:00] <Riddell> now it's showing two versions in release https://launchpad.net/ubuntu/+source/qtbase-opensource-src
[17:00] <Riddell> I think qt is taxing launchpad somewhat :)
[17:00] <Riddell> anyway, well done mitya57, Mirv :)
[17:04] <Mirv> thanks :)
[17:04] <Mirv> yeah I remember cjwatson raising eyebrows the last time on the gigabytes flowing through infrastructure :)
[17:11] <Riddell> good review for one of our derivatives http://betanews.com/2015/02/16/netrunner-15-prometheus-is-here-the-best-kde-based-linux-distro-gets-better/
[17:11]  * Riddell out
[17:41] <stikonas> ScottK: I think partitionmanager should not have any dependency on udisks now because  udisks was only used via Solid which is not used now...
[17:42]  * ScottK looks
[17:44] <ScottK> stikonas: Looks like you're right.  Thanks.
[17:44] <stikonas> probably kdelibs4support is not necessary either
[17:44] <ScottK> It is.
[17:44] <stikonas> oh, ok...
[17:45] <ScottK> It provides kdex.dtd.
[17:45] <ScottK> The docs don't build without it.
[17:45] <stikonas> oh, ok, I will see whether it can be fixed upstream...
[17:46] <ScottK> The code itself doesn't need it.
[17:46] <ScottK> stikonas: Your timing on the release was great.  Feature freeze for our next release is this week, so it was just in time.
[17:48] <stikonas> ScottK: glad to hear... That's why I was trying to get it out...
[17:48] <stikonas> although, I didn't know exact date
[17:48] <stikonas> but I thought it should be soon...
[17:48] <ScottK> Thursday.
[17:50] <ScottK> stikonas: If you do any bugfix updates to partitionmanager 1.2, please pimg me.  I wouldn't have noticed 1.2 except for your post on Planet KDE.
[17:50] <stikonas> ScottK: ok. I also posted it on kde-apps-announce
[17:50] <stikonas> but it is still stuck in moderation :(
[17:50] <ScottK> Well, I don't read that one anyway.  I probably should.
[17:51] <stikonas> ok, I will try to remember to ping you
[19:47] <BluesKaj> ok, I set up an old hdd and installed 15.04 on it so it now has it's own / and /home dirs witout resorting to extended partitioning
[20:12] <soee> hiho
[21:22] <soee> someone has this: KDEInit cannot run '': Cannot open library '/usr/lib/x86_64-linux-gnu/libkdeinit5_'. Cannot load library /usr/lib/x86_64-linux-gnu/libkdeinit5_: (/usr/lib/x86_64-linux-gnu/libkdeinit5_.so: cannot open shared object file: No such file or directory)
[21:22] <soee> when trying to load partition manager ?>
[21:59] <ScottK> soee: Which version?  Just uploaded a new one today for vivid.
[22:01] <soee> ScottK: i did the upgrades but didnt reboot
[22:01] <soee> do i need it to make it work ?
[22:01] <ScottK> Shouldn't for partitionmanager.
[22:03] <soee> ScottK: i can run if from terminal and i see windowd with input for password, if i enter password i have error
[22:03] <soee> something about pmlibpartedbackendplugin that cannot be loaded
[22:03] <ScottK> OK.
[22:03] <ScottK> Did you get the libkdeinit5_ error too?
[22:05] <soee> if i start from terminal? no just this this window with error http://wstaw.org/m/2015/02/16/worksace7.png
[22:10] <ScottK> soee: Would you please translate.
[22:13] <soee> ScottK: something like: Cannot load pmlibpartedbackendplugin that is set nor the default pmlibpartedbackendplugin plugin. Please check your install
[22:14] <soee> ok i googled it so it is in en:
[22:14] <soee> Neither the configured ("pmlibpartedbackendplugin") nor the default ("pmlibpartedbackendplugin") backend plugin could be loaded.
[22:14] <soee> Please check your installation.
[22:17] <soee> it was mentioned here https://aur.archlinux.org/packages/partitionmanager-git/?comments=all
[22:30] <ScottK> Thanks.
[22:36] <soee> ok time to get some sleep, ScottK ill try to catch you tomorrow and ask about this issue
[22:37] <ScottK> OK.  Thanks for the feedback.
[23:15] <stikonas> ScottK: looks like (non English) docs in the tarball are from kde4 branch, that's why you needed kdelibs4support-data. I will release 1.2.1 in the near future
[23:17] <stikonas> will try to do it before Thursday...
[23:19] <jussi> Morning all
[23:22] <ScottK> stikonas: No rush for bug fixes.  Only new features are affected by the deadline.
[23:22] <ScottK> stikonas: Any thoughts about what might cause http://wstaw.org/m/2015/02/16/worksace7.png (translates as Neither the configured ("pmlibpartedbackendplugin") nor the default ("pmlibpartedbackendplugin") backend plugin could be loaded.
[23:23] <stikonas> yeah, plugins installed in the wrong folder
[23:23] <ScottK> Where do I want them installed?
[23:23] <ScottK> I'll make sure they land there.
[23:23] <stikonas> KDE_INSTALL_USE_QT_SYS_PATH should be on
[23:23] <stikonas> I think
[23:24] <stikonas> actually Riddell told me this tip, but it worked for me
[23:24] <stikonas> KDE_INSTALL_USE_QT_SYS_PATH is a cmake option...
[23:25] <ScottK> Right.  They landed in /usr/lib/kde4/, which clearly isn't right.
[23:26] <ScottK> stikonas: Should that be enabled in the upstream CMakeLists.txt?
[23:26] <stikonas> don't know, maybe I should...
[23:26] <ScottK> (I can do it for the package, but it seems like something everyone would want)
[23:26] <stikonas> I know gentoo enables this option for all kde packages
[23:26] <stikonas> I guess I can do it too
[23:27] <ScottK> Something else for 1.2.1 then.
[23:27] <stikonas> ok, agreed
[23:27] <ScottK> Thanks.
[23:27] <stikonas> my release got a bit rough :(
[23:27] <ScottK> I'll set it in the packaging in the meantime.
[23:27] <stikonas> well, I think it was the first extragear project with KF5 support...
[23:27] <ScottK> If that's the worst of it, not so bad.
[23:27] <stikonas> so it was a bit more difficult
[23:28] <ScottK> No doubt.
[23:28] <ScottK> I appreciate the port.  The more stuff we can get to kf5 the better.
[23:28] <stikonas> well, kbruch and kteatime were also ported by me :)
[23:28] <stikonas> but they are much smaller projects
[23:31] <jussi> can someone verify a bug on plasma 5/14.10 for me? Lock your screen on a laptop, then plug an external screen (Im using VGA)in and see what happens? (I get my programs come up for a moment so I can see everything on the screen, then lock screen comes up)


[01:37] <axw> davecheney: how does the GUI know to hide NRPE relationships?
[01:37] <axw> NRPE-to-Nagios I mean
[01:43] <davecheney> subs are not shown
[01:43] <davecheney> thye are just a little marker on the sevice
[01:43] <davecheney> when you hover over them
[01:43] <davecheney> the links from the subs to their 'provides' peers are shown
[01:49] <rick_h_> heh, I work on the gui and didn't realize that was updated. I know there's some upcoming work for making relations show better though
[01:49] <rick_h_> just had to go try it out in jujucharms.com and see
[01:49] <davecheney> :)
[01:50] <rick_h_> there's been a lot of talk of 'visualization layers' though. one day
[01:54] <axw> cool
[01:58] <axw> hmm, I don't find the nrpe hover thing very intuitive
[03:13] <wallyworld> thumper: that test you didn't like needs to be in one method because it's testing multiple operations with some succeeding and others failing. i'll see if i can make it clearer by adding comments or whatever
[03:14] <wallyworld> since it's a bulk api, there's no point testing one machine at a time
[03:59] <thumper> it's been a shit day for getting things done
[03:59]  * thumper back later to talk to robie
[04:49] <hazmat> i just had to do something fairly dirty for removing  ghost machines.. direct db surgery.. fwiw, http://paste.ubuntu.com/6441072/
[04:57] <hazmat> should be unesc come 1.16.4 with terminate-machine --force
[05:08] <davecheney> hazmat: bad news
[05:08] <davecheney> that feature won't make it into 1.16.4
[05:08] <davecheney> it breaks upgrades
[05:08] <davecheney> so sinzui told me
[05:11] <hazmat> davecheney,  that seems odd, re garbage cleanup breaking upgrades.. haven't looked at fwereade's patch for it though.
[05:14] <davecheney> hazmat: something about the fix relies on an api call which is not present in 1.16.3
[05:19] <hazmat> ah
[08:10] <rogpeppe> mornin' all
[08:21] <jam> morning rogpeppe
[08:21] <jam> rogpeppe: I never did get your email
[08:21] <jam> let me check my spam folder just in case
[08:21] <rogpeppe> jam: oh, hmm
[08:22] <rogpeppe> jam: weird, looks like i never sent it
[08:22] <rogpeppe> jam: sent now
[08:22] <jam> nope, not there either :)
[08:23] <rogpeppe> jam: you should get it in a mo
[08:23] <jam> got it
[08:23] <rogpeppe> jam: cool. dunno how that happened...
[08:25] <jam> rogpeppe: its a big graph :)
[08:25] <rogpeppe> jam: yeah
[08:26] <jam> its interesting to see the simple ones off to the right, and the really big convoluted mess on the left
[08:26] <rogpeppe> jam: yeah
[08:26] <rogpeppe> jam: note how all the stuff on the left comes in through the API (the reflect.Call right at the top)
[08:27] <jam> yep
[08:27] <jam> handleRequest
[08:28] <TheMue> rogpeppe: thx for your review yesterday evening
[08:28] <rogpeppe> jam: note: when you see =0x[0-9a-f]+, that's when there's only a single value for that parameter in all the calls
[08:28] <rogpeppe> jam: otherwise the count is the number of distinct values for that parameter
[08:29] <rogpeppe> TheMue: np
[08:29] <jam> rogpeppe: "sync.runtime_Semacquire" with 14642 callers and 4922 distinct values
[08:29] <jam> I'm curious how that works
[08:30] <jam> I would have thought you'd have, like 1 lock object they were blocking on
[08:30] <rogpeppe> jam: i think it is, mostly - it's probably to do with the implementation of semacquire
[08:31] <jam> rogpeppe: well on the other hand if you had different objects talking about something similar, I would expect 14,000 different values
[08:31] <rogpeppe> jam: i'm also interested in the big sync.Mutex.Lock called by sync.RWMutex.Lock
[08:31] <jam> I'm curious that we would have some ratio there
[08:31] <jam> rogpeppe: that's the acquireSocket call
[08:31] <jam> which is "I want to ask Mongo something, let me have the socket to write to it"
[08:31] <rogpeppe> jam: the former has 4196 different values but the latter has only one
[08:32] <jam> hmmm.. why would we be calling RLock, though
[08:32] <jam> I would have thought we would need the WLock
[08:34] <jam> "acquireSocket" says "Read-only lock to check for previously reserved socket"
[08:35] <rogpeppe> jam: well, there are 9720 blocked on the same semaphore
[08:36] <jam> I haven't found 9720 yet
[08:36] <jam> but I do see 8478 calling sync.RLock
[08:36] <jam> and 6159 calling sync.Lock
[08:36] <jam> and the former has only 1 object
[08:36] <jam> the latter has 4916 objects
[08:36] <jam> so yeah, probably it is just that we have a couple different things going on, some of which are on a shared lock, some are on distributed locks
[08:37] <jam> I'm guessing the results from a mgo query
[08:37] <jam> are blocked on a sync lock
[08:37] <jam> unique to that queury
[08:37] <jam> query
[08:37] <jam> given SimpleQuery is blocked on 4916 different locks
[08:37] <jam> while acquireSocket is 2866 calls blocked on 1 object
[08:37] <jam> and the other 5612 calls from Find
[08:37] <jam> blocked on that same object
[08:38] <rogpeppe> jam: 14642 -  4922 = 9720
[08:39] <jam> rogpeppe: I think you're numbers are actually a bit wrong. 8478 are blocked on the same one, 4 are blocked on one side, and 4916 are blocked on unique objects
[08:39] <jam> specifically, acquireSocket and Find both use a session.m mutex to handle global state stuff
[08:40] <jam> session.queryConfig AFAICT
[08:40] <jam> and s.masterSocket
[08:41] <jam> rogpeppe: so if a bunch ofthings are blocked on a sync.RWMutex.RLock doesn't that mean that something else has the Lock of that object?
[08:41] <jam> otherwise the RLocks are mutually compatible, right?
[08:42] <rogpeppe> jam: yup
[08:44] <rogpeppe> jam: the RLock seems to be just to get the default query parameters
[08:44] <jam> rogpeppe: so in Find yes, in acquireSocket it is to get the masterSocket
[08:44] <jam> which then has its own Lock
[08:46] <jam> rogpeppe: right, so SimpleQuery has N locks (each call creates a new mutex which will be unlocked when the replyFunc gets the response from mongo
[08:47] <rogpeppe> jam: looks like the whole thing is blocked trying to write to the mongo socket
[08:47] <jam> rogpeppe: well all of those are blocked waiting for response
[08:47] <jam> responses
[08:47] <jam> they should have already written their requests
[08:48] <jam> rogpeppe: *lots* of things are blocked on the global session lock. Which all *should* be using RLocks, but something is taking out the other lock
[08:48] <rogpeppe> jam: look at the 1-wide trail coming out of mongoSocket.Query
[08:48] <rogpeppe> jam: leading to tls.Conn.Write
[08:49] <rogpeppe> jam: and eventually to net.netFD.Write
[08:49] <rogpeppe> jam: i think it's likely that's the path that actually has the lock
[08:50] <rogpeppe> jam: hmm, mind you, the write lock should not block the readers
[08:51] <jam> rogpeppe: a write lock does block read locks
[08:51] <jam> I thihnk
[08:51] <jam> think
[08:51] <jam> since it is saynig "I'm changing the data you want to read"
[08:51] <rogpeppe> jam: no, sorry, i meant something different there
[08:52] <jam> rogpeppe: but the lock in mongoSocket.Query should be the mongoSocket mutex *not* the Session mutex
[08:52] <rogpeppe> jam: i meant the lock on the io.Writer shouldn't block the io.Readers
[08:52] <jam> rogpeppe: so digging around mgo/session.go I don't see many code paths that take the session.m.Lock
[08:52] <jam> Login does
[08:52] <jam> and Clone
[08:53] <rogpeppe> jam: and indeed mongoSocket.readLoop is blocked on tls.Conn.Read as expected
[08:53] <jam> rogpeppe: sure, I'd expect that, but it doesn't explain why the Session.m is write Locked blocking all the acquireSocket and Find calls
[08:54] <rogpeppe> jam: there are quite a few Clones around
[08:54] <jam> rogpeppe: session.Clone
[08:54] <jam> there is only one going via sync.RWMutex.Lock
[08:54] <jam> ah, nm, there are 1136 of them
[08:54] <jam> probably only 1 of them is trying to execute
[08:55] <rogpeppe> jam: that doesn't feel quite right - if one was executing, it wouldn't be in Lock, i think
[08:55] <jam> maybe
[08:55] <rogpeppe> jam: except fleetingly
[08:55] <jam> so if you look at Clone, and then follow it down to sync.RWMutex.Lock
[08:55] <jam> you'll notice that all of them are called with the same object
[08:56] <jam> and 1135 of them are stuck in sync.*Mutex.Lock
[08:56] <jam> and *1* of them is in sync.runtime_Semacquire
[08:56] <jam> well, directly vs indirectly
[08:56] <rogpeppe> jam: so perhaps that's just spinning fast
[08:57] <jam> rogpeppe: yeah, its possible, it does have 1136 Lock requests to chew through and another 8478 RLock requests concurrently
[08:57] <jam> rogpeppe: so it *looks* like our transaction logic is requiring a Clone which requires a write Lock on the session object
[08:58] <jam> runTransaction leads down into mgo.Query.Apply which ends up at session.Clone
[08:58] <rogpeppe> jam: yeah, i don't know what Query.Apply does
[08:59] <rogpeppe> jam: ah: 	session.SetMode(Strong, false)
[08:59] <rogpeppe> jam: that's why it does the Clone
[09:00] <jam> rogpeppe: what I'm getting out of this is that the txn logic gums up a lot of the internals :)
[09:00] <jam> we have 3307 calls to state.runTransaction
[09:00] <jam> mostly from SetAgentVersion calls
[09:00] <jam> which *do* write to the DB
[09:00] <rogpeppe> jam: it's what i expected
[09:00] <jam> so a unit agent coming up does a bunch of writes
[09:01] <rogpeppe> jam: the txn stuff is marvellously inefficient
[09:01] <jam> SetPrivateAddress, SetPublicAddress, SetAgentVersion are the big ones
[09:04] <jam> rogpeppe: you know what would be interesting, being able to poll runtime.Stack and generate this graph "live"
[09:04] <jam> and watch it evolve
[09:05] <rogpeppe> jam: i've been thinking about this, yes
[09:05] <rogpeppe> jam: the question is how to relate two graphs in the sequence
[09:05] <rogpeppe> jam: because the layout may be very different
[09:06] <jam> rogpeppe: I *think* you can see something like dot with existing locations
[09:06] <jam> but yeah, it doesn't guarantee they'll stay put (AFAIK)
[09:06] <jam> morning fwereade
[09:06] <rogpeppe> jam: but it would not be hard to make an api call to get the current stack
[09:06] <fwereade> jam, heyhey
[09:07] <rogpeppe> jam: (or the summary of the current stack, which would incur considerably less network traffic)
[09:07] <rogpeppe> fwereade: hiya
[09:07] <jam> rogpeppe: I would probably just grab the stack and dump it out to a local place/socket/whatever and have that process do the CPU work of collapsing it
[09:08] <rogpeppe> jam: just make the API call locally
[09:09] <rogpeppe> jam: or perhaps from another adjacent machine, so the processing doesn't mess too much with progress
[09:09] <fwereade> hey rogpeppe
[09:15] <axw> jam: https://codereview.appspot.com/28270043/ updated to use agent.conf; a bit less awkward now, I think.
[09:33] <dimitern> fwereade, rogpeppe: poke from yesterday :) https://codereview.appspot.com/21940044/ - upgrade-juju + api
[09:33] <rogpeppe> dimitern: will look after i've finished looking at axw's
[09:33] <axw> thanks rogpeppe
[09:40] <dimitern> rogpeppe, cheers
[09:43] <rogpeppe> axw: could you remind me why we need configurable agent and mongo service names?
[09:43] <axw> rogpeppe: local provider, so different users can each have an environment on the same machine
[09:44] <rogpeppe> axw: ah right.
[09:44] <rogpeppe> axw: i guess we could just put the uuid in there
[09:44] <axw> rogpeppe: tho ideally, they'd go into user-level upstart jobs
[09:44] <rogpeppe> axw: but that's a bigger change
[09:44] <axw> rogpeppe: true, could do that across the board
[09:44] <rogpeppe> axw: that would be better still
[09:44] <axw> an even bigger change ;)
[09:45] <rogpeppe> axw: (and not possible currently AFAIK)
[09:45] <axw> yeah, I don't know the status of that
[09:50] <rogpeppe> axw: reviewed
[09:51] <axw> ta
[09:52] <axw> rogpeppe: yeah, I started down the road of len(errors)==1 (actually a switch), but it started getting ugly
[09:53] <rogpeppe> axw: yeah.
[09:53] <axw> the error message will only go into the machine log anyway.
[09:53] <rogpeppe> axw: true 'nuff
[09:53]  * rogpeppe sometimes wonders about a MultiError type
[09:54] <axw> heh, I did consider it :)
[09:54] <axw> didn't feel like burdening this CL with a one-size-fits all error list
[09:59] <wallyworld> fwereade: hi, don't feel obliged to look unless you are interested - these follow on from our conversations https://codereview.appspot.com/28790043/ https://codereview.appspot.com/28890043/
[10:00] <fwereade> wallyworld, thanks, I *might* get to them before the standup
[10:00] <wallyworld> no hurry or obligation
[10:22]  * rogpeppe reboots, sigh.
[10:47] <jam> mgz: rogpeppe, natefinch standup? https://plus.google.com/hangouts/_/calendar/am9obi5tZWluZWxAY2Fub25pY2FsLmNvbQ.mf0d8r5pfb44m16v9b2n5i29ig
[10:47] <jam> wallyworld: ^
[11:17] <jam> dimitern: I understand William's concern about an API that goes unused almost immediately, but I think we'd still have a "tell me what tools you can find" API, and then follow that with a maybe-upload, and then a "now set your Agent Version", so we still need the api
[11:19] <dimitern> jam, sounds reasonable
[11:20] <dimitern> jam, except that the actual tools selection for the upgrade will happen in the command still
[11:31] <jam> dimitern: https://codereview.appspot.com/21940044/ reviewed
[11:33] <dimitern> jam, ta
[12:52] <mattyw> rogpeppe, fwereade I've got a cl for you to take a quick look at: https://codereview.appspot.com/28970043. (it's better to ask forgiveness than permission)
[12:54] <fwereade> mattyw, LGTM
[12:56] <fwereade> mattyw, actually
[12:56] <fwereade> mattyw, would you copy the addresses slice instead of returning the internal one?
[13:04] <mattyw> fwereade, sorry - I'm not sure I understand
[13:04] <fwereade> mattyw, allocate a new slice of the same type/size, copy the contents, return the fresh one
[13:05] <fwereade> mattyw, lest a client alter the returned slice and mess with the config's internals
[13:05] <mattyw> fwereade, isn't []string a value anyway?
[13:07] <rogpeppe> mattyw: a slice is a reference type
[13:07] <fwereade> mattyw, slices are references -- http://play.golang.org/
[13:08] <rogpeppe> mattyw: the slice itself is like a struct containing a pointer to the underlying array, the length and the capacity
[13:08] <mattyw> rogpeppe, fwereade sorry - just reading go-slices and internals and realised - thanks - I'll sort it out
[13:09] <fwereade> mattyw, no worries, easy to miss
[13:09] <mattyw> rogpeppe, oh yes - of course, I probably have to be reminded of that every week ;)
[13:10] <rogpeppe> mattyw: that said, i don't care too much in this instance; the config isn't an immutable type. still, probably best to copy to avoid unexpected behaviour
[13:24] <rogpeppe> trivial code move review anyone? https://codereview.appspot.com/28980043
[13:24] <rogpeppe> fwereade, jam, dimitern: ^
[13:24] <mgz> fwereade seems to have reviewed it alreadyu
[13:27] <mgz> rogpeppe: seems good to be as well though
[13:28] <dimitern> rogpeppe, reviewed
[13:32] <mattyw> rogpeppe, I've updated https://codereview.appspot.com/28970043. I'm afraid I didn't notice your comment until I'd pushed the change for fwereade's comment so the delta from patch set might be a bit mixed up -but it's hopefully small enough a change to not matter
[13:37] <rogpeppe> mattyw: reviewed
[13:49] <rogpeppe> fwereade: looking at AssignToNewMachineOrContainer, it seems to me that the logic isn't quite right when there are several clean machines
[13:49] <fwereade> rogpeppe, oh yes?
[13:49] <rogpeppe> fwereade: at the end of that function, it seems to assume that because the machine it tried to choose isn't now clean, that there are no clean machines
[13:50] <rogpeppe> fwereade: but i think it should probably just recurse into AssignToNewMachineOrContainer or something like that
[13:50] <rogpeppe> fwereade: i.e. look for another clean machine
[13:52] <adeuring> rogpeppe: a trivial MP: https://codereview.appspot.com/29000043
[13:52] <rogpeppe> adeuring: looking
[13:52] <adeuring> thanks!
[13:53] <rogpeppe> adeuring: LGTM
[13:53] <rogpeppe> adeuring: thanks
[13:53] <fwereade> rogpeppe, yeah, we should probably iterate through the clean machines, well soptted
[13:53] <adeuring> rogpeppe: thanks!
[13:53] <TheMue> rogpeppe: https://codereview.appspot.com/24040044/ is in again after handling your review
[13:53] <rogpeppe> fwereade: i don't think we can just iterate through the clean machines
[13:54] <rogpeppe> fwereade: because a new clean machine might be created during the iteration
[13:54] <TheMue> rogpeppe: there's still an open question regarding the passing of timeouts from the clients to the apiserver
[13:54] <rogpeppe> TheMue: looking
[13:54] <TheMue> rogpeppe: thx
[13:56] <fwereade> rogpeppe, I'm not too bothered by that case -- isn't that always a possibility? any time we decide there aren't any clean machines and create a new one, a sufficiently annoying and precise demon could create a new clean machine and say "why didn't you use that? lol u idiots"
[13:56] <rogpeppe> fwereade: true enough
[13:58] <fwereade> rogpeppe, in practice I think we'd need a whole bunch of clean machines for the iteration to take a long time *and* for all of those to be sniped *and* for a new clean one to be created in that window, which probably isn't *that* wideopen in the first place
[13:58] <rogpeppe> fwereade: i've been sporadically tempted to fact out the unit machine-assigning stuff to addmachine.go too, BTW, but i keep swithering
[13:58] <rogpeppe> s/fact/factor/
[13:59] <fwereade> rogpeppe, yeah, AssignToNewMachine is definitely related, the rest is a bit less clear
[14:20] <rogpeppe> fwereade: another thing i just noticed: the logic inside the "if machineIdSpec != """ test inside juju.Conn.AddUnits really looks as if it should be living inside state - do you concur?
[14:22] <fwereade> rogpeppe, not immediately clear to me, anyway -- expand?
[14:23] <fwereade> rogpeppe, in particular handling lxc:3 inside state seems like it's definitely a bad idea
[14:24] <fwereade> rogpeppe, the "lxc:" ought to be handled by something more like an environ (ok, a pseudo-environ backed by state, but still)
[14:44] <rogpeppe> TheMue: you've got a review
[14:45] <TheMue> rogpeppe: ta
[14:45] <rogpeppe> fwereade: sorry, only just saw your remarks
[14:45] <rogpeppe> fwereade: thinking
[14:47] <rogpeppe> fwereade: why does state need to be ignorant of the lxc:3 syntax?
[14:48] <rogpeppe> fwereade: i'm probably just ignorant of the underlying rationale behind that syntax
[14:48] <rogpeppe> fwereade: and where it sits in the set of juju abstractions
[14:50] <fwereade> rogpeppe, the name we've been using is "placement directives"
[14:51] <fwereade> rogpeppe, provider-specific languages for instance locations
[15:03] <rogpeppe> fwereade: I'm having conceptual difficulties reconciling lxc:3 with ec2:us-east-1c.
[15:03] <rogpeppe> fwereade: The former is saying "an lxc container within machine 3" AFAICS and the latter "the us-east1c region within the ec2 provider".
[15:03] <rogpeppe> fwereade: The container/contained relationship seems to be different in each one.
[15:03] <rogpeppe> fwereade: Is there a nice way of thinking about these things?
[15:05] <fwereade> rogpeppe, consider lxc a provider -- something that gives you new instances
[15:06] <fwereade> rogpeppe, the domain it has access to happens to be the set of machines already in the environment
[15:06]  * rogpeppe twists his brain
[15:10] <rogpeppe> fwereade: also, wondering why lxc:3:lxc:2  is equivalent to lxc:3/lxc/2
[15:10] <rogpeppe> fwereade: or if it is - i may well be missing something
[15:12] <fwereade> rogpeppe, if there's a lxc:3:lxc:2 in there that's just a mistake I think
[15:13] <rogpeppe> fwereade: i'm looking at this line: mid = strings.Join(specParts[1:], "/")
[15:13] <fwereade> rogpeppe, lxc:3/lxc/2 would be "a new lxc container inside 3/lxc/2"
[15:13] <fwereade> rogpeppe, <provider>:<directive>
[15:13] <fwereade> rogpeppe, where the lxc provider accepts machine ids as directives
[15:14] <rogpeppe> fwereade: but it splits the whole thing on ":" then joins it again on "/"
[15:14] <rogpeppe> fwereade: so AFAICS lxc:3:lxc:2 will be transformed into lxc:3/lxc/2
[15:15] <rogpeppe> fwereade: perhaps it's not deliberate
[15:15] <fwereade> rogpeppe, I suspect it's just an oversight
[15:15] <rogpeppe> fwereade: ok
[15:15] <fwereade> rogpeppe, in general the plan is to extract the bit before the first colon and hand the bits after the colon off to the provider unchanged
[15:16] <fwereade> rogpeppe, good catch, thank you
[15:16] <rogpeppe> fwereade: ah, i think they probably just want to SplitN
[15:16] <fwereade> rogpeppe, +1
[15:31] <natefinch> wow, I just noticed mongo's replset flag is actually replSet (capital S).... who uses camelcase in their command line flags? :/
[15:31] <mattyw> rogpeppe, is there a way I can get the name of the current envname for passing to juju.NewAPIClientFromName?
[15:33] <rogpeppe> fwereade: still looking at Conn.AddUnits, getting closer to why I thought some of it at least should live in state, what's to stop the newly added machine (the AddMachineWithConstraints line) being grabbed by some random other service with a container=lxc constraint?
[15:33] <rogpeppe> mattyw: just pass ""
[15:34] <mattyw> rogpeppe, that uses the defauly - all sorts of craziness happens if I use juju switch
[15:34] <rogpeppe> mattyw: ah, i see
[15:34] <rogpeppe> mattyw: what's the context?
[15:34] <fwereade> rogpeppe, nothing, I've always hated all that stuff :(
[15:35] <fwereade> rogpeppe, I think I'm with you on the non-lxc: bits being better off as single txns
[15:35] <rogpeppe> fwereade: i'd hoped to get away without touching this stuff
[15:36] <fwereade> rogpeppe, sadly the state of state is such that changes almost invariably involve fixes as well
[15:36] <rogpeppe> mattyw: i think we probably want to factor out the juju switch logic somewhere
[15:37] <rogpeppe> fwereade: most of the dubious stuff is relatively recent :-(
[15:37] <fwereade> rogpeppe, but I don't think that particular stuff is in scope -- pre-existing bugs shouldn't pull you out of your way unless fixing them actually helps you
[15:38] <fwereade> rogpeppe, the add-unit/add-machine stuff was always a problem, and I'm sure the machine-sniping problem always existed too
[15:38] <fwereade> rogpeppe, the current arrangement of the code maybe brings the problems into clearer focus
[15:39] <rogpeppe> fwereade: the --to and containers stuff has added a great deal of difficult-to-reason-about code
[15:40] <rogpeppe> fwereade: at least, i find it hard to reason about :-)
[15:40] <fwereade> rogpeppe, but the real problem is that we've never really had a coherent state model for machines, and so we built on a shaky foundation without firming it up underneath us
[15:40] <fwereade> rogpeppe, yay pressure
[15:40] <rogpeppe> fwereade: yeah
[15:41] <rogpeppe> mattyw: i think we probably want a DefaultEnvironName function inside juju
[15:41] <rogpeppe> mattyw: inside the juju package, that is
[15:42] <fwereade> rogpeppe, mattyw: hmm, I don't think we should be talking about environs' names at all inside state -- except where we really cannot help it
[15:43] <fwereade> rogpeppe, mattyw: and those should always be for historical reasons
[15:43] <rogpeppe> fwereade: so how do you think an external command that calls NewAPIClientFromName should work?
[15:44] <rogpeppe> fwereade: given that it wants to respect the usual conventions for finding an environment
[15:44] <rogpeppe> fwereade: JUJU_ENV, switch value
[15:44] <fwereade> rogpeppe, mattyw: ok, I misread somehow, because I am an idiot
[15:45] <fwereade> rogpeppe, mattyw: I'd been thinking of Conn as something server-side
[15:45] <fwereade> rogpeppe, mattyw: and think of juju as primarily there for the Conn
[15:46] <fwereade> rogpeppe, mattyw: client-side that's fine... I guess the juju package itself should just be split up at somepoint
[15:47] <rogpeppe> fwereade: what part of the juju package isn't intended for client side?
[15:47] <fwereade> rogpeppe, Conn?
[15:48] <rogpeppe> fwereade: that's definitely client-side, isn't it?
[15:48] <rogpeppe> fwereade: ah, except that it's used by the API these days
[15:48] <fwereade> rogpeppe, that state+environ combo is most certainly not ;p
[15:48] <fwereade> rogpeppe, once, indeed, it was
[15:49] <fwereade> rogpeppe, but, eh, different bits evolve at different rates and things end up in surprising places
[15:49] <rogpeppe> fwereade: you're right - it should be again
[15:49] <rogpeppe> fwereade: the client api has really taken on the role of juju now
[15:49] <fwereade> rogpeppe, yeah
[15:50] <rogpeppe> fwereade: the state-connection stuff should probably be moved somewhere under apiserver
[15:51]  * rogpeppe grabs some lunch
[16:02] <mattyw> rogpeppe, fwereade for now it looks like I can use cmd.ReadCurrentEnvironment() to solve my issue
[16:17] <rogpeppe> mattyw: that doesn't respect $JUJU_ENV, unfortunately
[16:17] <mattyw> rogpeppe, I don't seeme to have JUJU_ENV set on my machine - where does that come from?
[16:25] <rogpeppe> mattyw: you don't need it set, but it's an optional thing
[16:25] <rogpeppe> mattyw: it overrides juju switch
[16:31] <mattyw> rogpeppe, but I can do if os.Getenv("JUJU_ENV") == "" { envName := cmd.ReadCurrentEnv() } ?
[16:41] <mattyw> rogpeppe, I guess what you're saying is all of that logic should be put somewhere in juju?
[17:09] <natefinch> rogpeppe: so I'm trying to write tests and I realized that we have testing.mgo ... but it's all set up to be a single instance of mongo.  Seems like it should be refactored to allow N instances... probably by just making it all methods on a type rather than package level functions.  What do you think?
[17:31] <rogpeppe> natefinch: i was wondering when you'd come up against that issue...
[17:32] <rogpeppe> natefinch: (sorry for slow response - my irc client is declining to run my notification script again)
[17:32] <natefinch> rogpeppe: no big deal.  Was getting lunch anyway
[17:32] <rogpeppe> natefinch: i agree, although to save churn perhaps we should keep the existing entry points the same, but as a thin layer on top of the multiple-mongo layer
[17:33] <rogpeppe> natefinch: perhaps a testing/mongo package?
[17:40] <natefinch> rogpeppe: yeah, that's doable, though I could refactor the current file without modifying the existing entry points.  Either way is fine.
[17:45] <rogpeppe> natefinch: go with whatever you feel like.
[17:46] <rogpeppe> natefinch, fwereade: trivial code review BTW: https://codereview.appspot.com/29130043/
[17:46] <natefinch> rogpeppe: I can get it.  I have been slacking in the review dept
[17:47] <natefinch> rogpeppe: ahh yeah, this is what you guys were talking about earlier
[17:48] <rogpeppe> natefinch: yeah
[17:52] <natefinch> rogpeppe: I wish that machine id parsing code were broken out into its own function
[17:52] <natefinch> rogpeppe: would be a lot easier to test in isolation
[17:53] <rogpeppe> natefinch: it's not really machine id parsing
[17:53] <rogpeppe> natefinch: but yes, i agree
[17:53] <natefinch> rogpeppe: right, sorry, bad choice of words
[17:53] <rogpeppe> natefinch: but i'm not fixing everything now
[17:55] <natefinch> rogpeppe: now is the best time to fix everything ;)    Well, not everything.  But little things, sure.  Anyway, LGTM.
[18:09] <jcastro> any core devs joining in the juju sessions at UDS?
[18:09] <jcastro> http://summit.ubuntu.com/uds-1311/meeting/22011/t-cloud-juju-destroy-machines-by-default/
[18:12] <natefinch> jcastro - I can join
[18:12] <jcastro> https://plus.google.com/hangouts/_/7acpimg327ft0ld2qto6rnffgk?authuser=0&hl=en
[18:43] <rogpeppe> jcastro: sorry, if i'd seen your msg above, i'd have joined
[18:44] <rogpeppe> jcastro: to my shame, i didn't know about this at all
[18:52] <jcastro> rogpeppe, ok I can post a reminder
[18:53] <natefinch> jcastro: thanks... I didn't know about it either.
[18:59] <jcastro> There is a juju-core update for trusty tomorrow that we'll need some of you guys for
[19:00] <jcastro> mainly a "what's coming in 14.04" kind of thing
[19:00] <rogpeppe> jcastro: interesting discussion
[19:01] <rogpeppe> jcastro: i think my view would be: if we created the machine automatically, we should destroy it automatically.
[19:01]  * jcastro nods
[19:01] <rogpeppe> jcastro: but if you used add-machine explicitly, i'm not sure we should
[19:04] <natefinch> rogpeppe: honestly, add-machine doesn't really fit the way juju is supposed to work anyway.
[19:05] <rogpeppe> natefinch: but that's the way it does work, and we have to, um, work with that
[19:05] <jcastro> hah, we have add-machine?
[19:05] <jcastro> never needed it
[19:06] <natefinch> rogpeppe: commands can be removed as easily as they're added.  More easily, even.  But even if not... I'd hate to see add-machine causing more complexity percolating through the system.
[19:06] <natefinch> jcastro: exactly. There
[19:06] <natefinch> jcastro: there's very little need for it
[19:07] <jcastro> yeah, if I need a new machine it's `juju deploy ubuntu`
[19:26] <mattyw> rogpeppe, you still there?
[19:28] <rogpeppe> mattyw: i am
[19:29] <rogpeppe> mattyw: (lucky i saw your msg - my irc client has stopped notifying me again dammit)
[19:29] <rogpeppe> mattyw: what's up bro?
[19:29] <mattyw> rogpeppe, can I be a pain and ask for another look at https://codereview.appspot.com/28970043/?
[19:29] <rogpeppe> mattyw: np
[19:29] <mattyw> rogpeppe, thanks - you sure you didn't turn of notifications ;)
[19:30] <rogpeppe> mattyw: in general if i say LGTM i mean you can make the change and submit
[19:30] <rogpeppe> mattyw: yeah, unfortunately so
[19:30] <mattyw> rogpeppe, I thought that was probably the case - but part of my contract says to keep rogpeppe 100% happy though
[19:31] <rogpeppe> mattyw: i don't use the magic acronym if i don't mean it :-)
[19:31] <rogpeppe> mattyw: aw
[19:31] <rogpeppe> mattyw: LGTM says "i'm happy"
[19:31] <mattyw> rogpeppe, you cheated though - you said LGTM with a tiny simplification
[19:32] <mattyw> wanted to make sure you were happy with the simplification
[19:32] <rogpeppe> mattyw: given that it's exactly what i suggested (apart from that mistake i made), i should hope so :-)
[19:32] <mattyw> rogpeppe, sweet
[19:33] <mattyw> I don't have permission to mark it approved - I guess someone else will pick that up
[19:33] <rogpeppe> mattyw: i'll approve it
[19:33] <mattyw> rogpeppe, thanks - another question then while I've distracted you
[19:33] <rogpeppe> mattyw: done
[19:33] <mattyw> thanks
[19:33] <rogpeppe> mattyw: go on
[19:35] <rogpeppe> mattyw: make it quick - i just saw the car arrive back and i'll need to go and have supper...
[19:35] <mattyw> on 1.16 - when I'm "WatchingAll" throught the api and I call add-unit, i seem to get updates about all the state changes for the new unit - then after the new unit gets to started I see another update about the existing unit
[19:35] <mattyw> rogpeppe, you can go
[19:35] <mattyw> we can talk about this tomorrow
[19:35] <rogpeppe> mattyw: ok, ping me
[19:35] <mattyw> and I'll work out some proper details and some pastes
[19:35] <rogpeppe> mattyw: cool.
[19:35] <mattyw> rogpeppe, enjoy supper
[19:35] <rogpeppe> mattyw: see ya tomoz
[19:35] <rogpeppe> g'night all
[19:36] <mattyw> night
[19:52] <thumper> morning
[20:01] <natefinch> thumper: morning
[20:02] <thumper> hi natefinch
[20:02] <thumper> reading your experiences with high res desktops :)
[20:02] <natefinch> thumper: haha... the answer is "you're gonna have to wait".... which I think is pretty bad.
[20:02] <thumper> well...
[20:02] <thumper> hangout?
[20:03] <thumper> there are a few things you could try
[20:03] <thumper> natefinch: https://plus.google.com/hangouts/_/76cpi5uan67mdgbaass8rvt83o?hl=en
[22:08] <thumper> gah...
[22:08] <thumper> I need to fix syslog for the local provider
[22:08]  * thumper pokes rsyslog with a stick
[22:10]  * thumper cringes inside
[22:13] <sidnei> thumper: please do!
[22:13] <sidnei> thumper: actually, that's something i wanted to bring up
[22:13] <thumper> :)
[22:14] <sidnei> thumper: because the local provider pokes into lxc rootfs, but with lvm the container root is not under rootfs
[22:14] <sidnei> so that's a blocker for me
[22:15]  * thumper nods
[22:15] <thumper> I've got kvm machines working with my local provider
[22:15] <thumper> but it has no mounting like lxc
[22:15] <thumper> so I need to get the log files out
[22:15] <thumper> however...
[22:15] <thumper> I'm trying to work out how we can have a general juju local rsyslog conf file
[22:16] <thumper> so we don't block the non-sudo bootstrap that may happen later
[22:16] <thumper> since we need sudo to add the rsyslog conf and restart the rsyslog service
[22:16] <thumper> although I guess you could do the horrible bit of encoding sudo into the command running
[22:16] <thumper> not sure how that would work though
[22:16] <thumper> but anyway,
[22:17] <thumper> I suppose I could fix the syslog bit independently
[22:17] <thumper> ugh...
[22:17] <thumper> multiple local environments would be a pain
[22:17] <thumper> I have that now
[22:17] <thumper> I have "local" and "local-kvm"
[22:17] <thumper> both running
[22:17] <thumper> but we'd need to filter syslog messages nicely
[22:17] <thumper> can do this with some syslog tags
[22:18] <thumper> but needing multiple filenames...
[22:18] <thumper> etc
[22:18] <thumper> the problem there is the line: UDPServerRun 514
[22:18] <thumper> so perhaps...
[22:18] <thumper> we'd have to move the rsyslog port into config...
[22:18] <thumper> ick
[22:19] <sidnei> thumper: multiple rsyslog processes running under the user with different ports? inject the port config via cloudinit?
[22:21] <thumper> sure, that isn't the problem
[22:21] <thumper> and I guess, this is only a value that the user needs to change if they want multiple local jujus running
[22:22] <thumper> but it is just the whole "need to put it into config" that makes me go ugh
[22:22] <thumper> but easy enough to add
[22:23] <thumper> I am also very concious that the logging is a single point of failure
[22:24]  * thumper considers briefly making rsyslog put logging messages into a real db that we can spread around...
[22:28]  * thumper sighs


[13:15] <gmay> hi, im very sorry if the issue has already been raised, but it seems that archive.ubuntu.com is super slow and non-responsive (on all 3 IPs), specifically from within AWS eu-north-1
[13:15] <gmay> is this issue known?
[13:58] <Fluor> haven't seen it mentioned here, but i do see the same for security.ubuntu.com
[14:04] <Znevna> hello, if there's no country mirror for country-code. etc it defaults to the main server?
[14:06] <ravage> Znevna: yes
[14:07] <Znevna> boo :p that's why it's affected by the current issues then
[14:07] <Znevna> thanks
[16:19] <leftyfb> unreported issues this morning? W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/focal-updates/InRelease  Cannot initiate the connection to us.archive.ubuntu.com:80 (2001:67c:1562::18). - connect (101: Network is unreachable)
[16:21] <bancroft> I'm getting problems when trying to update with connection failures on <IP_ADDRESS> is there a way to tell which mirror that is?
[16:22] <bancroft> same with <IP_ADDRESS>
[16:22] <leftyfb> also W: Failed to fetch http://us.archive.ubuntu.com/ubuntu/dists/jammy/InRelease  Could not connect to kazooie.canonical.com:80 (<IP_ADDRESS>), connection timed out Cannot initiate the connection to us.archive.ubuntu.com:80 (2001:67c:1562::18). - connect (101: Network is unreachable)
[16:22] <leftyfb> intermittent from multiple releases and locations
[16:28] <axino> we're working on it
[16:32] <leftyfb> axino: could someone update https://status.canonical.com/ in the meantime? (preferably not someone working on the actual issue)
[16:34] <axino> leftyfb: I'll see what I can do
[16:53] <Ari[m]> hi, is it a known issue that archive.ubuntu.com is very slow?
[17:18] <leftyfb> Ari[m]: yes
[18:12] <Ari[m]> danke
[18:38] <Znevna> switching to deb mirror://... will prevent stuff like this, right?
[18:43] <sarnold> afaik ubuntu doesn't have the mirror lists necessary for that to work
[18:44] <Znevna> it seems to work fine
[18:50] <sarnold> weird :) nice
[19:01] <Znevna> https://paste.debian.net/plainh/453f1ad7
[19:01] <Znevna> 3 years, kek


[00:22] <commyPunt> and what about the queen is she resigning too?
[00:27] <OerHeks> Buckingham is shaking https://www.youtube.com/watch?v=lkpUgNyOgIc
[00:28] <OerHeks> but this channel is ubuntu 16.10 support
[09:16] <lordievader> Good morning
[09:21] <bazhang> hi
[09:24] <lordievader> Hey bazhang
[09:30] <bazhang> is the software updater a work in progrss? a huge white space with a tiny orange circle at the center is not the greatest
[09:30] <bazhang> other than that, this runs like a close to finished release
[09:31] <bazhang> though there is some issue with getting andale32.exe corefont
[09:31] <bazhang> could be sourceforge's fault
[11:38] <BluesKaj> hiyas all
[22:48] <TheGhostInTheMac> What's new in yakkety yak?
[23:31] <bazhang> !info snappy
[23:32] <TheGhostInTheMac> They removed snappy core?
[23:33] <bazhang> !info ubuntu-snappy
[23:33] <bazhang> yikes
[23:34] <TheGhostInTheMac> !info yakkety
[23:34] <TheGhostInTheMac> !info vim


[01:06] <nathwill> hey everybody
[01:12] <bkerensa> nathwill: hi
[01:13] <nathwill> bkerensa: ordered my n40l this morning :D
[01:14] <bkerensa> nathwill: cool they have a huge cluster of them here
[01:14] <bkerensa> :D
[01:14]  * bkerensa disappears to the keysigning party then dinner
[01:14] <nathwill> oh yeah? nice
[01:15] <nathwill> alrighty, enjoy
[01:16] <nathwill> man, wifi here at ava is the pits
[05:00] <bkerensa> hi nathwill
[05:00] <nathwill> hey bkerensa
[05:00] <bkerensa> kees: this was the paste from caff http://paste.ubuntu.com/981097/
[05:18] <kees> bkerensa: weird!
[05:19] <bkerensa> kees: Do I need to define a keyserver for caff and if so where?
[05:19] <kees> bkerensa: try adding "keyserver keyserver.ubuntu.com" to your ~/.gnupg/gpg.conf file?
[05:19] <kees> bkerensa: you read my mind :)
[05:20] <kees> bkerensa: ah-ha, try ~/.caffrc instead:
[05:20] <kees> $CONFIG{'keyserver'}='keyserver.ubuntu.com';
[05:22] <bkerensa> >.<
[05:22] <bkerensa> caff hates me
[05:22] <bkerensa> did both and still no go
[05:22] <kees> pastebin your .caffrc ?
[05:23] <kees> next you'll have to set up an mta to actually send the emails. :)
[05:23] <bkerensa> kees: I have one setup
[05:24] <bkerensa> kees: http://paste.ubuntu.com/981125/
[05:24] <kees> bkerensa: okay, good. that's usually what gets hard to fix
[05:25] <bkerensa> Yeah I am using msmtp & msmtp-mta and did test mails so I know thats working :P
[05:25] <kees> bkerensa: and it still says it can't find the key?
[05:25] <bkerensa> kees:  yep
[05:25] <bkerensa> same exact error
[05:26] <kees> hrm... what does "gpg --keyserver keyserver.ubuntu.com --recv-keys E061E1F6" say?
[05:27] <bkerensa> kees: it pulls bilals key and says nothing change etc
[05:27] <bkerensa> :)
[05:32]  * kees holds his face
[05:32] <kees> random... try 0xE061E1F6 ?
[05:32] <kees> I'm struggling to understand what could possibly be stopping caff from working :(
[05:33] <bkerensa> kees: with the normal --recv-keys that works but if I do caff 0xE061E1F6 then no go
[05:38] <nathwill> you must stand on your head and name the day of the discordian calendar while typing the commands
[05:41] <bkerensa> kees: I think Bilal helped me fix
[05:41] <bkerensa> he told me to remove ~/.caff/gnupghome completely and re-run caff with the keyids
[05:41] <nathwill> yaaay... apparently the juju guys realized that their docs are terrible and commissioned someone to fix them
[05:43] <kees> bkerensa: oh-ho! excellent.
[05:46] <bkerensa> kees: yeah but its prompting me for each key >.<
[05:53] <kees> bkerensa: right, you need to examine each fingerprint and decide if it's okay, say y/n then "save" at the end.
[17:50]  * nathwill yawns
[17:50] <nathwill> coffee coffee coffee
[19:15] <bkerensa> lol
[22:59] <bkerensa> nathwill: HP's VP of Cloud Sales is hooking me up with free HP Cloud indefinitely
[23:00] <bkerensa> :D
[23:01] <nathwill> niiice
[23:01] <nathwill> you should let him know that thanks to their agreement to certify ubuntu for proliant, they made a sale
[23:02] <bkerensa> ;p nathwill he isnt server sales
[23:02] <bkerensa> :D
[23:03] <bkerensa> man my mini-fridge is stacked with cold beverages and booze
[23:03] <bkerensa> :D
[23:03] <bkerensa> nathwill: I get to have some 18 year aged rum tonight :D
[23:03] <nathwill> eew
[23:04] <bkerensa> nathwill: its the victory drink :)
[23:05] <nathwill> bkerensa: victory?
[23:05] <bkerensa> nathwill: :P idk Jorge Castro is hooking the Juju charmers team up with some private stock he has been sitting on
[23:05] <bkerensa> :D
[23:05] <nathwill> bkerensa: sweet
[23:49] <kees> bkerensa: hp could> nice!