[00:00]  * SpamapS EOD's
[02:38] <adam_g> SpamapS: re: rabbitmq. no, none of those ~openstack-ubuntu-testing charms are relevant to anything outside of that jenkins lab
[03:36] <_mup_> juju/unit-rel-lifecycle-start-invoker r535 committed by<EMAIL_ADDRESS>[03:36] <_mup_> Merged trunk
[03:39] <_mup_> juju/unit-rel-lifecycle-start-invoker r536 committed by<EMAIL_ADDRESS>[03:39] <_mup_> Addressed review points
[03:50] <jimbaker> adam_g, i just committed the fix for working with relation ids from relation hooks to trunk. SpamapS, this is a trivial one-liner and imho should be included asap in the juju distro
[03:51] <jimbaker> along the lines of other recent fixes we have had
[04:51] <adam_g> jimbaker: cool. if theres an SRU bug somewhere, i can verify. or let me know, and ill file one
[12:35] <imbrandon> SpamapS: i think rs is gonna be the way to go for sites similar to OMG, or ones setup to scale the same way
[12:36] <imbrandon> mainly because of their small servers that have 265mb ram but 4x2.2ghx proc and can sustain high cpu task
[12:36] <imbrandon> so bootstrap on a tiny
[12:37] <imbrandon> mysql on a something not considered here but seperate as is now
[12:37] <imbrandon> cluster or not etc
[12:37] <imbrandon> and each webhead ona  tiny but lots of them
[12:37] <imbrandon> cuz right now the OMG webheads are maxing the cpu's but use very little other resources
[12:38] <imbrandon> so scaleing them out to many of these ultra tiny webheads that have lots of cpu makes sense
[12:39] <imbrandon> ( just thinking out loud here, as i prep the same charms to deploy websitedevops.com )
[12:40] <imbrandon> oh and the tiny's are 0.01c hr , vs 0.08 for mediums on aws
[12:41] <imbrandon> so couple that with some rrdns and the lb setup we adopted
[12:41] <imbrandon> = win
[13:04] <imbrandon> SpamapS: http://cl.ly/GNEY  <--- thats pretty avg accross the 3 current webheads , 15 to 25 Mb/s traffic, 30ish % of the 1.6 G ram used and 1.0 sys load
[13:08] <imbrandon> kinda strange to me, past experince has always been the ram not cpu on webheads
[13:08] <imbrandon> heh
[14:30] <marcoceppi> bkerensa: Are you working on the OpenPhoto charm?
[14:44] <SpamapS> imbrandon: the reason the RAM isn't running out is because of the heavy caching, you don't need many active processes
[14:45] <bkerensa> marcoceppi: yes
[14:46] <marcoceppi> bkerensa: ah, wasn't sure
[14:46]  * SpamapS wishes mediagoblin was easier to package, he'd finish it and get it promulgated
[14:47] <SpamapS> actually what I really wish is that pip installs used https
[14:47] <marcoceppi> Time for a patch?
[14:47] <SpamapS> no, pypi doesn't have https
[14:47] <SpamapS> Though we *could* mirror pypi into a launchpad project.....
[14:48] <SpamapS> but, no, thats silly. Packaging isn't actually that hard, I just need to finish it
[14:49] <imbrandon> SpamapS: yea, just thought it was unique
[14:49] <marcoceppi> bkerensa: I read your G+ post about openphoto and I was like "YES THEY HAVE A REPO" and then I saw the install script they made, which is like 90% charm ready
[14:50] <marcoceppi> s/G+/planet/
[14:50] <SpamapS> imbrandon: its actually really encouraging. :)
[14:50] <SpamapS> imbrandon: leaves RAM for VFS cache and stuff. The webheads are doing the cache of files, right?
[14:53] <bkerensa> marcoceppi: yep and I have it partially done and hope to have it fully done by the deadline... I might pick your brain to make it more frosty but right now I have to go pack :D
[14:54] <marcoceppi> I should probably pack soon too. I have too many social engagements leading up to my departure Sunday morning
[14:55] <m_3_> SpamapS: oh, btw, the new version of rubygems checks https certs... saw the release notes at conference
[14:56]  * m_3_ has to check that against the version we have in precise
[14:59] <imbrandon> SpamapS: yup
[15:19] <marcoceppi> Can a relation hook both set and get relational data?
[15:20] <m_3_> marcoceppi: yup
[15:20] <marcoceppi> spectacular
[15:21] <SpamapS> m_3_: sweet
[15:21] <m_3_> marcoceppi: the conversation keeps firing as long as either hook keeps _set_ting relation data
[15:21] <SpamapS> marcoceppi: there are a few, like mysql replication, that do several rounds of back and forth relation get/sets
[15:27] <marcoceppi> I think that's what I want do to for gluster
[15:28] <marcoceppi> instead of just having one giant shared fs, each charm should have it's own brick so the gluster client and gluster server need to keep up communication
[15:28] <m_3_> marcoceppi: the coolest part of gluster is that we now have subordinates!
[15:28] <marcoceppi> m_3_: I know! That's why I've started working on proper subordinate gluster-server/client charm pair
[15:28] <m_3_> marcoceppi: that's the hard part... specifying the striping config you want from the clients
[15:28] <marcoceppi> m_3_: I figured just config value for each gluster-client
[15:29] <marcoceppi> there's only 4 different types of stripes
[15:29] <marcoceppi> unfortunately this is only a segue charm pair so I can get back to work on my main charm of interest
[15:31] <m_3_> marcoceppi: yeah, the client should get the makeup of the entire volume its currently using as config... not easy though
[15:32] <m_3_> marcoceppi: maybe the stack startup script would specify the volume composition, then pass that into the config for the client... dunno how to discover that dynamically though.  maybe see what clint did on ceph
[15:36]  * imbrandon gigles a little inside at seening his newest charm have "#!/usr/bin/env php" at the top of hooks
[15:38] <imbrandon> SpamapS: is it nessesary to have a requires in the metadata ?
[15:42] <bkerensa> imbrandon: we still have no solid time/day for cloudflare?
[15:42] <bkerensa> :(
[15:42] <imbrandon> bkerensa: no worries, it will work out
[15:42] <imbrandon> and if not there is always next time
[15:43] <bkerensa> imbrandon: Im sure they will be there pretty much 9 to 5
[15:43] <bkerensa> :D
[15:43] <bkerensa> so long as a I ping @eastdakota half hour before we head out they can prepare
[15:43] <imbrandon> bkerensa: my goal is to be out on the left coast by this time next year anyhow :)
[15:43] <imbrandon> :)
[15:43] <bkerensa> for work/living?
[15:43] <imbrandon> yea
[15:44] <bkerensa> is that what were known as in the red states?
[15:44] <bkerensa> The left coast?
[15:44] <imbrandon> hahaha
[15:44] <imbrandon> pretty much
[15:44] <tooth> also matters what continent.
[15:44] <bkerensa> for good reason probably
[15:44] <bkerensa> :D
[15:44] <imbrandon> brb afk
[15:44] <marcoceppi> Will `relation-list` in a peer relation list the current unit?
[15:45] <imbrandon> marcoceppi: i dont think so, thats why the 127 in the omg
[15:45] <imbrandon> lb relation
[15:58] <marcoceppi> Gluster seems like it's this huge thing, but so far it looks really straight forward to setup
[15:59] <jcastro> I see your incoming charm
[16:00] <jcastro> Yeah I set it up, it was dead easy
[16:04] <bkerensa> anyone want to review locker charm? :)
[16:07] <SpamapS> marcoceppi: the question is, how to get charms to mount gluster
[16:07] <marcoceppi> SpamapS: that's what I'm trying to figure out in an elegant fashion
[16:08] <marcoceppi> Charms will have to expect gluster current
[16:08] <SpamapS> marcoceppi: or, perhaps, charms should just have a 'scope: container' relationship where they ask for a place to put their data
[16:08] <SpamapS> marcoceppi: interface: mount
[16:09] <SpamapS> marcoceppi: then gluster, nfs, and ceph, all have subordinates which speak that interface, and tell them "put it here..." and mount the data there
[16:09] <marcoceppi> In fact, the way I have the gluster-client currently setup, it expects two relations, juju-info and a shared-fs relation where the charm tells gluster where the mount point should be
[16:09] <SpamapS> marcoceppi: \o/
[16:09] <marcoceppi> yeah, figured that was the best way for now
[16:09] <SpamapS> thats perfect
[16:10] <SpamapS> we should do NFS too... just for the "never do this" case. :)
[16:10] <marcoceppi> SpamapS: already did that too :)
[16:10] <marcoceppi> gluster-server charm has a direct NFS relation
[16:10] <SpamapS> marcoceppi: I'm going to give jcastro some cash so he can buy you beers all the nights I'm not there next week ;)
[16:10] <marcoceppi> so you can use the gluster-client, or just add-relation to the nfs interface on the main charm
[16:11] <SpamapS> marcoceppi: the NFS interface isn't as fault-tolerant though.. is it?
[16:11] <marcoceppi> and not as robust
[16:11] <SpamapS> so.. IMO.. leave it out
[16:11] <SpamapS> its for non Linux clients
[16:12] <marcoceppi> SpamapS: http://i.imgur.com/hZf6H.jpg
[16:18] <imbrandon> ugh
[16:18] <imbrandon> getting a little confused
[16:18] <imbrandon> http://paste.ubuntu.com/967228/
[16:18] <imbrandon> SpamapS marcoceppi ^^
[16:18] <bbcmicrocomputer> Have a Q.. when you have a one to many relation between say service A, B and C, e.g. A->C , A->B, when C breaks its relation with A, A's relation-broken hook doesn't appear to have a means of telling whether it's relation with B or C is being broken, so it seems impossible to make the hook idempotent, anyone know any answers?
[16:19] <jcastro> SpamapS: get in line.
[16:19] <SpamapS> bbcmicrocomputer: there is a way, its just not obvious
[16:19] <SpamapS> bbcmicrocomputer: and many charms don't make use of it, because it only landed in recent juju versions
[16:20] <SpamapS> bbcmicrocomputer: $JUJU_RELATION_ID
[16:20] <SpamapS> bbcmicrocomputer: you can enumerate the relations with the relation-ids command
[16:20] <bbcmicrocomputer> SpamapS: ah cool, will investigate
[16:21] <SpamapS> imbrandon: that looks good. assuming then that its just for serving static content?
[16:21] <imbrandon> yea i want the websites to determine the
[16:21] <imbrandon> dynaic part
[16:21] <imbrandon> but not sure how to handel that yet
[16:22] <imbrandon> e.g if they want to use uwsgi or php or whatever
[16:22] <SpamapS> imbrandon: in addition to 'webroot' perhaps have an interface 'fcgi-socket' ?
[16:23] <imbrandon> hrm
[16:23] <imbrandon> would that be an interface or just a config
[16:24] <SpamapS> imbrandon: youc an feed back 3 things .. fcgi-socket, static-wwebroot (for the "if it exists just serve from there"), and 'cache-url-patterns' for the thing to define where to look for cached pages.
[16:25] <imbrandon> as it is right now , i want this to be the base charm, not sub, and provide a nginx that is both a content on 8080 and 80 like the omg
[16:25] <SpamapS> imbrandon: interface definitely
[16:25] <imbrandon> and then yea have "sites" as subcharms
[16:25] <imbrandon> even frameworks and then sites
[16:25] <SpamapS> imbrandon: right, so nginx is primary, opens ports, etc. Then you have 'omg-wp' as a subordinate that drops its files in, and tells nginx how to serve it'
[16:25] <imbrandon> yea
[16:25] <imbrandon> exactyly
[16:26] <SpamapS> you can relate subs to other subs btw
[16:26] <imbrandon> yea , i was thinking this as the base and then sub be wp, then sub of that be omg-wp
[16:26] <imbrandon> was my plan
[16:26] <imbrandon> but also support like marcoceppi gluster etc
[16:26] <SpamapS> so while it will be a bit wonky, you can have 3 tiers of relations on a box.. like...  nginx->php-fcgi->wordpress (and then get crazy, ->omg-themes)
[16:26] <imbrandon> thus the other optional bits
[16:27] <imbrandon> SpamapS: yea ,e xactly
[16:27] <imbrandon> well omg-something as it would be themes+plugins
[16:27] <imbrandon> but yea
[16:27] <SpamapS> imbrandon: perhaps I will write an Apache 2.4 charm w/ the same interfaces, and we can have a shootout. :)
[16:27] <imbrandon> :) rockin
[16:27] <imbrandon> lll
[16:28] <imbrandon> i rally want so seperate it too at some point
[16:28] <imbrandon> but not in time for the contest
[16:28] <SpamapS> imbrandon: one thing I want to do is enhance the http interface with an 'endpoint-host' that can be set by either side. I'm not sure which one should take precedence though.. upstream or downstream.
[16:28] <imbrandon> as in seperate the nginx lb+cache and the 80
[16:28] <imbrandon> so apache could be the content serving
[16:29] <balloons> allo, mes amis.. So I'm looking at this page now: https://juju.ubuntu.com/docs/getting-started.html#configuring-your-environment. It says to run juju without arguements to generate an example enviroments.yaml.. That doesn't seem to work.
[16:29] <imbrandon> SpamapS: yea i had that question too, just wasent sure how to articualte it yet
[16:29] <balloons> Juju just responds with the argument list
[16:29] <SpamapS> balloons: did you look at ~/.juju/environments.yaml ?
[16:30] <balloons> SpamapS, right.. there's no folder created
[16:30] <balloons> that *should* work then yes
[16:30] <balloons> ?
[16:30] <SpamapS> balloons: interesting, I think we must have broken that
[16:30] <imbrandon> thats used to work
[16:30] <SpamapS> balloons: try 'juju bootstrap', does it create it then?
[16:30] <SpamapS> I think we made it so it only creates it if you try to do something now
[16:30] <SpamapS> since typing 'juju --help' was creating it
[16:30] <balloons> juju: error: too few arguments, and gives arg list
[16:30] <imbrandon> ahh
[16:30] <SpamapS> so docs probably need fixing
[16:30] <balloons> k, trying juju bootstrap
[16:31] <balloons> awesome: error: No environments configured. Please edit: /home/balloons/.juju/environments.yaml
[16:31] <balloons> so yea.. just needs updated I guess
[16:32] <SpamapS> balloons: if you're feeling adventurous.. 'bzr branch lp:juju/docs' .. and fix it. :) I'll merge it :)
[16:32] <SpamapS> balloons: otherwise file a bug here https://launchpad.net/juju/+filebug and we'll get to it right away
[16:32] <imbrandon> SpamapS: btw here in a few hours when i get frustrated enough with the nginx charm to switch gears i got some small updates to the newrelic one if you wouldent mind pushing, mostly stuff you sugested the other day
[16:33] <balloons> SpamapS, yea I had planned on branching and merging
[16:33] <balloons> I'll add it to the list of changes :-)
[16:33] <SpamapS> Also there's another way to setup a new environments.yaml.. 'jitsu setup-environment' ... a little more user friendly :)
[16:33]  * SpamapS adds ssl-hostname-verification to that
[16:34] <SpamapS> imbrandon: sweeeeet .. yeah just bug me. I'll be out on the road for a couple hours starting at 1200 my time tho.
[16:34] <imbrandon> kk
[16:34]  * imbrandon has to pack sometime today
[16:36] <imbrandon> btw i'm thinjking more downstrea,
[16:36] <imbrandon> as in the "lowest" sub should be able to overide anything its layerd on
[16:36] <SpamapS> imbrandon: I was thinking there will be times where it may be useful to define it at the upstream point, for instance if you want to host two apps under one proxy.
[16:37] <FunnyLookinHat> Is there an etiquette for assigning a charm request bug to yourself if someone else owns it?  It looks like there has been no movement on it:
[16:37] <FunnyLookinHat> https://bugs.launchpad.net/charms/+bug/931835
[16:37] <_mup_> Bug #931835: Charm needed: Gitlab <Juju Charms Collection:New for antono> < https://launchpad.net/bugs/931835 >
[16:37] <SpamapS> which is quite likely for big multi-layerd apps
[16:37] <SpamapS> but.. those should really not be doing Host: inspection
[16:37] <imbrandon> yea
[16:37] <SpamapS> still sometimes you need to know what the Host is. :p
[16:37] <imbrandon> and would likely have
[16:37] <imbrandon> well
[16:37] <imbrandon> hrm
[16:37] <marcoceppi> FunnyLookinHat: I'm actually working on that atm
[16:37] <FunnyLookinHat> marcoceppi, Ah - glad I asked.
[16:38] <marcoceppi> yeah, I didn't claim it yet, becaues I was trying to get a hold of the author
[16:38] <FunnyLookinHat> Same here - but I was trying to do it through the ticket
[16:38] <imbrandon> mmm i forgot to file an nginx one, supose i should do that
[16:38] <SpamapS> So, IMO, Antono claimed it almost 2 months ago
[16:38] <FunnyLookinHat> marcoceppi, you can take it though  :D
[16:38] <marcoceppi> If you wanted to take a stab feel free, I'm trying to do a gluster, gitolite, gitlab combo to make a scalable github-esque setup
[16:38] <SpamapS> and has then gone dark
[16:39] <FunnyLookinHat> marcoceppi, oh geez... I just wanted a simple charm to deploy a gitlab setup so that people could easily either run git or sparkleshare types of stuff on their client
[16:39] <SpamapS> How does everybody feel about making the policy that you can only "claim" a new charm bug for 30 days before it goes back to available?
[16:39] <FunnyLookinHat> SpamapS, good idea.
[16:39] <SpamapS> Debian has recently done the same with ITP bugs for intent to package.
[16:39] <marcoceppi> SpamapS: +1
[16:39] <imbrandon> SpamapS: +1
[16:39] <SpamapS> m_3_: ^^
[16:39] <SpamapS> Ok, the motion carries.
[16:39] <FunnyLookinHat> w00t.
[16:40] <SpamapS> I will record that at https://juju.ubuntu.com/Charms
[16:40] <SpamapS> marcoceppi: are you definitely ready to work on it now, or do you want to give it to FunnyLookinHat ?
[16:40] <FunnyLookinHat> So if I need ruby 1.9.2 and only 1.9.1 is available in the repositories, should I make my charm download/build 1.9.2 or should I try to reference another charm somehow?  I know one is in dev here: https://bugs.launchpad.net/charms/+bug/799879
[16:40] <_mup_> Bug #799879: Charm needed: rails (framework) <developers> <Juju Charms Collection:In Progress by mark-mims> < https://launchpad.net/bugs/799879 >
[16:41] <m_3_> SpamapS: yeah, that sounds good
[16:41] <marcoceppi> SpamapS: I plan to have it done for UDS, I'm kind of doing gluster, gitolite, then gitlab in that order, so FunnyLookinHat if you want to take the gitlab charm feel free
[16:41] <FunnyLookinHat> I'm going to try to throw it together for UDS - figured it'd be a decent entry for the competition
[16:41] <FunnyLookinHat> LOL
[16:41] <FunnyLookinHat> marcoceppi, You take it
[16:41] <FunnyLookinHat> I have others to do
[16:41] <FunnyLookinHat> magento is one that a lot of people seem to want
[16:43] <SpamapS> marcoceppi: please assign it to yourself
[16:44] <m_3_> FunnyLookinHat: note that the package 1.9.1 is actually a newer version of ruby
[16:44] <FunnyLookinHat> m_3_, newer than 1.9.2 ?
[16:44] <m_3_> 1.9.3p0
[16:44] <FunnyLookinHat> How does that work?
[16:44] <FunnyLookinHat> Ooooh
[16:44] <m_3_> it's just the package _name_ was chosen poorly imo
[16:45] <FunnyLookinHat> Should be ruby-current
[16:45] <m_3_> FunnyLookinHat: also note that rvm is packaged now too
[16:45] <FunnyLookinHat> Or just ruby
[16:45] <FunnyLookinHat> Oh awesome
[16:45] <m_3_> that makes it easier
[16:47] <FunnyLookinHat> much
[16:48] <SpamapS> FunnyLookinHat: the reason 1.9.1 was used was that it was wildly incompatible with 1.9.0
[16:48] <SpamapS> FunnyLookinHat: so anything that depended on ruby1.9 wouldn't necessarily work with ruby1.9.1
[16:48] <m_3_> FunnyLookinHat: feel free to run with rails for the charm contest.  the one in there is mine, but it's pretty naive and I really only use it for example hooks... it definitely needs some love across the board.  should be split from apache/passenger so nginx, unicorn, thin, etc could be used.  perhaps as a subordinate charm even
[16:49] <SpamapS> this unfortunately put the package maintainers in a bad position when 1.9.2 and 1.9.3 arrived, because they *are* compatible with 1.9.1
[16:49] <m_3_> yikes... really?
[16:49] <SpamapS> yep
[16:49] <SpamapS> its really ruby's fault
[16:49] <SpamapS> should have been 1.10, not 1.9.1
[16:49] <m_3_> no surprise, but still quite ugly
[16:50] <imbrandon> or <IP_ADDRESS>
[16:50] <imbrandon> heh
[16:51] <FunnyLookinHat> m_3_, this would be my FIRST charm... so I think I'll write the magento one first ( seems the easiest to deploy ) and then I might try my hand at something more complex.
[16:51] <SpamapS> I think ruby1.9.1 was the wrong choice
[16:51] <m_3_> FunnyLookinHat: awesome!
[16:51] <SpamapS> But it was right before freeze for squeeze IIRC
[16:55] <tobin> Is there a concept of server vs. client when writing charms? IE only the server has specific configs, and the client another set.
[16:55] <SpamapS> Can you guys look at https://juju.ubuntu.com/Charms and make sure I specified that correctly? Specifically search for '30 days' and see the footnote
[16:55] <SpamapS> tobin: charms provide, and require things
[16:55] <SpamapS> tobin: typically servers provide, and clients require
[16:56] <tobin> Okay somewhat like dpkg. Got it. thank you SpamapS.
[16:57] <marcoceppi> SpamapS: should there be an exception if there's a repository attached to the bug but no activity in 30 days?
[16:58] <balloons> alright -- juju bootstrap worked.. I see a small instance deployed
[16:58] <balloons> a few questions :-) can I control the instance size / type it creates when I bootstrap?
[16:58] <balloons> sorry I should say.. I bootstrapped to ec2
[16:59] <imbrandon> balloons: yea with constraints
[16:59] <m_3_> SpamapS: https://juju.ubuntu.com/Charms sounds good
[17:00] <balloons> imbrandon, thanks.. I see the docs on constraints.. looks simple
[17:04] <m_3_> marcoceppi: hmmm... yeah, we sort of have to account for charms people write that attach to a bug but they might not wanna publish it into the store
[17:04] <m_3_> not sure
[17:05] <balloons> so I issued the 'juju debug-log' command in one window, and a juju deploy mysql in another.. I don't seem to be getting any messages in the tailing log window though :-( Is there a log level I can set perhaps?
[17:05] <m_3_> I guess the bugs are for the charms we're wanting in the store... so no, they'd still be fair game
[17:05] <marcoceppi> cool
[17:05] <marcoceppi> makes sense
[17:06] <balloons> nvm.. things are cranking in the log now :-)
[17:06] <SpamapS> marcoceppi: I don't think so, no. Though anybody else who takes it on would be a bit silly to not at least use that as a starting point.
[17:06] <m_3_> balloons: "provider-delay" let's call it :)
[17:06] <balloons> that took a long time after I issued the commands and they returned successful.. interesting
[17:06] <marcoceppi> SpamapS: makes sense
[17:07] <balloons> m_3_, yes makes sense..
[17:07] <balloons> gotta spin up the machines, etc
[17:07] <SpamapS> marcoceppi: I'd like to favor the person interested *now*. :)
[17:07] <marcoceppi> Not a bad idea
[17:07] <m_3_> agree
[17:08] <SpamapS> The reason for the bug assignment bit is that we want to reduce duplication of effort.
[17:08] <m_3_> ok, so "super last-minute drop everything" project isn't happening right now, so back to charm testing...
[17:08] <SpamapS> BTW, I saw no response to my maintainer: thread on juju.. so I'm going to start assigning maintainers soon.
[17:08] <m_3_> BTW, we're rolling up test results to jenkins.qa.ubuntu.com
[17:08] <jcastro> SpamapS: hey so, I'm thinking, kill the spreadsheet for charms
[17:08] <m_3_> still working to get other provider tests to show too
[17:08] <jcastro> and move to all bug reports.
[17:08] <m_3_> jcastro: yes, please
[17:09] <SpamapS> m_3_: woot. Where is the main charmtester branch? I want to add explicit tests soon
[17:09] <SpamapS> jcastro: yes please
[17:09] <imbrandon> jcastro: spreadsheets are evil
[17:09] <SpamapS> m_3_: JINX!
[17:09] <SpamapS> oh wait
[17:09] <SpamapS> I said your name.. so.. yo're already free
[17:09] <m_3_> lp:~mark-mims/charmers/charms/precise/charmtester/trunk
[17:09] <m_3_> ha!
[17:09] <SpamapS> stupid IRC killing a children's game
[17:09] <imbrandon> lol
[17:09] <SpamapS> m_3_: you mean /charms/precise right, not /charmers/charms
[17:10] <m_3_> surely we can remember others... /me digs around in there
[17:10] <m_3_> crap... yeah
[17:10] <imbrandon> SpamapS: when can i use #!/usr/bin/php on install hook kthxbia!
[17:10] <m_3_> lp:~mark-mims/charms/precise/charmtester/trunk
[17:10] <m_3_> was reading other things while typing...
[17:11] <marcoceppi> imbrandon: almost never :)
[17:11] <m_3_> imbrandon: +1 for adding dep packages in metadata
[17:11] <imbrandon> :)
[17:12] <SpamapS> imbrandon: when the sun rises in the west and sets in the east
[17:12] <imbrandon> my install hook for nginx is seriously "apt-get update && apt-get install nginx php5-cli && php ./includes/install"
[17:13] <imbrandon> heh
[17:14] <marcoceppi> imbrandon: nothing wrong with that
[17:14] <imbrandon> oh i know, just kinda pointless
[17:15] <imbrandon> and the rest all use #!/usr/bin/php :)
[17:15] <m_3_> imbrandon: that's really pretty close to sourcing the php interpreter to consume the rest of the hook :)
[17:16] <marcoceppi> ¯\(o_o)/¯
[17:16] <m_3_> we should put a snippet together to do that :)
[17:16] <imbrandon> :)
[17:16] <m_3_> s/php/anything else/ of course :)
[17:16] <imbrandon> would work for ruby or anything
[17:16] <imbrandon> yea
[17:17] <m_3_> yup
[17:17] <m_3_> fairly obscene tho
[17:17] <imbrandon> lol yea
[17:17] <imbrandon> i see SpamapS cringing now
[17:20] <m_3_> SpamapS: I just realized I haven't updated that branch in a while... git-bzr barfed on me a while ago and I haven't done the workaround... updating now
[17:21] <imbrandon> m_3_: speaking of yea the one you use is the one i do as well
[17:21] <imbrandon> git bzr ng

[17:21] <imbrandon> git bzr clone lp:blah
[17:21] <imbrandon> etc
[17:22] <SpamapS> so sad that you guys can't just play nice w/ bzr. :)
[17:22] <imbrandon> heh it hates me
[17:22] <imbrandon> and i dont like the forks are called branches
[17:22] <imbrandon> :)
[17:23] <SpamapS> I don't like that git calls update revert, and revert merge, and merge .. wtf I am lost already :)
[17:23] <SpamapS> but I still use git when I am working on projects that use git
[17:23] <imbrandon> heh
[17:24] <imbrandon> thats it tho my projects are in git, not bzr, i just must use it to get reviewed :)
[17:24]  * imbrandon stops
[17:25]  * imbrandon hugs SpamapS :)
[17:25]  * m_3_ actually thinks there're more similarities than differences...
[17:25]  * SpamapS hugs err'body
[17:25] <imbrandon> yea there are quite a few, but i see bzr is more akin to hg, infact its damn near identical
[17:25] <imbrandon> just slower
[17:26] <SpamapS> There may come a day where we can have charms in git in the store
[17:26] <balloons> SpamapS, I think I did the docs merge properly (hope) https://code.launchpad.net/~nskaggs/juju/juju-bootstrap-fix/+merge/104781
[17:26] <SpamapS> that day is not today
[17:26] <marcoceppi> relation-list spits out service/unit correct?
[17:26] <SpamapS> marcoceppi: yeah
[17:29] <imbrandon> really my main main gripe is split between bzr merges seem dumb compared to gits ( as do pretty much any other vcs compared to git, there is a reason hg as a config option of [merge] git=true to use git for merging ) and the fact that bzr branches are actualy forks and not "in-place" like git branches with hardlinks, i REALLY like that feature
[17:29] <SpamapS> imbrandon: actually there's been recent work to have in place branches in bzr
[17:30] <SpamapS> as everybody seems to like that
[17:30] <imbrandon> dude, if that lands i'll convert
[17:30] <FunnyLookinHat> So question - I feel as though I'm creating a bad charm if all it does it download code, create a user, extract code and assign rights, and then setup a VirtualHost - am I missing something?
[17:30] <SpamapS> Heh, but what about rebase, and fastforward.. and the 3x speed difference? :)
[17:30] <FunnyLookinHat> i.e. is there some magic sauce where I'm supposed to make sure it can be duplicated or something ?
[17:30] <imbrandon> heh i can take one for the team
[17:30] <imbrandon> :)
[17:30] <SpamapS> imbrandon: talk to niemeyer, he wrote a plugin to do it
[17:30] <SpamapS> imbrandon: its called 'cobzr' you can probably find it
[17:31] <imbrandon> kk yea i'll check it out soonish
[17:31] <m_3_> FunnyLookinHat: there's all sorts of stuff you can do to expand on charms... but the basics are pretty basic... on purpose
[17:31] <SpamapS> FunnyLookinHat: thats a great charm!
[17:32] <FunnyLookinHat> Ok awesome- just making sure I'm not submitting work that's worthless and has to be redone  :D
[17:32] <SpamapS> FunnyLookinHat: if the charm stores user data locally.. you may want to find a way to store that in a shared place (like a database, or a shared filesystem), but that is where things get complicated and we all huddle together to scale-out a service.
[17:32] <m_3_> SpamapS: great description
[17:32] <SpamapS> I really think if I spend a week on ways to scale-out w/ mysql I will be able to make mysql's 'add-unit' extremely useful.
[17:33] <imbrandon> SpamapS: yea i wanna get with you at uds too about a ndb mysql charm
[17:33] <SpamapS> Like, make it a replication ring, or maybe use galera to do sync-replication.. or screw it lets just make everything NDB cluster.
[17:33] <SpamapS> imbrandon: NDB's problem is network bandwidth
[17:33] <imbrandon> ahahaha
[17:33] <SpamapS> you need a ridiculous amount of it
[17:33] <imbrandon> right but its so sexy
[17:34] <SpamapS> imbrandon: sure, its sexy on infiniband. I doubt it performs on EC2
[17:34] <m_3_> FunnyLookinHat: we try to make suggestions for how to handle scaling, upgrades, external relations, etc in review too
[17:34] <FunnyLookinHat> m_3_, oh ok cool
[17:34] <imbrandon> SpamapS: i can see a whole env juju'd with ndb charms , then have your "web" farm in another juju env
[17:34] <imbrandon> just dunno how to make them talk yet
[17:34] <imbrandon> :)
[17:36] <imbrandon> external relations
[17:36] <imbrandon> mmmm
[17:37] <imbrandon> so i can upgrade or blow away my web farm but not my shared storage farm or my memcache farm or my sql farm
[17:37] <imbrandon> mmmm dreams
[17:38] <imbrandon> kinda like meta suboranates ? heh
[17:39] <m_3_> imbrandon: take a peek at the mongodb charm's config.yaml file... note that the replicaset_master can be specified by host/port explicitly.  It's pretty manual, but it's a way of bridging between two juju envs
[17:40] <imbrandon> nice, i was sure i wasnt the first to think of it
[17:41] <m_3_> imbrandon: so the charm needs to be written to handle both "kinds" of relations
[17:41] <imbrandon> right
[17:41] <imbrandon> small price
[17:41] <m_3_> imbrandon: but it's what we have atm
[17:41] <imbrandon> yea, better than full on manual
[17:41] <SpamapS> imbrandon: also subordinates can easily be used to proxy between two envs
[17:42] <m_3_> in all sorts of interesting ways
[17:42] <imbrandon> SpamapS: ahh hadent thought of that
[17:42] <SpamapS> especially now that we have out-of-hook relation-set capability
[17:42] <m_3_> ha!
[17:42] <m_3_> yes
[17:42] <imbrandon> hrmm, intresting times we now live in
[17:42] <SpamapS> just need dynamic relation capability and we can have a juju-proxy charm
[17:43]  * imbrandon just needs to get a job where he can write charms all day
[17:43] <SpamapS> m_3_: watch your back!
[17:43] <bkerensa> SpamapS: if you move a merge proposal to "merged" will launchpad merge it?
[17:43] <SpamapS> ;)
[17:43] <m_3_> ha!
[17:43] <SpamapS> bkerensa: not sure, that would be cool though
[17:43] <bkerensa> lol
[17:43] <m_3_> imbrandon: yeah, you end up doing all sorts of other stuff too :)
[17:43] <imbrandon> :)
[17:43] <bkerensa> SpamapS: ok well for some reason I have review privileges on a branch
[17:43] <bkerensa> >.<
[17:44] <bkerensa> and I reviewed some code and it looks fine
[17:44] <bkerensa> :P
[17:44] <SpamapS> bkerensa: lp:juju/docs is owned by ~charm-contributors
[17:44] <SpamapS> Basically anybody who asks real nice can update the documentation. :)
[17:44] <m_3_> bkerensa: yeah, we've got a bit of disconnect between charms and our charm process and launchpad atm
[17:45] <bkerensa> LOL
[17:45] <bkerensa> m_3_: your not a bot?
[17:45] <bkerensa> :D
[17:45] <SpamapS> bkerensa: no, change it back to Approved, launchpad did not merge it ;)
[17:45] <SpamapS> as cool as that would be
[17:45] <bkerensa> SpamapS: yeah I saw it
[17:45] <m_3_> SpamapS: found my notes from series upgrade btw... there's still a couple of danglers
[17:45] <bkerensa> its moved back
[17:45] <m_3_> bkerensa: ha!.. nope, not a bot
[17:46] <m_3_> bkerensa: all my names start with 'm'... and you _don't_ wanna turn on irc highlighting for 'mmm' :)
[17:47] <imbrandon> lol
[17:47] <m_3_> SpamapS: but now we have unpromulgate... thanks!
[17:48] <SpamapS> oh that reminds me
[17:48] <SpamapS> I pushed adams crazy juju testing lab as the official rabbitmq-server branch
[17:48] <m_3_> SpamapS: btw, if you wanna see _exactly_ what the lp script did on series upgrade, lp:charms/nova-compute is still in a pristinely screwed up state (i.e., we haven't tried to fix it yet)
[17:49] <SpamapS> adam_g: is there any reason not to include your special testing lab fork in the main charm store? I'd rather there only be one place that is generally consumed.
[17:49] <m_3_> basically, compare lp:charms/nova-compute ( -> lp:~charmers/charms/precise/nova-compute/precise ) with lp:~charmers/charms/precise/nova-compute/trunk
[17:50] <SpamapS> bkerensa: you can go ahead and push that fix into the branch btw
[17:50] <bkerensa> SpamapS: How do I push it in?
[17:50] <bkerensa> =/
[17:50]  * bkerensa has never merged
[17:50] <bkerensa> do tell
[17:50] <balloons> :-) more doc changes..  juju is yelling at me for having a revision info in my metadata.yaml file.. looks like there is a revision file now.. the docs should be updated
[17:50] <m_3_> when lp:charms/nova-compute was updated from ...oneiric.. there was another branch on lp:~charmers/charms/precise/nova-compute/trunk, so the lp script renamed it to lp:~charmers/charms/precise/nova-compute/precise and aliased accordingly
[17:50] <SpamapS> bkerensa: there's a first time for everything! :)
[17:50] <bkerensa> SpamapS: do tell how
[17:50] <SpamapS> bkerensa: simplest way, 'bzr branch <<the branch you want to merge in>>'
[17:50] <balloons> I'll do my best to edit that also
[17:51] <bkerensa> then bzr merge?
[17:51] <SpamapS> bkerensa: then if there is only one commit, just 'bzr push lp:juju/docs'
[17:51] <bkerensa> ahh
[17:51] <bkerensa> k
[17:51] <m_3_> SpamapS: so the net is the aliased branch is old... needs to be unpromulgated and then the lp:~charmers/charms/precise/nova-compute/trunk branch needs to be promulgated in its place
[17:51] <SpamapS> bkerensa: if there are like, 10 crazy commits, you just want one in the mainline changelog, so you 'bzr branch lp:juju/docs', cd into that dor, and 'bzr merge ../whatever' and then commit as one thing.. 'Merging doc fix...'
[17:53] <m_3_> SpamapS: that's what happened with rabbitmq-server, but there was lots of manual "intervention" to try to fix this without an unpromulgate :(
[17:53] <SpamapS> Yeah
[17:53] <SpamapS> I think you named a brnch FML or something
[17:53] <m_3_> well... yes
[17:54] <m_3_> I should write this down for next release upgrade so we know exactly what we're gonna try to prevent
[17:54] <SpamapS> m_3_: I assume this is the one we want: lp:~charmers/charms/precise/nova-compute/trunk
[17:54] <m_3_> SpamapS: I think that's correct... looking at the history
[17:54] <balloons> can someone confirm the revision file is automatically created now, or is this something I should create and update?
[17:55] <SpamapS> m_3_: I'm pretty sure all we need to do is rename the trunk -> series name *and* get the charm store to ignore the branch name for official branches
[17:55] <m_3_> SpamapS: hmmm
[17:55] <SpamapS> balloons: you'll have to create it and update it whenever you want users to see the new charm.
[17:56] <balloons> SpamapS, hmm.. I don't remember making one.. but there is a file now called revision with a '1' in it
[17:56] <balloons> in my charm
[17:57] <SpamapS> m_3_: Ok so the fix is this: bzr branch lp:charms/nova-compute ; cd nova-compute ; charm unpromulgate ; cd .. ; mv nova-compute nova-compute-busted ; bzr branch lp:~charmers/charms/precise/nova-compute/trunk nova-compute ; cd nova-compute ; bzr push :parent ; charm promulgate
[17:57] <jcastro> woo, lots of charm activity lately!
[17:58] <imbrandon> offer shiney toys and that happens :)
[17:59] <SpamapS> jcastro: at least 60 commits per day since Feb 12.
[17:59] <m_3_> SpamapS: right, that sounds perfect... did you already do it, or shall I?
[17:59] <SpamapS> m_3_: I want you to do it, so I can confirm there's nothing special on my machine :)
[17:59] <m_3_> SpamapS: will do
[18:01] <SpamapS> m_3_: I'm also interested in seeing what happens when I 'bzr pull' from the aliased branch
[18:01] <jcastro> hazmat: speaking of, we might want to fix the charts ^^^^
[18:01] <SpamapS> m_3_: so let me know when you're done
[18:01] <m_3_> SpamapS: also my notes say it barfed on zookeeper, statusnet, nova-compute, nova-cloud-controller, rabbitmq-server
[18:01] <m_3_> I'll do nova-compute now... one sec
[18:02] <bkerensa> SpamapS: ok balloons stuff is up
[18:02] <SpamapS> bkerensa: woot!
[18:02] <bkerensa> I thought there was much more to all that
[18:02] <bkerensa> =/
[18:03] <SpamapS> I think the website refreshes every 15 min or maybe 60 min, not sure
[18:04] <m_3_> SpamapS: http://paste.ubuntu.com/967444/ I use this machine for bzr/lp all the time, so it has my lp id / keys
[18:07] <SpamapS> m_3_: are you ssh'd to it? that breaks
[18:08] <SpamapS> I don't know why
[18:08] <m_3_> probably... lemme see if I can turn that off
[18:08] <SpamapS> but launchpadlib won't work if you ssh into a machine that also has your lpcreds in gnome keyring
[18:08] <m_3_> oh... I see
[18:08] <m_3_> yeah, other desk one sec
[18:08] <SpamapS> yeah, its dumb
[18:09] <SpamapS> I'm sure there's a way to get it to ignore the gnome keyring creds, but I don't know what it is
[18:09] <imbrandon> works fine if osx keyring has them heh
[18:09] <imbrandon> i;m sure it dont look in the osx keyring on osx tho
[18:12] <SpamapS> imbrandon: does lplib work on os x?
[18:14] <imbrandon> yup
[18:14] <imbrandon> use it all the time
[18:14] <imbrandon> its how bzr knows who i am when pushing and such
[18:15] <imbrandon> like i said pretty sure it ignores the osx keyring tho
[18:23] <balloons> hmm.. ok, how do I undeploy a charm if you will?
[18:23] <SpamapS> balloons: juju destroy-service foo
[18:24] <SpamapS> balloons: note that the machines are not terminated
[18:24] <balloons> right, is destory enviroment the only way to kill a machine?
[18:24] <balloons> or can i selectively kill off a machine?
[18:25] <balloons> as far as I can tell, I don't see destroy-service mentioned in the docs anywhere
[18:25] <m_3_> SpamapS: ok, so I keep gettings can't determine launchpad location from bzr branch
[18:25] <marcoceppi> -relation-departed the $JUJU_REMOTE_UNIT is the unit which "departed", correct?
[18:26] <SpamapS> m_3_: you might have forgotten the 'bzr push' step?
[18:26] <SpamapS> marcoceppi: correct
[18:27] <SpamapS> balloons: terminate-machine to terminate a specific machine
[18:27] <m_3_> nope, this was during unpromulgate... editing the .bzr/branch/branch.conf manually worked though
[18:27] <SpamapS> m_3_: OOOHHH right, I forgot a step .. ;)
[18:27] <SpamapS> m_3_: bzr push :parent
[18:28] <m_3_> SpamapS: yeah, did that
[18:28] <m_3_> but the branch it put there didn't let me unpromulgate
[18:28] <SpamapS> m_3_: promulgate just looks at the push branch , so if bzr info shows something else, thats what is wrong
[18:28] <m_3_> had to manually change it to the one I wanted
[18:28] <SpamapS> m_3_: you can tack on '--remember' to change it
[18:28] <SpamapS> oh
[18:28] <SpamapS> you know that makes sense
[18:28] <SpamapS> m_3_: right you have to push to the explicit name
[18:28] <SpamapS> didn't think about that
[18:28] <m_3_> I can get the url if you want... it was +branch/..../
[18:29] <m_3_> either way... that's working... lemme promulgate the other branch
[18:29] <SpamapS> m_3_: we should also look at the charm store and see if it is listing our new ones in a while
[18:29] <SpamapS> m_3_: we might have to bump the revision file
[18:29] <SpamapS> though actually it probably doesn't seem them cause their name is 'precise'
[18:29] <SpamapS> so the new one named 'trunk' will show up
[18:30]  * SpamapS facepalms
[18:30] <SpamapS> ETOOMANYVARIABLES
[18:31] <balloons> when you deploy a charm, does it pull from bzr or your local files? I made changes but they aren't reflecting in my deploy.. seems like perhaps bzr plays a part here
[18:32] <balloons> in short, if I make a change to my charm, what do I have to do before doing another test deploy from my local repo?
[18:32] <adam_g> SpamapS: those testing charms are full of little hacks that are specific to our deployment and environment
[18:32] <m_3_> SpamapS: ok, that worked... lp:charms/nova-compute points to the right place... yeah, we might have to invalidate the store cache entry
[18:32] <adam_g> SpamapS: things like wget'ing stuff from a local webserver, granting ubuntu user permission to stuff it shouldn't have, etc
[18:33] <adam_g> SpamapS: im curious, why is hte rabbit charm causing problems but hte other stacked ones are not?
[18:33] <m_3_> adam_g: they are :)
[18:33] <SpamapS> aye
[18:33] <SpamapS> adam_g: all the ones that we had versions of in precise before the branch-distro script got run caused issues
[18:33] <m_3_> adam_g: I'll send you an email with a detailed description of what happened...
[18:33] <SpamapS> balloons: depends on how you deployed it
[18:34] <balloons> SpamapS, haha..
[18:34] <SpamapS> balloons: if you used local: .. then the local dir is scanned for a revision file, and if it is different from the one you already have in your environment, the new charm is deployed, otherwise the one already in the env is deployed
[18:34] <balloons> ah-ha!
[18:34] <m_3_> adam_g: just the lp tool we used does some special things for pre-existing target branches
[18:34] <balloons> that pesky revision file!
[18:35] <SpamapS> balloons: there is a switch for deploy -u, which will force the revision file to be bumped up by 1
[18:35] <m_3_> adam_g: nothing about your charms/branches at all
[18:35] <balloons> so everytime I make a change I have to bump that file?
[18:35] <SpamapS> balloons: also you can use the 'upgrade-charm' command to bump the rev and upload the new version for an existing deployment
[18:35] <balloons> hmm.. I think I'll like this deploy -u
[18:35] <balloons> I'm just trying to test and debug the charm I have
[18:36] <balloons> so iteratively deploying, changing, deploying
[18:37] <balloons> I'll try the deploy -u and see if that solves my issue.. it's interesting nonetheless
[18:37] <SpamapS> balloons: one thing I do is to make the 'upgrade-charm' hook do 'stop;install;config-changed;start' so that I can just iterate with 'ugprade-charm'
[18:37] <SpamapS> actually I think that order is wrong though.. I need to change it to stop;install;start;config-changed
[18:38] <SpamapS> (or perhaps juju should just do that for me.. since it makes the most sense. ;)
[18:38] <balloons> SpamapS, hmm.. I'd be happy to take up your best practice on this
[18:38] <balloons> let me know :-)
[18:40] <m_3_> SpamapS: ok, so that looks good... I'll go ahead and catch the rest of the upgrade errors
[18:41] <SpamapS> m_3_: ok, I think we can avoid this at branch-distro time by renaming any 'trunk' branches in quantal to 'quantal', then running the branch-distro.. then do the mass rename from quantal->trunk
[18:42] <SpamapS> we're also going to have to look at the problem that branch-distro *locks* all existing branches
[18:42] <m_3_> SpamapS: ah... yeah... so just rearrange the order... good idea
[18:42] <SpamapS> since the charm store won't let us push anything except 'trunk'.. that means we can't have like, a -updates branch that we then change the pointer to
[18:42] <m_3_> SpamapS: I'm writing up the whole process so we don't forget... send it to the list
[18:42] <SpamapS> I think we have to fix the charm store
[18:43] <SpamapS> it should blindly publish anything that has an official pointer
[18:43] <m_3_> dunno... it should ignore feature branches though and only display trunk huh?
[18:44] <imbrandon> or master
[18:44]  * SpamapS gets the hose
[18:44] <imbrandon> hahahahaha
[18:44] <m_3_> ha!
[18:44]  * imbrandon about choked on my mt dew
[18:44] <m_3_> imbrandon: actually the difference between "trunk" and "master" names has saved me many times in git-bzr-ng screwups
[18:45] <m_3_> but yes... not your point
[18:45] <imbrandon> hahah same here on hg <--> git
[18:45] <imbrandon> at penton
[18:49] <SpamapS> imbrandon: http://bit.ly/IOdIgm
[18:49] <m_3_> great pic
[18:50] <m_3_> clarise
[18:50] <m_3_> or rather clarisssssssse
[18:50] <imbrandon> hahha
[18:51] <SpamapS> m_3_: the trunk name should totally be the name it uses for publish/notpublish per-user branches. But there's no reason to apply that same rule to official branches
[18:51] <SpamapS> The other option though, is to unlock those branches for updates
[18:51] <SpamapS> which I'd actually be in support of for Ubuntu as well.
[18:51] <SpamapS> Because having different branches for different pockets is confusing and does not work well.
[19:01]  * imbrandon like the lp:~imbrandon/charms/nginx/trunk for devel , /charms/nginx/precise for precise and /charms/nginx/oneiric for oneiric
[19:01] <imbrandon> personaly, thats how i do other non charm projects
[19:01]  * m_3_ still trying to figure out what a pocket is on lp
[19:01] <imbrandon> trunk or master or whatever is the main devel branch, then named branches for stage or prod etc
[19:02] <imbrandon> in this case releases
[19:03] <SpamapS> imbrandon: lp:~imbrandon/charms/precise/nginx/trunk ...
[19:03] <SpamapS> m_3_: pocket is release, security, updates, proposed
[19:03] <imbrandon> i realize that but thats reversed
[19:03] <SpamapS> m_3_: release is the pocket assumed in the absence of a pocket ;)
[19:04] <SpamapS> imbrandon: the reason we want them to be this way, is that its not just your charm. You are well integrated with all the other charms.
[19:04] <balloons> hmm.. juju debug-log seems to have some crazy lag on it when using it in connection with wget
[19:04] <imbrandon> sure thats what the /charms/ name space does
[19:04] <SpamapS> Making them their own little islands will fail at the de-duplication of effort that we're striving for.
[19:05] <SpamapS> imbrandon: but we want each release to work well as a whole
[19:05] <imbrandon> no no your mising a part there
[19:05] <imbrandon> sure
[19:05] <balloons> any idea why that might be? 2012-05-04 11:59:35,646 unit:vivo/4: hook.output ERROR: ..... .......... ....
[19:05] <balloons> 2012-05-04 11:59:35,647 unit:vivo/4: hook.output ERROR: ...... .......... 38% 22.7M 7s
[19:05] <SpamapS> as the OS moves on, we want the charms to move, as a whole, with the OS.
[19:05] <imbrandon> the release loosk for the $release banch
[19:05] <SpamapS> what I don't want is a bunch of "if release == oldnbusted: else ...
[19:05] <imbrandon> um no
[19:05] <balloons> the file downloaded minutes ago, but the debug log is still slowly scrolling through lines that look like that, giving download status updates
[19:05] <imbrandon> not at all
[19:05] <imbrandon> where do you get that ?>
[19:06] <SpamapS> imbrandon: thats what will happen if we leave the release out of the url. And if we put it at the end, its purely psychological.. they won't be seen as a whole "precise" set of charms or "quantal" set of charms.
[19:06] <imbrandon> e.g my drupal modules ( as well as thousands of others ) are that way, and in no way have "if release -- blah"
[19:06] <SpamapS> its entirely psychological
[19:06] <imbrandon> no no
[19:07] <imbrandon> wow no
[19:07] <imbrandon> what it comes down to is shared code
[19:07] <imbrandon> notthing more
[19:07] <imbrandon> your way causes fragmentation
[19:07] <SpamapS> precise/nginx means precise's nginx. nginx/precise means the nginx that works on precise..
[19:07] <imbrandon> the other allows hsared
[19:07] <imbrandon> right
[19:08] <imbrandon> exactly, and thats what it is
[19:08] <SpamapS> and lp:charms/nginx means "where you do dev now"
[19:08] <imbrandon> no thats where sotre releases are
[19:08] <imbrandon> no one devs there
[19:08] <SpamapS> its actually not, the store releases lp:charms/precise/nginx
[19:08] <SpamapS> and lp:charms/oneiric/nginx
[19:09] <imbrandon> still no chared code , forces forking, is bad
[19:09] <imbrandon> shared*
[19:09] <SpamapS> imbrandon: we have a session scheduled for this actually
[19:09] <imbrandon> thus the way drupal has done it now for years just for this very reason
[19:09] <SpamapS> I'm not sure what code you want to share tho?
[19:09] <imbrandon> i seriously say we take a book from them
[19:09] <imbrandon> all of it
[19:09] <SpamapS> drupal is a single project though
[19:09] <imbrandon> not much is gonna chage
[19:09] <imbrandon> SpamapS: no its not
[19:09] <SpamapS> I don't know if a distribution of things loosely coupled works like a project
[19:09] <imbrandon> its 10000's of smaller ones
[19:10] <SpamapS> ah ok
[19:10] <imbrandon> no i mean drupal as in every module included on drupal.org
[19:10] <imbrandon> like 6k+
[19:10] <imbrandon> they all follow one rule
[19:11] <imbrandon> dev is done in ~/projectname/master ( its git blah , trunk here ) and then
[19:11] <imbrandon> ~/prijectname/7.x branch for
[19:11] <imbrandon> drupal 7
[19:11] <imbrandon> and 6.x branch for 6
[19:11] <imbrandon> etc
[19:11] <imbrandon> that way its not forked
[19:12] <imbrandon> its the same git repo
[19:12] <SpamapS> imbrandon: btw, I forwarded your newrelic-php charm to the newrelic sales guy who contacted me. He forwarded it along to their dev/products teams.
[19:12] <imbrandon> just a branch, so when 8.x comes out, git branch 8.x from the current dev and get to work
[19:12] <SpamapS> imbrandon: ah I think thats semantics. We're really just branching the same mainline.. lp:charms/charmname, and then we can easily merge backward to all previous releases.
[19:12] <imbrandon> and merge back into each other as its applicable
[19:13] <imbrandon> SpamapS: SWEET
[19:13] <imbrandon> i have the others ready just about too
[19:13] <imbrandon> as in python , ruby and sysmon
[19:13] <imbrandon> more than that is gonna wait post uds
[19:14] <SpamapS> imbrandon: in fact our session that we have scheduled is about discussing whether we should automate that process by saying if the tests pass, it gets auto-pushed back to non-diverged branches
[19:14] <imbrandon> sysmon being the "main" newrelic namespace
[19:14] <imbrandon> SpamapS: yea and see its much easier to track that way
[19:14] <imbrandon> if its in the same branch named space
[19:14] <SpamapS> imbrandon: totally. I'd rather have releases improve constantly and only make it manual when we actually break stuff.
[19:14] <imbrandon> SpamapS: drupals automated testbot does it
[19:14] <imbrandon> right
[19:14] <SpamapS> sounds like we're already headed in the same direction then
[19:15] <SpamapS> ok crap time got away from me
[19:15] <SpamapS> time to hit the road
[19:15] <SpamapS> bbl
[19:15] <imbrandon> l8tr
[19:15] <flepied> what are the pre-requesites to run ec2 instances ?
[19:15] <hazmat> jcastro, re charts? commit activity?
[19:15] <imbrandon> flepied: just a amazon acount iirc ( with attached cc info )
[19:16] <m_3_> SpamapS: whats the name of the tool that lp originally ran?
[19:16] <m_3_> bump-series?
[19:16] <flepied> imbrandon, I saw you need an S3 bucket at least
[19:17] <SpamapS> m_3_: branch-distro
[19:17]  * SpamapS is gone
[19:19] <jcastro> hazmat: yeah, commit activity, remember you said it was wrong?
[19:19] <hazmat> jcastro, yeah.. it only captures 10 commits per charm
[19:19] <hazmat> i'll take a look at fixing it up this weekend, at conference at the moment (mongo)
[19:21] <flepied> I have the following error: ERROR SSH forwarding error: bind: Cannot assign requested address
[19:26] <flepied> after bootstrapping an ec2 environment
[19:26] <flepied> all commands report this error...
[19:27] <tobin> Can someone help me understand what 'interface: monitor' means within a metadata.yaml file. I believe I understand how requires and provides somewhat works, but unsure what monitor means.
[19:27] <nathwill> query: is $JUJU_RELATION_ID specific to a service unit, or is that generic to the relationship between the services?
[19:28] <tobin> For instance, the ganglia charm has a relation name of "ganglia-node" with a interface set to monitor. Why is this needed?
[19:33] <bkerensa> imbrandon: thoughts on Cloudfront costs?
[19:40] <victorp> I am trying to boostrap an ec2 environment, juju boostrap command finishes ok but juju status gives me an invalid SSH error
[19:40] <victorp> help?
[19:43] <victorp> jcastro, ^^
[19:43] <flepied> victorp, same error here
[19:43] <victorp> flepied, did you manage to fix it?
[19:47] <flepied> no
[20:04] <victorp> oh well
[20:04] <victorp> I cant get it to work
[20:05] <victorp> maybe daviey can help
[20:14] <flepied> got it to work
[20:14] <flepied> oops already gone
[20:27] <imbrandon> bkerensa: more expensive than compeditors but same as s3, so if your just serviing alteady out of s3 kinda nuts not to
[20:27] <bkerensa> imbrandon: ahh I was one it for a few because maxcdn got blocked by my host
[20:27] <bkerensa> :D
[20:27] <bkerensa> but now its sorted... their VP had people call my host and get their ranges white listed
[20:27] <bkerensa> and then told me how much he is enjoyinh 12.04
[20:27] <bkerensa> :D
[20:27] <imbrandon> maxcdn = shoddy and a pita to use IMHO
[20:28] <bkerensa> imbrandon: NetDNA/MaxCDN has sponsored me for three years
[20:28] <bkerensa> ;)
[20:28] <bkerensa> and I get unlimited terabytes at no cost ;p
[20:28] <imbrandon> cool, still a PITA to use
[20:28] <imbrandon> ;)
[20:28]  * imbrandon dont like origin pull
[20:29] <bkerensa> you like push zones?
[20:29] <bkerensa> =/
[20:29] <imbrandon> and automation, yes, then i'm in control
[20:30] <imbrandon> or tranparent like cloudfront or cloudflare
[20:30] <bkerensa> :P
[20:31] <bkerensa> I think at the end of the year Im going to ask NetDNA to end my MaxCDN sponsorship and transition me to CloudCache
[20:31] <bkerensa> :D
[20:31] <imbrandon> really i'm more of a fan of abstraction tho, provider transparent
[20:31] <imbrandon> thus when juju grows cdn wings i'll be happy
[20:31] <marcoceppi> Making upstreams put their downloads behind SSL: https://twitter.com/#!/marcoceppi/status/198139725402488833 https://twitter.com/#!/johnmark/status/198509648603656194
[20:32] <imbrandon> marcoceppi: nice
[21:52] <victorp> flepied, hey - got it working
[21:53] <_mup_> Bug #994855 was filed: Error messages are logged twice in the command line <juju:New> < https://launchpad.net/bugs/994855 >
[22:08] <_mup_> Bug #994863 was filed: juju needs ssh keys in launchpad but we don't tell the user that. <juju:New> < https://launchpad.net/bugs/994863 >


[00:43] <mup> PR snapd#8373 closed: tests/lib/prepare.sh: use only initrd from the kernel snap <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8373>
[05:39] <mborzecki> morning
[05:42] <mborzecki> and back
[05:52] <mup> PR snapd#8376 closed: daemon: make POST /v2/systems/<label> root only <Simple 😃> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8376>
[05:52] <mborzecki> yay
[06:01] <jamesh> The travis jobs are precariously close to the 50 minute timeout
[06:03] <mborzecki> jamesh: trying to squeeze every minute of that test runs ;)
[06:03] <mborzecki> mvo: hey
[06:04] <jamesh> mborzecki: I've had a few test runs that seem to have just been unlucky and were killed
[06:05] <mborzecki> jamesh: yeah, the margin is just below 5 minutes now, if anything gets delayed (such as lxd test) we may easily hit the limit
[06:06] <mvo> hey mborzecki
[06:08] <mvo> mborzecki: this all sounds we really want to move to GH
[06:10] <mvo> mborzecki: are tests failing a lot this morning?
[06:11] <mborzecki> mvo: 2 of my prs had their travis jobs restarted (or they did not run since yday)
[06:11] <jamesh> mvo: not particularly more than usual.  I was just commenting on one of my runs getting failed by Travis's 50 minute timeout
[06:12] <jamesh> and that the usual successful runs aren't enormously shorter than that limit
[06:12] <mvo> right :/
[06:13] <jamesh> maybe we should stop adding new tests
[06:14] <jamesh> :-)
[06:14] <mvo> heh :) remove one exiting for each new test
[06:17] <mvo> hm, looking at 8392, what does "shealding" mean? "This is because the cloud team is shealding by default all the ubuntu
[06:17] <mvo> images on gce "?
[06:17]  * mvo maybe just did not had enough tea
[06:19] <mup> PR snapd#8391 closed: tests: fix cross build tests when installing dependencies <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8391>
[06:21] <mup> PR snapd#8387 closed: store: search v2 tweaks <Simple 😃> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8387>
[06:30] <zyga> o/
[06:31] <zyga> mvo: github-has-no-50-minute-limit (just saying)
[06:31] <zyga> we could move all travis spread jobs over
[06:31] <zyga> and leave some boring checks for next
[06:33] <mvo> zyga: yeah
[06:33] <jamesh> I don't know.  A "remove two tests for each new test added" policy sounds appealing
[06:34] <jamesh> get rid of that regulation
[06:44] <mvo> jamesh: if I want to report a bug on GH actions to support "fail-ignore" or something, what's the most appropriate place/component in their issues, do you have a suggestion?
[06:45] <zyga> Their community thing
[06:46] <zyga> But that is reported already
[06:46] <jamesh> mvo: I've seen some general bugs filed against https://github.com/actions/toolkit/.  The forum is also worth looking at
[06:46] <jamesh> mvo: given that each job shows up as a separate check suite, is it needed?
[06:49] <mvo> jamesh: I would like to see the overall tickmark green or red
[06:49] <mvo> jamesh: it's kind of annoying to have to go to the details, it's minor, agreed :)
[06:50] <mvo> jamesh: we have a bunch of "unstable" systems that have frequent e.g. package manager mirror issues and it would be nice to not count those in the overall "is-green" assesment on the GH pull overview page
[06:58] <mup> PR snapd#8386 closed: many: support immediate reboot <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8386>
[07:03] <pstolowski> morning
[07:03] <mvo> pstolowski: good morning - do you think you could have  a quick look at 8383 ? needs a review
[07:04] <pstolowski> mvo: yes, of course
[07:04] <mvo> jamesh: looks like 8289 is ready, it's just spread that's not quite there?
[07:04] <mvo> jamesh: but it has two plus one etc? can I squash merge it?
[07:06] <jamesh> mvo: yes.  This was the one that hit the 50 minute kill timeout on the travis jobs
[07:06] <jamesh> mvo: I think it is good to go
[07:06] <mvo> jamesh: thanks, merged
[07:07] <mup> PR snapd#8289 closed: xdgopenproxy: forward requests to the desktop portal <Squash-merge> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8289>
[07:07] <mborzecki> yay!
[07:07] <jamesh> yay!
[07:08] <mborzecki> mvo: 44.2? :)
[07:09] <mvo> mborzecki: there will be a .2 for the search-v2 :)
[07:09] <mborzecki> mvo: cool, can we include the portal proxy as well?
[07:12] <mvo> mborzecki: I just cherry picked it, I think we want it
[07:12] <mvo> unless pedronis feels it's too much of a change to include the portal-proxy in 2.44.2
[07:15] <pedronis> mvo: jamesh: what are the risks? it will not be tested much if it goes into .2
[07:19] <jamesh> pedronis: that snaps calling /usr/bin/xdg-open will fail.  The PR's spread tests provide decent confidence for the systems it runs on.  It probably works on the older systems where the test fixture doesn't run.
[07:19] <jamesh> pedronis: it should make no difference on systems that don't have xdg-desktop-portal installed at all
[07:20] <pedronis> mvo: when are you cutting .2 ?
[07:21] <jamesh> (the spread test runs against the system's real xdg-desktop-portal daemon)
[07:33] <mborzecki> #8305 needs a 2nd review
[07:34] <mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
[07:34] <mvo> pedronis: soon, today ideally
[07:35] <mvo> pedronis: I would like to go over the 2.44 marked PRs today, i.e. I'm trying to get the seed warning done
[07:35] <mvo> pedronis: eh, seed-failed warning
[07:37] <pedronis> mvo: there's a small risk of needing a .3 which would be annoying
[07:41] <mvo> pedronis: yeah, I don't have super strong opinions, we could be conservative and punt the portal stuff to 2.45
[08:08]  * zyga switches to reviews
[08:13]  * zyga reads 8305
[08:14] <mvo> pedronis, degville I updated the warning text in 8372, I think we should move forward with the warning as a start
[08:15] <degville> mvo: thanks, I'll take a look.
[08:37] <zyga> times are interesting
[08:37] <zyga> my kids are doing more video calls than I do
[08:40] <zyga> mborzecki: what is the marker file for again, to trigger the whole workflow of selection?
[08:40] <mborzecki> zyga: to indicate that we detected the trigger during boot
[08:41] <zyga> and then run the chooser?
[08:41] <mborzecki> yes
[08:43] <mborzecki> the console conf integration bits only start the chooser iff the marker file is present already, but the extra sanity checks in the chooser do not harm
[08:43] <zyga> mborzecki: https://github.com/snapcore/snapd/pull/8305#pullrequestreview-385359049
[08:44] <mup> PR #8305: cmd/snap-recovery-chooser: add recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8305>
[08:46] <zyga> mborzecki: I'll pick up another review but please ping me for more iteration on this, even if you just reply to my comments
[08:47] <abeato> hey, I am trying to run the UC20 image from cdimage with kvm+tianocore, but kvm crashes on me when selecting install/recovery option, are there any instructions on how to test UC20?
[08:49] <mvo> abeato: hm, kvm+uefi (OVMF) should work, did you enable virtio? without virtio on the disk grub is incredible slow in uefi mode
[08:50] <abeato> mvo, I'm using this command line (no virtio, I'll try that): kvm -m 1024 -redir :8022::22 -drive if=pflash,format=raw,readonly,file=/usr/share/OVMF/OVMF_CODE.fd -drive if=pflash,format=raw,file=OVMF_VARS.fd ubuntu-core-20-amd64.img
[08:55] <zyga> actually
[08:56] <zyga> do we have a single place that explains how to run core20
[08:56] <zyga> I'd love to try it
[08:56] <zyga> but it seems that at least for now it's a bit of black magic and goat sacrifice
[08:57] <jamesh> zyga or mvo: could I trouble you to merge https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/364742 ?  -- this is for a snap used by my dbus-activation branch.
[08:57] <zyga> snappy-hub :)
[08:57] <jamesh> (unfortunately it is probably a little more effort than just hitting a button though)
[08:57] <zyga> sure
[08:58] <jamesh> thanks
[08:58] <zyga> do we need to rebuild the snap and publish it
[08:58] <zyga> or just merge the branch
[08:58] <zyga> oh, it's bzr
[08:58] <jamesh> the snap needs rebuilding, but that might happen automatically
[08:58]  * zyga checks if bzr is in focal
[08:58] <jamesh> it is
[08:58] <jamesh> well, brz is
[09:00] <abeato> zyga, re: UC20, +1 on that :)
[09:02] <mvo> jamesh: in a meeting right now, if zyga can help that would be great
[09:02] <zyga> jamesh: it's merged
[09:02] <zyga> mvo: done
[09:02] <zyga> jamesh: let me know if the snap needs poking to build
[09:02] <zyga> but https://code.launchpad.net/~mvo/+snap/test-snapd-dbus-service claims it's building automatically
[09:05] <jamesh> I'll keep an eye on it to make sure it starts.  Thank you
[09:13] <mborzecki> hmm has the pi kernel grown?
[09:13] <zyga> cheers: )
[09:13] <zyga> mborzecki: how big is it?
[09:15] <mborzecki> 22M
[09:19] <zyga> for pi 4?
[09:19] <zyga> or pi 2-3?
[09:20] <mborzecki> idk, pi-kernel
[09:20] <mborzecki> whicheven tht supports
[09:38] <mup> PR snapd#8369 closed: boot, overlord/devicestate, daemon:  implement requesting boot into a given recovery system <Needs Samuele review> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8369>
[09:40] <zyga> mvo: https://github.com/snapcore/snapd/pull/8390#pullrequestreview-385400365
[09:40] <mup> PR #8390: state: add state.CopyState() helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
[09:45] <zyga> mvo: https://github.com/snapcore/snapd/pull/8382#issuecomment-607148635
[09:45] <mup> PR #8382: packaging: detect broken seed during focal and disable it <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[09:49] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378/files#diff-459c7505a1a8a6c804c8a0cf9032350eR82 is unused, is usage of opts coming later?
[09:49] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[09:52] <pstolowski> zyga: it's needed because all methods must implement common interface now. but perhaps it can be unnamed there
[09:52] <zyga> ah, I see
[09:52] <pstolowski> not every method will use opts internally
[09:52] <zyga> I'm mid-way through so perhaps it gets clear as I go down
[09:52] <zyga> thanks
[09:52] <zyga> I see
[09:52] <zyga> just asking :)
[09:53] <pstolowski> zyga: sure!
[09:55] <mup> PR snapd#8393 opened: cmd/snap,seed: validate full seeds (UC 16/18) for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8393>
[09:56] <mvo> zyga: thanks, looking
[09:56] <zyga> mvo: ping me for a follow-up of any kind please
[10:01] <mvo> zyga: thanks
[10:03] <mup> PR snapd#8383 closed: store: support for search API v2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8383>
[10:15] <mup> PR snapd#8394 opened: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[10:17] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378#pullrequestreview-385430838
[10:17] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[10:19] <zyga> mvo: https://github.com/snapcore/snapd/pull/8394#pullrequestreview-385450682
[10:19] <mup> PR #8394: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[10:19]  * zyga breaks to take the dog out
[10:21] <jamesh> mvo: when you're not busy, could you flip this snap build recipe over to building against Bionic? https://code.launchpad.net/~mvo/+snap/test-snapd-dbus-service
[10:25] <pstolowski> zyga: thanks, replied. i'll check if opts can be left unnamed
[10:26] <mvo> jamesh: do you have the link at hand? happy to do that
[10:34] <mup> PR snapd#8343 closed: config, features: move and rename config.GetFeatureFlag helper to features.Flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8343>
[10:39] <mvo> pedronis: when you have a moment, could you please have a look at 8372 ? hopefully very simple
[10:40] <mvo> jamesh: nevermind, updated and triggered a rebuild
[10:45] <mup> PR snapd#8395 opened: o/ifacestate: handle interface hooks when preseeding <Created by stolowski> <https://github.com/snapcore/snapd/pull/8395>
[11:08] <pedronis> mvo: there some preexisting comments by zyga there that are not answered, also I think we can remove the XXX
[11:34] <zyga> re
[11:34] <zyga> back, sorry for the lag, $events at home
[11:48] <pedronis> pstolowski: made some suggestions in 8378
[11:52] <pstolowski> ty
[11:54] <zyga> mborzecki: FYI https://wiki.archlinux.org/index.php/Talk:Snap
[11:54] <pstolowski> pedronis: yep, sounds good
[11:54] <mborzecki> zyga: yeah, it's a known thing, we have a forum topic about that too
[11:55] <mborzecki> zyga: imo the 'workaround' doesn't make sens anymore, but we don't know what's wrong yet
[11:55] <zyga> yeah, just wanted to let you know about the talk page
[11:55] <mborzecki> zyga: mhm, i get email notifications about edits there :)
[11:55] <zyga> ah, ok
[11:55]  * zyga too :)
[11:55] <mborzecki> but than's for poking me :)
[11:55] <mborzecki> thanks ;)
[12:30] <zyga> FYI https://bugs.launchpad.net/snapd/+bug/1870123
[12:30] <mup> Bug #1870123: Panic: unlocking unlocked mutex in unit test <snapd:New> <https://launchpad.net/bugs/1870123>
[12:33] <pstolowski> zyga: pushed the changes to #8378, per Samuele's suggestions
[12:33] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[12:33] <zyga> looking
[12:36] <cachio> mvo, debian sid is failing to update https://travis-ci.org/github/snapcore/spread-cron/builds/668599845
[12:37] <cachio> I tried many things to correct that but the repo is not consistent
[12:37] <pedronis> pstolowski: the validateOnly where not core only, no?
[12:37] <cachio> mvo, any idea about a workaround?
[12:37] <zyga>  clang : Depends: clang-9 (>= 9~) but it is not going to be installed
[12:37] <pedronis> pstolowski: otherwise looks good
[12:38] <zyga> hmm
[12:38] <zyga> the debian image has weird repos:
[12:38] <zyga> W: GPG error: http://dl.google.com/linux/chrome/deb stable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 78BD65473CB3BD13
[12:38] <zyga> why do we have a chrome PPA in a test image?
[12:41] <pedronis> pstolowski: btw we the tests were passing, maybe we need to mock release.OnClassic a bit more carefully
[12:42] <pedronis> that's old, not really related to the new code
[12:49] <pstolowski> pedronis: yes, you're right, thanks for catching!
[12:52] <mup> PR snapcraft#3006 opened: repo: always use host release and arch for Ubuntu <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3006>
[12:54] <cachio> zyga, hi
[12:54] <cachio> I saw that today
[12:54] <cachio> + rm -rf /tmp/snap.rootfs_SwGmI3 /tmp/snap.test-snapd-sh /tmp/snap.test-snapd-simple-service
[12:54] <cachio> rm: cannot remove '/tmp/snap.rootfs_SwGmI3': Device or resource busy
[12:55] <cachio> is it similar to what you sent yesterday
[12:55] <cachio> the issue in postrm
[12:55] <cachio> ?
[12:56] <mup> PR snapd#8372 closed: devicestate: generate warning if seeding fails <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8372>
[13:05] <zyga> cachio: no, that's not the same issue
[13:31] <mup> PR snapcraft#3007 opened: go: support projects with multiple binaries when using go.mod <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3007>
[13:34] <zyga> pedronis: I will review the user session daemons PRs
[13:34] <zyga> so the pi 4 heatsink without fans for folks in .pl: https://botland.com.pl/pl/obudowy-do-raspberry-pi/15107-obudowa-do-raspberry-pi-4b-aluminiowa-czarna-lt-4b03.html
[13:35] <zyga> and the version with fans https://botland.com.pl/pl/obudowy-do-raspberry-pi/15106-obudowa-do-raspberry-pi-4b-aluminiowa-z-dwoma-wentylatorami-czarna-lt-4b02.html
[13:35] <zyga> I bought both and I think the fans are useful, the heatsink got pretty hot otherwise
[13:35] <zyga> the same product can be obtained in other countries
[13:36] <zyga> it's brand new so should be coming in stock
[13:37] <ijohnson> abeato: just for the record are you also specifying the -bios option to ovmf ?
[13:39] <abeato> ijohnson, I tried that later and it crashed too - maybe the daily had some problem
[13:39] <ijohnson> mmm like you don't even get to the kernel ?
[13:40] <abeato> ijohnson, no - but later I created a UC20 image myself with some help from lool and I could get it to run
[13:40]  * zyga will grab some food and get back to reviews
[13:40] <ijohnson> abeato: ok were you using the image from cdimage originally?
[13:40] <abeato> I found other problems though - the network interface was not found by console-conf
[13:40] <abeato> yes
[13:41] <ijohnson> abeato: ok yeah I think there's something wrong with the images on cdimage, needs some investigation
[13:41] <abeato> ok
[13:50] <ijohnson> abeato: fwiw I just booted a fresh image I built with all edge or 20/edge snaps and it had a network connection fine, my qemu parameters are this:
[13:50] <ijohnson> https://www.irccloud.com/pastebin/C5EmaXnz/
[13:50] <abeato> ijohnson, thanks, will give that a try
[13:51] <ijohnson> and I built from this model: https://github.com/snapcore/models/blob/master/ubuntu-core-20-amd64-edge.model with these snaps:
[13:51] <ijohnson> https://www.irccloud.com/pastebin/nkoV2isM/
[13:52] <abeato> cool!
[13:54] <cachio> zyga, something insteresting
[13:54] <cachio> in bionic and focal we install evolution-data-server pkg
[13:54] <cachio> zyga, but https://paste.ubuntu.com/p/YSxvmGnSRK/
[13:54] <zyga> mmm
[13:55] <zyga> maybe do rdepends gdm3
[13:55] <zyga> and see what's there
[13:55] <zyga> something is pulling it in for sure
[13:55] <cachio> yes
[13:55] <cachio> 1 minutes, I am starting the instance
[13:56] <lool> abeato: how did you resolve the network connection issue?
[13:57] <zyga> cachio: rdepends you can check locally
[13:57] <abeato> lool, I've not solved it yet :) - I was about to try ijohnson stuff
[13:57] <lool>     -device virtio-net-pci,netdev=mynet0 \
[13:57] <lool> let's see  :-)
[13:59] <cachio> zyga, https://paste.ubuntu.com/p/BxZvWzWV99/
[14:00] <zyga> cachio: try this command
[14:00] <zyga> apt-cache rdepends gdm3 https://www.irccloud.com/pastebin/fVU2NVJt/
[14:00] <zyga> cachio: we must have got one of those installed
[14:00] <zyga> _or_ it's a recommends that is followed
[14:03] <cachio> I'll try that
[14:19] <mup> PR snapcraft#3004 closed: storeapi: add channel-map endpoint <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3004>
[14:20] <ijohnson> abeato: any luck?
[14:20] <cachio> zyga, none of them is installed https://paste.ubuntu.com/p/vHqV7gK2Tk/
[14:20] <mborzecki> zyga: ijohnson: pstolowski: which of you would like to take a look at https://github.com/CanonicalLtd/subiquity/pull/655 ?
[14:20] <mup> PR CanonicalLtd/subiquity#655: console_conf: implement UC20 recovery chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/655>
[14:21] <mborzecki> it might not match exactly our python formatting/naming rules, but tried to make it as close to what is already in subuiquity as i could
[14:21] <ijohnson> mborzecki: I can take a look at it, but I'm far from a python expert so I'll really just be reviewing for logic and not style or pythonicness
[14:21] <ijohnson> also wow that PR keeps growing :-)
[14:22] <mborzecki> thanks!
[14:22] <ijohnson> last I looked it was like 500 lines
[14:22] <mborzecki> ijohnson: tests made it grow a lot
[14:22] <mup> PR snapcraft#2995 closed: Add gcc to the build-packages for the gnome-3-34 extension <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2995>
[14:23] <cachio> zyga, I think –no-install-recommends should be used as you suggested
[14:23] <cachio> y
[14:25] <cachio> zyga, https://paste.ubuntu.com/p/bPVYwr9cgt/
[14:25] <cachio> zyga, I'll create a new PR in snapd to address that, thanks
[14:26] <pstolowski> mborzecki: i can take a look too, with same remark as Ian
[14:26] <mborzecki> pstolowski: thanks!
[14:28] <mvo> thanks zyga for help with this --no-intsall-recommends
[14:31] <zyga> I can look soon
[14:33] <mvo> zyga: I updated 8394
[14:35] <zyga> cachio: yeah, that's great
[14:35]  * zyga checks backlog
[14:42] <mup> PR snapd#8396 opened: tests: install dependencies with apt using --no-intsall-recommends <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8396>
[14:44] <zyga> mborzecki: as a meta-comment, it would be great to have some type annotations there
[14:45] <abeato> ijohnson, I just see a "Create bond" option, is that expected?
[14:45] <pstolowski> zyga: can you take another look at #8378?
[14:45] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[14:45] <zyga> pstolowski: sure
[14:45] <ijohnson> abeato: no :-/
[14:45] <ijohnson> abeato: what version of qemu are you using ?
[14:45] <zyga> we should snap qemu
[14:45] <ijohnson> abeato: I have QEMU emulator version 4.2.0 (Debian 1:4.2-3ubuntu4)
[14:46] <ijohnson> zyga: someone did I think? but it was not qemu directly it was one of the higher level things
[14:46] <abeato> ijohnson, I wonder if it is OVMF_CODE.ms.fd, I do not have that
[14:47] <abeato> ijohnson,  2.11.1(Debian 1:2.11+dfsg-1ubuntu7.23 - bionic, I guess I need to upgrade
[14:47] <ijohnson> oh wow yeah I think you need a new qemu version, can you try with a focal machine qemu ?
[14:47] <ijohnson> cmatsuoka: do you remember what the oldest version of qemu we have successfully booted uc20 with is? I seem to remember you had an old version for a while
[14:48] <ijohnson> abeato: re: OVMF_CODE I don't think that's an issue you wouldn't have made it to booting kernel and such if that was the issue
[14:48] <cmatsuoka> ijohnson: it was the stock bionic qemu I think
[14:48] <abeato> ijohnson, will try newer qemu, thanks
[14:48] <cmatsuoka> ijohnson: but with a newer ovmf
[14:49] <cmatsuoka> from... eoan?
[14:49] <ijohnson> ahhhh
[14:49] <ijohnson> cmatsuoka: but again that wouldn't affect networking would it?
[14:49] <cmatsuoka> never had problems with networking
[14:55] <cmatsuoka> mm wait, I think in early images we did have some problems with network options in console-conf
[14:56] <cmatsuoka> but it's already fixed
[15:11] <ijohnson> cmatsuoka: yeah I've never had problems with no network save when I wasn't able to boot it at all, but the oldest version of qemu I used was disco
[15:12] <ijohnson> (the version of qemu from disco)
[15:18] <zyga> mvo: https://github.com/snapcore/snapd/pull/8394#discussion_r401697213
[15:18] <mup> PR #8394: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[15:20] <zyga> pstolowski: https://github.com/snapcore/snapd/pull/8378#pullrequestreview-385691376 +1
[15:20] <mup> PR #8378: o/configcore: introduce core config handlers (3/N) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8378>
[15:21] <pstolowski> zyga: thanks!
[15:26] <zyga> hmm
[15:26] <zyga> latest lxd is not working on arm
[15:26] <zyga> fresh install fails
[15:26] <zyga> Error: Get "http://unix.socket/1.0": dial unix /var/snap/lxd/common/lxd/unix.socket: connect: permission denied
[15:26] <zyga> ah, on core we're not adding the user to the lxd group
[15:26] <zyga> bummer
[15:29] <zyga> I'll resume reviews in an hour
[15:29] <zyga> my family needs some help
[15:29] <zyga> o/
[15:31] <mvo> zyga: thanks, in meetings but looking now
[15:33]  * ijohnson takes a break
[15:35] <mvo> zyga: please reload 8394, looks ok to me, looks like the comment thing stale detection was not working
[15:35] <zyga> mvo: I reloaded and it's still saying "Output if seeding was successful"
[15:35] <zyga> is that expected?
[15:36] <mvo> zyga: yeah, it's different from before
[15:36] <zyga> oh
[15:36] <mvo> zyga: do you think this should be different?
[15:36] <zyga> I mean the word output is weird
[15:36] <zyga> output what?
[15:36] <mvo> zyga: "Output true/false if seeding was successful"?
[15:36] <zyga> yeah but the help message just says "output if seeding was succesful"
[15:36] <zyga> what you said above is better
[15:38] <mvo> zyga: ok, will update
[15:38] <zyga> it's ok
[15:38] <zyga> I can send a follow up
[15:38] <zyga> just wasn't sure if github is broken
[15:38] <zyga> or if we are talking about separate things without knowing it
[15:38] <zyga> mvo: LGTM and I'll send a patch
[15:39] <zyga> +1
[15:39] <mvo> zyga: updated
[15:40] <zyga> thank you :)
[15:40] <mvo> zyga: slightly changed but hopefully good
[15:40] <mvo> zyga: let me know :)
[15:40] <zyga> yeah, that's good :)
[15:40] <zyga> thanks!
[15:40] <mvo> zyga: thank you!
[15:40] <mvo> zyga: this will unblock 2.44.2 :)
[16:16] <mup> PR snapd#8394 closed: snap: add `snap debug state --is-seeded` helper <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8394>
[16:21] <cachio> cmatsuoka, zyga reboot loop in digital ocean also happens
[16:21] <cachio> same bahaviour
[16:21] <cachio> so it is not related to gce
[16:24] <mvo> zyga, ijohnson I updated 8382 to use the snap debug validate-seed to properly fix/disable this
[16:25] <ijohnson> mvo: nice looking now
[16:26] <mvo> ijohnson: indeed, I'm much happier with this than with what we had before
[16:26] <ijohnson> yes this will hopefully make it a much better experience for users who run into this
[16:27] <ijohnson> mvo thanks, approved
[16:27] <mvo> \o/
[16:27] <mvo> thank you!
[16:28] <mup> PR snapd#8393 closed: cmd/snap,seed: validate full seeds (UC 16/18) for 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8393>
[16:29] <mvo> cachio: do we need anything for 2.44.2, any test fixes or anything? if not I will most likely finalize it tonight/tomorrow morning
[16:30] <cachio> mvo, no
[16:30] <cachio> mvo, no so far
[16:34] <mvo> cool
[16:35] <mup> PR snapd#8384 closed: tests: run "lxd" test again (reverts PR#8381) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8384>
[16:46] <zyga> mvo: looking
[16:47] <mup> PR snapd#8370 closed: snap-bootstrap: fix disk layout sanity check <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8370>
[16:49] <zyga> mvo: https://github.com/snapcore/snapd/pull/8382#pullrequestreview-385768438
[16:49] <mup> PR #8382: packaging: detect/disable broken seed in the postinst <Created by mvo5> <https://github.com/snapcore/snapd/pull/8382>
[17:06] <mvo> zyga: replied
[17:07] <zyga> mvo: approved, thanks
[17:07] <mvo> zyga: \o/
[17:09] <jdstrand> mvo (cc ijohnson): I reviewed PR 8304 (and removed the blocked tag)
[17:09] <mup> PR #8304: usersession/userd: add zoommtg url support <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
[17:09] <jdstrand> ijohnson: note, there is a non-blocking comment in there about zoomus://
[17:10] <ijohnson> thanks jdstrand I haven't seen that before, have you ever seen zoomus:// ?
[17:10] <jdstrand> ijohnson: no, just in that blog. it seems like it is just for iOS/android
[17:10] <ijohnson> jdstrand: ack
[17:10] <jdstrand> ijohnson: but I don't know for sure
[17:12] <mup> PR snapd#8304 closed: usersession/userd: add zoommtg url support <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8304>
[17:20] <ijohnson> mvo: do you want to cherry-pick 8304 on top of release/2.44  ?
[17:27] <ogra> jdstrand, snap install zoom-client ;) (sadlyy i cant make it register a mime type to open zoomus:// urls yet)
[17:30] <jdstrand> ogra: https://forum.snapcraft.io/t/allow-snaps-to-register-new-mime-types/6467/10
[17:30] <jdstrand> ogra: I suggest Wimpress or someone raise this in stakeholders meetings to see if it can get roadmapped
[17:31] <ogra> well, it isnt urgent and i know there are more pressing tasks on the TOD of the snapd team ... but yeah, i saw that
[17:31] <ogra> *TODO
[17:32] <ogra> iirc that thread is pretty old already
[17:32]  * ogra checks again
[17:32] <jdstrand> ogra: it is, but with new comments
[17:32] <jdstrand> ish
[17:33] <ogra> yeah
[17:42] <cjp256> stgraber: came across an random failure `aa-exec: Permission denied` during `lxd waitready` following snap install: https://travis-ci.org/github/snapcore/snapcraft/jobs/666847835#L403  I'm not sure if it's an LXD issue or maybe a snapd issue?  Any idea?  Happy to submit a bug report, just wanted to send it to the right place :)
[17:43] <stgraber> cjp256: sounds like the lxd-support interface wasn't properly connected or applied
[17:44] <cjp256> stgraber: thanks!
[17:57] <cjp256> stgraber: fwiw, reported at https://bugs.launchpad.net/snappy/+bug/1870201
[17:57] <mup> Bug #1870201: lxd-support interface doesn't appear to get properly connected/ready <Snappy:New> <https://launchpad.net/bugs/1870201>
[17:58] <mup> Bug #1870201 opened: lxd-support interface doesn't appear to get properly connected/ready <Snappy:New> <https://launchpad.net/bugs/1870201>
[18:36] <interfect> Hey, what directories does snapd store state in?
[18:37] <interfect> I'm trying to run snapd inside Docker, and I need to set up volumes wherever snapd writes files it expects to read later, so I can destroy and recreate the container and not lose installed snaps.
[18:38] <interfect> Apparently preserving /var/run/snapd and /var/cache/snapd is not sufficient. Where else does snapd write to?
[18:39] <ogra> /etc/systemd/system ....
[18:39] <ogra> and /varLib/snapd
[18:39] <ogra> */var/lib/snapd
[18:40] <ogra> and if you have users also ~/snap and all the data therein
[18:48] <interfect> Hm. It looks like it drops files in /etc/systemd/system which need to be preserved, next to a bunch of files from the base image that also need to be there. So you can't just mount an empty host directory there to hold snapd's files, because that would hide all the files from the base system.
[19:09] <zyga> stgraber, cjp256 we've seen this randomly in tests as well
[19:09] <zyga> but I'm skeptical it's on snapd side, we really don't run any commands before confinement is set up
[19:10] <zyga> as for the case that an interface is not connected we would have to look
[19:10] <zyga> stgraber: when does lxd use aa-exec? super early on?
[19:11] <mup> PR snapd#8392 closed: tests: remove google-tpm backend from spread.yaml <Simple 😃> <Skip spread> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8392>
[19:11] <mup> PR snapd#8396 closed: tests: install dependencies with apt using --no-install-recommends <Simple 😃> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8396>
[19:12] <stgraber> zyga: in this case, cjp256 is running the "lxd" command from the snap which does use the a--exec wrapper logic
[19:13] <zyga> cjp256: in the case when it failed, did it work just a moment later
[19:13] <zyga> cjp256: or did you have to do something to fix it?
[19:13] <cjp256> zyga: it was on google spread, i couldn't really do anything to test that unfortunately
[19:13] <zyga> aha
[19:13] <zyga> yeah, same as we saw :/
[19:13] <zyga> it's rather infrequent, maybe once a week
[19:13] <cjp256> but i expect that it worked fine on the next attempt
[19:14] <cjp256> i imagine we can just write a simple script to loop the same steps and maybe repro
[19:18] <interfect> OK I worked out how to get the volume to initialize from the container with https://github.com/MatchbookLab/local-persist but preserving /etc/systemd/system and /var/lib/snapd and /home isn't enough to make snapd keep its state across destruction and recreation of the container.
[19:18] <interfect> Or rather it seems that the snap stays installed but the command it sets up on the PATH goes away
[19:19] <interfect> Is /snap/bin bind-mounted over from somewhere else on the filesystem or something?
[19:24] <ijohnson> interfect: unfortunately snapd inside docker does not really work, because snapd needs lots of permissions to run, so even if you can get all the files in place, snapd would probably not start successfully
[19:27] <interfect> No I have it starting successfully, and I can even run snaps!
[19:28] <interfect> It looks like mounting /snap as a Docker volume also solves the persistence problem.
[19:28] <interfect> I'm working on top of https://github.com/ogra1/snapd-docker
[19:28] <interfect> But I'm adding the bits I need to also grant X11 access
[19:29] <interfect> It manages to turn off enough of Docker's confinement that snapd can run and do its confinement.
[19:29] <interfect> The only problem I have left is that I need to start a snap as root before it runs properly as my user.
[19:30] <interfect> Otherwise I get something like: cannot preserve mount namespace of process 875 as teatime.mnt: Permission denied
[19:31] <interfect> The only Google result for that error is the snapd source code; can anyone explain why it needs to preserve a mount namespace and why it would only work if root is running the `snap` binary? `snapd` is running as root the whole time.
[20:18] <ijohnson> interfect: ah well if you're using the bits from ogra's snapd-docker then you've already probably read the large security caveats there
[20:18] <ijohnson> interfect: why can't you run snaps outside of docker anyways?
[20:19] <ijohnson> interfect: I don't know exactly what you need to allow to make that mount namespace error go away, but it's quite likely that things have changed in snapd enough that ogra's project doesn't fully work there
[20:32] <mup> PR snapcraft#3008 opened: cli: use the channel-map api for status <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3008>
[21:06] <interfect> ijohnson: My home directory isn't under /home on my system, so I'm trying to work around the lack of any support in snapd for this: https://forum.snapcraft.io/t/support-for-non-home-homedirs/11209
[21:07] <interfect> ijohnson: If I run snapd and all the snaps in a Docker container, I can mount my real home directory as /home/$USER in the container, and also provide a /etc/passwd that claims that that is my home directory.
[21:08] <interfect> The recommended workaround of bind mounting your home directory into /home isn't sufficient, because it looks at /etc/passwd instead of $HOME for the user executing the snap to try and figure out where the home directory is.
[21:09] <interfect> So in addition to doing the bind mount you would still have to actually change your home directory to /home/$USER, as far as I can tell.
[21:10] <interfect> There must be a much lighter-weight way to trick snap/snapd into thinking your home directory is actually set to /home/$USER, but I haven't found one, and putting the whole thing in Docker seems to actually mostly work.
[21:21] <interfect> IMHO if Snap apps just saw my home directory as /home/$USER wherever it *really* was, it would save me a lot of headaches. I'm not sure having a consistent view of file paths between snap apps and the rest of the system is really that important.
[22:37] <mup> PR snapd#8397 opened: cmd/snap-confine/mount-support-nvidia.c: add libnvoptix as nvidia library <Simple 😃> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8397>
[23:17] <mup> PR snapd#8254 closed: usersession/userd: add "zoommtg" to the white list of URL schemes handled by xdg-open <⛔ Blocked> <Created by troyready> <Closed by troyready> <https://github.com/snapcore/snapd/pull/8254>


[08:17] <lordievader> Good morning
[11:46] <BluesKaj> Hi folks
[12:13] <Mamarok> hm, am I a bit dumb or do we really only have pgsql version 10 in the archives, nothing higher?
[12:13] <Mamarok> or do I need an extra PPA?
[12:17] <RikMills> !info postgresql-11
[12:18] <RikMills> !info postgresql-11 eoan
[12:18] <RikMills> !info postgresql-11 focal
[12:18] <RikMills> Mamarok: ^
[12:19] <Mamarok> weird, discover doesn't even list it
[12:19] <RikMills> Mamarok: perhaps no appstream data
[12:21] <BluesKaj> odd, postgresql shows in muon
[12:22] <BluesKaj> that's one reason why I don't use discover
[12:23] <RikMills> nope. no appstream data, so to discover, it doesn't exist
[12:25] <Mamarok> right, so back to Muon then
 hi guys!
 I am doing my first minimal install of Kubuntu 18.04. Using Breeze dark.
 Having weird theming issues.
 I use Kubuntu 18.04 since it came out.
 So I usually know my way around.
 Kate always reverts to the default theme after a restart and I have to set it to breeze dark after each reboot.
 Libre office (from the repos) does not follow the dark theme, although it does on my other computers.
 Any ideas?
 It really bugs me since I use Kate and Writer a lot!
 @RikMills
 😊
 I am writing a "first steps after installing Kubuntu 18.04" in German for friends and family, @RikMills !
 Not at the moment, I'll try to look later
 Sure.
 See you later!
[14:54] <user|37456> hi every body. I have problem whit my kubuntu 19.10. words dont show correctly in chrome and vlc subtitle. I have changed font setting but it didnt work.
 @user|37456, Hi! Can you send a screenshot?
[14:55] <user|37456> https://www.filepicker.io/api/file/Uco2oayqQH66lmf8HUII?signature=7bc386dd407dc1fb696e2005e9f6dd2e24cdbed47886039fa72242609f9b0538&policy=eyJleHBpcnkiOjE1NzY2ODI3MTN9
 @user|37456, So sorry, I am afraid, that's above my level of expertise...
[20:17] <Linzeestomp> anyone online who has the current release candidate of Wine? I'm trying to figure out how to get it. I'm guessing it's gonna be a compile/build yourself type deal.
[21:20] <valorie> a release candidate implies a release of some sort, or at least a tarball
[21:21] <bprompt> Õ¿Õ
 @Linuxophil, @RikMills , is now a better time? Do you have an idea why that is? Else I might have to reinstall the full install of Kubuntu 18.04. Kubuntu 18.04 with backports ppa and Libre office ppa stable channel.
 Sorry, no. I would have to set up a VM to test, which might not help much anyway if it is some weird config issue.
 @RikMills, Nono, dont consider doing that. I will just set it up again with a full install. Weird though. It is my first try with a minimal install. One for the bin then. 😉
 Thanks for answering though!
 Usually I would creat a new user, log in with that and see if the same thing happens.
 By the way, last week, two more people using Kubunt u 18.04!
 @RikMills, I can do that.
 If it repeats you know it is a system issue. If it does not, you know that it is some weird user config issue on your current user.
 @RikMills, it repeats.
 @RikMills, Is it valuable to you if I send you screenshots of the issue? Not to trouble shoot my problem, but for general knowledge. I will reinstall anyway.
 Do it anyway for the record.
 OK
 (Photo, 1280x720) https://irc-attachments.kde.org/bbXDw3n1/file_21044.jpg
 (Photo, 1280x720) https://irc-attachments.kde.org/UY3kYcaR/file_21045.jpg
 Breeze and breeze dark are not even recognized.
 This issue existed before, but is normally solved many versions ago.
 I do a lot of messign with things, but don't think I have ever made things break like that. WELL DONE. lol
 Also: Kate always reverts to "Normal" after restart.
 @RikMills, Really superweird. But I actually have an almost click by click account of how I did the new install because I used it to write a "first things to do after installing Kubuntu 18.04" for family and friends.
 And I actually did all the things as I always do them. The only difference is that I used the minimal install this time.
 Unfortunately the writeup is in German.
 @RikMills, And also: Thanks! 😂😂😂
 is your issue in LIbreoffice?
 @bprompt> <Linuxophil, Yes. One of them is.
  you know you can always run a different version of it, you can download the whole suite from their site and it installs separately to /opt/Libreoffice, I have kubuntu 16.04 and that came with Libreoffice 5.0, but due to some issues, I installed version 4.2 from their site, works smooth, runs off /opt, also installed version 6.0 but
[22:27] <bprompt> didn't like it for what I use it, mainly for Libreoffice Draw
 @bprompt> <Linuxophil, Do you know a solution?
 @bprompt> <Linuxophil, I see.
 nevertheless, there are at least two problems, so I will reinstall.
 alrity, installation on an SSD for me is a 10 minutes issue
[22:30] <bprompt> however I always back up my $HOME
  optionally office wise, there's always WPS office, which is very decent
 @bprompt> <Linuxophil, ...but not open source...
 Good night fellow Kubuntu friends!
[23:13] <Linzeestomp> Does anyone possibly know why my bluetooth was working yesterday and now kubuntu doesn't even pick up any adapters?


[10:49] <henrix> dgadomski: i'm seeing a failure verifying bug #1124250 . could you please have a look?
[10:50] <henrix> dgadomski: the failure doesn't come from the original reporter, so it is possible the user is having a different issue
[11:31] <dgadomski> henrix: hey, I will ask the user about it, but I suspect that he didn't extend his key quota, I'll confirm that
[11:32] <henrix> dgadomski: awesome, thanks
[14:54] <jsalisbury> **
[14:54] <jsalisbury> ** Ubuntu Kernel Team Meeting - Canceled**
[19:25] <cristian_c> jsalisbury, hello
[19:28] <jsalisbury> cristian_c, hi
[19:30] <cristian_c> jsalisbury, sorry, I'd like to know if there any news about the kernel build
[19:31] <jsalisbury> cristian_c, I still haven't completely narrowed it down.  I'll make time to take another look at it this week.
[19:33] <cristian_c> jsalisbury, ok, thanks


[03:25] <_mup_> ensemble/standardize-log-testing r254 committed by<EMAIL_ADDRESS>[03:25] <_mup_> Switched to using processEnded to ensure that output streams are ready for reading, removed unnecessary test timeout override, and removed some save_logging/reset_logging
[03:32] <mhall119> okay, I'm checking out ensemble formulas, but they're not making much sense to me
[03:32] <mhall119> is anyone around to help?
[03:37] <_mup_> ensemble/standardize-log-testing r255 committed by<EMAIL_ADDRESS>[03:37] <_mup_> Removed last parts of save_logging/reset_logging/assertInDefaultLog from codebase
[12:17] <_mup_> Bug #795894 was filed: Add python-yaml to the dependencies <Ensemble:New> < https://launchpad.net/bugs/795894 >