[00:06] <SpamapS> FYI, there's a new charm-tools in the PPA now
[00:07] <SpamapS> includes 'unpromulgate'
[00:20] <SpamapS> imbrandon: did you get your newrelic-php charm to deploy?
[00:20] <SpamapS> imbrandon: the metadata is a bit confusing
[00:20] <SpamapS> imbrandon: no interface: juju-info ..
[00:20] <imbrandon> SpamapS: i was about to try in in just a few minutes
[00:20] <imbrandon> no i did it blind so far
[00:20] <imbrandon> untill a few ago no to deploy it
[00:20] <SpamapS> imbrandon: I think you need interface: juju-info
[00:20] <imbrandon> i thought i put it
[00:21]  * imbrandon looks
[00:21] <imbrandon> SpamapS: i can give you a valid key
[00:21] <imbrandon> if you wanna try it too
[00:21] <imbrandon> the one i use for brandonholtsclaw.com so the numbers dont matter if a little skewed
[00:21] <imbrandon> etc
[00:22] <SpamapS> well I'd think juju would just refuse
[00:23] <lifeless> newrelic have a free account for low traffic sites IIRC, so you can get a key easy.
[00:23] <SpamapS> yeah that should go in the README of the charm :)
[00:23] <imbrandon> lifeless: yea for the system monitor only
[00:23] <imbrandon> lifeless: not the lang ones like php
[00:24] <imbrandon> this is a php one
[00:24] <lifeless> imbrandon: wait, what ?
[00:24] <lifeless> that sucks
[00:24] <SpamapS> imbrandon: copyright: This charm is not endorsed or affiliated with the Locker project and the Locker source is the respective work of its author.
[00:24] <imbrandon> yea the free only does like cpu memory and disk and like that
[00:24] <lifeless> $pointless
[00:24] <imbrandon> SpamapS: whoop
[00:24] <imbrandon> SpamapS: sounds like an old push
[00:24] <imbrandon> SpamapS: let me make sure bzr is uptodate
[00:25] <SpamapS> bzrhater
[00:25] <imbrandon> subordinate: true
[00:25] <imbrandon> requires:
[00:25] <imbrandon>   juju-info:
[00:25] <imbrandon>     scope: container
[00:25] <imbrandon> provides:
[00:25] <imbrandon>   logging:
[00:25] <imbrandon>    interface: newrelic-php
[00:25] <imbrandon> is that not right ?
[00:25] <SpamapS> nope
[00:25] <SpamapS> at the same level as scope: container, you need 'interface: juju-info'
[00:25] <SpamapS> at least, thats how I read the docs
[00:25] <imbrandon> ok and leave the other too
[00:26] <imbrandon> so two juju-infos
[00:26] <imbrandon> ?
[00:26] <SpamapS> same level as scope
[00:26] <SpamapS> requires:
[00:26] <SpamapS>   juju-info:
[00:26] <imbrandon> right but do i leave the other
[00:26] <SpamapS>     interface: juju-info
[00:26] <imbrandon> ok
[00:26] <SpamapS>     scope: container
[00:26] <imbrandon> kk yea thats what i was asking if i left both
[00:26]  * imbrandon fixes
[00:27] <SpamapS> no files dir either
[00:27] <imbrandon> lifeless: yea "system" monitoring is free for unlimited servers, "application" monitoring is now
[00:27] <imbrandon> not*
[00:28] <imbrandon> yea bzr was out dates
[00:28] <imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ bzr add .
[00:28] <imbrandon> adding files
[00:28] <imbrandon> adding files/548C16BF.gpg
[00:28] <imbrandon> doh
[00:28]  * SpamapS suspends review
[00:28] <lifeless> imbrandon: I think you are wrong
[00:28] <imbrandon> 3 seconds and i'll have it pushed
[00:28] <lifeless> http://newrelic.com/pricing/details
[00:28] <lifeless> lite
[00:28] <lifeless> free
[00:29] <imbrandon> right but thats for the newrelic-sysmon
[00:29] <lifeless> includes basic db and app monitoring
[00:29] <lifeless> anyhow
[00:29] <imbrandon> ahh yea
[00:29] <imbrandon> when theysay basic they mean BASIC
[00:29] <lifeless> oops gathers more data :)
[00:29] <imbrandon> as in is it running
[00:30] <lifeless> and is always free
[00:30] <imbrandon> but yea
[00:30]  * imbrandon will add a bit about that in the readme
[00:30] <SpamapS> imbrandon: you need a start/stop hook
[00:30] <SpamapS> contrary to popular belief, having an init.d installed in runlevel 2 is not enough
[00:31] <imbrandon> SpamapS: k
[00:31] <SpamapS> eventually juju will use stop/start to support migrating services, and possibly snapshotting.
[00:32] <imbrandon> SpamapS: also if you do grab a lite key while i push this, and the "deploy" it to test the charm, they count that as a depooy and will send ya a data-nerd t-shirt :_
[00:32] <SpamapS> I am starting to think more and more that we should take the debhelper 7 approach and try to get this all down to one hook file that just calls out to various helpers
[00:32] <imbrandon> heh
[00:32] <SpamapS> 99% of charms are doing the same things
[00:33] <SpamapS> No revisions or tags to pull.
[00:34] <imbrandon> push
[00:34] <imbrandon> ed
[00:34] <imbrandon> should be rev 3
[00:34] <imbrandon> on bzr
[00:37] <imbrandon> SpamapS: PM with key if you wanna try without hassle of signing up, just a convience
[00:40] <imbrandon> just added a line in the readme too about getting a ( free ) newrelic account
[00:40] <imbrandon> ty lifeless , i mis-understood
[00:40] <SpamapS> oh nice , I get a data nerd shirt
[00:40] <imbrandon> yup yup, i got two from them , nice shirts actually
[00:41] <imbrandon> and i got a book "The Lean Startup" hard cover they was giviing away a few weeks ago
[00:41] <imbrandon> they are always giving some kinda swag out to twitter followers
[00:42] <SpamapS> Ok I'm going to point it at my thinkup instance
[00:42] <imbrandon> kk
[00:43] <imbrandon> i'm after testing and prom etc i'm gonna deploy it to omg instead of how its done by hand now
[00:43] <imbrandon> omg is using cloudflare now too
[00:43] <imbrandon> :)
[00:44] <SpamapS> 2012-05-01 17:43:44,651 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/install: line 13: syntax error near unexpected token `else'
[00:44] <imbrandon> crap
[00:44]  * imbrandon looks
[00:44] <SpamapS> forgot ; after ]
[00:44] <imbrandon> damn i was gonna say this is like the simplest chamr
[00:44] <imbrandon> lol
[00:45] <imbrandon> pushed
[00:45] <SpamapS> yeah I just haxored it in and I'm rerunning the install hook now
[00:45] <imbrandon> kk
[00:45] <imbrandon> :)
[00:45]  * SpamapS hugs juju resolved --retry
[00:45] <SpamapS> I think we should just alias that to 'juju retry'
[00:46] <SpamapS> I almost always want --retry anyway
[00:46] <SpamapS> 2012-05-01 17:46:09,907 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/install: line 10: md5: command not found
[00:46] <SpamapS> ha-ha
[00:46] <SpamapS> md5sum
[00:46] <SpamapS> imbrandon: man u suck at this! ;-)
[00:46]  * SpamapS hides
[00:46] <imbrandon> i am so gonna make the error and info functions in juju to be "ohai = info " "ohnoe = warn" "ohpoo = error"
[00:46] <imbrandon> wow
[00:46] <lifeless> imbrandon: misunderstood what ?
[00:47] <imbrandon> lifeless: the free leel
[00:47] <imbrandon> level
[00:47] <imbrandon> SpamapS: no md5sum on base install ?
[00:47] <imbrandon> frak
[00:47] <SpamapS> no *md5*
[00:47] <SpamapS> md5sum is there
[00:47] <SpamapS> well, it might be
[00:47] <SpamapS> not entirely sure actually
[00:47] <imbrandon> ph, frakin osx thin
[00:48] <imbrandon> there is here
[00:48] <imbrandon> not sure on linux
[00:48] <lifeless> imbrandon: ah, so it does do more than you thought ?
[00:48] <imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$ md5 -q files/548C16BF.gpg
[00:48] <imbrandon> be9704aa1e7001d855a60c4c05d7598b
[00:48] <imbrandon> bholtsclaw@ares:~/Projects/local/charms/precise/newrelic$
[00:48] <SpamapS> md5sum is in coreutils
[00:48] <imbrandon> lifeless: yup, not a lot , i'd still pay,. but yea
[00:49] <SpamapS> imbrandon: realistically, that check doesn't add any security. If a bad actor could change that, it could change install
[00:49] <imbrandon> true
[00:49]  * imbrandon just drops it
[00:49] <SpamapS> 2012-05-01 17:49:21,939 unit:newrelic-php/0: hook.output ERROR: /var/lib/juju/units/newrelic-php-0/units/newrelic-php-0/charm/hooks/config-changed: line 12: /ect/newrelic.cfg: No such file or directory
[00:49] <imbrandon> jesus i am bad
[00:49] <SpamapS> imbrandon: I am your debugger
[00:50] <SpamapS> imbrandon: perhaps consider variables rather than repetitive hard coding as a strategy to mitigate mt. dew induced type-o impact
[00:50] <SpamapS> imbrandon: or maybe Mavis Beacon? :)
[00:51]  * SpamapS will stop going all alpha-dog on imbrandon now :)
[00:51] <imbrandon> all pushed
[00:51] <imbrandon> heheh
[00:51] <imbrandon> np
[00:51] <imbrandon> i deserve it most of the time :)
[00:51] <imbrandon> including now
[00:51] <SpamapS> 2012-05-01 17:51:24,404 unit:newrelic-php/0: hook.output INFO: Starting New Relic Proxy Daemon: newrelic-daemon
[00:51] <SpamapS> 2012-05-01 17:51:25,412 unit:newrelic-php/0: hook.output INFO:  FAILED
[00:51] <imbrandon> no lic key
[00:51] <imbrandon> likely
[00:52] <SpamapS> I did set one, I think
[00:52] <SpamapS> perhaps not in the confusion
[00:52] <bkerensa> SpamapS: Would you like to share some examples of your ninja variables work in a charm? :D
[00:52] <bkerensa> examples accepted
[00:53] <SpamapS> A=speling
[00:53] <imbrandon> lol
[00:53] <SpamapS> echo "I suck at $A even when I'm competing in a $A bee"
[00:54] <SpamapS> Starting New Relic Proxy Daemon: newrelic-daemon OK
[00:54] <imbrandon> shaweet
[00:55] <SpamapS> imbrandon: one weakness..
[00:55] <SpamapS> imbrandon: it doesn't restart apache
[00:55] <imbrandon> yea i thought about that
[00:55] <SpamapS> imbrandon: seems like you could just restart any that are running.
[00:55] <imbrandon> i would need tro know any way php could be installed and start apache nginx php-fom
[00:55] <imbrandon> etc
[00:56] <SpamapS> imbrandon: thats what the scope: container relationships are for
[00:56] <imbrandon> ?
[00:56] <imbrandon> it stil dont help me to know the type i need to restart
[00:56] <SpamapS> imbrandon: you can have one interface: php-app-server ... and then the charms that implement it can feed back things like what service to restart
[00:56] <imbrandon> oh yea
[00:56] <imbrandon> that way
[00:57] <imbrandon> yea that was the "comming soon" thing we mentioned
[00:57] <imbrandon> btw you should be able to refresh the page once or twice and it start feeding data
[00:58] <imbrandon> its almost realtime
[01:00] <SpamapS> I don't see any data yet
[01:00] <SpamapS> but, it appears to be working basically
[01:01] <imbrandon> make sure your on the apps tab
[01:01] <imbrandon> and not the system one
[01:01] <imbrandon> at the top left
[01:01] <SpamapS> imbrandon: thats pretty impressive
[01:01] <imbrandon> :) the sysmon one will fill in the system tab
[01:01] <imbrandon> etc
[01:02] <imbrandon> then ruby and python
[01:02] <imbrandon> et al
[01:02] <SpamapS> imbrandon: I wonder if we shouldn't just make a "newrelic" subordinate and have each different app type installable via relation or config
[01:02] <imbrandon> well i thought about that for the apps but figured it would be configin
[01:03] <imbrandon> confusing*
[01:03] <SpamapS> the reason I like doing it that way is that you can have one place for your key.. one place to upgrade
[01:03] <SpamapS> oh also, I'd recommend calling the config option just 'key'
[01:03] <imbrandon> stil all uses /etc/newrelic.cfg
[01:03] <imbrandon> or whatever
[01:03] <imbrandon> kk
[01:04] <SpamapS> no reason to prefix it when it is already namespaced into the charm
[01:04] <imbrandon> k
[01:04] <imbrandon> so in theory
[01:04] <imbrandon> then as long as i do them all the same
[01:04] <imbrandon> if you installed the python one now
[01:04] <imbrandon> you would not need to mess with the key
[01:04] <imbrandon> since i put it in the if/else
[01:05] <imbrandon> on config-change only
[01:05] <SpamapS> right
[01:05] <imbrandon> so kinda the same just not said expliositly
[01:05] <imbrandon> bah
[01:05] <SpamapS> Interesting, it seems like it held off feeding back the massive spike that my siege created until I let the load drop
[01:05] <imbrandon> its a little behind
[01:06] <imbrandon> not 1000% realtime
[01:06] <imbrandon> but almost
[01:06] <SpamapS> damn tho
[01:06] <SpamapS> drilling down now
[01:06] <SpamapS> We'd have been able to fire 3 people at my last place w/ this
[01:06] <imbrandon> :)
[01:06] <SpamapS> not because they wouldn't have work to do
[01:06] <imbrandon> yea dude it rocks, and thats just the default settings
[01:06] <SpamapS> but we'd finally be able to prove that their code was causing all the suck
[01:07] <imbrandon> if you get into the api you can set some treally cooll stuff
[01:07] <imbrandon> https://newrelic.com/docs/php/the-php-api
[01:08] <SpamapS> wow
[01:08] <SpamapS> what a PoS thinkup is
[01:08] <imbrandon> https://newrelic.com/docs/php/php-agent-phpini-settings#inivar-tt-top100
[01:08] <SpamapS> every hit to index.php does show tables like '?'
[01:09] <imbrandon> heh nice
[01:09] <SpamapS> this app wouldn't even work on mysql 5.0 .. it takes a table lock (briefly) to do that
[01:09] <imbrandon> good thing for mysql query cache
[01:09] <imbrandon> lol
[01:09] <SpamapS> bunch of lazy load insanity here
[01:10] <imbrandon> newrelic.framework = ""
[01:10] <imbrandon> Scope: PERDIR
[01:10] <imbrandon> Type: String
[01:10] <imbrandon> New Relic tries hard to automatically detect the frameworks it supports, but it can get it wrong if you are using experimental new versions or you have customized the framework. This setting can be used to manually set the framework if the auto-detection fails. This must be one of "cakephp", "codeigniter", "drupal", "joomla", "kohana", "magento", "mediawiki", "symfony", "wordpress", "yii", "zend" or "no_framework" to force no framework even if one was detec
[01:10] <imbrandon> ^^ very nice
[01:10] <SpamapS> imbrandon: the mysql QCache is also a problem.. though they've finally got it working ok by splitting it up into multiple mutexes
[01:11] <imbrandon> SpamapS: yea an ppl often make it huge thinking it will help
[01:11] <imbrandon> and iit  burries them
[01:13] <SpamapS> yeah, I went through the thrashing up and down for a while at my last place before I realized turning it *OFF* actually made things better :)
[01:13] <imbrandon> and yea in like a day or so you'll get an email from $sales saying "we sent ya a tshirt, enjoy" but then takes like 2 weeks to show :)
[01:13] <imbrandon> just fyi
[01:13] <SpamapS> I didn't give them an address yet
[01:13] <SpamapS> but thats cool
[01:13] <imbrandon> ahh ok
[01:13] <SpamapS> I'll gladly wear it, this is cool stuff
[01:13] <imbrandon> :)
[01:14] <SpamapS> SET time_zone = '?'
[01:14] <imbrandon> HAHAHA
[01:14] <SpamapS> theres one that just runs into concurrency problems
[01:14] <SpamapS> 1,483 ms
[01:14] <imbrandon> wow
[01:15] <SpamapS> imbrandon: here's one thought. What about just restarting apache2 and php5-fpm .. those two would cover 99.9% of the cases where a daemon is serving PHP
[01:15] <imbrandon> good call
[01:15] <imbrandon> untill something better
[01:15] <imbrandon> is done
[01:15]  * imbrandon adds it
[01:16] <imbrandon> is the service apache or aoache2 ( /me dont have it installed )
[01:16] <SpamapS> apache2
[01:16] <imbrandon> k
[01:16] <SpamapS> and use the service command
[01:16] <SpamapS> that way it works even if we move it to upstart
[01:16] <imbrandon> yea i do
[01:16] <SpamapS> actually, /etc/init.d/apache2 works that way too.. so.. :-P
[01:16] <imbrandon> cuz php5-fpm will restart its self that way
[01:16] <SpamapS> but, service > /etc/init.d/oldcrap
[01:17] <imbrandon> yea i like upstart works liek god
[01:17] <imbrandon> god == the bomb tho
[01:18] <SpamapS> imbrandon: ok, so thats my review. Change the name of the config option to 'key' and restart the services. Everything else can stay as a TODO for the future. Well done. :)
[01:19] <imbrandon> ty ty and i'm pushing herer in a 30 seconds
[01:19] <SpamapS> also what do you think about calling it newrelic
[01:20] <imbrandon> nah, its the php one , there is another that will be just newrelic
[01:20] <SpamapS> Ok
[01:20] <imbrandon> this installs the newrelic.so
[01:20] <imbrandon> sysmon will be just newrelic
[01:20] <SpamapS> We need to grow 'replaces' and 'provides' like capabilities for charms so when we consolidate those or rename something users can get it on an upgrade-charm
[01:20] <imbrandon> as i needs absolutely nothing else
[01:20] <SpamapS> heh, 'juju dist-upgrade'
[01:20] <imbrandon> lol
[01:20]  * SpamapS is not sure he likes the implications there
[01:21] <SpamapS> Ok time to go
[01:21] <SpamapS> imbrandon: will promulgate later tonight
[01:21] <imbrandon> brew upgrade all
[01:21] <SpamapS> family is home
[01:21] <imbrandon> SpamapS: ty ty
[01:21] <imbrandon> kk
[01:25] <imbrandon> SpamapS: ok pushed, for when you do get back round
[01:25]  * imbrandon grabs some late dinner
[01:29] <nathwill> is there a no-cache option to forcibly reload a charm from the repository?
[01:29] <nathwill> when doing a deployment ^
[01:30] <imbrandon> hrm not sure, i think it just looks at the revision
[01:31] <nathwill> ok. too bad, that would be handy
[02:06] <imbrandon> SpamapS: how far behind is the go client, as in is it useable _at all_ now and not upto feature parady or ...
[02:47] <imbrandon> SpamapS: zomg sexy .... love; why cant this be unity .... me want .... https://plus.google.com/u/0/100530892038948253747/posts
[03:40] <SpamapS> imbrandon: as I understand it, a week or two ago the go client was able to spin up ec2 instances
[03:40] <SpamapS> imbrandon: and some details about how the bootstrap will differ from the python client are being worked out
[03:40] <SpamapS> imbrandon: so, its still quite far behind, but the foundations are laid
[03:40] <SpamapS> imbrandon: FYI, there is a --upgrade option to deploy that satisfies what nathwill was asking earlier
[03:43] <imbrandon> ahh
[03:44] <imbrandon> SpamapS: kk, i was thinkning about compiling the go here local and trying to kick the tires a bit , nothing serious really just see what works and dont
[03:51] <SpamapS> I tried that about 2 months ago and there was nothing, but I'm told there is at least something to play with now
[03:51] <SpamapS> imbrandon: you can also start up your own charm store ;)
[03:59] <imbrandon> oh ?>\
[03:59] <imbrandon> with go or ?
[03:59] <imbrandon> just in general ?
[04:17] <SpamapS> imbrandon: the charm store backend is written in go
[04:17] <SpamapS> and is in lp:juju/go/store
[04:28] <SpamapS> imbrandon: still have that bit about Locker in the copyright
[04:28] <SpamapS> oh wait no
[04:28] <SpamapS> it says newrelic now, never mind :)
[04:29] <imbrandon> :)
[04:29] <SpamapS> imbrandon: so, the provides ..
[04:29] <SpamapS> that needs to go
[04:29] <SpamapS> unless you're going to add a hook, or explain who will require: that
[04:29] <imbrandon> ... um i wantthat later
[04:29] <SpamapS> is it going to be purely for private-address/public-address ?
[04:30] <imbrandon> probably
[04:30] <imbrandon> and unit names
[04:31] <SpamapS> imbrandon: so you don't actually have to do anything on the newrelic side of things?
[04:31] <imbrandon> and the ability to have other svc change its configs
[04:31] <imbrandon> huh ?
[04:32] <SpamapS> imbrandon: I'm asking if its possible w/o hooks
[04:32] <imbrandon> if what is
[04:32] <imbrandon> your not clear at all
[04:32] <SpamapS> imbrandon: that relation
[04:32] <imbrandon> i'm still very lost
[04:32] <SpamapS> You have a relation
[04:32] <SpamapS> with no hooks
[04:32] <imbrandon> yes
[04:32] <SpamapS> I'm questioning the value of such a thing
[04:33] <imbrandon> its for later so names and other config bits can easily be set
[04:33] <imbrandon> from peers
[04:33] <SpamapS> There is an *implied* juju-info relation in all charms. https://juju.ubuntu.com/docs/implicit-relations.html
[04:33] <SpamapS> imbrandon: until you have actual hooks, just use that.
[04:33] <imbrandon> right but it wont always be juju-info that was a hack till i get php-app in all others
[04:34] <imbrandon> no then i got to go back and change it yet again
[04:34] <imbrandon> why
[04:34] <SpamapS> step back, this is the provides, not the requires
[04:34] <imbrandon> yes , it proviodes a php logging interfae
[04:34] <imbrandon> it does
[04:35] <SpamapS> so, the only way an interface: can be defined is by an implementation (currently). I'm hesitant to have an interface w/o an implementation.
[04:35] <SpamapS> Oh, does it like, listen on a port or something?
[04:35] <imbrandon> what does it hurt, and it helps by making things very clear
[04:35] <imbrandon> yes
[04:35] <imbrandon> the daemon does
[04:35] <SpamapS> this is uncharted territory
[04:36] <SpamapS> so tell me to F off all you want. :)
[04:36] <imbrandon> right
[04:36] <SpamapS> I'll take it well
[04:36] <imbrandon> heheh well i'm looking at it more like i'll probably use it so good to have it from the get go and it dont hurt
[04:36] <SpamapS> So at this point, interface: newrelic-php , listens on a given port on the private-address.
[04:36] <imbrandon> instead of doing like juju-info and then changing later
[04:37] <imbrandon> right, well right now its <IP_ADDRESS>/unix/sockt
[04:37] <SpamapS> *doh*
[04:37] <imbrandon> but i will have it just use one daemon and a tcp port
[04:37] <imbrandon> when ther is more than one
[04:37] <imbrandon> i'm still missing what why its bad to have
[04:38] <imbrandon> and i see it as good even witout a implmntation as it makes it very clear
[04:38] <imbrandon> even in the status
[04:38] <SpamapS> It still sounds like its a broken interface at this point.
[04:38] <SpamapS> no documentation for it..
[04:38] <SpamapS> no partner implementation
[04:38] <SpamapS> Not saying "NO"
[04:38] <SpamapS> just asking for a good reason to keep it
[04:39] <imbrandon> and i'm asking for a good reason to ditch it
[04:39] <SpamapS> when it sounds like you'll have to change things in the charm to make it actually work anyway
[04:39] <SpamapS> cause its broken
[04:39] <imbrandon> no it works fine
[04:39] <imbrandon> in telling me that via the meta info its a logging php infterface
[04:39] <SpamapS> there's nothing that can relate to it
[04:40] <imbrandon> that cant be the *only* reason for the meta info otherise why have it
[04:40] <imbrandon> and just go on whatever interfaces ahve implentations
[04:40] <SpamapS> It is *definitely* the only reason
[04:40] <imbrandon> then just enumerate the implmented interfaces
[04:40] <imbrandon> and ditch all the meta info
[04:40] <SpamapS> Otherwise somebody goes off and writes themselves a thing that wants to log to newrelic-php
[04:40] <SpamapS> and then they get really annoyed that it won't work
[04:40] <SpamapS> and they have no example to follow from the author
[04:41] <imbrandon> if if exposes no info for them to do so
[04:41] <imbrandon> then they wont
[04:41] <imbrandon> and i linked the docs in the readme
[04:41] <SpamapS> So, it doesn't say 'will-provide' logging, it says 'provides' logging. And yet, it listens on no ports.
[04:41] <imbrandon> logging dosent have to mean it provieds to all
[04:41] <imbrandon> or on a port
[04:42] <imbrandon> it does to the app
[04:42] <imbrandon> and only the app
[04:42] <imbrandon> but it still does
[04:42] <imbrandon> and its still an interface
[04:42] <SpamapS> thats scope: container then
[04:42] <imbrandon> its in container
[04:42] <SpamapS> Yeah, so thats not relatable over the network
[04:42] <SpamapS> so add scope: container
[04:42] <imbrandon> omg
[04:42] <imbrandon> yes it is and no
[04:42] <imbrandon> it is not setup that way
[04:43] <imbrandon> there is not a config opetion
[04:43] <imbrandon> so it is not there
[04:43] <imbrandon> for public use
[04:43] <imbrandon> but it IS there
[04:43] <SpamapS> Well since you can't show me how its setup, because you haven't implemented it, I stand by my -1, if for no other reaosn than primal fear of the unknown. :)
[04:43] <imbrandon> look in the only config
[04:44] <SpamapS> thats not -1 as in, NACK for cs:
[04:44] <SpamapS> just, -1
[04:44] <SpamapS> you're good to go for cs:
[04:44] <imbrandon> ... >.<
[04:44] <SpamapS> though I'm going to open a bug in the charm as a reminder to fix it or drop it. :)
[04:44] <imbrandon> ok then i'm truely missing something
[04:45] <imbrandon> and i'll mark as wontfix unless you can tell me what the hell you mean
[04:45] <SpamapS> relations define *network* service relationships. There is no logging network interface exposed by the installed/configured software.
[04:45] <SpamapS> so it is effectively broken
[04:45] <imbrandon> that is not explisit
[04:45] <imbrandon> and if its 100% then we need a local relations speeled out too
[04:45] <imbrandon> more than container
[04:46] <SpamapS> container == local
[04:46] <imbrandon> right this is both
[04:46] <imbrandon> now what ?
[04:46] <SpamapS> that would be two relations
[04:46] <imbrandon> ...
[04:46] <imbrandon> really?
[04:46] <SpamapS> one for relating via the socket
[04:46] <imbrandon> thats broken
[04:46] <SpamapS> one for relating over the network
[04:46] <imbrandon> no only one is active
[04:46] <imbrandon> at a time
[04:46] <imbrandon> or can be
[04:46] <SpamapS> Thats fundamental to the way subordinates work.
[04:47] <SpamapS> Think it through
[04:47] <imbrandon> no or the thing would not work now
[04:47] <imbrandon> if that was the case
[04:47] <imbrandon> it DOES work like the way i did it
[04:47] <imbrandon> and does imply the way it is
[04:47] <imbrandon> but if i put two
[04:47] <imbrandon> one will always be wrong
[04:47] <SpamapS> if its "both", how do you direct juju to install the charm subordinate to any given service *and* let other things log to that particular daemon? you can't because the scope defines where the charm ends up running.
[04:48] <imbrandon> because it installs both a php nrerelic.so that talks to a running daemon
[04:48] <imbrandon> that so can be on any machine
[04:48] <imbrandon> one one daemon is needed
[04:48] <imbrandon> but aman can be runniung
[04:48] <imbrandon> right now its made where many are
[04:48] <imbrandon> weach has their own
[04:49] <imbrandon> thats how its both
[04:49] <SpamapS> that all makes sense
[04:50] <SpamapS> but for juju, you can't have one relation that is both container scope, and not container scope
[04:50] <imbrandon> i do right now :)
[04:50] <imbrandon> or you mean i'm not intended to ?
[04:51] <SpamapS> Could be the latter.
[04:51] <imbrandon> hehe
[04:51] <imbrandon> i do think thats wrong though, for other thingas like the LB
[04:51] <imbrandon> that might have a webserver local and remote
[04:51] <imbrandon> etc
[04:51] <imbrandon> and more not on the top of my head
[04:51] <imbrandon> container/not container should be a hint not restriction
[04:52] <SpamapS> It should work, to relate the local one to the same service it is deployed on. Thats fine, I'd encourage that sort of thing. But you can't use the unix socket without doing backflips to figure out if you are local or not.
[04:52] <imbrandon> brb more soda
[04:52] <SpamapS> 8 min, I have to go :p
[04:52] <imbrandon> okies
[04:53] <imbrandon> ok so for real
[04:53] <imbrandon> add container ? imho thats just crust
[04:53] <imbrandon> but i will and then bitch later
[04:53] <imbrandon> very not in line with DRY
[04:54] <SpamapS> no actually I think you should just remove it still, until you can actually make it work across the network. :)
[04:54] <imbrandon> well even if i dont i still want it there so its explisit in the metadata
[04:54] <imbrandon> i dont think that metadat should only be for implmented services or then why have it
[04:55] <imbrandon> s/servicecs/interfaces
[04:55] <SpamapS> its explicitly lying about its capabilities. Stubs are generally kept private while they're being worked on.
[04:55] <imbrandon> thats it its not a stuf
[04:55] <imbrandon> stub
[04:55] <imbrandon> bah
[04:56] <SpamapS> Yeah I get it, you can force it to work by only relating it to services it is already deployed on top of
[04:57] <SpamapS> But, you can see where I'd think that sounds a whole lot like a scope: container relationship, right?
[04:57] <imbrandon> yea i do see that
[04:57] <imbrandon> but then thats a real limitation
[04:57] <imbrandon> where as if i leave it off  its not
[04:57] <imbrandon> its only a "would be better" kinda thing that is debateable
[04:58] <imbrandon> but i DO see your point
[04:59] <SpamapS> I think eventually, I'd rather see this charm have 2 requires, and 1 provides...
[04:59] <imbrandon> ugh i do gotta run a few and you'll likely be gone when i get back ( just a few minutes ) so catch ya in the morning man, openweek tomarrow with the OMG story :)
[04:59] <imbrandon> hrm that might be ok
[04:59] <SpamapS> the 2 requires are both scope container, one is the generic juju-info .. and the other is for services which implement the php-app interface.
[05:00] <imbrandon> yea
[05:00] <SpamapS> The provides is for network based logging into the daemon
[05:00] <imbrandon> well then the top php need not be container
[05:00] <imbrandon> but other than that yea
[05:01] <SpamapS> it does, because you need a way to pass local aspects
[05:01] <imbrandon> but i need a way to gather network ones too
[05:01] <SpamapS> without haveing to pass the hostname, and compare it to your own, so you know you are local and not remote, and can do things like restart services.
[05:02] <imbrandon> i was thinking about making all the service restarts config options anyhow
[05:02] <imbrandon> and doing it in config-changes
[05:02] <imbrandon> that would solve some othert issues as well
[05:02] <SpamapS> The network ones would be via the provides interface. I assume what you want is to deploy the daemon to only one app server service, but then log to it from many other services.
[05:03] <SpamapS> That would create issues though. The more config options that are needed to make the system work, the more one has to think about how to automate.
[05:03] <imbrandon> defaults
[05:03] <SpamapS> much better if it works well for 99% of use cases w/o configs
[05:03] <imbrandon> sure sane defaults
[05:03] <imbrandon> it would be more like protected class vars
[05:03] <SpamapS> does newrelic have any other interesting local-only data that it needs to know about your app?
[05:04] <imbrandon> is how it would be used
[05:04] <imbrandon> hrm yea
[05:04] <imbrandon> well
[05:04] <SpamapS> I assume most of it can be gleaned from the PHP modules, so just knowing how to configure that is all you need
[05:04] <imbrandon> hrm
[05:04] <imbrandon> alot of it is set in the actualy app booptstrap code
[05:04] <imbrandon> its self
[05:05] <imbrandon> other than that it guesses or you can manualy overidse in the newrelic.ini
[05:05] <imbrandon> really the main thing that NEEDS to be local is the app group anme and the app server uniq name
[05:06] <imbrandon> so like onthe omg webheads all have   "OMG-ALL;OMG-1"   "OMG-ALL;OMG-2"
[05:06] <imbrandon> etc
[05:06] <imbrandon> where N is $JUJU_MACHINE_ID
[05:06] <SpamapS> yeah
[05:06] <SpamapS> juju has a nice logical model for that :)
[05:07] <bkerensa> pah
[05:07] <imbrandon> they all agrogate to one and each ahve their own
[05:08] <imbrandon> in this i set it to JUJU-ALL;$JUJU_MACHINE_NAME
[05:08] <imbrandon> i think
[05:08] <imbrandon> but i wanna make that a config as well
[05:08] <SpamapS> this is wher ethe juju-info relation would come in handy
[05:08] <SpamapS> what you really want is OMG
[05:09] <SpamapS> so add a hook that records $JUJU_REMOTE_UNIT
[05:09] <SpamapS> since 'omg/0' is way more interesting than 'newrelic/0'
[05:09] <imbrandon> hrm, good idea
[05:09] <SpamapS> must be my lucky day :)
[05:09] <imbrandon> hehehe
[05:10] <imbrandon> yea i'll do thhat before i sack out, doing got a lot more left in me
[05:10] <imbrandon> but ok so is it in the store now ?
[05:10] <imbrandon> and ty ty btw
[05:10] <imbrandon> and how do i do updates ? more bugs ?
[05:10] <SpamapS> Yeah I'm pushing it now as-is
[05:10] <imbrandon> sweet ty
[05:11] <imbrandon> yea i'll make a few small changes to ngiht and also try to get the other newrelic ones ( minimum python and ruby )
[05:11] <SpamapS> imbrandon: if you want to own it, I'd be good with that. We can create a team which has you + charmers in it. Or you can get some other ~charmers person to +1 you and start reviewing charms too.. :)
[05:11] <imbrandon> thte latter is what i plan
[05:11] <imbrandon> just everyone been busy with releases
[05:11] <imbrandon> so i kinda held back
[05:12] <SpamapS> well is this your first promulgate? I can't believe that
[05:12] <imbrandon> drupal should ahve been many
[05:12] <imbrandon> weeks ago
[05:12] <imbrandon> but omg hit the fan
[05:12] <imbrandon> :)
[05:13] <imbrandon> and not that subs are out ( yea its been that long ) i wanna change it up some
[05:13] <imbrandon> now*
[05:13] <SpamapS> Yeah, subs are fun
[05:13] <imbrandon> but yea i got nginx and mysql ndb
[05:13] <imbrandon> local
[05:13] <imbrandon> and on github
[05:13] <imbrandon> but not ready
[05:14] <imbrandon> drupal and these newrelic ones and the omg playground
[05:14] <imbrandon> :)
[05:14] <imbrandon> ok gonna run a few, youll ber gone so i'll catchg ya tom man
[05:14] <imbrandon> ty ty
[05:15] <imbrandon> gotta do openweek tom
[05:15] <imbrandon> heheh
[05:15] <imbrandon> makin a slick graphic for it now
[05:15] <imbrandon> turning out much better than i had hoped
[05:16] <SpamapS> cool!
[05:16] <_mup_> Bug #993027 was filed: 'juju get' needs an option to produce the same yaml that 'juju set --config' will consume <juju:New> < https://launchpad.net/bugs/993027 >
[05:21] <imbrandon> SpamapS:
[05:21] <imbrandon> still round ?
[05:21] <imbrandon> http://cl.ly/GIxf
[05:22] <imbrandon> still needs work, but nice graffic to go along with Juju: the OMG!Ubuntu story :)
[05:23] <SpamapS> sparklies
[05:27] <imbrandon> lol
[05:28]  * imbrandon hugs photoshop
[05:32] <_mup_> Bug #993034 was filed: lxc deployed units don't support https APT repositories <juju:New> < https://launchpad.net/bugs/993034 >
[08:10] <mrevell> i
[08:36] <koolhead17> marcoceppi, ping
[10:13] <mgz> is there some way in juju to make it ssh to the instance IP rather than the hostname?
[10:17] <mgz> ...seems not, ProviderMachine takes dns_name and private_dns_name only
[11:10] <m_3_> mgz: for some providers you might get away with adding .ssh/config that includes entries to a.) get to the bootstrap node, and b.) proxy through the bootstrap node for other instances
[11:11] <mgz> m_3_: so, my immediate problem is canonistack doesn't seem to work unless I manually edit my .ssh/config with the details of the bootstrap node
[11:12] <mgz> if that's the current expected state, I guess that's okay.
[11:12] <m_3_> mgz: yeah, afaik that's the current state of affairs with openstack installs
[11:13] <m_3_> mgz: or drive juju from "inside" the openstack cloud itself... provided you can route to the endpoint urls
[14:04] <_mup_> Bug #993288 was filed: Provide an option to specify creation of a new instance upon deployment <juju:New> < https://launchpad.net/bugs/993288 >
[14:12] <SpamapS> bbcmicrocomputer: Confirmed your bug, good idea. :)
[14:45] <bbcmicrocomputer> SpamapS: ah cool :)
[14:53]  * flepied is happy to have a working mongodb charm using his own configuration engine and having the change port test working
[15:01] <SpamapS> bbcmicrocomputer: just finished a review of your solr charm. REALLY nice work. You can ping me in here as soon as you address the issues.
[15:01] <SpamapS> flepied: Is this an evolution of the existing one, or a total rewrite?
[15:01] <bbcmicrocomputer> SpamapS: ok thanks
[15:01] <flepied> SpamapS, it's based on the mongodb one
[15:02] <SpamapS> flepied: cool. :) If you want to propose it as a merge into the existing one we'll review that just like we review new charms.
[15:02]  * SpamapS points in a circle at all the other ~charmers members *YOU* will all review it, right?! RIGHT
[15:04] <flepied> SpamapS, I don't think it can be used by anyone else at this point as it uses my adminkit config engine and adminkit needs to be preloaded on the image before beeing used
[15:05] <m_3_> SpamapS: right
[15:06] <flepied> but if someone is curious, just look at https://code.launchpad.net/~flepied/charms/precise/mongodb/adminkit
[15:27] <m_3_> argh... leaking security groups in autotesting
[15:28] <m_3_> gonna start having to use eucatools and ec2 tools to avoid things like 'cross-fingers; destroy-environment; sleep 120; destroy-environment; pray'
[15:29] <SpamapS> m_3_: something cares if there's already a group?
[15:30] <SpamapS> m_3_: perhaps you need to bump the env name
[15:31] <m_3_> yeah, that would work... but then I'd be leaking them longer-term
[15:31] <m_3_> didn't think about tmp-envs tho... good idea
[15:31] <m_3_> might be just lagging cleanup of sec grps
[15:33] <SpamapS> m_3_: its probably worth adding an option to bootstrap like --nuke-from-orbit to make sure the old env is gone before bootstrapping
[15:34] <jimbaker> m_3_, security group reuse along the lines of what was done in the go port is probably a good idea
[15:34] <m_3_> SpamapS: yeah, I did that with local providers (mostly remove data_dir)
[15:34] <m_3_> jimbaker: yeah, we've been informed that the current way we use groups will need to be limited in ec2
[15:35] <m_3_> jimbaker: simply not enough available to really scale
[15:35] <jimbaker> m_3_, right
[15:35] <SpamapS> OH, does ec2 actually hvae a limit?
[15:36] <m_3_> SpamapS: but I'll have to do something different to nuke envs in ec2/openstack... hence the ec2tools/eucatools... perhaps
[15:36] <m_3_> SpamapS: longer quiet periods between tests don't seem to suffice
[15:36] <SpamapS> m_3_: sounds like a job for jitsu :)
[15:36] <m_3_> SpamapS: yup!
[15:37] <m_3_> SpamapS: all this stuff's going into jitsu
[15:37] <SpamapS> werd
[15:37] <SpamapS> I need to finish getting the stable releases -> ppa automated
[15:41] <lynxman> jcastro: ping
[15:50] <_mup_> Bug #993372 was filed: terminate-machine should accept an option for --all-unused <juju:New> < https://launchpad.net/bugs/993372 >
[17:15] <AlanBell> hi all, I am having a problem with juju bootstrap, I have rebooted, but I still get error: internal error Network is already in use by interface virbr0
[17:15] <AlanBell> I do have virtualbox installed if that is relevant
[17:18] <AlanBell> I just added myself to the libvirtd group and it worked \o/
[17:18] <AlanBell> maybe it should do that automatically?
[17:19] <koolhead17> AlanBell, file a bug if you think something is missing :)
[17:19] <SpamapS> AlanBell: when you install libvirt-bin, all administrators are added to that group
[17:20] <AlanBell> I am an administrator (single user default precise desktop installed yesterday)
[17:20] <SpamapS> AlanBell: though it sounds like juju needs to explicitly check for that group membership.
[17:23] <AlanBell> hmm, so running juju with no arguments should create ~/.juju/environment.yaml?
[17:23] <AlanBell> it doesn't
[17:30] <AlanBell> I set up the environment.yaml manually, it seems to run without error but very very fast and I don't think it is doing anything http://paste.ubuntu.com/962806/
[17:31] <AlanBell> here is my environments.yaml http://paste.ubuntu.com/962809/
[17:34] <SpamapS> AlanBell: it takes a long time to build the first container
[17:34] <AlanBell> then again, it may have actually worked
[17:34] <AlanBell> gosh, it did
[17:34] <SpamapS> AlanBell: has to bootstrap mini-ubuntu .. and then install juju on top of that
[17:35] <AlanBell> I installed an SSD yesterday, not used to the speed and silence, didn't realise it was doing stuff!
[17:35] <AlanBell> I appear to have a working wordpress install
[17:37] <SpamapS> Yeah SSD's suddenly rob you of the scratchy sound of "I'm Busy"
[17:37] <SpamapS> AlanBell: woot
[17:41] <AlanBell> so where are these virtual machines it created? they are not in ~/.juju or the environment working directory ~/Projects/juju
[17:41] <AlanBell> there is stuff in there, but only 264k
[17:41] <SpamapS> /var/lib/lxc
[17:42] <AlanBell> 2GB of stuff there, that sounds about right
[17:46] <SpamapS> yeah, I think its about 600MB per container usually
[19:08] <jcastro> SpamapS: can you review and promulgate something? We're 1 away from 70. :)
[19:29] <_mup_> Bug #993492 was filed: Wrong error message when calling remove-relation with a subordinate charm <juju:New> < https://launchpad.net/bugs/993492 >
[19:37] <SpamapS> jcastro: I'm reviewing dokuwiki right now actually
[19:37] <SpamapS> jcastro: and solr is very close :)
[20:03]  * SpamapS rings the bell
[20:03] <SpamapS> dokuwiki promulgated
[20:03] <SpamapS> jcastro: ^^
[20:06] <marcoceppi> I thought we had a glouster charm?
[20:06] <SpamapS> I think somebody was messing with that
[20:06] <SpamapS> It really needed subs
[20:07] <SpamapS> Same w/ ceph really. I need to write a ceph-client sub
[20:07] <SpamapS> we should probably start slow w/ an NFS-client sub
[20:08] <SpamapS> I really just want to sit and rewrite half the old charms I wrote to be way more awesomer w/ subs.
[20:09] <marcoceppi> SpamapS: that's kind of what I need now
[20:10] <marcoceppi> a Glouster like sub
[20:10] <marcoceppi> I guess it's about time it gets written
[20:11] <marcoceppi> SpamapS: can subs open ports yet?
[20:15] <SpamapS> marcoceppi: no :(
[20:20] <marcoceppi> SpamapS: it's too bad, Glouster would be really easy to charm if I could just open those ports
[20:21] <marcoceppi> I wonder why it doesn't actually work
[20:22] <SpamapS> marcoceppi: wait, why do you need to open ports?
[20:22] <SpamapS> marcoceppi: thats only for *external* access
[20:22] <marcoceppi> DUH
[20:22]  * marcoceppi is so silly
[20:23] <SpamapS> marcoceppi: for a client.. you don't need anybody accessing their local gluster daemons :)
[20:24] <marcoceppi> So, next question, if a charm is a sub, and I juju add-unit to the parent of the sub, will the sub be re-deployed on the new unit (I assume yes) and if so will the peer relation be fired?
[20:28] <SpamapS> marcoceppi: yes
[20:29] <SpamapS> marcoceppi: do you believe in magic? :)
[20:29] <marcoceppi> SpamapS: http://i.imgur.com/f2qPJ.jpg
[20:30]  * SpamapS lols, like, literally
[20:42] <marcoceppi> I think I'm going to end up writing three charms just to author this one charm
[20:45] <SpamapS> marcoceppi: awww yeah thats how the sexy charmers do it, http://on.mtv.com/IYDYWJ
[20:47] <marcoceppi> awwww yeah
[20:51] <nathwill> i... this falls under the category of "can't unsee"
[20:51]  * nathwill shudders
[20:56] <SpamapS> :-D
[20:56] <SpamapS> nathwill: awwwwwwwwwyeah
[21:01] <_mup_> Bug #993552 was filed: Charm store should automatically close any bugs marked using '--fixes' when charm is published. <juju:New> < https://launchpad.net/bugs/993552 >
[21:08] <_mup_> Bug #993557 was filed: Charm store should delete charms that have been removed. <juju:New> < https://launchpad.net/bugs/993557 >
[22:42] <gmb> Hi folks. juju deploy is telling me that a charm doesn't exist in a local repository. AFAICT, it does - and juju was working before an update & reboot. How can I debug this problem?
[22:42] <gmb> s/and juju/this juju deploy command/
[22:46] <SpamapS> gmb: pastebin?
[22:48] <gmb> SpamapS, http://pastebin.ubuntu.com/963475/
[22:48] <SpamapS> gmb: and I assume under /home/graham/launchpad/workspace/juju-charms/precise , you have a dir named 'launchpad-clinic' ?
[22:49] <SpamapS> gmb: whose metadata.yaml also has name: launchpad-clinic ?
[22:50] <gmb> Oh, big hairy arse.
[22:50] <gmb> SpamapS, I forgot I'd renamed the charm but not updated metadata.yaml. Thanks :)
[22:50] <SpamapS> that name: bit will bite you ever time. I just added a charm proof rule to warn people
[22:50] <gmb> Awesome, ta.
[22:53] <_mup_> Bug #993616 was filed: We should ship a boilerplate environments.yaml. <juju:New> < https://launchpad.net/bugs/993616 >
[23:23] <SpamapS> marcoceppi: hey, been reading a few of your reviews. start/stop are not just for the here and now of charms. They're separate hooks from install because they are meant to be run when units are migrated between hosts or rebooted.
[23:23] <SpamapS> marcoceppi: at the moment, they're not used, but I'd like to see new charms implement them as their own, independent entities that can be run at any time.


[01:04] <Unit193> Does anyone on the Xubuntu team (or contributors) use xfdashboard?
[11:14] <bluesabre> Unit193: I do not


[17:42] <sidh> Greetings
[17:42] <sidh> I just opened a ticket on Launchpad and a bot asks me to qualify a package that is faulty
[17:43] <sidh> https://bugs.launchpad.net/ubuntu/+bug/1952114
[17:43] <sidh> well i don't know if it's grub, or zsys or ...
[17:43] <sidh> could you help to define the package culprit ?
[17:44] <sidh> I really need to solve this bug, as I fear to update my workstation because of this grub boot error
[17:48] <sidh> and I fear running out of battery too :(


[08:46] <ppisati> moin
[08:46] <smb> morning
[09:37] <ashwini> is there any link to know how to use kgdb over ethernet with kernel 3.x ??
[09:53] <apw> zequence, no that is fine for now, but for next time yes
[10:53] <ppisati> brb
[10:54] <hrw> hi
[10:55] <hrw> is https://help.ubuntu.com/community/Kernel/Compile still the only source of 'how to adapt ubuntu kernel to your needs'?
[11:05] <smb> hrw, There would also be https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel. Though it just might be 'different' and not add much more... not sure
[11:06] <henrix> ogasawara: do you know who could verify bug #1103320?
[11:06] <hrw> anyway 'debian/rules editconfigs' just kill my whole config anyway
[11:06] <ubot2> Launchpad bug 1103320 in linux (Ubuntu Quantal) "Ubuntu 13.04 and 12.04.2: Login screen does not appear after installing OS on SL4545 G7" [Medium,Fix committed] https://launchpad.net/bugs/1103320
[11:07] <smb> hrw, not sure I understand. It will run menuconfig with presets taken from the current flavour configs and saves them there...
[11:09] <hrw> smb: before: 75624 config.flavour.chromebook after: 93 bytes of comments only
[11:11] <smb> hrw, If the setting will not affect other flavours or is commonly used, things may get moved to one of the higher level config files (even config.common.ubuntu)
[11:13] <hrw> smb: in other way: if just one kernel is built from tree then flavour file is just placeholder and all is moved to common/
[11:13] <hrw> time to kill enforce checks
[11:15] <ogra_> that means you will miss ubuntu options the userspace needs
[11:15] <ogra_> well ... you risk to miss them at least
[11:16] <smb> hrw, If that flavor actually has nothing from either the architecture or common configuration I would say yes. apw <-- ^ ?
[11:16] <hrw> smb: it is chromebook kernel which I am trying to update
[11:16] <smb> hrw, And as ogra_ said those checks are there for a reason.
[11:17] <hrw> sure, I know that
[11:17] <apw> hrw,smb, right if you have one flavour the then all of the settings are common and move up
[11:18] <apw> you can confirm the config is the same however by 'debian/rules genconfigs' and looking at CONFIGS/<name>
[11:19] <hrw> CONFIG_USB_DEVICEFS is listed as deprecated. ubuntu still requires that?
[11:20] <apw> seems to no longer exist in raring at least
[11:20] <apw> if that is an accurate spelling
[11:21] <hrw> I have 3.4 kernel
[11:21] <apw> debian.master/config/enforce:value CONFIG_USB_DEVICEFS n
[11:21] <apw> and we insist it is off, not on ?
[11:21] <hrw> ahm right
[11:22] <hrw> ogra_: can CONFIG_GPIO_TWL4030 land in omap kernels only (enforcement)?
[11:22] <ogra_> not sure how configs vs. dtb will work but sure
[11:26]  * ppisati goes out for lunch
[11:27] <hrw> few more enforces to kill and kernel should get to state where I can try to build
[11:31] <hrw> check-config: 41/41 checks passed -- exit 0
[11:31] <hrw> uf.
[11:33] <hrw> there were few other things which I would love to kill but no time
[11:34] <hrw> thanks guys
[12:52]  * cking going offline, electrical supplier is doing meter upgrade soon
[13:40] <ogasawara> henrix: i'll ping narinder to verify 1103320.  he not online yet, but will be in a few hrs.
[13:40] <henrix> ogasawara: great, thanks
[14:57]  * henrix -> reboot
[15:39]  * ogasawara back in 20
[15:48] <infinity> apw: I can haz meta-lowlatency to match the kernels?
[16:00] <apw> infinity, yeah i am doing them right now
[17:02]  * ppisati -> gym
[17:02] <ogasawara> infinity: random question re: the clean old kernels stuff, I thought you'd completed that work?
[17:04] <infinity> ogasawara: It's mostly complete in raring, except for some "polish" work items.
[17:04] <infinity> ogasawara: We haven't backported it to precise, which was also a goal.
[17:05] <ogasawara> infinity: ack, thanks.  I had a random work item to check up on it's status.
[17:06] <infinity> ogasawara: Oh, right, I saw that WI in passing. :)
[17:06] <infinity> ogasawara: I think you'd checked.  DONEify it.
[17:10] <apw> infinity, in better news it even seems to work for me :)
[17:36] <infinity> bjf: Want to do a manual shankbot run for me to see if it wants to update the lowlatency tracking bugs?  I'm trying to sort out of Andy bollocksed them again, or if I'm just impatient. :)
[17:37] <bjf> infinity, ack
[17:42] <infinity> bjf: Oh, I see.  It takes two iterations. :/
[17:42] <infinity> bjf: First one sets upload-to-ppa as Fix Release, second sets the promote-to-proposed task to Confirmed.  Weird.  Why the artificial delay?
[17:43] <bjf> infinity, just the way it's coded
[17:43] <infinity> bjf: (And one more run to fix that, please? :P)
[17:43] <bjf> infinity, i'm runing it multiple times
[17:43] <bjf> infinity, it doesn't loop on one bug/task until there is nothing to do
[17:43] <infinity> Ahh, so you are.  It caught up to where I wanted it now. :)
[17:44] <infinity> Cheers.
[17:44] <bjf> infinity, i'm giving it one more for good measure
[17:45] <ogasawara> apw: refresh my memory, you'd written a script we'd run after we rebase that would insert any BugLinks fixed in the latest rebase into our changelog
[17:45] <ogasawara> apw: I can't remember the name of that script
[17:45] <apw> ogasawara, insert-upstream-changes
[17:45] <apw> debian/scripts/misc
[17:45] <ogasawara> apw: ah, thanks!
[17:45] <ogasawara> apw: I was looking in kteam-tools and was having no luck
[17:46] <apw> heh
[17:56] <einonm> Hullo, I've just posted a patch to the kernel-team list to fix an ubuntu kernel issue I discovered (Bug #1105250) ... the patch is probably also needed in the upstream kernel - what's the general procedure for that? Should I just post the patch upstream and wait for it to trickle down to you, or is a direct patch to ubuntu-kernel also good?
[17:56] <ubot2> Launchpad bug 1105250 in linux (Ubuntu) "MSI laptop, crash on first suspend and suspend fails thereafter" [Medium,Incomplete] https://launchpad.net/bugs/1105250
[17:59] <jsalisbury> einonm, yes, it's best to send the patch upstream for inclusion.  I can post a comment in the bug on how to do that.
[18:00] <einonm> jsalisbury: Thanks. I've got a linux-next tree, so just run the usual get-maintaners on that, but also cc an ubuntu email?
[18:02] <jsalisbury> einonm, yes, get-maintainers will tell you who to send it to.  Be sure to cc stable.  There is some info in the source tree ~/Documentation/stable_kernel_rules.txt
[18:02] <einonm> great, will do.
[18:03] <jsalisbury> einonm, thanks.
[18:09] <bjf> :w
[18:46] <zequence> apw: The lowlatency meta for precise, is it still wrong?
[18:46] <apw> 'still wrong' ?
[18:46] <zequence> The wrong version
[18:47] <apw> looks to match to me in the current pocket versions ?
[18:48] <apw> linux-meta-lowlatency | <IP_ADDRESS>.26 | precise-security/universe | source
[18:48] <apw> linux-meta-lowlatency | <IP_ADDRESS>.26 | precise-updates/universe | source
[18:48] <apw> linux-lowlatency | 3.2.0-36.36 | precise-security/universe | source
[18:48] <apw> linux-lowlatency | 3.2.0-36.36 | precise-updates/universe | source
[18:48] <zequence> One ends with 26, and the other with 36
[18:48] <zequence> But, that's ok?
[18:49] <apw> zequence, no that is right.  the last number is the upload number for the package
[18:49] <apw> so there has been 10 more uploads of the kernel than meta, which happens as you only
[18:49] <bjf> jjohansen, bug 1106992
[18:49] <apw> bump meta when there is an abi bump
[18:49] <ubot2> Launchpad bug 1106992 in linux (Ubuntu) "tomoyo version mismatch, kernel panic" [Medium,Confirmed] https://launchpad.net/bugs/1106992
[18:50] <zequence> apw: So, I can go ahead and test them now?
[18:50] <apw> i am unsure if they ahve been copied out of the PPA as yet, do not appear to be yet
[18:50] <jjohansen> bjf: okay I'll bug tetsuo and see what he says we should do
[18:51] <zequence> Ah, a bit later than..
[18:51] <bjf> jjohansen, thanks
[18:53] <apw> zequence, ahh they were copied out 18 minutes ago, so the -23 and -37 versions are ready to go yes
[18:54] <zequence> apw: Alright
[19:05] <smb> :q
[19:52] <chiluk> Hey everyone sorry for the improperly formated SRU mail on kernel-team .  Live and learn.
[19:52] <chiluk> if it's still wrong feel free to let me know.
[19:54] <bjf> chiluk, np
[19:54] <bjf> chiluk, still wrong
[19:54] <chiluk> nuts.
[19:54] <bjf> chiluk, :-P
[19:54] <chiluk> what should I have done differently?
[19:54] <chiluk> I was trying to follow https://wiki.ubuntu.com/KernelTeam/KernelUpdates
[19:54] <chiluk> perhaps the wiki page needs to be more pedantic ?
[19:55] <bjf> chiluk, how long have you been following the mailing list?
[19:56] <chiluk> not long enough... only a few weeks.
[19:56] <bjf> chiluk, i'd point you at one if you've been there a while
[19:57] <bjf> chiluk, do you have the brcmsmac patch from seth in your history? if so look at the patch 0/1 patch 1/1 mail for comparison
[19:58] <chiluk> I do. reading..
[19:59] <bjf> chiluk, so basically, the SRU text is correct, the patch shouldn't come in as an attachment
[20:00] <chiluk> ok.
[20:02] <chiluk> bjf, so what's the special sauce, that formats the patches and sends the e-mail?
[20:03] <chiluk> git-send-email I'm assuming?
[20:05] <bjf> chiluk, that's what i use though i have a script which has all the command line options that i want
[20:06] <bjf> git send-email --no-chain-reply-to --thread --suppress-cc all --from "Brad Figg<EMAIL_ADDRESS>--to<EMAIL_ADDRESS>$1
[20:06] <bjf> chiluk, ^
[20:06] <chiluk> thanks bjf.
[20:06] <bjf> chiluk, np
[20:08] <infinity> bjf: And now he's going to send a patch to the list from you. ;)
[20:08] <chiluk> give me at least a little credit.
[20:08] <bjf> infinity, it's how i get credit
[20:08] <bjf> dang
[20:08] <infinity> chiluk: Where's the fun in that?
[20:09] <chiluk> do you guys want me to send yet another e-mail? or do you want me to just do it right the next time around?
[20:14] <chiluk> bjf infinity ^ ?
[20:15] <bjf> chiluk, you can make the call. if you want to try git-send-email, that's cool otherwise we'll deal with it as it is
[20:16] <chiluk> alright, I'll probably be sending out another SRU either later today or tomorrow.
[20:16] <chiluk> so I'll git-send-email on that one.
[20:17] <bjf> chiluk, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
[20:18] <bjf> chiluk, also not that the patch needs to have the "BugLink: " line in it
[20:25] <chiluk> I'll make that piece a bit more obvious in the wiki.
[20:26] <bjf> chiluk, on the wiki page i referenced it is #1 in the comment body section
[20:27] <bjf> chiluk, also, there is a python tool we have that is very usefull for adding all this "stuff"
[20:27] <chiluk> linkage
[20:27] <chiluk> ?
[20:27] <bjf> was getting there :-)
[20:28] <bjf> chiluk, git clone kernel.ubuntu.com:/ubuntu/kteam-tools
[20:28] <chiluk> and what's the wiki page you referenced above?  I only see one reference to buglink on the kernelUpdates page.
[20:28] <bjf> chiluk,  kteam-tools/stable/bug-mod
[20:29] <bjf> chiluk, https://wiki.ubuntu.com/Kernel/Dev/StablePatchFormat
[20:30] <chiluk> hmm looks like the sru page might be better served by pointing to your link
[20:31] <bjf> chiluk, probably, feel free to do so
[20:31] <chiluk> will do.
[20:31] <bjf> chiluk, the wiki is "kind of" a mess
[20:31] <chiluk> that's what the new guys are for right?
[20:32] <bjf> to make it messier? yup :-P
[20:32] <chiluk> lol
[23:52] <brennan> hello room
[23:52] <brennan> how do you upgrade the dist?
[23:53] <brennan> ????????????????????
[23:54] <ppisati> sudo apt-get update && sudo apt-get dist-upgrade?
[23:54] <ppisati> brennan: &
[23:54] <ppisati> ^
[23:54] <brennan> thanks man
[23:54]  * ppisati -> EOD


[21:32] <dzho> yeah that's an ugly business
[21:33] <dzho> i was a little worried when the talk first popped up of doing yet another community distro to fill the hole left by the CentOS pivot
[21:33] <dzho> because it was "talk with us in Slack or see our Github!"
[21:34] <dzho> but they've added other communication methods so it's not quite so corporate silo
[21:35] <dzho> and #rockylinux has >500 nicks in it, many via the Matrix bridge
[22:03] <cmaloney> if you were using the Ubuntu Michigan Loco Google Calendar I'm sad to inform you that it no longer exists.
[22:04] <cmaloney> Please form an orderly queue for your weeping.
[22:08] <greg-g> :'(
[22:08] <greg-g> ;)
[22:09] <cmaloney> Just deleted the page as well. Goodbye, holdover from G+
[22:17] <greg-g> ahhh, that's what that mastodon post was about :)
[23:09] <cmaloney> ayep