[01:04] <mup> Issue operator#529 opened: allow stopping service by ServiceInfo <enhancement> <Created by sed-i> <https://github.com/canonical/operator/issues/529>
[01:54] <mup> Issue operator#529 closed: allow stopping service by ServiceInfo <enhancement> <Created by sed-i> <Closed by sed-i> <https://github.com/canonical/operator/issues/529>
[09:40] <mup> Issue operator#530 opened: [RFE] How to manage restart with datastore/database applications in the operator? <Created by phvalguima> <https://github.com/canonical/operator/issues/530>


[00:40] <ScottK> Could someone point me to an explanation of what LPstats is and why I might want to log into it?
[00:42] <wgrant> ScottK: It's an intenal Canonical graphing thing, I believe.
[00:42] <wgrant> You probably don't want to go thee.
[00:42]  * ScottK thinks not.
[00:42] <ScottK> I don't think I even have an Ubuntu SSO to log into that if I wanted to.
[00:43] <wgrant> That's just a Launchpad account.
[00:45] <ScottK> Oh.  OK.
[00:45] <ScottK> Well then I guess I do.
[00:45] <ScottK> The explanation made it sound like something completely different.
[00:58] <cjohnston> there is no way to mark a question duplicate is there?
[01:08] <wgrant> Is there a workaround for bug #496056?
[03:12] <aalex> Why do I get a Upload Warning "No copyright file found."? There is a copyright file in my source code, and I call dh_installdocs copyright in my debian/rules file.
[03:13] <wgrant> aalex: It needs to be in debian/copyright
[03:13] <wgrant> (In the unpacked source package.)
[03:40] <aalex> wgrant: but in a Debian package, it needs to be in debian/../copyright, no?
[03:40] <aalex> wgrant: that would mean my debian/rules should contain dh_installdocs debian/copyright ?
[03:44] <wgrant> aalex: In a Debian or Ubuntu package, it needs to be in debian/copyright. dh_installdocs will install that file by default.
[03:44] <aalex> wgrant: ah ok, thanks
[03:45] <aalex> That's weird, I have installed the public key using "sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 79DF04BB", but I get an error : "GPG error: http://ppa.launchpad.net intrepid Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY CA9840026B51D222"
[03:46] <aalex> It's not the same key, it seems
[03:46] <aalex> See my key: https://launchpad.net/~sat-metalab/+archive/propulseart
[03:47] <wgrant> aalex: I suspect you have another PPA there.
[03:48] <aalex> wgrant: ah! you are right. thanhks a lot
[03:51] <aalex> Is there a simple shell script somewhere to add a PPA to the sources.list, install the public key and update apt? That would facilitate massive installations...
[03:51] <wgrant> add-apt-repository
[03:51] <wgrant> Only in Karmic and above, however.
[03:52] <aalex> :(
[03:52] <aalex> Still using Hardy on many machines at work
[03:52] <aalex> we'll update to the next LTS
[03:53] <aalex> is it the name of its package?
[03:56] <aalex> If I have written "hardy" as a distro in my debian/changelog, should the entry in apt/sources.list be hardy ot intrepid, on an intrepid host?
[06:57] <xxploit> hello, im receiving rejections based on the section im trying to use in the control file. I've tried to use network/networking but receive rejections for it. Could someone inform me how the section field works?
[06:58] <james_w> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
[06:58] <james_w> xxploit: ^ see the list of valid sections there
[06:58] <james_w> "net" may be what you want?
[07:00] <xxploit> ok so would it be valid to use universe/net
[07:01] <james_w> yes
[07:01] <xxploit> thx james_w
[07:17] <xxploit> if i had uploaded a package to my ppa and didnt realize i had not yet signed the code of conduct, which then i signed, and went to reupload the same package and get the notification 'already uploaded to my ppa', will the launchpad system rerun the package realizing i have now signed the CoC or do I somehow to need to delete this uploaded package?
[07:18] <mwhudson> xxploit: i think dput -f will force the upload
[07:18] <xxploit> mwhudson: thx that worked
[07:18] <mwhudson> (this "already uploaded" thing is client-side, i think)
[07:22] <james_w> correct
[07:57] <MTecknology> Anybody know about packaging? in here?
[07:57] <MTecknology> I'm getting this as the first error when I run debuild -S; I can give a pastebin if needed - debian/rules:4: /usr/share/dpatch/dpatch.make: No such file or directory
[09:22] <peloverde> If a package from unstable that I need to backport in my ppa has switched to 3.0 quilt am I pretty much hosed?
[09:23] <RAOF> No; Soyuz should accept 3.0 packages now.
[09:24] <peloverde> I just got an e-mail saying: "audacity_1.3.10-1~ajc1.dsc: format '3.0 (quilt)' is not permitted in karmic."
[09:25] <RAOF> Ah; karmic might not have a new enough dpkg?  I think it should work for Lucid.
[09:29] <peloverde> According to the DebSrc-3.0 wiki dpkg >=  1.14.27 is necessary, karmic runs 1.15.4ubuntu2
[11:10] <geser> anyone around who can see what caused OOPS-1476FTPMASTER1?
[11:11] <spiv> geser: I can, but that OOPS hasn't been synced yet.
[11:11] <spiv> (should be no more than 15 min IIRC0
[11:11] <spiv> )
[11:12] <geser> it's from friday
[11:12] <spiv> Huh.
[11:12] <spiv> That's weird.
[11:12] <spiv> Probably needs a losa to track down, at a guess.
[11:13] <spiv> Possibly just something silly like ftpmaster oopses aren't being copied to the central lp-oops system.
[11:14] <geser> the oops happened after an archive admin tried to sync a package (which failed in the end with this oops)
[12:21] <didrocks> did someone got that in debian/watch pointing to launchpad? "http://launchpad.net/notify-osd/+download failed: 501 Protocol scheme 'https' is not supported (Crypt::SSLeay or IO::Socket::SSL not installed)" in notify-osd for instance
[12:31] <didrocks> ok, found it, need to install libcrypt-ssleay-perl
[13:08] <vadi2> Not sure if it's known, but loggerhead is down again
[13:09] <beuno> LOSAs, ping  ^
[13:16] <mthaddon> was at lunch - checking
[13:27] <vadi2> works now, thank you
[14:55] <glen> hi. what i do wrong if i merge from translation branch to trunk, i always get collisions (conflicts)
[14:57] <glen> i have configured https://translations.launchpad.net/eventum trunk export to lp:~glen666/eventum/po/, and i issue in ~/bzr/eventum/trunk bzr merge ../po
[15:00] <glen> that is the way of doing it, is it?
[15:05] <mars> henninge or danilos, ^ ?
[15:06]  * mars wonders if there is a Translations Guide on help.launchpad.net
[15:07] <henninge> mars: no need to wonder ... ;)
[15:09] <mars> henninge, cool, that is comprehensive.  But is there any advice there for glen?
[15:09] <henninge> mars: ;) I am looking at it.
[15:09] <henninge> glen: ^
[15:12] <henninge> glen: Please explain where the conflict is.
[15:12] <glen> mostly in the .po headers
[15:13] <glen> "PO-Revision-Date: 2009-12-31 14:37+0000\n"
[15:13] <henninge> glen: ah, sorry. Now I understand what you mean!
[15:13] <glen> good :)
[15:14] <glen> perhaps i shouldn't reformat the .po files in one run? i.e first do the bzr merge, then wait for one day that the automatic import has went over, and then reformat .po and submit again?
[15:15] <glen> or the .po header conflict is unavoidable when doing bzr merge ?
[15:15] <henninge> glen: I was about to ask you if you do change your files because that is the only reason.
[15:15] <henninge> glen: no, there is nothing special about them.
[15:15] <glen> yes, i do msgmerge if .pot is updated
[15:16] <glen> so, i should only commit .pot to bzr?
[15:16] <henninge> glen: that should work better, I guess.
[15:17] <henninge> glen: in that case the po and pot will differ until you merge the exported branch.
[15:17] <henninge> but you'd avoid the conflicts.
[15:17] <glen> ok. i'll try to not to commit .po. 1. commit only .pot. 2. bzr merge time to time.
[15:18] <henninge> glen: If you do translations only in Launchpad and not elsewhere, that should work out.
[15:19] <glen> yes, that's the goal
[15:19] <henninge> glen: when you update the pot in Launchpad, that is a msgmerge basically.
[15:21] <henninge> glen: you could set up Launchpad to only import the template (pot) and to export translations to the same branch.
[15:21] <glen> pot should be imported automatically from trunk branch
[15:21] <henninge> glen: what I meant, yes
[15:21] <glen> just in case i use different branch to get a chance to review the translations
[15:22] <glen> and there afaik was some bug at the time that import to same branch back did not work ok :)
[15:22] <glen> ok thanks for the info!
[15:22] <henninge> glen: hm, team-owned branches still does not work, maybe that was the bug.
[15:23] <glen> yeah, something like that
[15:23] <henninge> glen: there is work-around though, see bug 407260
[19:02] <maxb> matsubara: Hi. Somethings odd with the PPA publisher. Half an hour after the build has finished, a couple of builds in ~launchpad/+archive/ppa are still waiting for their binaries to be published.
[19:02] <matsubara> maxb, hi, bigjools is investigating something on private PPA with the same symptom. it might be related
[19:03] <maxb> ok
[19:17] <pmjdebruijn> maxb, matsubara I have the issue too
[19:17] <pmjdebruijn> I uploaded three packages 2 hours ago, which immediately started builing, so they have been unpublished now for 1:30 hours...
[19:17] <matsubara> pmjdebruijn, there's something going on with the publisher. bigjools is on it
[19:18] <pmjdebruijn> matsubara: I read that
[19:18] <pmjdebruijn> just confirming more folks are affected
[19:19] <matsubara> pmjdebruijn, ok. thanks for bringing it up
[19:32] <xnox> Hmm I'm upstream of project Xiphos which was previously known as Gnomesword
[19:33] <xnox> Now we have Xiphos project & teams & branches on launchpad
[19:33] <xnox> Someone external to us registrered Gnomesword project and is inactive on launchpad
[19:33] <xnox> How do I claim ownership of Gnomesword project?
[19:38] <goundy> Hi
[19:38] <goundy> Still nothing about a wiki support in launchpad guys ?
[19:44] <boss> ciao a tutti
[19:45] <maxb> xnox: In the first instance, attempt to contact the other person. If he is unresponsive, request administrative intervention via https://answers.launchpad.net/launchpad/+addquestion
[19:51] <xnox> maxb: ok thank you
[19:53] <goundy> maxb, any guess about my question maybe ? :p
[19:57] <maxb> goundy: I'm not aware of any plans for it soon. (Though I'm not a Canonical person)
[19:57] <goundy> maxb, oh I see, thank you and sorry ;)
[19:59] <thumper> goundy: what was your question?
[20:00] <thumper> mtaylor: hi
[20:00] <goundy> thumper, it was whether there's some fresh plans on integrating any wiki system to launchpad or not ? :)
[20:00] <goundy> I asked about it months ago and I've been told that a workarround has been started already
[20:00] <thumper> goundy: yes there are plans, but it is not actively being worked on right now
[20:01] <goundy> so I'm just wondering what's up since I couldn't get any information about it by searching the web
[20:01] <mtaylor> morning thumper
[20:01] <goundy> thumper, oh got ya, thanks ;)
[20:06] <xnox> goundy: bug #240067
[20:06] <xnox> You should subscribe =)
[20:06] <goundy> Oh yep
[20:07] <goundy> thank you very much
[20:40] <mnft> Hi Barry
[20:40] <barry> mnft: hi
[20:41] <bigjools> PPA publisher is working again
[20:41] <mnft> Ah, sent a joke at python-dev just
[20:42] <mnft> let#s go there, its python-mode stuff
[21:07] <barry> rockstar: ping
[21:07] <rockstar> barry, pong
[21:08] <barry> rockstar: hi!  i'm wanting to sort out python branch imports on lp which are woefully out of date.  are you the right guy to chat with about this?
[21:08] <rockstar> barry, I am _a_ right guy to chat with.
[21:09] <barry> rockstar: you might be the only awake right guy atm :)
[21:09] <rockstar> barry, well, I'm the only one not at LCA...
[21:09] <barry> rockstar: even more win! :)
[21:11] <barry> rockstar: so the problem is that we're currently importing bzr branches from code.python.org, but those are dead.  haven't been updated in tens of weeks.  we should switch them back to importing the svn branches.  not sure exactly the right way to do that
[21:11] <ScottK> barry: Sounds like your original question was right on then.
[21:11] <barry> ScottK: :)
[21:11] <wgrant> Everyone should be awake, but whether they have a connection with <10s lag is another matter...
[21:12] <barry> rockstar: we're currently importing python's trunk, 3.1, 3.0, and 2.6 series.  we should drop 3.0 and pick up py3k (for 3.2)
[21:13] <rockstar> barry, the _easiest_ way to do that is by deleting the imports and creating new ones.
[21:14] <barry> rockstar: do we still have a limitation that we can only import trunk?
[21:14] <rockstar> barry, well, we only have that limitation to get around people misunderstanding things.
[21:14] <rockstar> barry, I think we can make an exception for you.  :)
[21:15] <barry> rockstar: bad idea, but i'll take it anyway :)
[21:15] <geser> any LOSA around to lookup OOPS-1476FTPMASTER1?
[21:15] <rockstar> The constraint about only trunk is because we don't people thinking they can import their 2.0 branch and merge it with trunk (cscvs doesn't like that)
[21:15] <rockstar> barry, that constraint should go away with bzr-svn
[21:16] <barry> rockstar: right.  cool.  thanks for the advice, let me try to do it that way (delete and re-import)
[21:16] <rockstar> geser, it doesn't look like that oops has synced just yet.  Give it 5 minutes.
[21:16] <geser> rockstar: the oops is from friday
[21:16] <rockstar> geser, hm, weird.
[21:24] <geser> rockstar: any other ideas how to find it why it OOPSed?
[21:24] <rockstar> geser, we get emails with the aggregate oopses every day.  It looks like it's a soyuz issue, so I'm sure they will take a look.
[21:26] <geser> it was from a sync done by an archive admin for a package which was attempted to get synced twice, so I tried to find out why
[21:33] <geser> bigjools: Hi, can you find out what caused OOPS-1476FTPMASTER1? it happened when an archive admin tried to sync a package (libxcb) on friday (the package already resisted at least two other sync attempts)
[21:33] <bigjools> geser: yeah I'll look tomorrow, I'm heading to bed now
[21:34] <geser> bigjools: ok
[21:34] <bigjools> the oops hasn't synced anyway
[21:34] <pmjdebruijn> bigjools: I noticed... thankyou!
[21:56] <xxploit> would someone be able to have a quick look at this build log, it's hanging on an image file format and i dont know why. I compiled this on my machine fine but im at a loss as to why it fails on launchpad. http://pastebin.org/78387
[22:05] <geser> xxploit: can you point me to your PPA? I might have an idea but what to confirm it first
[22:06] <xxploit> https://launchpad.net/~xxploit/+archive/linuxfrag/+packages
[22:13] <geser> xxploit: add "librsvg2-common" to Build-Depends (you need /usr/lib/gtk-2.0/2.10.0/loaders/svg_loader.so from that package)
[22:14] <geser> the build should succeed after that (at least it did in my pbuilder)
[22:14] <xxploit> geser: ill try that, i did add the dev package to it before with no effect (librsvg2-dev)
[22:16] <geser> the -dev package depends on the library package but the library package doesn't depend on -common (for what ever reason)
[22:16] <xxploit> geser: ok thx man
[23:54] <Daviey> Is it possible i could have the contents of a LP OOPS?
[23:55] <Daviey> it's one that keeps happening when using openid, my user and my app.


[04:25] <mup> Bug #1611481 changed: IPMI autoconfiguration and startup not working <MAAS:Expired> <https://launchpad.net/bugs/1611481>
[04:25] <mup> Bug #1611980 changed: Upgrade from MAAS 2.0 RC3 to RC4 has pre-removal script error messages <MAAS:Expired> <https://launchpad.net/bugs/1611980>
[04:56] <Prabakaran> Hello Team, Getting timeout issue while commissioning the node in MAAS 1.9, Logs are pasted in here  http://pastebin.ubuntu.com/23301741/ could somebody help me on this?
[10:56] <mup> Bug #1631908 opened: VLAN over balance bondig doesn't work <MAAS:New> <https://launchpad.net/bugs/1631908>
[12:17] <mup> Bug #1631934 opened: MTU values should not be on the bridged interface <MAAS:New> <https://launchpad.net/bugs/1631934>
[13:26] <mup> Bug #1631946 opened: daily images have broken cloud-init <MAAS:Incomplete> <https://launchpad.net/bugs/1631946>
[14:26] <mup> Bug # changed: 1274168, 1279460, 1326485, 1363074, 1364097, 1367843, 1368307, 1370371, 1372794, 1374242, 1376075, 1378865, 1379639, 1381390, 1622971
[14:26] <mup> Bug #1631971 opened: TestDHCPNetworkLayout.test__dhcp_configurations_rendered is dependent on /etc/hosts <ipv6> <tests> <MAAS:Triaged> <https://launchpad.net/bugs/1631971>
[14:56] <mup> Bug # changed: 1272016, 1343317, 1374478, 1393997, 1394277, 1402086, 1437251, 1438780, 1453749, 1465735, 1467694, 1476254, 1476746, 1481281, 1481283, 1483694, 1498854, 1503483, 1503530, 1507670, 1510070, 1513695, 1515975, 1519177, 1526859, 1556431, 1590768
[15:18] <mup> Bug #1628114 changed: [FUJ] SSH input field not indicated for invalid username & the error is incomprehensible <MAAS:Fix Released> <https://launchpad.net/bugs/1628114>
[15:18] <mup> Bug #1629080 changed: [2.1 ipv6] deploying machine needs connectivity to maas (address family) <maas-ipv6> <MAAS:New> <https://launchpad.net/bugs/1629080>
[15:36] <mup> Bug #1621090 changed: rack controller broken after a period of time when deployed on a seperate machine from the region <MAAS:Invalid> <https://launchpad.net/bugs/1621090>
[16:52] <Prabakaran> Hello Team, Getting timeout issue while commissioning the node in MAAS 1.9, Logs are pasted in here  http://pastebin.ubuntu.com/23301741/ could somebody help me on this?
[16:57] <mup> Bug #1514436 changed: Support redirects for maas.ubuntu.com/images <MAAS:Fix Released by andreserl> <https://launchpad.net/bugs/1514436>
[18:54] <baldpope> sup all - am I correct in understanding that maas cannot deploy to a vm running on the free version of esxi?
[18:55] <baldpope> when attempting, I get a generic error - Unable to find a rack controller with access to chassis
[18:56] <baldpope> i get that when running that from cli or webui when attempting to add chassis
[18:57] <baldpope> and if I attempt to add a machine, i get this error in the webui -No rack controllers can access the BMC of node:
[19:00] <roaksoax> baldpope: maas *can* deploy to a VM running on ESXI
[19:01] <roaksoax> baldpope: the issue, based on what you mention, is that the rack controller cannot access the ESXI host IP
[19:01] <baldpope> definitely not a firewall issue this time - no blocked traffic between the two
[19:01] <roaksoax> baldpope: for example, you may not have routing between MAAS and the ESXi host you are trying to control
[19:02] <roaksoax> baldpope: can you ping your ESXi host from the machine MAAS is running ?
[19:02] <baldpope> i can run openssl s_client -connect against the vm server and do showcerts
[19:02] <baldpope> yea, ping works as well
[19:02] <roaksoax> baldpope: is the rack controller connect to MAAS ?
[19:03] <roaksoax> baldpope: as it, it is showing a green check that everything is working ?
[19:03] <baldpope> roaksoax, not sure I know where to look for that
[19:04] <roaksoax> baldpope: in the UI, under the 'Nodes' tab, click on 'Controllers'
[19:04] <baldpope> yea, green
[19:05] <roaksoax> baldpope: strange then
[19:05] <roaksoax> baldpope: so do this: tail -f /var/log/maas/rack.log and then add a chassis, grab the log it shows, and please file a bug :)
[19:05] <roaksoax> baldpope: also, provide output pingin the IP where ESXi host is running and such
[19:10] <baldpope> roaksoax, if I do attempt to add chassis, supplying the hostname, user/pass and prefix filter, I receive the following in the webui
[19:10] <baldpope> Unable to find a rack controller with access to chassis <myhost>
[19:10] <baldpope> but I see no output in rackd.log
[19:15] <roaksoax> baldpope: what if you supply an IP instead of a hostname ?
[19:15] <baldpope> tried both, same
[19:18] <baldpope> I can kinda proceed if I set the power to manual and then manage power via the UI through vmware
[19:18] <baldpope> was able to complete the commission step
[19:22] <MrDanDan> hi guys
[19:22] <MrDanDan> at the end of the commision phase, the nodes should power off, right?
[19:22] <baldpope> yea
[19:23] <roaksoax> baldpope: if you could file a bug with the logs above would be great
[19:23] <MrDanDan> well, mine enter prompt
[19:23] <baldpope> roaksoax, ok, will give you what I got
[19:23] <MrDanDan> and on web UI hangs at commisioning
[19:23] <roaksoax> MrDanDan: have your machines changed from "Commissioning" to "Ready"  ?
[19:23] <MrDanDan> no
[19:23] <roaksoax> MrDanDan: so then they are probably not accessing the commissioning environment
[19:23] <MrDanDan> they stay commisioned
[19:23] <MrDanDan> well, the network is a host-only on vmware
[19:24] <MrDanDan> if that is of any issue
[19:24] <roaksoax> MrDanDan: either a fail in PXE booting or loading the image, to tring to commission and something blocking it
[19:30] <MrDanDan> think it was the fact the vms had ide disks attached
[19:30] <MrDanDan> trying with scsi
[19:57] <MrDanDan> issue was caused by some networking issues with HDCP
[19:57] <MrDanDan> issue was caused by some networking issues with DHCP
[20:15] <baldpope> roaksoax, https://github.com/conjure-up/conjure-up/issues/484
[20:20] <stokachu> baldpope: yea the charm is attempting to locate a network device that isn't accessible
[20:23] <baldpope> not even sure where to begin with that?
[20:31] <baldpope> stokachu, what if deployment just takes a really long time - i ask because after waiting (for about 10+ mins) on 4 of the 5 blades, I see started lxd - main daemon
[20:32] <baldpope> but the conjure-up session was already dead
[20:32] <baldpope> is it possible to continue or?
[20:33] <stokachu> it'll continue without conjure-up running
[20:33] <stokachu> you'll just need to use juju for interfacing with it
[20:35] <baldpope> juju status shows everything either in a waiting or pending state - nothing appears to have completed
[20:39] <stokachu> neutron-gateway is in a failed state because of the network config
[20:39] <stokachu> so that needs to be resolved first
[20:40] <baldpope> yea, i just read your comment on github (assume that's you) - how is the network config broken, at the moment, all pretty flat with a single vlan
[20:43] <baldpope> or is this more a basic issue like expecting eth[0-x] where my ethernet devices are named something else?
[21:37] <smgoller> hey all, I've got maas set up and running. The maas DNS component seems to register all the machines in a .maas domain by default. This works fine. Machines that are provisioned correctly get the maas dns server as their default resolver. however, there is no 'search maas' line in the resolv.conf. Is there a maas setting that manages this?
[21:38] <smgoller> so for example, I have a host called r01-s02. ping 'r01-s02' fails because it can't resolve the hostname because of no 'search maas' line in resolv.conf
[21:45] <smgoller> Does anyone have any pointers to best practices when it comes to IPMI?
[21:47] <smgoller> What I've been doing up to this point is putting IPMI traffic on a different vlan that is connected to the rack controller. I provide DHCP on that network via the rack controller. However, I'm running into a problem where there seems to be duplicate lease entries or something and I keep getting errors about keys already existing in the database for a given ip address.


[05:12] <jibel> cjwatson, I declared trusty but I need a cloud image of trusty to build the base testing environment. I'll ping smoser
[05:17] <jibel> hm, and also update distro-data on all the testing nodes in the lab so they know what is the devel release.
[05:18] <jibel> ev, vila ^ could you check that servers in the lab are up to date?
[05:20] <jibel> vila, you'll need to upgrade the machines used for destkop testing to trusty and probably the ones running raring to saucy for SRUs or split in 2 pools for raring/saucy otherwise SRUs on raring will have to be done manually
[05:30] <jibel> vila, RT65382
[07:00] <vila> jibel: ack, will raise the ticket during the standup and talk with fginther, doanac and plars
[08:09] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131021.1/
[08:09] <ogra_> welcome to trusty !
[08:10] <didrocks> ogra_: \o/
[08:10] <ogra_> and here is the system image :) http://system-image.ubuntu.com/trusty-proposed/mako/
[08:11] <didrocks> ogra_: how will http://people.canonical.com/~ogra/touch-image-stats/ behave btw?
[08:11] <didrocks> if we have a saucy and trusty image rebuild the same day?
[08:11] <ogra_> will be crowded with the next build and fine agaiun with the one after
[08:11] <ogra_> i have to do a special setup for saucy later today
[08:11] <didrocks> the version of the ubuntu chroot are different?
[08:11] <didrocks> ok
[08:11] <ogra_> the paths all changed with the release
[08:11] <ogra_> you mean for building ?
[08:12] <didrocks> no, I think we need to be clear which version is shown
[08:12] <ogra_> yeah it is always the release we build for which we use fro the chroot
[08:12] <didrocks> ok, and we'll have a saucy/ dir?
[08:12] <ogra_> we already do
[08:13] <ogra_> http://system-image.ubuntu.com/
[08:13]  * didrocks sees current/
[08:13] <didrocks> ogra_: I'm speaking of http://people.canonical.com/~ogra/touch-image-stats/
[08:13] <ogra_> we have saucy and trusty channels
[08:13] <ogra_> yeah, that will get a saucy dir
[08:13] <didrocks> great :)
[08:15] <cjwatson> jibel: Huh, why can't you bootstrap it off the saucy image?
[08:15] <jibel> cjwatson, that's what I did
[08:16] <cjwatson> jibel: OK, I still see nothing at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ though
[08:17] <jibel> cjwatson, autopkgtest for trusty is open, jobs that were queued are running. I'll create the views and file a ticket to do the same on the public instance
[08:18] <cjwatson> jibel: OK, I have a feeling proposed-migration lost its records of them so I'm inclined to remove its state and let it all retrigger
[08:19] <cjwatson> jibel: There should be a lot more than just mod-gearman listed in excuses and I don't see any records of it collecting any PASSes
[08:19]  * cjwatson nukes the state dir
[08:19] <jibel> cjwatson, you should see visp as FAIL and glib2.0 as PASS
[08:20] <cjwatson> I do not, but sadly adt-britney loses results sometimes as previously explained
[08:20] <jibel> that's the 2 I used for testing
[08:20] <cjwatson> I don't trust it :(
[08:20] <jibel> cjwatson, :( I'll spend some time on it again this week.
[08:20] <cjwatson> Let's see if it does a better job this time round
[08:21] <cjwatson> jibel: Do you think you could edit https://wiki.ubuntu.com/NewReleaseCycleProcess to explain what we need to do (or notify somebody to do) when setting up new series?
[08:21] <cjwatson> This has become fairly critical infra so we should make sure it's up early
[08:23] <jibel> cjwatson, sure, I'll update it. I added a specific document to the prject auto-package-testing too.
[08:24] <cjwatson> Thanks
[08:24] <cjwatson> Should be a batch of trusty jobs re-running now
[08:24] <cjwatson> I'll keep an eye on p-m to try to ensure it doesn't lose them
[08:29] <jibel> vila, retoaded I'm creating Trusty All and Autopkgtest views on jiufeng, I'll leave others to you.
[08:30] <vila> jibel: please update the ticket you created so we can keep track of what is left to be done (and document the process)
[08:30] <jibel> vila, that's different, I'll file another
[08:34] <didrocks> vila: joining us?
[08:34] <didrocks> ev: ?
[08:34] <vila> didrocks: omw
[08:35] <vila> didrocks: ev is at the cloud sprint
[08:36] <jibel> vila, RT65387
[08:37] <jibel> retoaded, ^
[08:53] <asac> didrocks: vila: so in general i believe nothing should need to be done when we continue staying on devel-proposed ... except creating new jobs to track the OLDRELEASED-proposed
[08:53] <asac> that should be our goal... maybe its already like that and we are just struck by lack of phones
[08:53] <didrocks> asac: agreed with that goal
[08:53] <vila> +1
[08:53] <didrocks> we are far from it, but let's focus on it :)
[08:54] <psivaa> didrocks: asac: ogra_: as per the build this morning. the jobs have not run yet. they are only triggered with changes to http://system-image.ubuntu.com/devel-proposed/mako/index.json
[08:54] <psivaa> which has not changed yet today
[08:54] <asac> psivaa: right. so if we had the channel moved on top ofd trusty-proposed it would have automatically happened
[08:55] <ogra_> psivaa, as i said, thats still saucy
[08:55] <asac> psivaa: however, why wasnt build 101 from devel-proposed picked up
[08:55] <asac> i assume thats because we have all phones down?
[08:55] <ogra_> because the phones are down ?
[08:55] <asac> right. so in theory nothing is wrong :
[08:55] <ogra_> would be my only explanation
[08:56] <ogra_> phablet-flash ubuntu-system --channel trusty-proposed --no-backup -d maguro
[08:56]  * ogra_ twiddles thumbs
[08:57] <ogra_> yay, my first four apps are in the appstore !
[08:57] <psivaa> ogra_: asac: phones are not down there, the jobs have not been triggered yet
[08:57] <asac> psivaa: because 101 is too new?
[08:57] <asac> psivaa: its 2-3 days old: http://system-image.ubuntu.com/devel-proposed/maguro/
[08:57] <ogra_> 101 is from friday night iirc
[08:58] <didrocks> asac: the jenkins job failed as told
[08:58] <psivaa> ohh 101 is from friday? sorry looking at it now
[08:58] <ogra_> the cdimage build ends up in a new dir ...
[08:59] <ogra_> do you use anything from cdimage for the trigger ?
[08:59] <ogra_> http://cdimage.ubuntu.com/ubuntu-touch/saucy/daily-preinstalled/
[08:59] <ogra_> (note the saucy subdir)
[09:01] <asac> afaik they use the index.json to trigger
[09:01] <asac> (from system image channels)
[09:07] <cjwatson> jibel: I wonder if the causes get lost on FAIL or something
[09:08] <cjwatson> jibel: for instance the very most recent run has:
[09:08] <cjwatson> lintian 2.5.19ubuntu1 FAIL lintian 2.5.19ubuntu1
[09:08] <cjwatson> jibel: but I don't see lintian mentioned anywhere in excuses, not even as something triggered by another package
[09:09] <cjwatson> jibel: (unfortunately I didn't catch this in time to stop p-m so you could investigate in place, but perhaps that's a hint)
[09:10] <cjwatson> Though lintian actually first failed in the run starting at 08:37:03
[09:10] <cjwatson> I mean p-m first recorded it as failing then
[09:14] <jibel> cjwatson, yes, I noticed that on saucy but couldn't find the cause. I also noticed results on excuses changing from PASS to FAIL without obvious reason. but I didn't find how to recreate the case locally.
[09:15] <jibel> cjwatson, I updated https://wiki.ubuntu.com/NewReleaseCycleProcess and added a link to the detailed documentation.
[09:15] <cjwatson> Thanks
[09:45] <cjwatson> ogra_: Any luck with image 1?
[09:45] <psivaa> asac: ogra_: the reason for the smoke tests failing to run 101 is due to regressions in the way we now flash the devices.
[09:45] <psivaa> there was a merge to not use utah for this and this is causing the issue
[09:45] <ogra_> cjwatson, havent checked phonecalls yet ... and popey needs to test on mako
[09:45] <ogra_> cjwatson, installs and runs though :)
[09:46] <ogra_> popey, mind testing the trusty-proposed channel on your mako ?
[09:46] <psivaa> doanac: ^ would you be able to take a look at this the issue is only in install-and-boot
[09:46] <popey> ogra_: ooh, there's a new image?
[09:47] <ogra_> popey, two :) onte trusty and one saucy
[09:47] <popey> which one do you want testing?
[09:47] <cjwatson> please do the trusty one first as this is blocking opening
[09:47] <ogra_> popey, trusty-proposed please
[09:47] <popey> kk
[09:48] <ogra_> just a quick smoketest should do
[09:48] <popey> the delay wont be my testing, it will be my current 3g connection
[09:48] <popey> phablet-flash: error: argument : invalid choice: 'trusty-proposed' (choose from 'cdimage-touch', 'cdimage-legacy', 'ubuntu-system', 'community')
[09:48] <popey> oh, typo
[09:49] <popey>  2% [>                                      ] 8,183,808    368KB/s  eta 8m 13s
[09:49] <popey> not bad on the M6
[09:51] <ogra_> cjwatson, popey, asac, didrocks, trusty is good on maguro
[09:52] <asac> ogra_: can you run unity8 ap?
[09:52] <asac> :)
[09:52] <didrocks> ogra_: sweet!
[09:52] <asac> lol
[09:52] <asac> ogra_: guess thats still not good on maguro
[09:52] <asac> oh we have 101 http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/
[09:53] <asac> install-and-boot isnt happy though
[09:53] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/101:20131018:20131015/4775/
[09:53]  * asac assumes psivaa and vila are on that
[09:53] <vila> asac: I'm on cu2d for trusty withe didrocks
[09:54] <vila> psivaa: ^ you're on it ?
[09:55] <psivaa> asac: as i posted above, there was a regression in the way we provision the devices. i will have to revert the changes that doanac made in order to make the jobs proceed
[09:55]  * ogra_ notes that the maguro is really to slow for zombie apocalypse
[09:57] <popey> i handed my 100 phone out at a conference over the weekend. took less than 5 mins for someone to crash it
[09:58] <ogra_> yeah, we need to do more long term dogfooding
[09:58] <ogra_> i wrote 11 webapps on the weekend ...
[09:58] <ogra_> running like 5 of them at the same time makes everything go cracy
[09:59] <ogra_> the backgrounded apps never save their state
[09:59] <ogra_> and at times unity seems to get all confused and puts the wrong labels onto the wrong thumbnals etc
[10:00] <ogra_> i had two crashes over the weekend where unity just restarted
[10:02] <psivaa> asac: vila: running the jobs now for 101 saucy.. i'll let you  know the outcome
[10:20] <popey> ogra_: trusty 1 looks good here on mako
[10:32] <ogra_> great
[10:32] <ogra_> cjwatson, go for it then
[10:38] <asac> ogra_: successfully ran camera_app on #1
[10:38] <asac> doing webbrowser_app now as well
[10:38] <asac> didrocks: ^^
[10:38] <asac> (on maguro)
[10:38] <didrocks> great!
[10:38] <asac> unity is unfortunately unhappy still, right?
[10:38] <didrocks> asac: we'll need an iso though to plug trusty tests on desktpo
[10:38] <asac> at least on maguro i would think so
[10:38] <didrocks> desktop*
[10:39] <asac> didrocks: did the last day regression fix make it in for unity AP?
[10:39] <didrocks> cjwatson: I think that will take a while? (trying to find a backup solution)
[10:39] <didrocks> asac: they did
[10:39] <didrocks> ah
[10:39] <didrocks> unity8
[10:39] <didrocks> not 7
[10:39] <didrocks> no, it's not in
[10:39] <didrocks> as we didn't do any SRU-related work
[10:39] <asac> right. thinking about trusty. assume would come in once we start landing stuff, right?
[10:40] <didrocks> asac: there are 3 things to do/ensure:
[10:40] <didrocks> - daily-build ppa can build trusty
[10:40] <didrocks> - config changed by Mirv
[10:40] <didrocks> - otto being able to run tests on trusty (or I need to find a backup solution) -> meaning, an iso available
[10:41] <vila> - views updated ob jnekins (may be minor may be scripted already)
[10:41] <vila> *on jenkins
[10:41] <cjwatson> didrocks: we can probably do you a desktop build
[10:41] <asac> didrocks: so we depend on a desktop iso? or server?
[10:41] <didrocks> cjwatson: oh, that would be excellent :)
[10:41] <didrocks> asac: desktop
[10:42] <didrocks> cjwatson: and ppas can build trusty already?
[10:42] <cjwatson> didrocks: running
[10:42] <didrocks> thanks cjwatson :)
[10:42] <cjwatson> didrocks: er I'd have to check
[10:42] <didrocks> ok
[10:42] <cjwatson> didrocks: you could try it :)
[10:42] <didrocks> yeah, let's mess with it :)
[10:42] <didrocks> will keep you posted
[10:42]  * cjwatson goes to open trusty
[10:43] <cjohnston> asac: are the automated tests already running or are your results from manual testing?
[10:43] <cjwatson> (getting coffee first so this is your last opportunity to object)
[10:44] <asac> cjohnston: mine are from manual, because the automatic ones seem to not run
[10:44] <cjohnston> asac: they don't look to be setup.. let me see if I can figure that out
[10:44] <asac> cjohnston: check with psivaa and vila and didrocks if there was something started to fix this already
[10:44] <didrocks> cjohnston: enjoy :)
[10:44] <asac> cjohnston: so from what i uinderstand touch_mir should be pulling devel-proposed channel
[10:45] <asac> cjohnston: that channel wasnt moved over, so we need to wait till stgraber gets up, then our touch_mir jobs should pick the right thing up
[10:45] <didrocks> [PPA ubuntu-unity-daily-build] [ubuntu/trusty] bamf 0.5.1+13.10.20131011-0ubuntu1trusty1 (Accepted) -> sounds good :)
[10:45] <cjohnston> ok
[10:45] <asac> cjohnston: build the build number will go back to 1, so maybe check what happens on dashboard then
[10:45] <cjwatson> didrocks: good
[10:46] <didrocks> cjwatson: enjoy your coffee :)
[10:47] <psivaa> cjohnston: fyi, saucy tests on touch devices are running but we have not set anything up for trusty yet
[10:48] <cjohnston> psivaa: cool.. looks like there are still MPs that need to land for trusty tests to work
[10:48] <psivaa> cjohnston: yea they are still in the review stage
[10:52] <ogra_> asac, Saviq , unity8 still fails for me, http://paste.ubuntu.com/6276025/ is what i se printed in the unity8 log if the tests try to start
[10:52] <Saviq> ogra_, stale socket
[10:52] <ogra_> yeah
[10:52] <ogra_> i thought we had fixed that
[10:52] <Saviq> ogra_, no, we amended it
[10:52] <ogra_> the test properly shuts down the shell
[10:52] <Saviq> ogra_, but if unity8 crashes - mir never removes the socket
[10:53] <Saviq> ogra_, it should only ever happen on unity8 crash now
[10:53] <ogra_> well, thats after a proper shutdown i think
[10:53]  * ogra_ reboots again to watch if there is a crash happening
[10:53] <Saviq> ogra_, hmm, can you rm /run/user/32011/mir_socket and clear /var/crash - and see if indeed you get the stale socket without unity8 crashing?
[10:53] <Saviq> or that
[10:54] <Saviq> ogra_, we should probably clear the socket in pre-start unity8
[10:54] <ogra_> root@ubuntu-phablet:/# ls /var/crash/
[10:54] <ogra_> _usr_bin_unity8.32011.crash
[10:54] <ogra_> wow
[10:54] <ogra_> it isnt even on the screen
[10:55] <ogra_> and i cleared the dir when shutting down (without unity running at all)
[10:55]  * ogra_ tries that again
[10:55] <Saviq> ogra_, how big is the crash file?
[10:55] <Saviq> ogra_, bug #1240866 probably
[10:55] <ogra_> root@ubuntu-phablet:/# ls -l /var/crash/
[10:55] <ogra_> total 384
[10:55] <ogra_> ---------- 1 phablet whoopsie 390128 Oct 21 12:53 _usr_bin_unity8.32011.crash
[10:56] <asac> cjohnston: do you know why we see those bogus entries on http://reports.qa.ubuntu.com/smokeng/saucy/
[10:56] <asac> cjohnston: e.g. the ones with just one date rather than normal veresion?
[10:56] <cjohnston> means the install failed
[10:57] <ogra_> no crash this time
[10:57] <ogra_> Saviq, so firing up the test definitely creates the crash file
[10:58] <ogra_> seemingly on shutdown of the shell
[10:58] <psivaa> cjohnston: asac: i dash_ignore 'd them but since they were from the weekend we need to wait till 1330 UTC to get them removed
[10:58] <Saviq> ogra_, yeah, we still have a crash on shutdown indeed
[10:58] <asac> cjohnston: looks buggy to me at least :)
[10:58] <Saviq> ogra_, or do we... thought we had that fixed
[10:58] <asac> psivaa: right. still think the visualization could be at least improved
[10:58] <Saviq> ogra_, can you give me your steps?
[10:58] <cjohnston> asac: we don't really have a way to guess what the build number should be if we can't get it
[10:59] <asac> cjohnston: so those cases we cant download?
[10:59] <asac> cjohnston: cant get the index.json?
[11:00] <cjohnston> AFAIK that part was fine
[11:00] <ogra_> Saviq, i flash. makes the image writable and run "phablet-test-run -n -p unity8-autopilot unity8" ... once the old shell stops i see the crash file apprear (before it prints that it starts the tests in the other terminal)
[11:00] <asac> cjohnston: my understanding is that we are looking at http://system-image.ubuntu.com/trusty-proposed/mako/index.json
[11:00] <asac> cjohnston: that one has the version info included
[11:00] <cjohnston> I thought we were getting the info from the device
[11:00] <Saviq> ogra_, /me does
[11:00] <asac> cjohnston: right. maybe we should use that info as well and then even compare those two infos :)
[11:01] <asac> as another meta test
[11:01] <Saviq> ogra_, did you keep the display lit?
[11:01] <cjohnston> ack
[11:01] <ogra_> Saviq, i tried to ...
[11:01] <ogra_> Saviq, it turns off when the shell goes away
[11:02] <Saviq> ogra_, you can always go "powerd-cli display on bright"
[11:03] <Saviq> ogra_, aah
[11:03] <ogra_> i cant trigger a crash when just stopping and starting unity8
[11:03] <ogra_> must be the start of the test that causes it
[11:04] <Saviq> ogra_, bug #1240801
[11:04] <Saviq> ogra_, that's fixed in unity8 trunk (and only affects testing)
[11:04] <cjwatson> ok, trusty is open
[11:04] <cjwatson> will be starting autosyncs shortly
[11:04] <ogra_> aha
[11:04] <cjwatson> and removing the proposed block shortly as well
[11:04] <Saviq> cjwatson, \o/
[11:04] <Saviq> ogra_, export XDG_DATA_DIRS before "autopilot run unity8"
[11:04] <Saviq> ogra_, and it will be fine
[11:04] <ogra_> Saviq, oh
[11:05] <Saviq> ogra_, XDG_DATA_DIRS=/usr/share autopilot run unity8
[11:06] <ogra_> phablet@ubuntu-phablet:~$ initctl stop unity8
[11:06] <ogra_> unity8 stop/waiting
[11:06] <ogra_> phablet@ubuntu-phablet:~$ XDG_DATA_DIRS=/usr/share autopilot run unity8
[11:06] <ogra_> Loading tests from: /usr/lib/python2.7/dist-packages
[11:06] <ogra_> Tests running...
[11:06] <ogra_> and it doesnt lie :D
[11:07]  * ogra_ sees the unity tests on screen
[11:13] <cjwatson> autosyncs starting
[11:15] <cjohnston> asac, psivaa they have been removed from the dash
[11:15] <didrocks> cjwatson: excellent!
[11:16] <ogra_> asac, Saviq, http://paste.ubuntu.com/6276146/
[11:16] <ogra_> so unity8 looks pretty good
[11:16] <Saviq> ogra_, yeah, just one crash on startup - the getenv one
[11:17] <Saviq> ogra_, that test will run if you start it again
[11:17] <ogra_> k
[11:17] <asac> ogra_: webbrowser is OK too (37 tests run)
[11:17] <asac> zero failure :)
[11:18] <asac> ogra_: so where is the udev fix :)?
[11:18] <asac> i want systemsettle to stop complaining
[11:18]  * ogra_ re-runs to prove the failure goes away
[11:18] <ogra_> asac, its in 101
[11:18] <asac> ogra_: so should be in 1 too?
[11:18]  * asac checks top
[11:18] <Saviq> Ubuntu Touch 101 ;D
[11:18] <ogra_> was in trusty-proposed, i dont think it was in trusty when we built the image
[11:18] <asac> ogra_: hmm. 97.8 idle only
[11:19] <asac> pulse is going wildish
[11:19] <ogra_> asac, i think it was held
[11:19] <asac> oh wait :)
[11:19] <asac> lol
[11:19] <asac> that was my x220
[11:19] <ogra_> heh
[11:19] <asac> ogra_: we still see systemsettle issues on 101 though: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/gallery-app-autopilot/
[11:20] <asac> ogra_: all are still orange because of that: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/
[11:20] <asac> pretty busy
[11:20] <asac> here is the before run of gallery http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/gallery-app-autopilot/493965/
[11:20] <asac> doesnt hit 97% average
[11:21] <asac> ogra_: sure its in 101? build 1 feels quiet
[11:21] <ogra_> asac, right, but no udevd issue it seems
[11:21] <ogra_> looks like top is the biggest consumer in the logs
[11:22] <asac> ogra_: ueventd is still there though
[11:22] <ogra_> yes, thats fine
[11:22] <asac> ogra_: the first sample always has top
[11:23] <ogra_> ueventd  != udevd
[11:23] <asac> ogra_: but why would top be so slow all of sudden?
[11:23] <asac> we never had this problem before
[11:23] <ogra_> and it is always under 0.5% as i see it
[11:24] <ogra_> dunno, but top consumes >3%
[11:24] <asac> right. thats new
[11:24] <ogra_> that keeps us below 97% idle
[11:24] <ogra_> no idea why
[11:24] <asac> cjohnston: did you guys ever touch the systemsettle code :)?
[11:24]  * asac tries to find it
[11:24] <asac> cjohnston: or the parameters?
[11:25]  * ogra_ doubts that
[11:25] <asac> ogra_: well, we see settle consistently failing after boot
[11:25] <asac> ogra_: either we have loads more processes
[11:25] <asac> or something slows it down
[11:25] <ogra_> do we have crash files ?
[11:26] <ogra_> hmm, no
[11:26] <ogra_> doesnt look liek we do
[11:26] <asac> zero crashes so far on 101
[11:26] <ogra_> right
[11:26] <ogra_> heh, spoke to soon :P
[11:26] <ogra_> mako has one
[11:27] <ogra_> maliit in andressbook-app
[11:28] <ogra_> asac, aha https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-maguro-smoke-friends-app-autopilot/22/artifact/clientlogs/top_before.log/*view*/
[11:28] <asac> ogra_: i think the most interesting part is likely starting from TOP DUMP (after settle run: 1)
[11:28] <asac> or even https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-maguro-smoke-friends-app-autopilot/22/artifact/clientlogs/top_before.log/*view*/
[11:28] <asac> err
[11:28] <asac> TOP DUMP (after settle run: 3)
[11:28] <ogra_> heh
[11:29] <asac> thats a few minutes into the boot
[11:29] <asac> so everything should be started by then
[11:29] <asac> TOP DUMP (after settle run: 9)
[11:29] <asac> thats the last run. whatever makes it fail there is the problem
[11:29] <ogra_> phablet@ubuntu-phablet:~$ XDG_DATA_DIRS=/usr/share autopilot run unity8
[11:29] <ogra_> Loading tests from: /usr/lib/python2.7/dist-packages
[11:29] <ogra_> Tests running...
[11:29] <ogra_> Ran 22 tests in 549.162s
[11:29] <ogra_> OK
[11:29] <asac> unity8 ueventd, adbd
[11:30] <ogra_> yay
[11:30] <asac> nice one
[11:30] <ogra_> only on second run though
[11:30] <asac> so our current settle limit was 97.5
[11:30] <asac> we now hit like 69.5 reliably
[11:30] <asac> on maguro
[11:30] <asac> err
[11:30] <asac> 96.5
[11:30] <asac> so we only need to explain a 1% boost
[11:31] <asac> that could easily be unity8 because of MIR, but i somewhat feel something else is also fishy
[11:31] <asac> why is adbd for instance there with 1%?
[11:32] <asac> ogra_: seems on SF its also pretty tight
[11:32] <asac> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/100:20131017:20131015/4768/calendar-app-autopilot/492569/
[11:32] <asac> it like succeeeding during the last attempt
[11:32] <asac> but that is before the udev fix
[11:33] <ogra_> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/100:20131017:20131015/4768/calendar-app-autopilot/
[11:33] <ogra_> but it succeeded
[11:34] <asac> ogra_: yeah, but still very tight/late
[11:34] <ogra_> and SF doesnt trigger udevd to go wiltd
[11:34] <ogra_> thats a Mir issue
[11:34] <asac> so anything changing can make us go red
[11:34]  * asac doesnt like that we only getting up to 97.5 anyway
[11:35] <asac> ogra_: maybe it is because we use powerd-cli screen-on ?
[11:35] <ogra_> well, top always eats some
[11:35] <ogra_> why would have influence the load ?
[11:35] <ogra_> s/have/that/
[11:36] <asac> ogra_: thats it. i turned the screen on and i suddenly see unity8 coming to the forefront of top
[11:36] <ogra_> sure
[11:36] <asac> ogra_: and ueventd
[11:36] <ogra_> has always been like that
[11:36] <asac> so thats the reason. if folks turn off the screen before settle,then we are green :)
[11:37] <ogra_> ueventd might be other fallout of the Mir bug
[11:37] <asac> cjohnston: doanac: plars: ^^
[11:37] <ogra_> tvos hass a fix for that afaik
[11:37] <ogra_> *tvoss
[11:37] <asac> ogra_: so the fact that unity8 starts consuming cycles when you turn screen on is considered a bug?
[11:37] <ogra_> no
[11:37] <ogra_> it has to refresh
[11:37] <ogra_> the bug is that the driver under Mir spams uevents
[11:38] <ogra_> that keeps traffic up in varioud places
[11:38] <asac> i right
[11:38] <asac> ack
[11:38] <ogra_> not all of them can be seen
[11:38] <ogra_> udevd was only one fallout
[11:38] <asac> ogra_: so you say there is still some noice now in ueventd that we fixed udev?
[11:38] <asac> ogra_: can we maybe also filter there smartly?
[11:38] <asac> noise
[11:38] <ogra_> thimas has a possible fix that only makes the uevent spam apper when there is actual interaction
[11:38] <ogra_> *thomas
[11:39] <ogra_> instead of having a constant stream of 60 events per sec
[11:39] <asac> ok, but we can't minimize the impact on the ueventd process during a spam/attac,k on top of that?
[11:39] <asac> rigt
[11:39] <asac> i understand i think.
[11:39] <ogra_> we need to kill the spam like SF does
[11:39] <asac> oki
[11:39] <ogra_> then it should work as fast as SF and your processes shouldnt misbeahve anymore
[11:39] <asac> well, that would mean that its a bug and we might want to continue keeping it visible on dashboard
[11:39] <asac> until we have fixed maguro
[11:40] <ogra_> i uploaded some HTML5 games to the shop over the weekend, zombie attach is a highly demanding game that makes a good performan.ce test
[11:40] <ogra_> *zombie apocalypse
[11:41]  * asac installs it
[11:41]  * asac always has to setup ubuntu one account
[11:41] <asac> odd
[11:42] <ogra_> once for shop access
[11:42]  * ogra_ never has to do it more than once
[11:43] <ogra_> that game runs on the edge on mako ... (runs super smooth on android btw) ... on mako it is just close to be unusable
[11:43] <ogra_> on maguro i get all actions with a long delay
[11:44] <ogra_> i.e. non usable at all
[11:44] <asac> ogra_: does it work well on android maguro?
[11:45] <asac> i tried it now on maguro and yes its not usable )
[11:45] <ogra_> no idea, it works well on my S4
[11:45] <asac> :P
[11:45] <ogra_> i have never run android on a maguro :P
[11:45] <ogra_> it definitely shows we need to improve the browser performance for such stuff
[11:46] <ogra_> having something like this game run smooth by trusty release might be a nice goal :)
[11:46] <ogra_> (on maguro)
[12:37] <cjohnston> asac: I honestly have no idea about any changes to systemsettle
[12:41] <asac> cjohnston: all good. i think we found it
[12:41] <asac> plars: doanac: cjohnston: we need to not enable the screen while running it
[12:41] <asac> (systemsettle)
[12:41] <asac> plars: doanac: cjohnston: or rather use powerd-cli to have it off i guess
[12:41] <asac> systemsettle test itself should do the right thing there
[12:45] <plars> asac: iirc, before we added the powerd-cli display on, more things were failing
[12:46] <plars> asac: so just turning the display on is causing unity8 to eat cpu?
[12:48] <sergiusens> @ci share-app hasn't been part of the product for a while, it's tests should probably be disabled since it's installing things that can skew the test results for other components by installing abandoned/obsolete deps
[12:54] <asac> plars: its only about systemsettle
[12:54] <cjohnston> sergiusens: in the daily image testing?
[12:54] <asac> plars: that testcase itself should ensure that screen is turned off
[12:54] <asac> plars: every other testcase should senusre that screen is turned on and unlocked
[12:54] <sergiusens> cjohnston, yup
[12:55] <asac> e.g. its a testcase thing and systemsettle shoudl ensure we do the right thing for it
[12:55] <cjohnston> plars: ^
[12:55] <plars> asac: the problem is, doanac found that if we don't turn the display on at the beginning, before system settle comes on, then it might not come on and tests had issues later
[12:55] <asac> plars: lets talk to doanac
[12:55] <asac> plars: turn it off
[12:55] <asac> turn it on after
[12:55] <asac> i dont think that should cause harm, but lets see
[12:55] <plars> sergiusens, cjohnston: ack, I'll disable share-app. It's not coming back later or anything is it?
[12:56] <sergiusens> plars, it's an ubuntu ui toolkit component since beginning of september
[12:56] <plars> sergiusens: that's what I thought, ok I'll remove it completely then
[13:00] <fginther> morning
[13:26] <Mirv> didrocks: ok, now ~everything is split to /saucy branches with updated Bzr-Vcs url:s for those, see doc
[13:26] <Mirv> I'll prepare a quick cu2d change proposal, but I'll leave it to you (for today) otherwise
[13:26] <didrocks> Mirv: great! the cu2d config is ready as well?
[13:26] <didrocks> Mirv: maybe you'll need to get in sync with fginther
[13:27] <fginther> didrocks, Mirv morning
[13:27] <didrocks> hey fginther ;)
[13:30] <Mirv> morning fginther
[13:31] <Mirv> fginther: didrocks: https://code.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/saucy_transition_misc_unity/+merge/191989 - that's a start at least, you can also modify the commit since it's under common LP username
[13:32] <Mirv> it covers those projects I created a /saucy for today, but not sil2100's ones that are still missing (I haven't gone through those)
[13:32] <didrocks> Mirv: ok great, maybe fginther, as having worked with sil2100 the other day has the othe part
[13:33] <cjwatson> didrocks: there are desktop images in pending, btw
[13:36] <didrocks> cjwatson: excellent, thanks for the head's up. I'll start trying to fetch it as soon as I can
[13:36] <cjwatson> didrocks: they're stuck in pending because the Windows executables on there are broken, but I expect you don't care
[13:36] <cjwatson> (well, s/broken/missing/)
[13:37] <cjwatson> didrocks: it's possible they may not work in other ways, though, as we haven't updated the installer for saucy yet
[13:37] <didrocks> cjwatson: I hope/try to fetch it from otto, at least, we have a base :)
[13:38] <cjwatson> otto?
[13:40] <asac> doanac: didrocks: don't wait for me. let's chat a few minutes after the meeting, i will reset the whole thing now and maybe come in after
[13:40] <didrocks> lp:otto, the tool we use to do desktop tests
[13:40] <didrocks> saucy sounds like quality for asac :p
[13:41] <ogra_> runs fine on my phone
[13:41] <ogra_> :P
[13:41] <didrocks> ahah
[13:44] <asac> doanac: i think NM/wpa sometimes act up and dont connect to the strongest AP here... not sure if its a threshold thing or not
[13:44] <asac> didrocks: ^^
[13:44] <asac> (sorry, typo)
[13:44] <jibel> retoaded, could you add trusty to the default view too on https://jenkins.qa.ubuntu.com/ ?
[13:45] <retoaded> jibel, sure
[13:45] <didrocks> asac: oh, that would be something for cyphermox I guess
[13:46] <retoaded> jibel, done
[13:46] <jibel> retoaded, and you can remove oneiric
[13:46] <retoaded> jibel, ack
[13:47] <jibel> retoaded, thanks
[13:47] <retoaded> jibel, hmmmm, that seems to have broken the view
[13:48] <jibel> retoaded, java.lang.StackOverflowError awesome.
[13:48] <jibel> :(
[13:48] <retoaded> jibel, and I don't even have the option to delete it so I can recreate it
[13:52] <retoaded> hmmm, and I can re-create Oneiric since jenkins thinks it already exists (but doesn't show)
[13:53] <jibel> from the error I'd say it tries to access a view that it thinks exists but actually doesn't and falls in a infinite loop
[13:54] <retoaded> jibel, ack. got it straightened out.
[13:55] <jibel> retoaded, good, thanks.
[13:55] <retoaded> jibel, changed the default view to something else, went back into Releases, removed Oneiric (again) and it worked this time. Reset default view back to Releases.
[13:55] <jibel> add a note for next time you have to remove a release from that list
[13:59] <cyphermox> asac: do you mean on initial connection?
[14:03] <didrocks> retoaded: http://<IP_ADDRESS>/iso/trusty/ is grabbing pending apparently, right?
[14:04] <retoaded> didrocks, yes
[14:04] <didrocks> excellent, thanks for confirming!
[14:05] <asac> cyphermox: no its after a few days and suspend/resumes
[14:05] <asac> cyphermox: i have a repeater very close and my main router far away, but you can still see my main router here
[14:06] <asac> cyphermox: seems that after a few of those suspend/resumes, NM or wpa prefers the "main router" and my inet etc. goes flaki
[14:06] <cyphermox> we,, it's possible you can see it, but have you compared the BSSIDs to make sure which one was conected to?
[14:06] <cyphermox> ok
[14:06] <asac> yeah
[14:06] <asac> i see that i am connected against the wrong one
[14:06] <cyphermox> there's a patch I'll upload soon that changes the threshold, perhaps that will help
[14:06] <asac> cyphermox: so i tried using NM UI to force the BSSID close by, but seems that doesnt prevent NM to still roa mto the other
[14:07] <asac> feels very weird how you as a user can "force" (gues its not a real force" for BSSID
[14:07] <asac> cyphermox: oh there is a threshold? let me know when its there, i am happy to test
[14:07] <asac> hehe
[14:07] <cyphermox> no, it's meant to be that way -- if you specify it, it will not roam and use the BSSID you provided
[14:07] <cyphermox> in some cases it's quite useful
[14:08] <alan_g> fginther: remember setting up CI for the mir/development-branch? I just noticed that it doesn't build for armhf like lp:mir does. Was that intentional?
[14:10] <fginther> alan_g, no that was not intentional, If I remember right, the armhf build was added to lp:mir after the development branch job was setup. We just didn't remember to modify both branch configurations.
[14:10] <fginther> alan_g, that should be fixed now
[14:11] <alan_g> fginther: thanks. (I thought armhf had been around a lot longer. But fixed is fixed)
[14:14] <cjwatson> armhf in general predates mir but PPAs don't build for armhf by default and I think the mir PPA initially didn't
[14:15]  * alan_g meant the mir armhf build
[14:20] <didrocks> http://<IP_ADDRESS>:8080/job/autopilot-trusty-setup_otto/label=qa-intel-4000/1/console
[14:20] <didrocks> vila: fginther ^
[14:20] <didrocks> 2013-10-21 14:19:27,634 ERROR An error during creation occurred, trying to cleanup the container: The container didn't stop successfully
[14:44] <fginther> kgunn, are you familiar with the mir branch changes that duflu is proposing? I have some questions about it
[14:46] <kgunn> fginther: i read thru it about an hour ago....shoot
[14:46]  * kgunn grabbing coffee & a fleece back in a moment
[14:47] <fginther> kgunn, will any future changes be directly proposed to lp:mir, or will all the changes go into the development branch and that is merged into lp:mir when it's ready?
[14:52] <kgunn> fginther: and i understand it..i think the idea is to stage everything on the development-branch...and then using a pull
[14:52] <kgunn> fginther: rather than a merge to get the history
[14:54] <fginther> kgunn, right. I'm trying to scope the amount of work needed here as a pull is not something that our tools currently support.
[14:55] <kgunn> fginther: its kind of interesting....i think if we every go to a truly feature development type dev environ
[14:55] <fginther> kgunn, It would help if I knew if we need to support other branches merging into lp:mir, or if we can lock this down to just the development branch
[14:55] <kgunn> that's actually what would be needed
[14:56] <kgunn> fginther: i'm totally ok with locking it down
[14:56] <kgunn> fginther: mmmm....let me backpeddal one mire
[14:56] <kgunn> minute rather
[14:57] <fginther> kgunn, I'm also not familar with all that pull is doing, so need to do a little research on my own
[14:57] <kgunn> fginther: i could foresee the potential need for speed, that someone might want to push to both
[14:57] <kgunn> fginther: altho...that would be a merge
[14:57] <fginther> kgunn, so other groups have proposed the trunk + feature branch development environment, but this is the first time pull has come up rather then merge
[14:58] <kgunn> fginther: right....i think this is all about the history of the branch being merged....
[14:59] <kgunn> fginther: and i don't understand it myself....but i think this is the problem with not having downstream able to pull from something other than "trunk"
[15:04] <asac> didrocks: doanac: cjohnston: so what was the outcome of bringing up trusty on dashboard etc.?
[15:04] <doanac> asac: we are trying to get them going today.
[15:05] <doanac> i have 3 MPs out that the team is reviewing
[15:05] <asac> doanac: ok cool. sounds goodie. would love to declare "happy development" to the UE team after seeing results
[15:38] <didrocks> asac: ogra_: plars: robru: psivaa: cyphermox: I guess there is no need for this afternoon landing team syncing up. Let's do it tomorrow morning, we're almost there!
[15:39] <ogra_> didrocks, ++
[15:40] <plars> doanac: ack
[15:47] <psivaa> didrocks: ack
[16:02] <asac> didrocks: oki ... was just wondering while i was on there :)
[16:03] <didrocks> asac: ahah, sorry ;)
[16:09] <lool> Hey folks
[16:09] <lool> I see there's a new trusty-proposed channel
[16:09] <lool> with an image
[16:09] <lool> but it's not in devel-proposed
[16:09] <lool> is that intentional?
[16:29] <lool> after chatting with stgraber, he intends to update both devel-proposed and devel once the first trusty-proposed image is promoted to trusty
[16:31] <ogra_> lool, yes, thats what we discussed a while ago
[16:31] <didrocks> ok, time for my daily run before it's night
[16:31]  * didrocks waves good evening
[16:32] <ogra_> ciao
[17:08] <plars> doanac: I just witnessed something that could cause us trouble
[17:08] <doanac> plars: i'm killing the jobs now. its too much to follow
[17:09] <doanac> and i found a small bug in free the devices
[17:09] <plars> ogra_: I was running the latest devel-proposed which I just installed locall, and connected to it with adb. Then mtp connected and as soon as the window popped up for it, adb disconnected.
[17:09] <plars> doanac: ^
[17:10] <doanac> ah - that's bad. I think josepht has seen something like that also
[17:10] <plars> ogra_: I was able to reconnect just fine, but losing that connection at some points in the install/setup process could produce inconsistent results
[17:15] <ogra_> plars, yes, known
[17:15] <ogra_> (and we discussed it plenty of times already i think)
[17:15] <plars> ogra_: is there something we can do on our side to prevent that from happening?
[17:15] <ogra_> the gadget device gets reset if its options change
[17:16] <ogra_> yes, rework the whole sh*t
[17:16] <ogra_> :)
[17:16] <plars> ogra_: heh
[17:16] <doanac> can we disable MTP on our host so it doesn't happen?
[17:16] <ogra_> plars, sergiusens was looking into setting persistent properties, once we can do that we should be able to not touch the settings of the device during boot
[17:17] <doanac> ah - i guess not
[17:17] <ogra_> doanac, no, once you change the settings of the gadget device on the phone it reconnects
[17:17] <ogra_> not related ot the host side
[17:18] <doanac> it weird its suddenly gotten worse. but I maybe we've just been lucky up till now
[17:18] <ogra_> so instead of changing the props dunamically every boot, we should use a persistent setting that onlt changes on demand (and keeps this setting over reboots)
[17:19] <doanac> plars: i've got to step away for a bit. I fixed a small bug in the master job.
[17:20] <doanac> and i'm letting the touch_sf4p run on maguro
[17:20] <doanac> http://<IP_ADDRESS>:8080/job/trusty-touch_sf4p-maguro-smoke-master/1/
[17:20] <plars> ok
[17:56] <doanac> plars: there's a bug in the unity8 tests. running "autopilot list unity8" shows a problem with unity8-autopilot/shell/tests/test_notifications.py", line 29, in <module>'
[17:57] <plars> doanac: that's happened several times before - something the unity8 team will have to fix
[17:57] <doanac> looks like we need to add python's "gi" repository
[17:57] <doanac> for now
[17:57] <plars> doanac: oh
[17:57] <plars> doanac: actually
[17:57] <plars> doanac: I looked at something with that late last week
[17:58] <plars> doanac: it looked like the latest phablet-tools installs gi in the autopilot dir from bzr when you run phablet-click-test-setup
[17:58] <plars> doanac: but the version it installs causes issues
[17:58] <plars> sergiusens: have you seen anything up with that? ^
[17:59] <doanac> plars: that's it. i just deleted the copy phablet-click-setup created and it works
[17:59] <plars> doanac: iirc one of the tests is already installing the python-gi package
[18:00] <doanac> hmm - i had to install just now, not sure
[18:00] <plars> doanac: it's easy enough for us to force it to install, but if it's required then it seems odd that just the tests would require it
[18:01] <plars> doanac: just the unity8 tests I mean
[18:01] <doanac> plars:  i don't think thats enough. the "gi" library under /home/phablet/autopilot/gi will take precedence
[18:01] <doanac> so we have to fix this in phablet-tools
[18:02] <plars> doanac: I know
[18:02] <doanac> sorry mis-read
[18:02] <plars> doanac: I'm just wondering if it's a package that should be there in the image
[18:02] <doanac> true.
[18:02] <doanac> a weird dep for just the test to need
[18:04] <doanac> the version phablet-tools grabs says its the same as i just installed. maybe the .deb extraction is messing something up
[18:05] <sergiusens> doanac, let me check; in any case I added that for veebers
[18:06] <doanac> sergiusens: here's the backtrace i just got:
[18:06] <doanac> Traceback (most recent call last):
[18:06] <doanac>   File "<stdin>", line 1, in <module>
[18:06] <doanac>   File "gi/__init__.py", line 27, in <module>
[18:06] <doanac>     from ._gi import _API
[18:06] <doanac> ImportError: could not import gobject (error was: 'cannot import name _gobject')
[18:06] <doanac> i just did a python shell with: from gi.repository import Notify
[18:07] <sergiusens> doanac, let me wrap up this bug fix and I'll get to it
[18:08] <plars> doanac: sergiusens: could it be that phablet-click-test-setup misses the .so files in python-gi?
[18:08] <sergiusens> plars, most likely; which tests use python-gi now?
[18:09] <plars> sergiusens: unity8 for sure, possibly others
[18:09] <doanac> that's what it is
[18:09] <doanac> i just verified
[18:09] <plars> doanac: ack
[18:10] <sergiusens> doanac, if it's just unity8, let's just remove it from there
[18:11] <doanac> sergiusens: remove python-gi from phablet-click-setup?
[18:11] <sergiusens> doanac, yes
[18:11] <doanac> sergiusens: ack - i'll submit an MP.
[18:12] <doanac> plars: you want to merge python-gi into our new apconfig.py file for unity8?
[18:12] <plars> doanac: sure
[18:13] <plars> doanac: we'll just need to make sure we update phablet-tools, it won't work until we have that fix in there also
[18:13] <plars> doanac: we could hand-patch on phoenix for now I suppose
[18:13] <doanac> plars: while you are in there: 'python-mock', 'python-dateutil' are already in phablet-click-setup so we don't need those anymore
[18:13] <plars> doanac: ack
[18:13] <doanac> plars: i think we probably need to change our touch test to take an option phablet-tools branch
[18:14] <doanac> i think we are too reliant on it now assume what's in the distro will handle everything
[18:15] <sergiusens> doanac, I've been wanting it to be sort of hand copied into a ppa you control
[18:17] <doanac> plars, sergiusens: actually since we use a PPA for precise. the changes land there pretty fast :)
[18:18] <plars> doanac: sergiusens: we could make a recipe for it and just request a build for our ppa whenever we want
[18:18] <fginther> rsalveti, ping
[18:18] <doanac> sergiusens, plars: https://code.launchpad.net/~doanac/phablet-tools/click-python-gi/+merge/192031
[18:19] <rsalveti> fginther: pong
[18:19] <fginther> rsalveti, we have a job hanging around for the qt51 build experiment. Is any of that still needed?
[18:19] <fginther> rsalveti, http://<IP_ADDRESS>:8080/job/ubuntu-touch-image-saucy-qt51/
[18:19] <plars> doanac: and https://code.launchpad.net/~pwlars/ubuntu-test-cases/pkg-changes/+merge/192033
[18:19] <rsalveti> fginther: no, that's saucy specific, so let's just disable it for now
[18:20] <rsalveti> and we'll probably try to migrate to 5.2 in a few weeks instead
[18:20] <fginther> rsalveti, somehow it created a massive file: "140737486266368 Oct 21 18:15 kcore"
[18:20] <doanac> plars: +1 thanks
[18:20] <plars> doanac: looks good to me, but I can't topapprove it
[18:21] <sergiusens> plars, doanac done
[18:22] <doanac> plars: oops - we also need to update the utah test entry for unity8
[18:23] <plars> doanac: oh, right
[18:23] <plars> doanac: one sec
[18:23] <plars> doanac: I update phoenix also
[18:23] <plars> doanac: phablet-click-test-setup on phoenix that is
[18:23] <doanac> plars: just the "/usr/bin/phablet-click-test-setup"?
[18:24] <plars> doanac: yes
[18:24] <doanac> k. i've updated phablet-config on phoenix :)
[18:24] <doanac> we need to keep track of this - or use a proper branch.
[18:24] <doanac> i'll get an MP for that soon
[18:24] <plars> doanac: wait, what needs updating in the utah test? it installs unity8-autopilot which should already depend on python-gi right?
[18:24] <doanac> it doesn't
[18:25] <doanac> well - let me check.
[18:25] <doanac> n/m
[18:25] <doanac> plars: ^^^ - we are good to go
[18:27] <rsalveti> fginther: hahah, wtf
[18:30] <plars> fginther: impressive!
[18:43] <sergiusens> fginther, do we have devices for core apps?
[18:44] <fginther> sergiusens, nope
[18:44] <sergiusens> fginther, would be good to run the click tests instead of deb package ones
[18:45] <fginther> sergiusens, agreed, I need to inquire about running these on our internal jenkins. Not sure if the split is still required
[18:46] <sergiusens> fginther, that would be awesome; well at least we can start looking into building them
[18:57] <plars> sergiusens: I'm uploading a recipe for phablet-tools to build off trunk and just use {debversion}-bzr+{revno}. Any preference what I call the recipe?
[18:57] <plars> sergiusens: that way we can just build in a ppa for us to pull, but would probably be useful to others as well for testing new phablet-tools etc
[18:59] <sergiusens> plars, call it what you wish; only thing is that the tests don't run on precise
[18:59] <sergiusens> plars, also, why not just rely on the daily release stuff?
[19:00] <plars> sergiusens: because it takes a while to get through that - especially if it's in manual mode as with the problem we had a while back
[19:00] <sergiusens> plars, manual mode, still?
[19:01] <plars> sergiusens: you don't think that would ever happen again?
[19:01] <plars> sergiusens: we were just talking about this a bit ago, having a ppa for ci to use for things like this, which we could control when we build for it and what we put there
[19:01] <sergiusens> plars, the concept of daily release came up (I've been told) because the recipe system wasn't enough
[19:02] <sergiusens> plars, if people start using recipe builds it sort of beats the purpose; I feel we are just circumventing a problem here
[19:02] <plars> sergiusens: this is not for official builds, this is just so that image smoke testing can update phablet-tools quickly as needed for things that need to be fixed quickly to keep ci from slowing down
[19:03] <sergiusens> plars, ack, feel free to create it
[19:27] <plars> asac: is there really any difference between what's in the saucy build vs the trusty build?
[19:27] <plars> right now that is?
[20:41] <jdstrand> lool: hey, are we supposed to be asking for permission to upload now? if so, may I upload this simple update: http://paste.ubuntu.com/6279220/
[20:43] <cjwatson> jdstrand: lool is on vacation
[20:46] <fginther> plars, we have a way to automatically dput new phablet-tools packages to a ppa on each commit to trunk
[20:48] <fginther> plars, the advantage is that the dput occurs as soon as the commit to trunk is made instead of waiting for the recipe to daily build
[20:52] <jdstrand> cjwatson: thanks
[20:52] <jdstrand> asac: ^
[20:54] <jdstrand> lool: nm
[20:56]  * lool whistles
[20:56] <lool> jdstrand: truth is I'm not sure what you need right now  :-)
[20:57] <lool> but I guess safe uploads to trusty with heads up to landing team would be ok
[20:58] <jdstrand> yeah, it isn't clear yet. I'll wait for asac
[20:58] <jdstrand> lool: thanks! and you should be vacationing now :)
[20:58]  * lool &
[20:58] <jdstrand> :)
[21:29] <plars> ev: :)
[21:29] <ev> :-P
[21:29] <plars> ev: stupid irc clients
[21:29] <ev> I'm not a fan of the entire protocol.
[21:29] <ev> that reminds me, I need to sign up for an irccloud account to make it someone else's problem
[23:13] <asac> doanac: cjohnston: how is the trusty bring up going?
[23:13] <asac> ev: ?
[23:14] <doanac> asac: we have jobs configured but they are buggy. i think i just fixed the issue.
[23:14] <doanac> i'm running a local test right now
[23:14] <doanac> moving the powerd-cli call around was causing an adb-shell call to hang
[23:21] <sergiusens> doanac, hey
[23:22] <sergiusens> doanac, was just testing the edge intro thing; you can probbaly remove the reboot completely as it's not needed at all
[23:22] <sergiusens> doanac, as soon as you change the config, it gets out of your way
[23:22] <doanac> sergiusens: ah - that's even better!
[23:23] <doanac> i'll update the MP
[23:23] <sergiusens> doanac, ah, thought you might of left; I copy/pasted to the mp
[23:23] <doanac> sergiusens: cool. i'm about to eat, but will address tonight.
[23:23] <doanac> thanks
[23:24] <sergiusens> doanac, yeah, just enabled/disabled a couple of times without reboot, saw it come and go
[23:24] <sergiusens> so it's good to avoid the reboot :-)
[23:24] <doanac> yep. that increases our odds of having a good test run :)
[23:27] <asac> doanac: moving powercli around -> for systemsettle?
[23:28] <asac> doanac: i think only screen on we dont want
[23:28] <asac> the rest isnt really hurting us (not sure what else you run)
[23:29] <doanac> asac: if you don't call powerd-cli the screen won't come on (even if you call unlock_screen) and the tests fail
[23:29] <asac> doanac: right. thats for the AP tests
[23:29] <doanac> so we moved it to just before the test
[23:29] <asac> doanac: for systemsettle we dont want it on
[23:29] <asac> right
[23:29] <doanac> note: system-settle still looks bad
[23:29] <asac> doanac: is the screen off?
[23:29] <asac> sure?
[23:30] <doanac> the screen is in the process of getting there. we call system-settle shortly after booting. so its timing dependent what state the screen is in
[23:30] <asac> doanac: how long would the screen stay on before automatically going off?
[23:31] <doanac> asac: not sure. i think its a powerd setting
[23:33] <asac> doanac: are we still use powerd-cli active ?
[23:33] <asac> doanac: thats what we surely shoud call right after boot
[23:33] <asac> then each test calls either on or off etc.
[23:33] <asac> depending on what it needs
[23:34] <doanac> asac: I'm trying a fix that calls active and display-on right before we run unlock_screen
[23:34] <doanac> i'm seeing it doesn't need to happen right after boot
[23:34] <doanac> and then that keeps system-settle from being altered
[23:35] <asac> doanac: ok ... i wont hold you back. i believe getting a trusty build is more important than solving systemsettle though - in case that helps somewhat
[23:36] <doanac> helps a bit. I'm hoping for the best of both worlds with my patch though.
[23:36] <doanac> its looking good at home so far
[23:36] <asac> cool
[23:36]  * asac crosses fingers
[23:37] <doanac> asac: if plars is on later tonight, we have a good shot at merging the fix and being ready to test tomorrows image


[05:06] <jose> guys, how can I get a unit's name without the /#? Let's say, instead of returning wordpress/1, return just wordpress
[05:16] <lifeless>  | sed -e '|/*||' ?
[07:00] <raywang> hi just a quick question, anyone knows how do I know where can i get those EC2 variables from openstack env (horizon doesn't have that)?
[07:19] <mattrae_> hi, with juju core i have a services and machines that are stuck in the dying state
[07:19] <mattrae_> how do i get them to move along
[07:19] <mattrae_> ?
[07:20] <mattrae_> using 1.13.3
[07:20] <mattrae_> or is there a better working version?
[07:23] <raywang> mattrae_, I used 1.13.2, and had the same problem like you :)
[07:29] <mattrae_> raywang: cool thanks for confirming :)
[07:31] <raywang> mattrae_, I think jpds might report the block bug like that, Maybe he has findings :)
[07:31] <gnuoy> Bug#1214651 looks similar
[07:31] <_mup_> Bug #1214651: Machine stuck in 'pending' state cannot be terminated <juju-core:Triaged> <https://launchpad.net/bugs/1214651>
[07:31] <raywang> mattrae_, or melmoth also run into the problem like that
[07:32] <gnuoy> in that bug the agent-state is pending and  life: dying
[07:34] <gnuoy> does anyone know when the python based openstack charms are likely to be replaced by the python-redux one ?
[07:34] <gnuoy> urgh, I meant: does anyone know when the *bash* based openstack charms are likely to be replaced by the python-redux one ?
[07:38] <mattrae_> raywang: great thanks for the bug. i'm trying to just redploy the charm with a different service name
[07:38] <mattrae_> raywang: i'm just leaving the old charm there dying since i have a spare machine to use
[07:38] <raywang> mattrae_, that's good :)
[07:38] <mattrae_> hopefully it will work
[07:39] <mattrae_> gnuoy: you might ask adam_g about when the python-redux charms will be available
[07:41] <gnuoy> mattrae_, thanks, will do.
[07:51] <mattrae_> does debug-hooks in 1.13 work for the install hook?
[07:51] <mattrae_> i have an error on an install hook
[07:52] <mattrae_> how do i debug?
[07:52] <mattrae_> debug-hooks didn't take me to the install hook when i ran: juju resolved hook/0 --retry
[07:52] <mattrae_> i mean juju resolved charm/0 --retry
[07:59] <melmoth> raywang, indeed. There are a couple of similar bugs. The main thing i remember is: never destroy a unit before the end of the install hook
[07:59] <melmoth> otherwise, your fskcp with the machine in a state you cannot change and cannot remove it neither, all is left is destroy env
[08:58] <jamespage> gnuoy, re openstack redux charms - once they have had enought testing
[08:59] <jamespage> we agreed a few general approach changes at vUDS that still need to be implemented
[08:59] <jamespage> gnuoy, of course if you want todo some testing much appreciated!
[09:01] <gnuoy> jamespage, I'll certainly take them out for a spin :-)
[09:02] <jamespage> gnuoy, lovely
[10:06] <mthaddon> anyone know what this means from the local provider on bootstrap (juju-core, 1.13.3-1~1737~ubuntu13.04.1): error: required environment variable not set for credentials attribute: URL
[10:08] <mthaddon> also, I'm following https://juju.ubuntu.com/get-started/local/, but "juju init -w" gives "error: flag provided but not defined: -w"
[10:10] <mthaddon> also, "juju init" creates a file that includes instructions to use -e to switch environments, but that fails with "error: flag provided but not defined: -e"
[10:11]  * mthaddon files bugs
[10:12] <_mup_> Bug #1221127 was filed: juju docs recommend "juju init -w" but that fails <juju:New> <https://launchpad.net/bugs/1221127>
[10:13] <thumper> mthaddon: people coming to help RSN
[10:13] <mthaddon> I've worked around it, as juju init does the right thing, just trying to help improve the docs
[10:16] <mgz> I don't know what the local provider error issue is, it looks like that's not the local provider at all
[10:16] <mgz> as it's an error we get from the openstack provider if you don't have an identity server url set in config or envvar
[10:17] <TheMue> mthaddon: hmm, i've done it the doc way (to check what i wrote *smile*) and it worked
[10:17] <mgz> mthaddon: double check you have "type: local" set, and are using the right env?
[10:17] <TheMue> mthaddon: i've used a clean environment, no other juju installation before
[10:17] <TheMue> mgz: +1
[10:18] <TheMue> mgz: but that may be a good hint. when generating we default to amazon. and i didn't wrote about setting it to local.
[10:18] <mthaddon> TheMue, mgz: I've fixed it by creating a new env (using juju init) but are you saying "juju init -w" works for you?
[10:18] <TheMue> mgz: will add this
[10:19] <_mup_> Bug #1221134 was filed: "juju init" creates a file that includes comments recommending -e to switch environments <juju:New> <https://launchpad.net/bugs/1221134>
[10:19] <mgz> mthaddon: nope, the docs are just wrong on that (did it change at some point?) init only takes what --help says it does, which does not include  -w or -e
[10:19] <mthaddon> mgz: ok, thanks - I guess those two bugs are valid then
[10:20] <mgz> the second one I find slightly confusing...
[10:20] <mgz> commands where having an environment makes sense should interpret -e
[10:20] <mthaddon> mgz: how so?
[10:21] <mthaddon> mthaddon@mallory:~$ juju -e amazon status
[10:21] <mthaddon> error: flag provided but not defined: -e
[10:22] <mgz> hm, maybe it's only registered as a normal flag now, after the plugin changes... I take it `juju status -e amazon` works?
[10:23] <mthaddon> ah, yeah, it does, will update the bug report
[10:23] <mgz> wallyworld_: ^was a deliberate change to how we parse -e in commands?
[10:24] <wallyworld_> mgz: not for juju commands, only plugins
[10:25] <mgz> hm, am sure that the before-the-command form used to work
[10:25] <wallyworld_> mgz: InitCommand extends BaseCommand and not EnvironCommand, that is the issue if -e is required
[10:26] <wallyworld_> but init should not need the -e option
[10:27] <wallyworld_> mgz: i *think* -w was removed because init now writes by default
[10:27] <wallyworld_> and --show is required just to dump the contents
[10:27] <wallyworld_> mthaddon: it seems get-started/local is out of date
[10:27] <mgz> wallyworld_: that makes sense for the -w removal... I guess we just update the docs
[10:28] <wallyworld_> it's a doc issue rather than a juju bug
[10:28] <mgz> wallyworld_: what I'm not sure about is if we've changed from accepting `juju -e amazon status` to only allowing `juju status -e amazon`
[10:29] <mthaddon> wallyworld_: absolutely, I'm happy for it to be a doc bug rather than a juju bug
[10:29] <wallyworld_> mgz: i think the -e may now need to come after the sub command, but not 100% sure
[10:30] <wallyworld_> mgz: yes, it appears so
[10:30] <wallyworld_> so if any docs say otherwise, they need to be changed too
[10:32] <mthaddon> is juju-core lxc supposed to work these days? bootstrap node seems fine, but deployed machine is stuck in pending
[10:33] <wallyworld_> mthaddon: it will be pending while it downloads the image
[10:33] <wallyworld_> can take a while
[10:33] <wallyworld_> i think we need a better status
[10:33] <mgz> mthaddon: looking at juju.ubuntu.com and the branch, the local provider setup instructions say `juju generate-config` not `juju init -w` it seems
[10:34] <wallyworld_> wow, generate-config is old
[10:34] <TheMue> it's an alias
[10:35] <mthaddon> mgz: is that different from https://juju.ubuntu.com/get-started/local/ ?
[10:36] <mgz> ...yes
[10:38] <mgz> hm, clicking on local configuration from the getting started link gets me to the right page, but not that one...
[10:39] <TheMue> oh, just seen, we're inconsistent in our internal help texts. some times "init -w", some times "generate-config -w".
[10:39] <mthaddon> ah, I see - if you navigate from the website you get to https://juju.ubuntu.com/docs/config-local.html
[10:40] <mthaddon> I was following the link in the generated juju env file from "juju init"
[10:40] <mthaddon> I'll note that in the bug report
[10:40] <mgz> bah, I don't have the karma to edit the askubuntu response, so I'm not sure if that's directly linked or just copied
[10:43] <mgz> ha, yes I do, and it is live updated
[10:44] <mthaddon> sorry, which askubuntu question is this?
[10:44] <mgz> so, -w is gone from that page now, hopefully people on older versions will now not be confused
[10:44] <mgz> mthaddon: that page is generated from an askubuntu response
[10:44] <mgz> if you click the byline at the top, it links there
[10:45]  * mthaddon nods
[10:46] <mgz> or, actually, the title, clicking jorge links to jorge
[10:46] <mthaddon> mgz: so why do we have to pages for getting started with the local provider? should the juju init comment link to https://juju.ubuntu.com/docs/config-local.html ?
[10:46] <mthaddon> er, why do we have *two* pages
[10:46] <mgz> mthaddon: I think so
[10:48] <TheMue> the config-local.html has been written during the doc sprint last week like those other config-foo for other providers.
[10:48] <mgz> I think we just need to migrate properly to the lp:juju-core/docs stuff, askubuntu was a stopgap
[10:50] <mthaddon> my env is still in pending... :(
[10:51] <TheMue> mthaddon: which bandwidth? loading the images can last some time?
[10:52] <mthaddon> TheMue: 20Mbits download - I guess it could still be working
[10:58] <TheMue> mthaddon: still pending? after the image the software itself is downloaded and installed (e.g. worpress, mysql)
[10:59] <TheMue> mthaddon: this may last longer on a private box than on fine ec2 instances ;)
[10:59] <mthaddon> yep - http://paste.ubuntu.com/6066089/
[10:59] <gnuoy> does the requirement to ufw disable still exist ?
[11:00]  * gnuoy looks for the bug
[11:00] <TheMue> mthaddon: a ps could show that there are some wgets running
[11:01] <mthaddon> no wgets running
[11:01] <gnuoy> Bug#998238
[11:01] <_mup_> Bug #998238: local provider unit agents get stuck in pending state because of host firewall blocking communication <juju:Confirmed> <https://launchpad.net/bugs/998238>
[11:02] <gnuoy> mthaddon, is ufw enabled ?
[11:02] <mthaddon> gnuoy: it was, lemme destroy env, disable it and try again
[11:04] <gnuoy> mthaddon, the other issue I had some time ago was a bad image in /var/cache/lxc/cloud-precise . I removed it and all was good, but I think the ufw problem is the most likely
[11:05] <mthaddon>     agent-state: started <-- seems like it was ufw again...
[11:06]  * mthaddon will comment on the bug report after confirming the instance boots to completion
[11:09] <mthaddon> 2013-09-05 11:08:47 ERROR juju git.go:188 worker/uniter/charm: git command failed: exec: "git": executable file not found in $PATH
[11:09] <mthaddon> this is from the unit log
[11:13] <mthaddon> gnuoy: does that sounds like the bad image issue you had a while back? ^
[11:14] <gnuoy> no, machines were stuck pending
[11:14] <mthaddon> k, thanks
[11:52] <marcoceppi> mgz: the -w isn't even needed anymore
[12:07] <mgz> marcoceppi: do you know what the status of the old askubuntu pages is?
[12:08] <marcoceppi> mgz: I don't know what you mean
[12:08] <mgz> should we just make sure everything in those answers is also in the new configuring docs, then remove the links and pages?
[12:08] <marcoceppi> mgz: we had a hybrid aproach planned for the new docs, embedding some questions in the docs, it's just been deferred
[12:09] <marcoceppi> if something is out of date, anyone can edit and rectify the issue
[12:09] <mgz> compare juju.ubuntu.com/get-started/local and juju.ubuntu.com/docs/config-local.html
[12:09] <marcoceppi> mgz: we should probably just drop that get-started link and have it redirect to the docs
[12:10] <marcoceppi> jcastro evilnickveitch: thoughts ^
[12:10] <evilnickveitch> marcoceppi, mgz - i am not sure but I think those pages may be culled in the redesign happening later
[12:11] <evilnickveitch> (the non docs ones)
[12:12] <evilnickveitch> I think we should redirect to the docs for all the getting started stuff
[12:20] <jcastro> I agree
[12:20] <jcastro> however the AU pages get a bunch of google juice, so we need to make sure they are up to date so they act as an onramp to the docs
[12:34] <mattyw> I can't seem to ssh into unit's I've deployed locally, anyone else seen this?
[13:17] <marcoceppi> mattyw: how are you sshing?
[13:17] <mattyw> marcoceppi, juju ssh
[13:17] <mattyw> marcoceppi, I get permission denied public key
[13:18] <marcoceppi> mattyw: are you using the machine number or the unit name?
[13:18] <mattyw> marcoceppi, machine number
[13:19] <marcoceppi> mattyw: that doesn't work with local provider, use unit name instead
[13:49] <X-warrior> When you add postgresql service to bootstrap machine, the log goes into a loop and keep increasing forever
[13:49] <X-warrior> is it a bug?
[13:54] <mgz> X-warrior: file a bug with a complete description and steps how to reproduce it, easiest way to find out
[13:57] <marcoceppi> X-warrior: I think this has been documented already
[13:57]  * marcoceppi looks
[14:01] <X-warrior> https://bugs.launchpad.net/juju-core/+bug/1218616
[14:01] <_mup_> Bug #1218616: all-machines.log is oversized on juju node <juju-core> <juju-core:Triaged> <https://launchpad.net/bugs/1218616>
[14:18] <X-warrior> how could I get juju/devel to work on mac ?
[14:20] <mattyw> marcoceppi, ok thanks
[14:20] <marcoceppi> X-warrior: You'll need to compile it, there are instructions on this
[14:22] <marcoceppi> X-warrior: http://paste.ubuntu.com/6066656/
[14:23] <marcoceppi> X-warrior: that will be in the docs soon, just a little bit behind
[14:24] <marcoceppi> X-warrior: also, that will get you the tip of trunk, which should be fairly tested, but won't exactly be what's in the devel ppa
[14:28] <mattyw> marcoceppi, is not being able to do juju ssh <machine-number> on the local provider a long term thing? or just a bug at the moment?
[14:28] <marcoceppi> mattyw: core team is aware of it, not sure if it's a long term thing or not. AFAIK, there are two local provider caveats; no ssh to machine number and debug-log doesn't work
[14:29] <mattyw> marcoceppi, ok cool, thanks again
[15:00] <mgz> arosales: actually, I don't have the edit bit set for the juju status doc it seems
[15:01] <arosales> mgz, sorry, please refresh and you should have edit access
[15:02] <mgz> arosales: thanks!
[15:02] <arosales> mgz, thnks for updating :-)
[15:09] <X-warrior> marcoceppi: ty
[15:09] <X-warrior> :D
[15:52] <dalek49>  when trying to bootstrap my local environment, i get "TLS handshake failed: x509: certificate signed by unknown authority"
[15:52] <dalek49> I also saw this bug report https://bugs.launchpad.net/juju-core/+bug/1178312
[15:52] <_mup_> Bug #1178312: ERROR state: TLS handshake failed: x509: certificate signed by unknown authority <ui> <juju-core:Triaged> <https://launchpad.net/bugs/1178312>
[15:52] <dalek49> I'm not seeing any information on how to troubleshoot this
[16:37] <diegonat> hi im using juju local but I cannot log in into lxc instances. What are the username and password??
[16:38] <mgz> diegonat: you can't login, you need to ssh in, use `juju ssh UNIT`
[16:40] <diegonat> Permission denied (publickey,password).
[16:40] <diegonat> error: exit status 255
[16:41] <mgz> diegonat: paste bit the juju status output and the exact command you ran to ssh in?
[16:41] <mgz> !patebin
[16:41] <mgz> !pastebin
[16:41] <mgz> ;_;
[16:42] <rick_h> I had this I think. You have to ssh manually with ubuntu@xxx when I tried it out
[16:44] <mgz> that should be fine regardless, yeah (unless ~/.ssh/config is borked)
[16:44] <diegonat> http://pastebin.com/i52qKLuD
[16:45] <diegonat> mgz, any error?
[16:45] <mgz> diegonat: you can't ssh to the machine number with local, you need to use the unit, eg mysql/0
[16:47] <diegonat> ok
[16:48] <mgz> ...oddly we don't seem to have a bug open for that
[16:48] <diegonat> another question that i cannot find an answer online. How does juju work with AWS ? I mean, when I deploy a server, does it launch an instance automatically with the service without me configuring the instance?
[16:48] <mgz> diegonat: yup, by default
[16:50] <diegonat> going back to my test machine with lxc... I jujued wordpress and mysql. Is there any way that I can do the same but with wordpress and mysql already configured? For example with mysql user and pass set as I want ?
[16:51] <mgz> yuo can pass configuration to the carms to customise them, but user/pass is really not something you want to put it, it's much better from a security perspective to autogenerate
[16:52] <diegonat> ok, now for example... I have wordpress and mysql. How can I configure wordpress without knowing mysql user and pass?
[16:52] <diegonat> where should i find them?
[16:53] <mgz> you just add a relation between the two, and that information gets communicted across
[16:53] <diegonat> ok thats nice
[16:53] <diegonat> =)
[17:07] <jcastro> yeah, the entire idea is for you to not have to care about doing that by hand
[17:11] <diegonat> is it possible to install the web UI ?
[17:11] <jcastro> yeah
[17:11] <jcastro> juju deploy juju-gui
[17:11] <jcastro> will deploy the web UI in the environment
[17:11] <jcastro> https://jujucharms.com/precise/juju-gui-HEAD/#bws-readme has the instructions
[17:12] <jcastro> rick_h: hey, can you guys stick the copyright of the gui README at the bottom or something?
[17:12] <jcastro> that top thing pains me
[17:13] <sarnold> I miss the older charm browser.. it was so much faster
[17:14] <jcastro> http://manage.jujucharms.com/ still works!
[17:14] <sarnold> don't get me wrong, I'm thrilled there's a juju gui demo around, and once it has listing code, I cna understand why you'd rather just maintain the one..
[17:14] <sarnold> jcastro: oh thanks :) nice. near-instant response. hehe.
[17:16] <jcastro> I think once the URLs are sorted and the load time is reduced it'll be fine
[18:28] <jackweirdy> Don't suppose anyone could help me with my juju hanging on mongo problem? http://askubuntu.com/q/341845/61821
[18:29] <AskUbuntu> juju hangs when connecting to mongo | http://askubuntu.com/q/341845
[18:44] <jrwren> jackweirdy: are you doing something non-standard with a local environment?
[18:45] <jrwren> jackweirdy: normally the bootstrap of the local environment creates a completely separate mongo db instance, so you wouldn't have a mongodb.conf like your question states.
[18:45] <jackweirdy> I've followed the steps here to the letter
[18:45] <jackweirdy> https://juju.ubuntu.com/docs/config-local.html
[18:45] <jackweirdy> the only difference was that I had mongo already installed from the 10gen repo
[18:46] <jackweirdy> so I had to purge that and remove it from sources.d
[18:46] <jackweirdy> but after an update & autoclean everything seemed ok
[18:46] <jrwren> right.
[18:46] <jrwren> sounds like you edited the mongodb.conf to listen on the port which juju wants. don't do that.
[18:47] <jackweirdy> I changed that because beforehand it was just failing
[18:47] <jrwren> juju bootstrap will start a mongo instance with its db dir in .juju/  not the system mongo.
[18:47] <jackweirdy> Ah I see;
[18:47] <jrwren> it might not have been failing. it might have been REALLY SLOW. first connects would take 30sec for me sometimes.
[18:48] <jackweirdy> In debug it was implying nothing was listening on that port
[18:51] <jackweirdy> I'm getting lots of this when I juju bootstrap --debug
[18:51] <jackweirdy> 2013-09-05 18:51:05 ERROR juju open.go:89 state: connection failed, will retry: dial tcp <IP_ADDRESS>:37017: connection refused
[18:51] <jackweirdy> 2013-09-05 18:51:05 ERROR juju open.go:89 state: connection failed, will retry: dial tcp <IP_ADDRESS>:37017: connection refused
[18:51] <jackweirdy> 2013-09-05 18:51:06 ERROR juju open.go:89 state: connection failed, will retry: dial tcp <IP_ADDRESS>:37017: connection refused
[18:51] <jackweirdy> oh, it's working now :)
[18:51] <jackweirdy> I should be more patient :)
[18:51] <jackweirdy> Thanks :)
[19:25] <jcastro> jackweirdy: it should take about 30 seconds
[19:25] <jcastro> anything longer than that is a problem
[19:25] <jcastro> jackweirdy: is this the very first time you're bootstrapping?
[20:00] <marcoceppi> jackweirdy: it depends on how fast your disks are, but it could take up 90 seconds until the bootstrap comes back. It does a bunch of stuff behind the scenes for the local provider
[20:08] <jcastro> hazmat: around?
[20:12] <jcastro> hazmat: hey so for the local instructions, we have the `lxc-local` convenience package so you don't need to install "mongodb-server", which I think is overkill anyway, isn't it mongodb-clients?
[20:15] <hazmat> jcastro, local provider needs mongodb server
[20:15] <hazmat> jcastro, the client lib is builtin-to the juju binary
[20:15] <hazmat> its basically two extra packages though
[20:15] <hazmat> which we made a new package to automate ;-)
[20:16] <jcastro> oh, nm, I see mongodb-server is a depends on lxc-local
[20:16] <jcastro> anyway, I was thinking we could slim down the install line on that page
[20:16] <jcastro> to just `sudo apt-get install juju-local`
[20:16] <jcastro> which pulls in lxc and mongo
[20:16] <hazmat> yup
[20:17] <jcastro> ok mind if I make the change?
[20:17] <hazmat> fine by me
[20:29] <kentb> where can I go if I want more info on whether or not I need the ext-port set on a quantum-gateway charm? I'm deploying grizzly on bare-metal using maas & juju and each server has multiple nics....just not sure when ext-port is appropriate.
[20:30] <kentb> and is it wise / safe to put quantum-gateway on the same server as nova-cloud-controller, keystone, mysql, rabbitmq-server using juju-core?
[20:30] <marcoceppi> jamespage adam_g ^
[22:29] <mwhudson> davecheney: ping
[23:54] <davecheney> mwhudson: ack