[00:07] <thomi> Hi all, is anyone able to help me parse this log message please? "unit spi-mongodb/1 cannot get assigned machine: unit "spi-mongodb/1" is not assigned to a machine"
[00:07] <thomi> it's the last 'ERROR' in a failing deployment, and I have zero clue what that means
[00:07] <thomi> In fact, it seems paradoxical to me...
[01:39] <lazyPower> thomi: thats interesting, i only see that during the first steps of deployment
[01:40] <lazyPower> i think its related to the agent deployment but i'm not entirely sure
[01:40] <thomi> hmmm
[01:40] <lazyPower> thomi: however its not critical, and i never see it again once the agent is up and running
[01:40] <lazyPower> is this a manual provider environment?
[01:40] <thomi> lazyPower: no, local
[01:40] <lazyPower> which juju version? I assume this is 1.24.3 the current -stable release?
[01:41] <thomi> 1.24.2
[01:41] <thomi> which is the latest in vivid... unless a new release came out this week?
[01:41] <lazyPower> 1.24.4 was released this week actually
[01:42] <thomi> ahh, ok
[01:42] <thomi> I'll upgrade and retry :D
[01:42] <thomi> It's all complicated by the fact that I'm also using mojo and therefore juju-deployer
[01:42] <lazyPower> thomi: another question, have you tried deploying something "simple" like the ubuntu charm to verify the local provider is indeed working?
[01:42] <thomi> so I have three places to look for errors :D
[01:43] <thomi> lazyPower: yes - by the time it errors I've already deployed apache, haproxy and a few other things
[01:43] <lazyPower> ok, well thats promising that its not a full scale local provider issue
[01:43] <lazyPower> should narrow things down a bit when debugging anyway
[01:43] <thomi> hmmm, I'm not seeing a new juju in vivid?
[01:43] <lazyPower> interesting, i wonder if vivid packages weren't published yet, i just got 1.24.4 today on trusty
[01:44] <lazyPower> seems that its in the ppa
[01:44] <lazyPower> https://launchpad.net/~juju/+archive/ubuntu/stable
[01:45] <thomi> hmmm
[01:45] <lazyPower> ah, i mis-spoke. 14.10.1 has 1.24.2-0
[01:46] <lazyPower> thomi: but if you're on vivid, 15.04 - you should have 1.24.4 available to you.. the 1.24.2 is for utopic(?)
[01:47] <thomi> apt-cache policy says 1.22.1 is all that's in the archive.
[01:47] <thomi> I could add the PPA and get it
[01:47] <thomi> I'm just wondering if that's going to break anything else
[01:55] <thomi> lazyPower: who should I talk to about juju-deployer?
[01:55] <lazyPower> thomi: our devx team currently maintains juju-deployer. tvansteenburgh (out on vaca) and marcoceppi are 2 good resources
[01:56] <thomi> thanks. I guess it's a bit late for marcoceppi :D
[01:59] <crab> hi.
[02:18] <lazyPower> hello crab
[02:18] <lazyPower> thomi: it is, its 10:20 here
[02:18] <lazyPower> however to be fair, you never know when he's lurking about
[02:22] <marcoceppi> thomi: hello o/
[02:22] <lazyPower> speak of the force of nature
[02:28] <marcoceppi> thomi: is spi-mongodb a subordinate?
[02:38] <pmatulis> should bugs be filed on github or launchpad?
[02:38] <pmatulis> i see tracking on both sites
[02:38] <lazyPower> pmatulis: Launchpad is the preferred location
[02:39] <pmatulis> lazyPower: ok, but why 2 trackers?
[02:39] <lazyPower> Good question, there was an open discussion about it on the list last year and it was decided to not have an issue tracker on github. I'm not sure why that was overturned. It may be to reduce the barrier to entry for bug contributors that are not on launchpad
[02:40] <pmatulis> lazyPower: awfully confusing and inefficient
[02:40] <marcoceppi> pmatulis: bugs are tracked on launchpad for juju, all project management is done there
[02:41] <pmatulis> marcoceppi: alright. maybe we should shut down the github tracker then
[02:41] <marcoceppi> pmatulis: we probably should
[02:41] <marcoceppi> pmatulis: I'd email<EMAIL_ADDRESS>to start that discussion
[02:42] <pmatulis> marcoceppi: alright, thanks for clarifying
[02:55] <thomi> marcoceppi: sorry, was AFK. Are you still here?
[02:55] <marcoceppi> thomi: yup
[02:56] <thomi> marcoceppi: I'm seeing juju-deployer errors like: http://pastebin.ubuntu.com/12058570/ when I run my mojo spec
[02:56] <thomi> marcoceppi: most of those ERROR lines occur even on a successful run
[02:56] <thomi> but the 'Unknown error' doesn't
[02:56] <thomi> any ideas what could be happening?
[02:57] <marcoceppi> what version of deplyer?
[02:57] <marcoceppi> thomi: also, it appears that deployer is having a hard time parsing your bundle
[02:57] <thomi> marcoceppi: 0.5.1-3
[02:57] <marcoceppi> thomi: cool, that's latest
[02:57] <marcoceppi> thomi: do you have the bundle? could you pastebin that?
[02:58] <thomi> marcoceppi: by 'bundle' you mean the yaml files?
[02:58] <marcoceppi> yes
[02:58] <thomi> sure, one second..
[02:59] <thomi> marcoceppi: there's two files: http://paste.ubuntu.com/12059115/ and http://paste.ubuntu.com/12059114/
[03:00] <marcoceppi> thomi: okay, so it lists charm, I'm not 100% sure on mojo stuff, but are those "charms" in a local directory somewhere? It's trying to parse the charm URL for those and it's failing
[03:00] <marcoceppi> it expects a protocol like cs:<series>/<charm>
[03:00] <marcoceppi> or local:<series/<charm>
[03:00] <marcoceppi> or instead of a charm key, a branch key with a bzr branch
[03:01] <thomi> marcoceppi: I think that's a red herring - mojo builds the charm repo, and those ERROR messages about missing charms happen even for successful runs
[03:01] <marcoceppi> thomi: then your next error is "deployer.deploy: Invalid config charm result-enum-worker nagios_context=None"
[03:02] <marcoceppi> does the result-enum-worker charm have a nagios_context configuration option?
[03:02] <marcoceppi> You may also want to try setting it to ""
[03:02] <thomi> I'm 90% sure... just double checking
[03:03] <thomi> marcoceppi: ugh... that'd be it... now I feel silly :D
[03:03] <thomi> marcoceppi: the change to the charm didn't land yet it seems.
[03:04] <marcoceppi> I feel like I should dig into mojo more, those charm/branch errors seem so...weird
[03:04] <thomi> marcoceppi: I will buy you many $(beverage_of_choice) if it means juju and mojo devs start talking to each other
[03:04] <thomi> I'm not even joking. SO MANY BEERS.
[03:05] <marcoceppi> thomi: so, on the devx team we have dedicated time to work on tooling each week (amulet, deployer, charm-tools, etc) we may take one of these slots to just get a bunch of info about how mojo is using deployer and see if we can make it happier
[03:06] <marcoceppi> thomi: we just landed something that might be useful for mojo, where charm: can now be an absolute path to a charm directory on disk, may help streamline some of what mojo is trying to do
[03:07] <thomi> marcoceppi: that sounds good. It seems like there's lots of places where mojo & juju could work better together
[03:12] <thomi> marcoceppi: if you're still around: What's the best way to make your team aware of  such issues? Perhaps there's a bug tag to use, or something? a mailing list, or...?
[03:13] <marcoceppi> thomi: if you want to tag bugs with mojo on lp:juju-deployer (or any project) we can use that for filtering
[03:14] <thomi> marcoceppi: will do - thanks
[03:14] <lazyPower> marcoceppi: did you know juju-reboot existed?
[03:14] <marcoceppi> lazyPower: yes, it came into existance because of windows charms
[03:15] <marcoceppi> lazyPower: I troll juju help-tool a lot to keep up to date with new stuff landing in hookenv
[03:15] <lazyPower> man, thats awesome. I just discovered it tonight poking around in the tools dir
[03:15] <lazyPower> i'm working off the feat-proc-mgmt branch and finding out whats impl and whats pending - ran across that nugget of goodness
[04:08] <thomi> Is there a way I can get juju to show me all the relations that a deployed charm supports?
[04:08] <thomi> 'juju stat' seems to only show me relations that are actually connected to something
[04:09] <thomi> I guess I want a 'juju list-relation'
[08:30] <Tribaal> Hi all. The ingestion queue for the charm store seems to be incredibly slow. I've been waiting for my branch to be ingested for hours... Can somebody have a look?
[09:29] <jamespage> gnuoy, https://code.launchpad.net/~james-page/charm-helpers/liberty-versioning/+merge/264998
[09:30] <jamespage> that's the other ch bit for liberty version detection
[09:54] <gnuoy> jamespage, merged
[09:55] <gnuoy> jamespage, https://code.launchpad.net/~openstack-charmers/charms/trusty/neutron-api/vpp/+merge/263224 for the neutron-api changes
[10:10] <jamespage> gnuoy, one niggle
[10:10] <gnuoy> hit me
[10:11] <gnuoy> oh, I see, you have. ta
[10:14] <gnuoy> jamespage, fixed
[10:16] <jamespage> gnuoy, http://paste.ubuntu.com/12060702/
[10:16] <jamespage> just noticed that
[10:16] <gnuoy> argh, on it
[10:18] <gnuoy> jamespage, fixed
[10:19] <jamespage> gnuoy, +1
[10:19] <gnuoy> \o/
[10:19] <gnuoy> thanks
[10:19] <jamespage> I'll asume the lint will pass now :-)
[10:19] <gnuoy> defo
[11:48] <g3naro> anyone familiar with aws ?
[11:53] <marcoceppi> g3naro: as familiar as the next person
[12:08] <g3naro> marcoceppi: elastic-beanstalk
[13:58] <g3naro> jooojooo
[14:21] <Bigdeal> Newbie seeking help on JUJU: ssl when connecting to openstack
[14:33] <Bigdeal> newbie question, problem bootstraping juju with openstack due to ssl error
[14:34] <Bigdeal> How can I foce juju to accept a self sign cert
[14:37] <jose> Bigdeal: there are no newbie questions at all :) someone should be around soon to give you a hand, I need to leave
[14:37] <Bigdeal> Jose: Thanks
[14:38] <jose> Bigdeal: what juju version are you using? (juju version gives you that)
[14:38] <Bigdeal> Jose: 1.24.4-trusty-amd64
[14:39] <jose> huh, I see a bug but it was fixed on 1.15+... let's wait for someone else to check on that :)
[14:39] <Bigdeal> Jose: I ran the quickstart -i
[14:40] <Bigdeal> used ssl-hostname-verification : false
[14:58] <hatch> I have a config field for a 'secret' this secret can be any series of characters but it fails if it is all numbers because juju says the types don't match...quoting the value solves the problem but that's not going to be very user friendly as I have to strip the quotes off if they exist (and aren't part of the actual secret string) and the user has to know to quote it...are there any other workarounds for this?
[14:58] <ddellav> Bigdeal, whats the exact error you are getting? and is it during the bootstrap process or is it in a browser we trying to access juju-gui/horizon dashboard?
[15:03] <Bigdeal> this is during the bootstrap process
[15:04] <Bigdeal> ddellav: I used quickstart -i then filled in the parameters for my openstack env.
[15:05] <ddellav> ok, can you paste me the error output? You can use http://paste.ubuntu.com
[15:15] <ddellav> hatch, as far as i know right now we only support integer, string, and boolean types for config valus.
[15:15] <ddellav> *values
[15:15] <Bigdeal> ddellav:
[15:15] <Bigdeal> ERROR there was an issue examining the environment: authentication failed.
[15:15] <zeron> ddellav: sorry for the delay, Bigdeal is currently at a meeting, he will revert to you as soon as he comes out of it. thanks.
[15:15] <ddellav> if it's a string value (meaning quoted) then you can put whatever you want in there and you shouldn't have to remove the quotes when retrieving it later (though Im not 100% sure about this)
[15:15] <hatch> ddellav, yeah, is there maybe a way to make the yaml field a 'string' without quotes?
[15:16] <hatch> yeah this is kind of an edge case bug....because it's a secret it can be anything, (the user, or I have control over this secret value)
[15:16] <ddellav> hatch, not that I know of but there may be something in the YAML spec that allows for it, I'd have to look it up. Something like heredoc syntax.
[15:17] <ddellav> zeron, no problem :)
[15:17] <ddellav> Bigdeal, have you tried setting ssl-hostname-verification to true?
[15:18] <hatch> ddellav alright np thanks, I'll keep looking
[15:20] <ddellav> also Bigdeal what provider are you using?
[15:20] <ddellav> (maas, aws, azure)?
[15:22] <Bigdeal> ddellav: I am pointing to my own Openstack environement
[15:25] <ddellav> Bigdeal, so you are using your own openstack environment as the provider?
[15:27] <Bigdeal> ddellav: I am pointing to my own Openstack environement as the provider, my environement uses selfsigned certs
[15:38] <ddellav> ok, i'm not quite sure what that could be and I can't find any relevant information on ssl issues when deploying juju on top of openstack. Perhaps lazyPower or beisner have some ideas?
[15:46] <Bigdeal> ddellav: would ssl-hostname-verification=false help?
[15:46] <Bigdeal> but I am not sure where it should go
[15:48] <ddellav> Bigdeal, that would go into your environments.yaml file
[15:49] <ddellav> https://jujucharms.com/docs/devel/config-general#alphabetical-list-of-general-configuration-values
[15:49] <Bigdeal> can you please tell me the path of the file?
[15:49] <ddellav> that's usually in ~/.juju/envionments.yaml
[15:50] <ddellav> *environments.yam
[15:50] <ddellav> ugh.. new keyboard, still breaking it in :(
[15:51] <g3naro> mechanical ?
[15:52] <lazyPower> Bigdeal: that would be a sub-key of your openstack provider environment defined in $HOME/.juju/environments.yaml
[15:53] <Bigdeal> my file is empty
[15:53] <ddellav> g3naro, yea, razer blackwidow chroma
[15:53] <lazyPower> Bigdeal: are you using encrypted homedir?
[15:53] <ddellav> Bigdeal, when using openstack provider you might want to read this: https://jujucharms.com/docs/devel/config-openstack
[15:56] <Bigdeal> lazyPower: not sure abour home dir
[15:56] <g3naro> ddellav:  nice one
[15:57] <g3naro> ive got corsair k70
[15:57] <g3naro> i tried them all
[16:05] <Bigdeal> I added the line and still getting  error: Bootstrap failed, cleaning up the environment.
[16:05] <Bigdeal> ERROR there was an issue examining the environment: authentication failed.
[16:08] <plars> I have some services that I want to deploy to lxc under maas. I'm using juju-deployer to deploy a empty ubuntu charm named something like service-host, and the rest with to: lxc:service-host
[16:08] <plars> but one of the things my service needs to do requires some changes to the default lxc apparmor template
[16:09] <plars> is there some way to pre-configure this when I deploy? or do I have to deploy some decoy to lxc, go modify the template by hand, and destroy the decoy?
[16:09] <plars> It's /var/lib/lxc/juju-trusty-lxc-template/config that I need to edit, but that doesn't seem to exist until I actually deploy something to:lxc:foo
[16:11] <lazyPower> plars: right, thats the chicken/egg of lxc configuration. What you can do, is deploy a subordinate that modifies that template and use juju-reboot to reboot the host.
[16:11] <lazyPower> plars: i ran into that when working w/ the fan and wanting to fully automate the fan networking setup
[16:14] <plars> lazyPower: I'm not sure I follow... how does a subordinate help unless you've already deployed something to an lxc container on the host?
[16:15] <plars> lazyPower: oh... I think I get it, you deploy everything, then the subordinate gets deployed, modifies the config, and reboots the host (eventually causing all the lxc instances to get restarted)
[16:15] <lazyPower> yep
[16:15] <plars> lazyPower: but is there some way to ensure that it doesn't reboot the host until after the lxc instances are finished deploying?
[16:15] <lazyPower> its not ideal as instances will reach error state, but on reboot they should re-execute and resolve themselves.
[16:15] <plars> ok
[16:16] <lazyPower> there is not, as there's no garantee that no hook is firing
[16:16] <lazyPower> juju-reboot will do its best to stop the containers then reboot the host
[16:16] <plars> lazyPower: I'll give it a try, thanks
[18:26] <Bigdeal> still stuck on the ssl issue
[18:27] <Bigdeal> my juju fesh install cant connect to my openstack private cloud, I get an authentication issue that is due to selfsigned certs
[18:59] <lazyPower> beisner: do you have any experience with openstack and selfsigned certs for auth?
[18:59] <lazyPower> beisner: the user has left, however this seems like good info to have for the future
[19:01] <beisner> lazyPower, i'd have to stand up a new environment to exercise that, in order to be able to t-shoot.
[19:02] <beisner> lazyPower, we'd also want to grab a juju stat, and know which version of OpenStack is deployed, juju version, ubuntu version, all that good stuff.
[19:02]  * beisner has to head out for a bit
[19:42] <thomi> marcoceppi: As per our conversation yesterday: https://bugs.launchpad.net/juju-deployer/+bug/1484260
[19:42] <mup> Bug #1484260: juju-deployer logs ERROR messages during successful deployment from mojo <mojo> <juju-deployer:New> <https://launchpad.net/bugs/1484260>
[20:31] <apuimedo> jamespage: gnuoy: Is there some flakiness with deploying nova-cloud-controller on an lxc container?
[20:31] <apuimedo> I got it failing when establishing the relation with nova-compute
[20:32] <lazyPower> apuimedo: they're UK based and probably not around. Can you hit the list with your findings of flakiness?
[20:32] <apuimedo> ah, that's true
[20:32] <apuimedo> I sometimes forget that people don't live in IRC :P
[20:32]  * lazyPower smirks
[20:32] <apuimedo> lazyPower: how are you?
[20:32] <lazyPower> guilty as charged
[20:33] <lazyPower> apuimedo: doing well, i sent you a follow up this morning about your charms and if there was anything required from me
[20:33] <apuimedo> oh, I didn't see it
[20:33] <apuimedo> let me check my mail filters
[20:33] <lazyPower> no worries :) You're probably not used to me emailing you since we have such an excellent record of IRC contact
[20:33] <apuimedo> oh, that was after I got home
[20:34] <lazyPower> ah yeah, important to specify *my* morning, not morning over in EU
[20:34] <apuimedo> I didn't check my email much since then
[20:34] <apuimedo> gotta entertain the child
[20:34] <apuimedo> :P
[20:34] <lazyPower> :D totally understood
[20:34] <lazyPower> and nothing pressing if you're chugging along well, thats excellent.
[20:34] <lazyPower> just wanted to make sure you're getting the help required
[20:34] <apuimedo> thanks ;-)
[20:35] <lazyPower> np np. I'm here to help
[20:36] <beisner> hi thedac, you may also be interested in checking out bug 1484260.  it's doesn't impact the run itself, but it does raise a brow or two with error noise.  not sure if mojo needs to pass things differently to deployer, or if deployer needs to just like it  ;-)
[20:36] <mup> Bug #1484260: juju-deployer logs ERROR messages during successful deployment from mojo <mojo> <uosci> <juju-deployer:New> <https://launchpad.net/bugs/1484260>
[21:02] <Bigdeal>  my juju fresh install cant connect to my openstack private cloud, I get an authentication issue that is due to selfsigned certs
[21:02] <Bigdeal> Anyone knows how to resolve it?
[21:04] <lazyPower> Bigdeal: i got some feedback from an openstack dev while you were disconnected
[21:05] <lazyPower> Bigdeal: we'd also want to grab a juju stat, and know which version of OpenStack is deployed, juju version, ubuntu version, all that good stuff.
[21:05] <lazyPower> Bigdeal: one of the things we'll need to do is try to reproduce your setup so we can accurately debug and see if we cant find an answer for you. Can you get me  a pastebin with the requested output above that i can forward over to the openstack team?
[21:15] <Bigdeal> lazyPower: We're running HP's Cloud System 8.1
[21:16] <lazyPower> Bigdeal: which version of juju, and which platform? (osx, ubuntu trusty, et-al)
[21:17] <lazyPower> beisner: ^ HP Cloud system 8.1 - i'm not familiar with this setup.
[21:18] <Bigdeal>  lazyPower: The Openstack version is Icehouse
[21:18] <Bigdeal> JUJU on ubuntu trusty
[21:19] <Bigdeal> I basically loaded a VM with Ubuntu 14.04 LTS, then I installed Juju
[21:20] <Bigdeal> then I ran juju-quickstart -i and created a new openstack config
[21:20] <Bigdeal> it fails bootstraping
[21:20] <beisner> hi Bigdeal, do you have debug output from the juju client?   fyi you can add --debug to just about any juju command.    ie.    `juju bootstrap --debug`
[21:21] <beisner> Bigdeal, also, can you paste your ~/.juju/environments.yaml  (remove passwords and other sensitives of course)?
[21:21] <beisner> Bigdeal, @ http://paste.ubuntu.com/
[21:22] <Bigdeal> I will run it again and share the output, when I looked earlier it was an SSL error, I assumed it has to do with the fact that I have self signed certs on my Openstack setup
[21:25] <beisner> Bigdeal, another bit that would be helpful is your `keystone catalog` output (sanitize to your comfort)
[21:25] <beisner> Bigdeal, however, keep in mind that i'm not specifically familiar with the undercloud you're running.  but with that ^ info we may be able to see what's going on.
[21:25] <Bigdeal> http://paste.ubuntu.com/12065817/
[21:26] <Bigdeal> here is the conf http://paste.ubuntu.com/12065827/
[21:27] <lazyPower> Bigdeal: missing object store - i think i found the issue
[21:28] <lazyPower> do you have swift/glance in this stack and have access to create object buckets?
[21:28] <Bigdeal> beisner: We running Openstack wth Vcenters for compute
[21:28] <Bigdeal> we have glance but I am not sure about object buckets
[21:28] <Bigdeal> I am new to openstack/juju
[21:28] <lazyPower> beisner: i may be mis-remembering if glance is an object store.... ally oop me?
[21:29] <lazyPower> Bigdeal: ah glance is the VM Image store, i am mis-remembering. i think it requires swift - there's a hard requirement of juju prior to 1.25 (currently in a highly unstable beta phase) which requires object storage. 1.25 will remove that limitation as i understand it
[21:30] <beisner> lazyPower, having object storage available via either swift or ceph-radosgw for object stores is pretty much a requirement with the juju openstack provider
[21:30] <beisner> er i mean, Bigdeal ^
[21:30] <lazyPower> ^
[21:30] <lazyPower> yeah, thats what I thought when i saw that output is we have found the culprit
[21:30] <beisner> lol
[21:30] <lazyPower> its not so much SSL as it is missing object storage
[21:30] <beisner> yep
[21:30] <lazyPower> juju writes a backup "state" pointer to the object store, which is used if your client .jenv is ever corrupted
[21:30] <lazyPower> so it can rebuild itself
[21:31] <lazyPower> we remove this requirement as it cut out over 1/2 of the cloud providers out there. Apprently this one included - as its missing a key component we are using today.
[21:31] <beisner> Bigdeal, `keystone catalog` would need to show a registered 'object-store' service to indicate that cloud is ready to juju
[21:31] <lazyPower> let me see if i can find the object storage removal bug and link you to that Bigdeal so you can track its progress. If you're fine with using a testing client you might even be able to install juju 1.25 and be an early adopter/driver of this provider code update.
[21:31] <Bigdeal> let me check what I have on that
[21:32] <lazyPower> or i can wait for that first :)
[21:32]  * lazyPower is notorious at putting cart before the horse
[21:32] <lazyPower> beisner: see? this is why i call you in on these projects. Mr big guns over there.
[21:33] <lazyPower> beisner: remind me in DC to buy you all the beer you can consume for being my go to for openstack stuff
[21:33] <beisner> lazyPower, ah thanks sir.   we should gather around beers regardless ;-)
[21:33] <lazyPower> a truer statement hath not been typed in this channel.
[21:33] <Bigdeal> How can I check if I have the object store?
[21:34] <Bigdeal> btw I dont mind being an early adopter, I 'll be happy to contribute
[21:35] <beisner> lazyPower, /me didn't know --object requirement @ ~1.25!
[21:35] <beisner> lol
[21:35] <beisner> xmas in aug
[21:35] <lazyPower> yessir!
[21:35] <lazyPower> Bigdeal: ok let me go dive into the bug tracker and ping some people and see what i can turn up
[21:35] <lazyPower> Bigdeal: it may not be landed in the devel ppa just yet, so there's a bit of digging i need to do before i can promise anything
[21:36] <Bigdeal> Keystone tells me I have cinder object store
[21:36] <beisner> Bigdeal, hrm.  cinder is block storage
[21:37] <Bigdeal> CinderV2 Block Storage Service API
[21:37] <Bigdeal> ok get it
[21:37] <lazyPower> Bigdeal: heres your bug you'll want to track - https://bugs.launchpad.net/juju-core/+bug/1456265
[21:37] <mup> Bug #1456265: Openstack provider should work without object-store <openstack-provider> <juju-core:Fix Committed by axwalk> <https://launchpad.net/bugs/1456265>
[21:37] <Bigdeal> block vs objct sorry
[21:37] <lazyPower> beisner: ^ might want to flag that as well since its fix committed
[21:37] <beisner> Bigdeal, ah ok.  so not object-store available?
[21:38] <beisner> lazyPower, tyvm!
[21:38] <Bigdeal> http://paste.ubuntu.com/12065894/
[21:39] <Bigdeal> That's the keystone service list
[21:40] <beisner> Bigdeal, yep, no object store
[21:40] <lazyPower> Bigdeal: i've got open questions out, and will circle back once i get an answer.
[21:41] <beisner> lazyPower, where is devel pushing packages these days?  https://launchpad.net/~juju/+archive/ubuntu/devel  looks stale
[21:41] <Bigdeal> mhh so what are my options? would it easy enough to setup an object store in openstack (swift?)
[21:41] <lazyPower> ayy, yeah
[21:41] <lazyPower> those are some old bins
[21:41] <beisner> while https://launchpad.net/~juju/+archive/ubuntu/proposed  appears fresh
[21:42] <lazyPower> beisner: that should be where we stage the beta versions. I admittedly have not been on the -devel ppa in a while since i'm building nightlies in docker these days
[21:42] <beisner> lazyPower, Bigdeal - gotta switch into evening, dinner, kiddo mode.  may  check in later this eve, if not, catch you tomorrow.   thank you.
[21:43] <lazyPower> ack beisner, thanks for the last minute checkin
[21:43] <lazyPower> see you in the AM o/
[21:45] <lazyPower> Bigdeal: just got word back that we dont have an update for the -devel ppa yet as core hasn't had a blessed release yet w/ the new features, so its coming but is not trivial to test right this minute.
[21:45] <Bigdeal> lazypower: Thanks a lot for your help
[21:46] <Bigdeal> in the meantime I will try to setup swift
[21:47] <lazyPower> Best of luck Bigdeal. If you encounter any further questions feel free to ask and someone will be with you shortly. Sorry I didn't have a quick answer for you to get moving right away today, but we're actively working on it :)
[21:49] <Bigdeal> Thank a lot I will keep trying this evening and get back to you tomorow
[21:54] <lazyPower> Cheers Bigdeal
[21:54] <lp|conference-mo> aww my -mode got nuked


[08:06] <ultrav1olet> anyone alive here?
[08:06] <ultrav1olet> can anyone help me with Fedora 13 upstart? I have changed tty.conf to this: http://pastebin.ca/1858626 but no mingetty ever starts
[08:06] <ultrav1olet> Is "\" supported for breaking the lines into two?
[08:18] <plautrba> ultrav1olet: you need to have line 9 and 10 inside script ... end script
[08:19] <ultrav1olet> plautrba: in Fedora 13 this file is started by another file
[08:20] <JanC> "Line breaks within a stanza are permitted within single or double quotes, or if preceeded by a blackslash." (from the manual)
[08:20] <ultrav1olet> JanC: so, my file is OK?
[08:20] <JanC> no
[08:21] <plautrba> ultrav1olet: you cannot use just '[ "$tty" = "tty1" ]', it has to be in 'script' stanza
[08:21] <ultrav1olet> plautrba: I got it
[08:22] <ultrav1olet> so script/end script denotes bash section? :)
[08:23] <plautrba> it's executed as '/bin/sh -e -c <content of script stanza>'
[08:34] <JanC> certainly not *bash* section
[11:29] <caolanm> it seems like "start on startup" fires before my home partition is mounted in lucid, should I be waiting for some other event?
[11:29] <Keybuk> start on filesystem
[11:42] <caolanm> Keybuk: it still doesn't seem to find anything on other partitions than root (I also have encryption turned on for /home if that makes a difference)
[11:42] <Keybuk> filesystem only happens after everything in /etc/fstab is mounted
[11:42] <Keybuk> (and root is r/w)
[11:43] <caolanm> hmm
[11:44] <caolanm> the works fine if run manually once the machine has booted, but can't seem to find files when run during boot.... what is the latest possible stage in the boot process I could run a job?
[11:51] <Keybuk> caolanm: shutdown? :-)
[11:51] <Keybuk> "filesystem" is generally the last significant event
[11:51] <Keybuk> everything after that is services
[11:52] <caolanm> heh
[11:52] <caolanm> ok
[11:52] <caolanm> this is seriously confusing then
[13:29] <caolanm> Keybuk: hey, sorry to keep bugging you on this, but I'm pretty sure its related to mounting /home... if I move it to /opt (on the root partition) it works!
[13:30] <Keybuk> /home isn't boot essential in Ubuntu
[13:30] <caolanm> ah I see
[13:30] <Keybuk> add "bootwait" to the options for it in /etc/fstab
[13:31] <caolanm> I saw a bug related to that in karmic, stopping the computer from booting
[13:31] <caolanm> any idea if that was fixed for lucid? ...I'm working on a remote machine and don't want it to go down :\
[13:32] <caolanm> well, I can risk it I suppose :)
[13:34] <Keybuk> it's deliberate
[13:34] <Keybuk> lucid still won't wait for /home
[13:36]  * caolanm crosses fingers
[13:38] <caolanm> damn, it didn't come back up
[13:38] <caolanm> Keybuk: thanks for your help, I have a much better idea of what to look into now!
[20:20] <bencc> can upstart rotate logs?
[20:21] <bencc> I'm using ubuntu lucid
[20:22] <sadmac> bencc: no. You need logrotate or what have you (though upstart can certainly /run/ that program)
[21:09] <bencc> sadmac: it'll be cool if I could define it as part of my upstart script


[04:48] <benkillin> I fully expect kostkon to get +q as well
[04:48] <benkillin> 00:34:18        kostkon | benkillin, 53 % 28 =  ?    you've got 2 secs
[04:48] <benkillin> 00:34:33        kostkon | benkillin, you failed
[04:48] <benkillin> because that is obviously clutter
[04:48] <Jordan_U> benkillin: koston was not a continuing problem. You were.
[04:49] <benkillin> and that problem is what?
[04:49] <benkillin> chatting in an IRC channel does not prevent anybody from getting help
[04:50] <Jordan_U> benkillin: Now that we have gotten past the whole "who is cluttering the channel" argument by moving the discussion here, are you willing to follow the guidelines in #ubuntu in the future?
[04:50] <benkillin> please re-link those guidelines
[04:50] <Jordan_U> benkillin: http://wiki.ubuntu.com/IRC/Guidelines
[04:52] <benkillin> including the code of conduct, the only guideline on that page I violated was "being annoying"
[04:52] <benkillin> which can obviously be subjectively extended to kostkon
[04:53] <benkillin> so if you do not say something to him I have no desire to ever help your project again on irc
[04:53] <benkillin> and just so you know I have over 13 years of experience with linux and I started with ubuntu in 2006
[04:53] <Jordan_U> benkillin: "Recommendations from channel operators, including those stored in the channel bots, should be followed."
[04:54] <benkillin> you are not designated as a channel operator in that channel
[04:54] <benkillin> channel operators have +o
[04:54] <Jordan_U> benkillin: True.
[04:54] <Jordan_U> !ot
[04:54] <benkillin> so if you desire to purport yourself as a channel operator, keep +o all the time
[04:55] <Jordan_U> Clearly that was not the factoid I was expecting.
[04:55]  * rww giggles
[04:56] <rww> !offtopic
[04:56] <Jordan_U> benkillin: I personally think that requests from all users should be considered respecfully, but indeed that is not in the guidelines literal text. But, now that you know that it is official policy of #ubuntu not to make offtopic comments, do you agree to follow that policy in the future?
[04:57] <benkillin> I agree, however I will no longer participate in your project
[04:58] <benkillin> volunteering to help people on the internet should not require this sort of bullshit
[04:58] <benkillin> I deal with enough of that all day long
[05:03] <Jordan_U> That portion of the channel guidelines, follow recommendations from ops, does indeed grate against the idea of "catalizing". We're somewhat trying to have it both ways. And using bot triggers to get around that with the letter of the guidelines is clearly suboptimal, and also often not the best way to catalize.
[05:55] <elky> catalyzing is a romantic notion to begin with.
[05:56] <elky> catalyzing is also not "compromise"
[05:56] <elky> if you have to let someone misbehave to compromise between removing their disruptiveness, there's something wrong
[07:39] <one> request for unban
[07:40] <one> jtrucks request for unban
[07:40] <one> Corey send it through
[07:44] <one> yano unban
[13:48] <DJones> @mark #ubuntu jkale/Agd_Scorp trolling, ban tracker flags up as syko
[13:49] <cfhowlett> DJones, that was random.  enters channel, fbombs and calls ops on himself ...
[13:51] <h00k> what is this, I don't even
[14:26] <k1l> syko :(
[15:03] <cprofitt> hello all
[15:03] <cfhowlett> cprofitt, greetings
[19:22] <jobarte_skuld> oper of #ubuntu-br here?
[19:23] <Unit193> Loco channel OPs are in #ubuntu-irc generally.
[19:42] <Unit193> jobarte_skuld: Been taken care of, was there anything else you needed?
[23:24] <Cheekio> Is a quiet a permanent thing, or a temp thing?
[23:29] <Jordan_U> Cheekio: It's something that you can get resolved by talking with us here. Welcome :)
[23:30] <Cheekio> Anyone else?
[23:30] <Jordan_U> Cheekio: We have certain guidelines in #ubuntu that we ask our users to follow.
[23:30] <Jordan_U> !guidelines | Cheekio
[23:31] <Jordan_U> Cheekio: Please take a moment to read them and tell me when you're done.
[23:32] <Cheekio> Is it not considered rude to ping a bot at someone instead of addressing them directly?
[23:32] <knome> Cheekio, the guidelines are at http://wiki.ubuntu.com/IRC/Guidelines
[23:33] <Cheekio> Reading it now, knome
[23:34] <Cheekio> Thanks for the link and being respectful.
[23:35] <Cheekio> Pretty solid Ts & Cs
[23:36] <Cheekio> I don't see how I violated any of these rules
[23:36] <Cheekio> I do, however, see that Jordan has violated the very first rule of being kind, respectful, and cooperative.
[23:38] <Jordan_U> Cheekio: I apologise for short responses, I'm trying to give 3 people support at once while talking to you. No disrespect was intended.
[23:40] <Jordan_U> Cheekio: You were asked to stop your offtopic discussion in #ubuntu, yet continued anyway.
[23:42] <one> unban one for helping others help
[23:43] <rww> one: where have you been helping others help?
[23:43] <one> for for
[23:43] <one> fore rww
[23:43] <rww> one: hrm?
[23:44] <rww> oh, you want me to unban you so that you can help others?
[23:44] <one> I can send it forward.
[23:45] <one> some have capabilities to help
[23:45] <rww> one: what is your normal language?
[23:46] <one> what sense of normal?
[23:46] <rww> one: the one that you speak most of the time and are best at
[23:46] <one> well yes
[23:47] <Jordan_U> Cheekio: Have you finished reading the channel guidelines, and if so, do you agree to follow them in the future?
[23:50] <one> I should help
[23:50] <rww> one: you should answer my question :)
[23:51] <one> what is is, you went from future to past
[23:51] <one> now is the time to help
[23:52] <rww> now is the time to give me confidence that if i let you back in #ubuntu you won't cause a mess again
[23:53] <one> just going to watch for 24h worth of clock cycles to assess strategems for help
[23:53] <rww> !1984
[23:53] <rww> feel free to read those ^ instead and come back here when you have such strategems. I'd be interested to hear them.
[23:54] <one> What are LoCo channels?
[23:54] <Cheekio> @Jordan: I agree
[23:55] <rww> LoCos are local community teams, but that's not important right now
[23:55] <one> now you are pointing to the past again
[23:56] <one> 24h of current is more important than logs of the past
[23:56] <rww> Thankfully, you can access 24h of current in 24h, using the log site.
[23:56] <rww> Anything else we can help you with today?
[23:57] <Jordan_U> Cheekio: Great, thank you. You are no longer quited in #ubuntu.


[11:06] <sergiusens> Elleo: hey there, any workaround to cancel downloads for LP: #1654153 ?
[11:49] <Elleo> sergiusens: hadn't seen that before, will look into it when I've got a bit of time
[14:17] <yang> Any ETA on the next Ubuntu touch tablet after Aquaris M10 ?
[14:48] <thrasos> hello
[14:49] <thrasos> does anyone run touch on Sony Xperia?
[15:06] <OerHeks> thrasos, Z1 ? http://www.omgubuntu.co.uk/2016/02/ubuntu-phone-sony-xperia-oneplus-one
[15:08] <thrasos> OerHeks, m4 aqua
[15:09] <OerHeks> not in the list > https://wiki.ubuntu.com/Touch/Devices#Working_ports.2C_but_w.2Fo_system-image_server
[15:12] <thrasos> i see
[16:20] <mterry> tedg_: OK, jdstrand doesn't like the existing snap appid format -- wants UAL to use what snappy does (snap.NAME_COMMAND) rather than NAME_COMMAND_REVISION -- any objection to me whipping up a branch to do that? Are there issues in such a migration?
[16:24] <tedg_> mterry: Uhm, where is he concerned about it?
[16:24] <tedg_> We also really need the revision in there.
[16:25] <mterry> tedg_: https://github.com/snapcore/snapd/pull/2787#discussion_r101558251
[16:26] <tedg_> jdstrand: It's *everywhere* and very few people use the helper classes, so we couldn't change it in one place.
[16:27] <tedg_> jdstrand: Also, how does snapd guarantee that there aren't two revisions of a snap being run? There are three versions installed...
[16:27] <tedg_> jdstrand: There's only one if I say "right now what is the revision" but the app could be running while it is upgraded and would continue to run.
[16:30] <jdstrand> tedg_: snapd does manager that. please note, you and I won't solve this here unless you conform to snapd's snap name as I advised. anything short of that will need niemeyer and tvoss
[16:30] <jdstrand> manage*
[16:31] <tedg_> jdstrand: Okay, how does snapd manage that? Open files?
[16:31] <jdstrand> tedg_: it would continue to run, but that is a problem area that UAL could actually help with. you may have the revision all pretty, but the policy changed out from under it and it failed
[16:31] <jdstrand> fails
[16:31] <tedg_> jdstrand: Uhm, that would really suck?
[16:32] <jdstrand> there are open bugs on that. I don't think UAL should be trying to work around this because the snap won't run right anyway
[16:32] <jdstrand> tedg_: it does suck. ual could perhaps notice this and guide the user to restart (or restart automatically
[16:33] <jdstrand> iirc, android restarts apps. I'm not sure how well we could manage that. simple is tearing down all state and starting anew, but that isn't great for open files
[16:34] <jdstrand> so perhaps guiding the user to restart is the way to go (that said, depending on the file, it may not be saveable in the old location)
[16:35] <tedg_> Well it depends on if the application has lifecycle support, which things like X11 apps don't have.
[16:35] <tedg_> So we could handle it in *some* situations, but we can't kill apps.
[16:35] <tedg_> I mean, seriously, we lose someone's life's work in an editor because of an upgrade...
[16:36] <jdstrand> yes. let me get the bug
[16:36] <tedg_> There was no bug fix worth that.
[16:36] <tedg_> And, to be more clear, this is why we have revision in the appid :-)
[16:37] <jdstrand> tedg_: https://bugs.launchpad.net/snappy/+bug/1616650
[16:38] <tedg_> So to be clear, I think that changing from "_" to "." would be a PITA and cause bugs, but I don't really *care* as much as I'd like to avoid it. But I think dropping revision would cause real problems.
[16:38] <jdstrand> tedg_: some people use SNAP_USER_COMMON for everything to help
[16:38] <jdstrand> I don't think that is great
[16:39] <tedg_> I think that USER_COMMON would be used for user data.
[16:39] <tedg_> And then USER_DATA should be anything like caches and such.
[16:39] <jdstrand> there are other solutions-- we could make all revisions writable instead of only the current revision. that was NAKd in the past, but perhaps a new argument could revisit that
[16:40] <tedg_> Well, it seems like the lazy unmounting fixes part of the problem, as the files will still be there.
[16:40] <tedg_> It seems like we just need the apparmor policy to have the revision in it.
[16:40] <tedg_> And to make sure we have apparmor policy for every revision mounted.
[16:41] <jdstrand> tedg_: yeah, that is what people are doing I think, though, even with caches that is problematic cause you might have the dir location saved in memory and you just got there (as opposed to reevaluating SNAP_USER_DATA on every open)
[16:42] <jdstrand> tedg_: adding apparmor policy files for each revision could also work. that was NAKd and would have to be revisited
[16:42] <tedg_> jdstrand: Was it NAKd just for cleanliness?
[16:42] <jdstrand> tedg_: adjust the policy to not be revision specific is easy
[16:43] <jdstrand> tedg_: well, it is cleaner, sure, but it reduces a lot of complexity in nearly every way
[16:43] <tedg_> jdstrand: Well, it'll always be revision specific just because each revision could have different interfaces.
[16:44] <jdstrand> tedg_: you misunderatnd. I mean the default template could use .../@{SNAP_NAME}/** w, instead of .../@{SNAP_NAME}/@{SNAP_REVISION}/** w,
[16:44] <jdstrand> that way you can still write to your open files. it breaks if you had 'home' (or something) in one and then don't in the new revision
[16:44] <tedg_> jdstrand: Sure, I'm just saying that all the other stuff like networking might be in one revision but not the other.
[16:44] <tedg_> jdstrand: So if the wrong policy gets used the app would break.
[16:45] <jdstrand> it's a tricky prospect and needs design
[16:45] <tedg_> There is the case of files in the home directory as well, but lots of other stuff too.
[16:45] <jdstrand> it is also more than apparmor. seccomp is only done on app launch and not reloaded and applied at runtime
[16:46] <tedg_> Well, if we're worried about running apps, that works :-)
[16:46] <jdstrand> again, I'd love to see this fixed, but need to have the right people involved. everything said so far has been discussed and decided already
[16:46] <tedg_> jdstrand: So if my app, foo is running and a new version gets install that doesn't have the home interface. Does the running instance still have access?
[16:51] <jdstrand> tedg_: no
[16:51] <jdstrand> there is one profile. period
[16:51] <jdstrand> it gets reloaded
[16:51] <jdstrand> and the app has to deal
[16:51] <jdstrand> it would be possible to move the reload to snap-confine
[16:52] <jdstrand> ie, refresh updates the file on disk, and even generate the cache, but doesn't load it into the kernel
[16:52] <jdstrand> snap-confine could then be made to apparmor_parser -r it to load it into the kernel
[16:52] <jdstrand> this is something else that would need to be discussed and ACKd by an architect
[16:53] <jdstrand> this is probably only cli and not 'daemon' behavior. daemons are restarted so they don't suffer the same issues
[16:54] <jdstrand> so this adds complexity and the possibility of never loading the right profile
[16:56] <studio_> hi again ...
[17:01] <studio_> dobey, the bq e4.5 kernel 3.10.54 is public (https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5_2.x) . why isn't it used for the ubuntu-touch? Why it never was patched for UT?
[17:02] <jdstrand> tedg_: on the one hand, having apparmor_parser called be snap-confine for non-daemon commands fixes a number of issues, but we would want to be smart to not add another exec needlessly so as not to impact performance (eg, imagine a command that is called over and over again). that is where the complexity comes in
[17:02] <jdstrand> called by*
[17:02] <jdstrand> anyway, need to get the right people involved
[17:06] <tedg_> jdstrand: Sorry, my dad stopped by. Reading now.
[17:07] <studio_> what is the latest kernel for the latest "official" ubuntu-touch device?
[17:08] <tedg_> jdstrand: So I think we should file a bug about it, I don't think that bug 1616650 is the right place because that's more about file access. Thinking something about apparmor profiles makes more sense.
[17:09] <jdstrand> tedg_: well, the title is vague enough for really anything :P
[17:09] <jdstrand> 'may cause issues', hehe
[17:10] <tedg_> Don't use refresh on nuclear submarines ;-)
[17:12] <studio_> is there any info about latest kernels and "official" ubuntu-touch devices? If yes, where?
[17:14] <tedg_> jdstrand: So, in the meantime, can we stick with the appid format we have for starting to land the unity8 interface stuff?
[17:15] <tedg_> jdstrand: It seems like snapd shouldn't *really* care what things built on top of it do.
[17:15] <tedg_> jdstrand: It'd be nice to make it consistent, but shouldn't really matter. Other desktops are likely to invent their own identifiers as well.
[17:18] <jdstrand> tedg_: snapd shouldn't care, no, but you're contorting snapd mechanisms that will lead to confusion and that is impacting snapd code and security policy
[17:18] <jdstrand> tedg_: so it is a bit different
[17:18] <jdstrand> tedg_: if you want to change it, you need niemeyer and tvoss involved
[17:18] <studio_> brunch875, are you still there?
[17:18] <brunch875> studio_, always available for you!
[17:19] <tedg_> jdstrand: I guess I don't understand how we're impacting snapd code or policy in this case. I consider the unity8 interface a "unity8 thing" not a "snapd thing".
[17:20] <studio_> do you have any idea (before i get kicked again from this channel)?
[17:20] <jdstrand> tedg_: I'm talking from snapd's perspective, sorry. if you want snapd to have some notion of old-world AppIDs, that needs niemeyer and tvoss' involvement. I see problems there
[17:20] <tedg_> jdstrand: I do *want* that, but I'm willing to move forward without it and realize that is a bigger change. But my immediate concern is getting a working unity8 interface.
[17:21] <jdstrand> tedg_: please read my comment in the PR and feel free to coordinate a discussion on it. I'm sorry, I'm trying to honor the snappy way
[17:21] <brunch875> studio_, you mean, you wish to buy a new ubuntu phone with a recent kernel?
[17:21] <brunch875> studio_, I have my eye put on the fairphone 2, I believe it will be released soon
[17:22] <brunch875> it's not something canonical is pulling out officially, but it looks promising from a kernel perspective
[17:22] <studio_> brunch875, no, i do not understand why the new kernel was not patched for UT.
[17:22] <jdstrand> tedg_: I would accept a patch that stripped all of the old-wold AppID and had a DBus path glog rule with a TODO to unblock the interface. the interface is restricted in who can use it now, so that's fine
[17:22] <jdstrand> glob*
[17:22] <brunch875> studio_, that is the work of the phone manufacturer, there's little ubuntu can do
[17:23] <studio_> brunch875, the kernel was allways patched by Canonical, wasn't it?
[17:24] <tedg_> jdstrand: Okay, I think that makes sense to move forward until we can have the bigger conversation.
[17:24] <tedg_> mterry: ^
[17:25] <brunch875> studio_, Allow me to explain: phones are a bit different from computers. When you buy an android phone, it comes bundled with a specific kernel to control things such as the camera. When installing ubuntu, you put it on top of that.
[17:25] <studio_> https://github.com/bq/aquaris-E4.5/tree/aquaris-E4.5-ubuntu-master committed with john-mcaleely
[17:26] <brunch875> studio_, this more or less explains why you won't be seeing ubuntu touch installed on an iphone
[17:26] <studio_>  john-mcaleely is a member from Canonical, right?
[17:26] <OerHeks> studio_, again? dobey / popey answered that already, what answer satisfies you?
[17:27] <studio_> no, on no way. why was the first kernel modyfied by john-mcaleely and the second not?
[17:30] <brunch875> studio_, the short, simple question is stuff like the camera would stop working if the newest kernel was used
[17:31] <brunch875> or that's what I know with my little knowledge :p
[17:32] <studio_> brunch875, where did you get this info from?
[17:32] <studio_> info
[17:34] <brunch875> just a moment
[17:34] <tedg_> jdstrand: mterry: Okay, commented on the PR.
[17:35] <mterry> tedg_, jdstrand: I can do a glob rule to unblock, sure
[17:35] <brunch875> studio_, have a look at this picture: https://developer.ubuntu.com/static/devportal_uploaded/136981fa-6287-49d3-9874-06f40b2e4eb7-cms_page_media/380/ubuntu_touch_architecture.png
[17:35] <jdstrand> ok, cool
[17:36] <brunch875> studio_, the blue stuff is what the phone manufacturer has created, and it is "secret". Ubuntu cannot change that part
[17:36] <brunch875> studio_, the blue stuff was build for a specific kernel version. If you change the kernel version, the blue stuff stops working
[17:37] <brunch875> How would you do this then? Well, the manufacturer of the phone (which isn't ubuntu) has to change the blue pieces to work for a newer kernel
[17:38] <brunch875> That is why I mentioned the fairphone before; the fairphone manufacturers are a lot less secretive about the blue parts and so anyone can work on those :)
[17:38] <brunch875> and so upgrading the kernel is possible
[17:38] <studio_> brunch875, but that's for 14.04, wasn't it?
[17:38] <brunch875> that is for any ubuntu version, sadly :(
[17:39] <brunch875> ubuntu 15.10 is still just the orange part
[17:39] <brunch875> you need to change the blue part for a linux kernel upgrade
[17:39] <brunch875> and the manufacturer keeps that fixed, ubuntu can only change the orange things
[17:40] <studio_> so, "to port a new device" will never work for a new kernel, exp. krillin?
[17:41] <brunch875> yes, unless you find a manufacturer which helps with the blue parts
[17:41] <brunch875> if you change the blue section, you can use a newer kernel
[17:42] <studio_> so how can it be possible to port a new device?
[17:42] <brunch875> when you port a new device, you write the orange things
[17:42] <brunch875> but you cannot change the blue parts
[17:43] <brunch875> and this isn't just with ubuntu, it also happens if you try to write a new android
[17:43] <brunch875> or cyanogenmod
[17:43] <mterry> tedg_: did you file a bug?
[17:44] <brunch875> to change the blue parts, you need colaboration with the phone manufacturer.
[17:44] <tedg_> mterry: Trying to figure out how to phrase it...
[17:45] <mterry> tedg_: understood  :)   ping me when you have one so I can add to source comment
[17:55] <studio_> brunch875, what kernel is the fairphone 2 using?
[17:57] <brunch875> studio_, it hasn't been released yet, I do not know. But fairphone 2 has a lot more control over the drivers of the device which means upgrading the kernel should be no troubles
[17:57] <brunch875> In other words, probably the latest, all the time
[17:58] <brunch875> or at least that is what I hope!
[17:59] <brunch875> I also heard it is possible to install ubuntu touch on the fairphone 2
[17:59] <studio_> hmm, my Rasperry PI's are using 4.9.9+
[18:00] <popey> 17:26 < studio_>  john-mcaleely is a member from Canonical, right?
[18:00] <popey> was, isn't anymore
[18:00] <studio_> would be nice if there is same support for phone manufacors
[18:01] <brunch875> studio_, yes, we would all love if the phone manufacturers were more open
[18:02] <popey> studio_: the fairphone 2 port is a community maintained one. You're better off asking the UBPorts people as they did it.
[18:02] <studio_> in the moment i and some more feel "pranked" from the phone industry
[18:02] <brunch875> studio_, yes, the phone industry is :[
[18:03] <dobey> jfc
[18:05] <dobey> stop asking the same thing over and over and over
[18:06] <dobey> but yes, it would be nice if phone and chip manufacturers would open source the drivers and specs for their hardware
[18:06] <studio_> but, is there a different to canonical? Because, they tell they are open source, but where to find the sources?
[18:06] <brunch875> studio_, canonical would have to create the blue part
[18:06] <dobey> all of the drivers are not open source
[18:07] <brunch875> which means canonical would have to manufacture the phone
[18:07] <brunch875> there was a project called edge, but it failed
[18:08] <ogra_> well ... even if it had not failed ... it isntactually the *phone* manufaturers, but the *chip* manufacturers
[18:08] <studio_> brunch875, where can i find the latest kernel patches for the bq e4.5?
[18:08] <brunch875> studio_, they do not exist :)
[18:08] <popey> studio_: for what kernel version?
[18:08] <ogra_> so even the edge would likely have had to use closed bits because you wont find open drivers anywhere for certain sensors and chips a phone needs
[18:08] <studio_> hmm, i can see the kernel config on my phone
[18:09] <brunch875> ogra_, does this mean not even the fairphone can pull this stunt?
[18:09] <ogra_> brunch875, right
[18:09] <dobey> the tree for the kernel for the e4.5 was published on github
[18:09]  * brunch875 crawls to a corner to cry
[18:09] <ogra_> there is no open modem chop
[18:09] <ogra_> *chip
[18:09] <ogra_> for example
[18:10] <ogra_> so if you want your phone to be able to make calls ... you have to use a closed driver
[18:10] <ogra_> and the modem chip manufacturers have no reason to change that
[18:10] <studio_> dobey, but it was never patched for 3.10.54
[18:10] <ogra_> same goes for most GPS chips ... sensors ... etc
[18:11] <popey> studio_: correct, it's 3.4 isnt it?
[18:11] <dobey> well, it takes a concerted effort, and involving companies with enough market capitalization, to change that
[18:11] <dobey> studio_: no e4.5 ever shipped with ubuntu and the 3.10 kernel
[18:12] <studio_> popey, 3.4. xx, yes but also never patched to the latest kernel
[18:12]  * k1l_ thinks we already had the solution, that studio_ will pay the chip makers to hand out the  driver sources
[18:12] <ogra_> +1
[18:12] <popey> studio_: right, you know the answer, so stop asking
[18:13] <ogra_> k1l_, i like your pragmatism :)
[18:13] <brunch875> studio_, you need to convince the chip makers to give us drivers
[18:13] <brunch875> you're our only hope
[18:13] <brunch875> if ubuntu gets open drivers, we can patch the kernel!
[18:14] <dobey> brunch875: i think you're only making things more confusing
[18:14] <dobey> drivers being opened or closed is irrelevant to "patching the kernel"
[18:14] <studio_> brunch875, the conversation with you was constructive, as you can see, some people here are not so constructive ... :(
[18:15] <brunch875> dobey, that's true. I'm just painting really bold strokes :p
[18:16] <k1l_> mediatek doesnt have the best reputation for helping with drivers.
[18:16] <brunch875> studio_, I'm glad you see it can't be done until the chip manufacturers stop cheating us :[
[18:17] <dobey> studio_: true. you are very non-constructive
[18:17] <studio_> dobey, you are the best :)
[18:18] <dobey> if you want a newer kernel on your phone, then have at it. nobody stopping you from doing all the work. go hack at it to your hearts content
[18:20] <studio_> dobey, the problem is the phone-update-software from canonical, it do not understand, that the phone is using a newer kernel.
[18:20] <dobey> it doesn't care
[18:20] <ogra_> why would it
[18:20] <studio_> that's the problem
[18:20] <dobey> no it isn't
[18:20] <ogra_> it just unpacks tarballs
[18:20] <ogra_> no matter what is inside
[18:21] <dobey> set up your own system-image server and build your own device tarballs
[18:21] <dobey> nobody stopping you
[18:21] <ogra_> and put in whatever kernel you like
[18:22] <ogra_> or talk to the guys in #ubports on how to sideload your own kernel without a system-image server
[18:22] <studio_> you are ignorants, sorry
[18:22] <ogra_> they do that all the time when porting
[18:22] <dobey> studio_: goodbye then
[18:23] <studio_> dobey, feel free to leave
[18:23] <ogra_> studio_, you are claiming nonsense ... and we are ignorants ? the upgrade mechanism has absolutely nothing to do with the kernel version ..
[18:23] <ogra_> just roll your own and be happy with it
[18:23] <dobey> k1l_: ^^ i guess he isn't learning :(
[18:23] <k1l_> studio_: the point is: you are still demanding things that cant be done officially from canonical.
[18:23] <ogra_> as i said above, the guys in #ubports can tell you how to install it
[18:24] <studio_> ogra_, do you have any static how my users, with official UT-Devices, are happy with their devices?
[18:25] <k1l_> studio_: that has been told to you very very very often. you are free to change kernels and stuff as you want. but demanding it from ubuntu to do the work for you doesnt work. this will never change, so better forget about that "solution" and start thinking of doing that work yourself or create a team who does that.
[18:25] <studio_> many
[18:26] <studio_> k1l_, could you please constructive? before you kick somebody?
[18:28] <k1l_> studio_: its constructive. this has been answered several times to you. and the answer will not change, no matter how often you keep asking it or how much pressure you try to make with insulting others.
[18:28] <dobey> studio_: as has been said a thousand times over, it is your attitude that it is the problem here. you keep asking the same things repeatedly, because you don't like the answers, you resort to insults, and you are demanding people build things how you want them.
[18:30] <studio_> again, do you have a current statistic about users who are satisfied with their UT-Device?
[18:31]  * ogra_ is pretty happy with his device
[18:31] <studio_> and i do not mean the developers only
[18:31] <k1l_> studio_: in a perfect world everyone would be happy to ship the latest kernel on open source ubuntu smartphones, that are dead cheap or even for free. but this is not the perfect world we live in. the technical issue have been explained in detail to you. there is no news on that and there wont be any. so there is no need on demanding things, either be happy as it is, or argue with the chipmakers to give you the driver sources or try to port another
[18:31] <ogra_> it makes calls, plays music, is usable as desktop ... etc etc
[18:31] <brunch875> I am also very happy with the e4.5!
[18:31] <k1l_> kernel on your own.
[18:31] <dobey> studio_: such a statistic is irrelevant. it's purely something you want to use as some sort of evidence to claim you are somehow right, and continue to insult ubuntu
[18:31] <ogra_> studio_, ?? its a developer device ...
[18:32] <dobey> studio_: if you don't like ubuntu, don't use it, and leave us alone
[18:32] <brunch875> studio_, you could try to flash android, but you'd still have the same kernel version problem
[18:33] <brunch875> this isn't an ubuntu thing, it can't be done
[18:33] <studio_> ogra_, what i am missing on your "etc", it can't handle video-calls nor sip-calls
[18:34] <ogra_> my hangouts definitely work ... i dont use SIP though
[18:34] <ogra_> my phone 100% fulfills my needs
[18:35] <studio_> ogra_, you are an developer, not a user
[18:35] <ogra_> using a device for developers
[18:35] <ogra_> nt for endusers
[18:35] <ogra_> so yeah ... 100% match i'd say
[18:35] <studio_> nt=nice try?
[18:36] <ogra_> *not
[18:38] <dobey> brunch875: well, you can get 3.10 with android apparently, but it's still only 3.10, and there's no specific noted advantage to having the newer kernel on that device
[18:38] <studio_> brunch875, sorry, i missed you answer, for the bq E4.5 you can try Lineage OS: http://www.htcmania.com/showthread.php?t=1162844
[18:38] <ogra_> happy trying then
[18:38] <ogra_> switch over any be happy
[18:39] <studio_> or the beta: http://www.htcmania.com/showthread.php?t=1279437
[18:40] <studio_> ogra_, the problem is, they can't handle sip calls as the 5.0 can do
[18:40] <dobey> now you're just spamming
[18:41] <ogra_> they ?
[18:41] <studio_> 6.x an 7.x
[18:41] <ogra_> who do you talk about ?
[18:41] <dobey> he's talking about android
[18:41] <dobey> this is not #android dear studio_
[18:41] <dobey> nor is it #lineageos
[18:41] <ogra_> ah
[18:42] <dobey> i'm pretty sure sip calls work fine there though
[18:42] <ogra_> i thought he meant people using ubuntu ...
[18:42] <dobey> well, at least, it worked fine on cyanogenmod 13 which is android 6
[18:42] <dobey> well, of course sip calls don't work in ubuntu. our dialer doesn't have sip support yet
[18:43] <studio_> yet ?
[18:43] <studio_> it never had
[18:43] <dobey> nobody said it ever did have
[18:44] <ogra_> nobody claimed it ever had
[18:44] <dobey> that is not what "yet" means
[18:44] <dobey>  it means it's certainly plausible/possible that a future version could have it
[18:44] <popey> mcphail: nice timing
[18:45] <dobey> especially if people were submitting patches to help get it enabled
[18:45] <mcphail> popey: ?
[18:45] <dobey> mcphail: your favorite cheek pinching puppet is here
[18:45] <studio_> so why the UT-Phone can't server basics like video- or sip-calls?
[18:45] <popey> studio_: because nobody has written that code yet
[18:45] <ogra_> basics ?
[18:45] <dobey> it can
[18:46] <mcphail> :) hi studio_ ! how's things?
[18:46] <dobey> google hangouts works
[18:46] <dobey> you can install other video/voice chat things and they will work
[18:46] <dobey> or should work
[18:46] <studio_> popey, don't you thing it's time for that?
[18:46] <ogra_> send patches
[18:46] <k1l_> studio_: its not basics to everyone. just because you demand it doesnt make it basics for erveryone. that is one of your misconceptions
[18:47] <ogra_> sourcs is on launchpad
[18:47] <ogra_> *source
[18:47] <dobey> migh have to crack open this tequila aged beer sooner than i thought
[18:47] <popey> studio_: no, i don't. I think the investment isn't worth it for the number of devices out there
[18:47] <ogra_> dobey, cheers
[18:47] <popey> studio_: if we had more devices in the pipeline, then maybe, yes.
[18:47]  * ogra_ looks for the glenvilet
[18:47] <dobey> mmmm
[18:48] <ogra_> ah, only glenmorangie
[18:48] <dobey> also mmmm
[18:48] <studio_> k1l_, video and sip calls are basics since a long time, do you remember NOKIA?
[18:48]  * popey is not allowed any, doctors orders
[18:48]  * dobey goes to make a sip video call on his 3310
[18:48] <k1l_> studio_: you mean that company that went bust?
[18:49] <dobey> i don't think any of my nokia phones support sip/video calls natively
[18:49] <dobey> nor do my samsung phones
[18:50] <dobey> not sure that my htc does either
[18:50] <studio_> dobey, maybe a problem from your telcom
[18:50] <popey> last nokia i had was 10 years ago and it didn't do vidoe calling or sip out of the box
[18:50] <dobey> studio_: no, it's nothing to do with the provider
[18:51] <studio_> popey, never ied an e-series or n-series?
[18:51] <dobey> first phone i had that did sip was probably my pre
[18:51] <dobey> anyway
[18:51] <dobey> again, has nothing to do with ubuntu
[18:51] <popey> actually maybe it did, I never used it though
[18:51] <popey> n82
[18:52] <studio_> dobey, "ubuntu" can do sip calls
[18:52] <dobey> studio_: if you think a specific feature needs to be implemented in ubuntu, i'm sure you can contact canonical sales and offer to contract them to implement the feature you desire
[18:53] <studio_> as i said, "ubuntu" can do calls via sip
[18:53] <brunch875> that sounds like a fantastic idea
[18:53] <dobey> build a phone and contract canonical to provide ubuntu for it
[18:53] <dobey> studio_: then you don't have a problem. so stop whining
[18:56] <popey> ogra_: saw this and thought of you https://plus.google.com/u/0/+TerryMcNeil/posts/SgDQdUUbyPn
[18:56] <OerHeks> One option that i miss, is Cell-broadcast. ( message in case of local emergency)
[18:56] <studio_> dobey, sorry, please let me whining, i am the only person who is whining since you have no statistic about users who satisfied with th UT-Device ;)
[18:57] <brunch875> studio_, :(
[18:57] <studio_> brunch875, come on, let me joke a little bit ;)
[18:58] <brunch875> popey, right now I have a conflict of hunger, laughter and facepalm
[18:58] <OerHeks> shoot the troll, i am hungry too!
[19:00] <brunch875> this calls for returning home to fill my abdomen
[19:01] <dobey> studio_: i think you missed the memo, but jokes are humorous, not slanderous.
[19:07] <studio_> dobey, as i wrote, you and other missed something. you wasn't able since 2013 to make a statistic what do the users want an think about mobile devices
[19:08] <dobey> no, nothing was missed
[19:08] <dobey> you are trolling
[19:09] <dobey> you are making the assumption that the majority of purchasers are somehow grossly dissatisfied, and you wish to use such a statistic to make further derisive commentary
[19:09] <dobey> that much is clear
[19:09] <studio_> no i am not trolling
[19:09] <k1l_> studio_: the point is: you think that your demands are not only your demands but are for all users. this is a misconception.
[19:10] <dobey> and frankly, either way, the number is mostly irrelevant
[19:10] <k1l_> studio_: so try not to make it look like the ubuntu phones are rubbish and dont have any features just because its missing one you would like to have.
[19:11] <studio_> but maybe canonical was trolling with the name ubuntu for mobile devices, as many user thought it the same as their "ubuntu-device"
[19:11] <k1l_> because this will not motivate people to help you
[19:11] <dobey> if you think it is important because you personally are unhappy, then you are saying you wish we would just kill the project, and you want to use something else anyway; so really, you should just go use that something else and stop trolling in here
[19:11] <k1l_> studio_: again: dont say "users" when it means "studio_"
[19:12] <studio_> k1l_, are you blind?
[19:12] <dobey> there have indeed been other people who were expecting their phone to be a PC
[19:13] <dobey> however, we explained to them the differences, and guess what. they don't keep coming in here asking the same thing over and over again and demanding we make something specific differently to satisfy them personally, as you do
[19:17] <studio_> dobey, do a big favour for all users an declare in the UT-Sites, that UT is not Ubuntu because it is depending from Android and has nothing to do with Ubuntu!
[19:18] <dobey> no
[19:18] <dobey> it is ubuntu
[19:18] <dobey> your idea of what ubuntu is, does not make it not ubuntu
[19:18] <studio_> so you want kidding users?
[19:18] <dobey> no
[19:18] <dobey> only you
[19:19] <k1l_> i declare the buffett to be open
[19:19] <OerHeks> 🍴
[19:20] <studio_> dobey, you are kidding yourself! change your password with passwd
[19:20] <dobey> why would i do that
[19:21] <studio_> to show you, that you are kidding yourself
[19:22] <dobey> so some bug that you are obviously referring to, is me kidding myself, because ubuntu is "working toward a fully converged system" and it's not quite there yet?
[19:22] <dobey> i would rather suggest perhaps you might want to go read about logical fallacies
[19:22] <dobey> you're full of them :)
[19:23] <studio_> as i said, why are you trying to kidding customers if you do not try kidding youself?
[19:24] <OerHeks> look in the mirror, studio_ :-D
[19:24] <studio_> :)
[19:24] <dobey> you keep using that word
[19:24] <dobey> i do not think it means, what you think it means
[19:25] <dobey> repeating your rhetoric isn't going to change the facts
[19:25] <OerHeks> But i had a question before this: One option that i miss, is Cell-broadcast. ( message in case of local emergency) Is there any sign that this will be implented?
[19:26] <OerHeks> c/implemented
[19:26] <dobey> OerHeks: i have absolutely no idea how that actually works, so i wouldn't have the slightest of clue
[19:27] <dobey> OerHeks: i presume if it doesn't need extra binary blobs, it probably wouldn't be too terribly hard to implement though, for someone who knows what they're doing
[19:30] <OerHeks> dobey, in short: any gsm in an area can recieve a text message in case of an emergency, like the acid disaster in Oberhausen today > https://en.wikipedia.org/wiki/Cell_Broadcast
[19:31] <dobey> OerHeks: right. i meant on the technical level with reespect to the android layer and getting those bits over into the ubuntu side
[19:31] <dobey> OerHeks: the name itself is pretty self-descriptive :)
[19:31] <studio__> dobey, again, "fooling" clients is a bad commercial strategy. you have to figure out if they are happy with the product.
[19:31] <dobey> attente: again, your rhetoric doesn't change facts. nobody is fooling anyone
[19:31] <dobey> err
[19:31] <OerHeks> dobey, for android one needs to install an app > https://play.google.com/store/apps/details?id=com.digitata.cellbroadcast&hl=en
[19:31] <dobey> not attente
[19:32] <dobey> studio__: again, your rhetoric doesn't change facts. nobody is fooling anyone

[19:32] <dobey> OerHeks: didn't cyanogenmod support it natively?
[19:32] <k1l_> studio__: its not fooling customers.
[19:32] <studio__> so do you have a statisic about UT?
[19:33] <dobey> studio__: again, stop repeating questions you have already received answers to
[19:33] <dobey> i have one statistic; every ubuntu phone/tablet has sold out of stock repeatedly
[19:33] <studio__> dobey, stop trolling!
[19:33] <dobey> k1l_: can you just ban him again? this is not going anywhere, yet again
[19:34] <OerHeks> dobey, not sure, on this page it looks like it is standard http://harwinder.in/blog/2014/08/04/disabling-cell-broadcasts-cm-11-m8/
[19:34] <k1l_> studio__: and to be honest, this is a very aggressive claim. if you make such claims you should have evidence that is more than "i want that feature".
[19:34] <dobey> OerHeks: i know on my phone there are some options for getting amber alerts and stuff, and i have cm13 on it

[19:35] <studio__> no feature, jus an statistic
[19:35] <studio__> just
[19:35] <dobey> and you were told the figure you asked for, does not exist
[19:35] <k1l_> studio__: do you realize what you are doing now?
[19:35] <dobey> so drop it
[19:35] <OerHeks> settings > wireless network > cellbroadcast ?
[19:36] <k1l_> studio__: you insult others and make claims, that ubuntu and canonical is betraying customers, just because you want a statistic?
[19:36] <studio__> k1l_, i asked a simple question
[19:36] <dobey> OerHeks: settings -> more -> emergency broadcasts
[19:37] <dobey> OerHeks: and extrem, sever, and AMBER alerts
[19:37] <k1l_> studio__: this is the reason why your behaviour is not acceptable.
[19:37] <k1l_> studio__: no, dont make it look like "you are just asking a question"
[19:38] <dobey> a simple question, asked repeatedly and aggressively
[19:38] <k1l_> studio__: your behaviour is again very out of the line. and you are doing this on purpose.
[19:38] <studio__> k1l_, as i said/asked are you blind?
[19:38] <dobey> ...
[19:38] <OerHeks> dobey, ah nice. How would i ask for this serious app , on https://forums.ubports.com/category/2/general or https://forum.xda-developers.com/ubuntu-touch ??
[19:39] <OerHeks> might as well point to amber alert too.
[19:39] <dobey> OerHeks: i don't think it would be an app; but like i said, i don't know enough details on how to get the necessary bits from the modem on the android side, over into ubuntu, to pop notifications
[19:39] <OerHeks> dobey me too :-(
[19:39] <dobey> OerHeks: i would say file a bug against canonical-devices-system-image about there being no cell broadcast support in ubuntu
[19:39] <dobey> OerHeks: and then we can go from there
[19:40] <dobey> and countdown to a new thread on ubuntuusers.de (or whatever the domain is)
[19:41] <k1l_> well, he deleted his account there (or got it deleted, i dont know anymore :) )
[19:41] <OerHeks> dobey, thank you. I will take the time to write a complete clear bugreport against 'canonical-devices-system-image'
[19:42] <OerHeks> .. after diner that is :-D
[19:42] <dobey> k1l_: hah, nice
[19:42] <dobey> OerHeks: great
[19:44] <ogra_> popey, LOL !
[19:44] <ogra_> thats hilarious
[20:02] <popey> :)
[20:24] <mterry> jdstrand: why don't I just include both appId schemes in the interface for now?  Rather than a glob
[20:25] <mterry> I guess your intent is to avoid snapd having any code that refers to existing appids...
[21:16] <jdstrand> mterry: the two rules I am suggesting won't work with UAL, but (arguably) should. So I'd like to have those intended rules. The glob rules are fine for now, just want to make sure we document the issue with them
[21:17] <jdstrand> we document the problems with rules in the policy for auditors, researchers and ourselves
[21:31] <mterry> jdstrand: right, I was just saying that rather than using an insecure glob, we can just allow {touchAppID,snapAppID}
[21:32] <mterry> But I was guessing that you preferred a glob rather than encoding anything Touch in snapd  :P
[21:39] <jdstrand> mterry: actually, how about leave the suggest rules, then do @{SNAP_NAME}_* for the Touch glob
[21:39] <mterry> jdstrand: well has to be a dbus version of the name so we still need the ugly replacement
[21:40] <jdstrand> mterry: that would not be a security issue since the snaps are still isolated (even if it is less precise from UAL's point of view
[21:40] <jdstrand> there's a helper for that
[21:41] <jdstrand> mterry: interfaces/dbus/dbus.go SafePath. give it the snap name + '_'
[21:42] <mterry> jdstrand: sure -- yeah I use that now.  NAME_COMMAND_* is my preference (just glob the revision, which doesn't have a concept yet in snap profiles)
[21:42] <jdstrand> let me reread what you have. I thought you had *name*
[21:43] <mterry> jdstrand: sorry I meant I use SafePath now
[21:44] <jdstrand> mterry: right, ok. do the go version of fmt.Sprintf("%s*", dbus.SafePath(plug.Snap.Name() + '_'))
[21:45] <jdstrand> mterry: then you can remove the foobarbaz stuff
[21:45] <mterry> jdstrand: right but is there a reason not to do Name_Command?
[21:45] <mterry> or rather name_command_*
[21:45] <jdstrand> mterry: no, you could do that if you prefer
[21:46] <mterry> jdstrand: alright will change tomorrow
[21:46] <jdstrand> mterry: so, fix that, then drop the foobarbaz isolation comment, but leave the FIXME and 'does not provide isolation' comments
[21:46] <jdstrand> sorry
[21:47] <mterry> jdstrand: does this not provide isolation?
[21:47] <jdstrand> leave the FIXME but drop the 'does not provide isolation' comments
[21:47] <mterry> k
[21:47]  * jdstrand is multitasking poorly :)


[18:40] <thebishop> if i want to build a 3.5 kernel on 12.04, can i do this through the git method or do i need to grab source from kernel.org "the old-fashioned way"?
[18:41] <thebishop> it's not clear to me from the git method guide:  git://kernel.ubuntu.com/ubuntu/ubuntu-precise.git  whether this repo has the absolute latest or just the latest for precise.  I see the mainline ppa stops at 3.4x for precise
[18:41] <thebishop> https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide?action=show&redirect=KernelTeam%2FKernelGitGuide


[01:39] <fallenour> @stormmore @rick_h @jampespage @catbus @Dweller_ @zeestrat I GOT IT! MWHAHAH! Ok so the issue is with the Dell Series systems, you have to configure all of your drives to VD from PD to Raid 0, with each drive configured individually and initialized individually in order for it to create each disk individually as VDs with the Perc cards. Once you do that, it works like a champ
[01:41] <fallenour> and here I was so excited :(
[01:41] <fallenour> I only see 400 of the total 3TB of storage available x..x
[01:42] <fallenour> upgrade from previous is though that all OSD devices show as active idle, unit is ready, 1 OSD each. So thats a good sign at the very least.
[07:59] <nofun> Hey all
[08:00] <nofun> Could anyone help answer a question
[10:55] <magicaltrout> hello folks, random design pattern question. We have a requirement to setup some services, in effect, as a base layer on all our nodes
[10:56] <magicaltrout> other than manually applying them to each node, or making them subordinate to something
[10:56] <magicaltrout> is there a way to do that thats nice? or not? :)
[11:40] <rick_h> magicaltrout: heh we do that internally. There's a basenode charm that is actually what's deployed and then other charms are hulk-smashed to those.
[11:40] <rick_h> magicaltrout: subordinate is nice way if you can work it that way
[11:41] <rick_h> magicaltrout: I think one of the issues our folks had was that some of the setup needed to be done before the main charm could operate so it had to be a promise that basenode was laid down first
[11:59] <stub> 'basenode' exists to configure apt repositories to our internal mirrors, which needs to happen before charms attempt to install stuff
[12:02] <stub> rick_h: Some sort of a predeploy hook that lets us mess with a machine between provisioning and deploying the charm would make my life a lot easier. we could lose basenode, and all the fallout which is significant.
[12:05] <stub> magicaltrout: We are currently deploying from local branches, which lets us dump stuff in $CHARMDIR/exec.d, and probably best documented in https://github.com/juju-solutions/layer-basic/blob/master/lib/charms/layer/execd.py
[12:05] <stub> (all reactive charms get the feature, whereas non-reactive need to explicitly make the correct charm-helpers calls)
[12:23] <rick_h> stub: rgr
[13:13] <fallenour> hey errbody!
[13:14] <Dweller__> mornin
[13:14] <tvansteenburgh> o/
[13:16] <rick_h> fallenour: how'd a night's rest go? Saw you made some progress late?
[14:18] <fallenour> @rick_h yea Ive got it fully up and running, now I just need to know why it only sees 400 of the 3 TB of space in horizon. Any ideas? All osds reporting as good to go.
[14:19] <fallenour> Im assuming that since the system will take the first drive for OS, and the rest for storage, I should only be down roughly 3 drives of the total available 22, so 19 at 146 gb each.
[14:19] <rick_h> fallenour: sorry, /me is storage ignorant. I just like building stuff that uses storage
[14:19] <fallenour> @rick_h lol @stokachu @jamespage any ideas then guys?
[14:36] <zeestrat> @fallenour: I suggest taking a look at ceph to get an idea of the state of your storage and then seeing if that matches up with what is presented in horizon
[14:39] <fallenour> @zeestrat I really wish I could, but I dont exactly know how to do that.. :(
[14:39] <fallenour> @zeestrat I know that the difference between the pure ceph-OSD node and the ones working is the nova-compute services are installed, which is why they appear in the hypervisor section. But other than that, and running drive related commands on the systems themselves, I dont know what to do next.
[15:00] <jamespage> fallenour: hmm - not sure that horizon well tell you the avaliable storage in cinder?
[15:00] <jamespage> normally it tells you the ephermeral storage capacity on the compute nodes
[15:01] <fallenour> @jamespage Yea that was my concern. I guess my next question, is I made the ceph nodes in order to expand my overall storage in openstack, how do I make sure that storage is available for my instances?
[15:01] <fallenour> @jamespage otherwise, Ive lost over 85% of the available storage for viable use, which is bad news bears.
[15:01] <jamespage> fallenour: so ceph can be used in multiple ways in openstack
[15:02] <jamespage> i suspect you have it configured as a cinder backend only; with this configuration you can do boot from volume for instances + attach persistent volumes to instances which have root disks on local disk on compute hypervisors
[15:03] <jamespage> fallenour: you can also configure nova to use ceph as the backend for all instance storage - the nova-compute charm supports this, but its not the 'default'
[15:03] <fallenour> @jamespage right now all I have installed on the nodes specifically is ceph-osd. Did I need to install something in addition to that?
[15:03] <jamespage> you have to toggle a configuration option on the nova-compute charm
[15:03] <fallenour> @jamespage ahh Im guessing thats the missing link. I do believe I installed cinder-ceph, but I dont know if nova accepts that.
[15:04] <fallenour> @jamespage does that mean another rebuild? Q___Q
[15:04] <jamespage> fallenour: no it should be switchable
[15:04] <jamespage> fallenour: https://jujucharms.com/nova-compute/#charm-config-libvirt-image-backend
[15:04] <jamespage> set that option to rbd
[15:06] <fallenour> @jamespage Libvirt-image-backend from lvm to rbd I take it?
[15:06] <fallenour> @jamespage will that also update the rados gateway and ceph osd nodes accordingly?
[15:06] <jamespage> fallenour: it won't be set at all right now
[15:06] <jamespage> fallenour: it should dtrt
[15:08] <fallenour> @jamespage is there a specific series of commands I should issue, or do I need to just modify the /etc/nova/nova.conf config files on all the nova boxes?
[15:20] <fallenour> @jamespage Another question, I would like to expand ont he ceph option osd-devices. Default only includes /dev/sdb, but with systems with more than two devices, will the system do a naming of /dev/sda, /dev/sdb, /dev/sdc, etc? If so, wont the default only capture the first avaialble drive only, and ignore the others? If so I would like to configure that to grab the others accordingly
[16:27] <xarses_> @rick_h: Please enjoy https://bugs.launchpad.net/juju/+bug/1716948 I sure didn't
[16:27] <mup> Bug #1716948: juju controller caches credentials from bootstrap <docs> <juju:New> <https://launchpad.net/bugs/1716948>
[16:52] <rick_h> xarses_: ruh roh
[16:52] <xarses_> ya, I didn't enjoy yesterday
[17:19] <rick_h> The Juju Show #21 in 40 minutes. Get your coffee cups ready!
[17:41] <rick_h> hml: kwmonroe tvansteenburgh hatch marcoceppi bdx magicaltrout beisner and anyone else able to make the show in 20min <3
[17:55] <rick_h> folks that want to chat in the show can join via https://hangouts.google.com/hangouts/_/okwrzmr46fgrvcwcokclw7yqcie
[17:55] <rick_h> and those that want to watch load up https://www.youtube.com/watch?v=3658lsehjKM
[18:23] <bdx> rick_h: include-file config only available in bundles, not charm config?
[18:29] <rick_h> bdx: correct, it's done client side as the bundle is processed
[18:29] <rick_h> bdx: charm already takes a --config option that can be yaml so not sure how useful it'd be
[18:37] <bdx> Got it, thx
[18:39] <bdx> rick_h: how do we get stale charms out of the charm store?
[18:39] <bdx> rick_h: contact the team and ask them to update the charm or revoke privs?
[18:39] <rick_h> File a bug. We file a thing with folks that have delete permissions.
[18:40] <bdx> rick_h: ah nice
[18:40] <rick_h> bdx: oh, yea if it's someone else's yea. Engage them is first steps
[18:40] <bdx> totally
[18:40] <bdx> ok, looks like I need to do both
[18:40] <bdx> I've got crufty trial and error charms just hanging around it would be nice to wipe off the face of the earth
[18:41] <bdx> rick_h: file a bug where?
[18:42] <rick_h> bdx: github.com/canonicalltd/jujucharms.com
[18:46] <kwmonroe> bdx: super quick fix is to remove read perms from everyone... like "charm revoke ~user/charm everyone".  you'll still see it (assuming you're the owner of the charm), but noone else will.
[18:52] <bdx> rick_h: totaly
[18:52] <bdx> rick_h: https://github.com/CanonicalLtd/jujucharms.com/issues/487
[21:46] <tychicus> sudo cat /var/lib/mysql/mysql.passwd
[21:46] <tychicus> I get: No such file or directory
[21:47] <tychicus> is there another method for getting the root mysql password?


[18:03] <OtmanGX> Hello guys
[18:03] <OtmanGX> I have a problem about apache
[18:04] <OtmanGX> I'm hosting a wordpress website, in localhost everything working fine
[18:05] <OtmanGX> But when I replace the wordpress url with a ddns I can't access the website locally
[18:06] <OtmanGX> Just remotly !