[10:47] <Wiz_KeeD> hey guys, i need some help with a merge, my scenario is exactly like this guy: http://stackoverflow.com/questions/6581330/how-to-properly-merge-two-bzr-branches
[10:47] <Wiz_KeeD> But I would like to see all the differences between the files
[10:59] <Wiz_KeeD> Can someone tell me how bzr merge works?


 Mirv: Hi! Can I please be added to ~ubuntu-qt-packagers?
[12:46] <Mirv> tsimonq2: done!
 @Mirv, Thanks!
[16:56]  * acheronuk says welcome to queuwbot. lol
[16:57] <acheronuk> or queuebot even
 :D


[19:48] <cub> !es
[20:00] <cub> The web site states "The minimum memory requirement for Ubuntu Studio is 512 MB of memory.", anyone tested that in a while or do we follow the xubuntu recommendations?
[20:01] <cub> I think xubuntu did a lot of testing with minimal ram for the 13.10 release?
[20:04] <knome> not too much, but some
[20:04] <knome> you can run xubuntu with 512mb ram


[00:38] <bluesabre> Definitely... I don't plan to touch 4.15+ packaging until at least after the LTS
[00:39] <Unit193> We'll see.
[17:00] -SwissBot:#xubuntu-devel- Reminder: Next meeting chair is knome


[17:49] <ramvi> When customizing Wubi, the WubiGuide tells me to disable signature checks in data/settings.nsh, but that file doesn't seem to exist?
[17:52] <ramvi> And now I've been though all revisions back to September. It seems to never have existed.. Is it possible to disable gpg tests?
[23:26] <CIA-3> debian-installer: cjwatson * r1291 ubuntu/debian/changelog: releasing version 20081029ubuntu101
[23:28] <CIA-3> debian-installer: cjwatson * r1292 ubuntu/debian/changelog: No-change rebuild to pick up new components.
[23:30] <CIA-3> debian-installer: cjwatson * r1293 ubuntu/debian/changelog: releasing version 20081029ubuntu102


[00:25] <rick_h_> katco: pong
[01:45] <axw> let the merge wars commence
[01:46] <axw> thumper wallyworld waigani anastasiamac: if you have things waiting, master is got unblocked
[01:46] <wallyworld> \o/
[01:46] <axw> naturally I started mine merging before I told you
[01:46] <waigani> axw: lol, cheers
[01:53] <mup> Bug #1501381 changed: panic: cannot pass empty version to VersionSeries() <blocker> <ci> <intermittent-failure> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1501381>
[01:53] <mup> Bug #1501432 changed: BootstrapSuite tests fail on non-ubuntu platforms with no matching tools <blocker> <centos> <ci> <test-failure> <windows> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1501432>
[01:53] <mup> Bug #1501786 changed: juju cannot provision precise instances: need a repository as argument <blocker> <ci> <precise> <regression> <juju-core:Fix Released by cherylj> <https://launchpad.net/bugs/1501786>
[02:18] <rick_h_> perrito666: how big?
[02:19] <perrito666> rick_h_: something that can compile mongo in less than the time it takes for launchpad I am trying to fix the willy build of a mongo3 ppa and I dont have a willy nor intentions of breaking my laptop
[02:20] <rick_h_> perrito666: what's your LP id?
[02:20] <perrito666> rick_h_: hduran-8
[02:23] <rick_h_> perrito666: oh bah, it's in use.
[02:23] <perrito666> rick_h_: ??
[02:23] <rick_h_> perrito666: well you can ssh to maas.jujugui.org and create an lxc container on that laptop and use it if you'd like, though tit's not that fast
[02:24] <rick_h_> perrito666: I thought we had an unused node in our guimaas the team uses
[02:24] <perrito666> rick_h_: I appreciate it, ill ponder on it if I dont fall asleep on the kb before
[02:24] <rick_h_> perrito666: but looks like the team put it to use
[02:25] <rick_h_> perrito666: ok, well let me know. We've got hardware if it'll help. However you should be able to create a wily lxc and do the builds in there and keep the laptop safe
[02:26] <natefinch> lol compiling mongo is super slow...  it took forever even on my quad core i7 with a beastly SSD.  That's C++ for you.
[02:26] <rick_h_> perrito666: worst case can ask urulama to take over the QA environment for a bit and get full machines
[02:27] <natefinch> I think it took like 45 minutes on my laptop
[02:27] <rick_h_> natefinch: have a 6 core 32gb machine if the instructions are easy for me to dupe
[02:29] <natefinch> rick_h_: I haven't done it in like a year, but IIRC, the directions were terrible
[02:30] <rick_h_> natefinch: :/ well if it would help happy to try to get something better working. shoot, maybe just get a giant ec2 machine for a bit. but understand if it's just a pita
[02:31] <perrito666> it is sort of a pita, especially the one I am trying to build, which is a debian package
[02:31] <natefinch> rick_h_: it's a good lesson for why perrito666 shouldn't buy such namby pamby laptops
[02:32] <rick_h_> lol
[02:32] <rick_h_> laptops are for portability, many core desktops with lots of ram for real work :)
[02:32] <perrito666> natefinch: my laptop kicks ass, I just dont want to install willy on it
[02:32] <natefinch> haha
[02:32] <rick_h_> perrito666: but surely in an lxc it's safe?
[02:32] <perrito666> rick_h_: ill give it a shot, I hadn't thought of it
[02:32] <natefinch> perrito666: just giving you shit :)
[02:33] <perrito666> natefinch: so is mongo :p
[02:33] <perrito666> I really need to buy some heavy lifting machine I am just too lazy to import it
[02:33] <perrito666> and to cheap to pay local price for what I can get here
[02:33] <natefinch> perrito666: probably easier to just get us to stop using mongo
[02:35] <natefinch> perrito666: I saw our new competitor nomad uses boltdb... which blows mongo out of the water as far as compile time and ease of setup.  Of course, it doesn't have replication, so they must be doing that themselves somehow.. but still.. I love boltdb... pure Go, man.  That's the way to do it.
[03:18] <cmars> I like boltdb, i've used it in some side-projects and it's always been great to work with. I've never really pushed it in terms of concurrent txns though.
[07:11] <mup> Bug #1502016 opened: Juju-quickstart error message lacks detailed error info <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1502016>
[07:14] <mup> Bug #1502016 changed: Juju-quickstart error message lacks detailed error info <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1502016>
[07:17] <mup> Bug #1502016 opened: Juju-quickstart error message lacks detailed error info <canonical-bootstack> <juju-core:New> <https://launchpad.net/bugs/1502016>
[08:37] <TheMue> fwereade: Happy Birthday
[08:48] <dimitern> fwereade, oh wow, happy birthday indeed! :)
[08:50] <anastasiamac> fwereade: ¸¸♬·¯·♩¸¸♪·¯·♫¸¸Happy Birthday To You¸¸♬·¯·♩¸¸♪·¯·♫¸¸
[08:58] <fwereade> TheMue, dimitern, anastasiamac: <3
[08:59]  * fwereade is tired and is taking a pre-travel swap day to relax
[09:02] <voidspace> fwereade: hippy bathday fella
[09:02] <voidspace> fwereade: enjoy the rest and seattle
[09:02] <fwereade> voidspace, cheers :)
[09:21] <mfoord> frobware: dimitern: conflicts resolved and unit public address branch set to attempt to land on master (again...)
[09:21] <dimitern> mfoord, awesome!
[09:21] <mfoord> frobware: dimitern: ec2 subnets branch also landing on master
[09:21] <dimitern> mfoord,
[09:22] <dimitern> mfoord, and it did land on 1.25 alread?
[09:22] <mfoord> dimitern: yup, already landed there
[09:22]  * dimitern gaahh I seem to be eating letter today
[09:22] <mfoord> :-)
[09:34] <rogpeppe> mfoord: fancy a review? http://reviews.vapour.ws/r/2822
[09:36] <mfoord> rogpeppe: sure, coffee first
[09:36] <rogpeppe> mfoord: ta!
[10:11] <mfoord> rogpeppe: the only wart is having assertErrorResponse return the failure for a single use case
[10:12] <rogpeppe> mfoord: yeah, i had to think a bit about that
[10:12] <rogpeppe> mfoord: if you've got a better suggestion... ?
[10:12] <mfoord> rogpeppe: haha, not sure I do :-)
[10:12] <mfoord> I'll have another look
[10:12] <mfoord> the rest is straightforward
[10:13] <rogpeppe> mfoord: thanks
[10:13] <mfoord> it's a common pattern in error testing (or testing in general) - to have some detail that only needs checking once
[10:19] <mfoord> rogpeppe: as doer is only used once, and it's a one line function, does it need to be a separate function?
[10:22] <dimitern> mfoord, is a Doer constructed by a Doerer ?:D
[10:23] <mfoord> dimitern: the doerer is the function that does the doer
[10:23] <mfoord> and what that does, well...
[10:24] <dimitern> is Do()es
[10:24] <dimitern> it even
[10:25] <mfoord> rogpeppe: LGTM with the minor proviso about (maybe) inlining doer
[10:25] <rogpeppe> mfoord: thanks
[10:25] <rogpeppe> mfoord: it's like that in the other tests
[10:26] <mfoord> rogpeppe: ah right, fair enough
[10:26] <rogpeppe> mfoord: it could be inlined, but it's like it is to make it trivial to make other similar tests
[10:26] <mfoord> ok
[10:26] <mfoord> fine, drop the issue then
[10:49] <rogpeppe> mfoord: done :)
[10:50] <rogpeppe> fwereade: ping
[10:57] <TheMue> rogpeppe: he's swapping due to Seattle
[10:57] <rogpeppe> TheMue: ah, np
[11:06] <dimitern> TheMue, reviewed - quite a lot of comments I'm afraid, ping me if anything is unclear
[11:06] <TheMue> dimitern: ok, and I appreciate any comments
[11:16] <TheMue> dimitern: jfi, I'll fix it in the 1.25 branch first but mark the issues in your review. later we can forward-port the 1.25
[11:26] <dimitern> TheMue, cheers, sounds good
[11:43] <bogdanteleaga> niemeyer: is -run deprecated in gocheck in favor of check.f?
[11:46] <TheMue> dimitern: great input, you speak juju networking fluently ;) changes are now visible in http://reviews.vapour.ws/r/2823/
[11:50] <dimitern> TheMue, looks good, thanks! I'll leave frobware / voidspace to proof-read as discussed
[11:51] <TheMue> dimitern: cheers
[12:36] <frobware> TheMue, I have a few comments - just wondering whether you want to address dimiter's first before I add mine
[12:37] <TheMue> frobware: I already have done and pushed it, see http://reviews.vapour.ws/r/2823/.
[12:37] <TheMue> frobware: dimitern reviewed my master branch, this is the 1.25 one.
[12:44] <frobware> TheMue, I've add some comments but will want to take another pass. Just adding and publishing now so you're not blocked. OK?
[12:44] <TheMue> frobware: great, thanks
[12:54] <TheMue> frobware: deploy.go:118, singular "space" or plural "spaces"? the latter sounds more natural to me.
[12:57] <frobware> TheMue, You could drop this bit "but not of the cmd and the database space"
[12:58] <TheMue> frobware: ok, thx
[12:58] <frobware> TheMue, leaving it as "deploy 2 instances of haproxy on cloud instances inside subnets of the dmz space only"
[12:59] <TheMue> frobware: short and clear, sounds even better ;)
[13:00] <frobware> TheMue, also note I saw a reference to "carret" which should be "caret"
[13:01] <TheMue> frobware: fixed
[13:14] <niemeyer> bogdanteleaga: Not deprecated per se.. -run still has its usual meaning, but it's orthogonal to gocheck.. The latter has check.f for its own use
[13:15] <bogdanteleaga> niemeyer: hmm, -run doesn't seem to work for me, while check.f does with the same simple regex
[13:27] <mup> Bug #1502127 opened: TestNoUniterUpdateStatusHookInError never reached desired status <ci> <intermittent-failure> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1502127>
[13:27] <mup> Bug #1502130 opened: charm upload fails often on maas <charm> <ci> <maas-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1502130>
[13:30] <mup> Bug #1502139 opened: Panic in TestUpgradeJuju on wily and vivid <ci> <intermittent-failure> <panic> <unit-tests> <vivid> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1502139>
[13:33] <mup> Bug #1502139 changed: Panic in TestUpgradeJuju on wily and vivid <ci> <intermittent-failure> <panic> <unit-tests> <vivid> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1502139>
[13:36] <mup> Bug #1502139 opened: Panic in TestUpgradeJuju on wily and vivid <ci> <intermittent-failure> <panic> <unit-tests> <vivid> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1502139>
[13:51] <mup> Bug #1502139 changed: Panic in TestUpgradeJuju on wily and vivid <ci> <intermittent-failure> <panic> <unit-tests> <vivid> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1502139>
[13:52] <mgz> what are you on mup...
[13:54] <mup> Bug #1502139 opened: Panic in TestUpgradeJuju on wily and vivid <ci> <intermittent-failure> <panic> <unit-tests> <vivid> <wily> <juju-core:Triaged> <https://launchpad.net/bugs/1502139>
[13:55] <niemeyer> bogdanteleaga: Probably because you're expecting -run to do something it doesn't do
[13:57] <bogdanteleaga> niemeyer: the docs seem to say they do pretty much the same thing(-run and check.f), just that check.f takes suites as well
[13:57] <mup> Bug # opened: 1502149, 1502153, 1502154, 1502158
[14:00] <frobware> dimitern, I was just getting back to the demo. Which region did you create the subnets in?
[14:00] <dimitern> frobware, eu-central-1
[14:00] <TheMue> frobware: dimitern: done, now just swapping offices. if branch is ok I will immediately merge it into 1.25 and then port it to master
[14:01] <dimitern> TheMue, cheers, will have one last look
[14:07] <mup> Bug #1502140 opened: panic in lastlogin upgrade step <blocker> <ci> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1502140>
[14:09] <frobware> dimitern, TheMue: taking another look
[14:09] <niemeyer> bogdanteleaga: Just that they are different, yes :-)
[14:10] <mup> Bug #1502140 changed: panic in lastlogin upgrade step <blocker> <ci> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1502140>
[14:12] <frobware> dimitern, how do I get to eu-central? My choices are frankfurt or ireland.
[14:18] <mgz> the 1.25 branch is blocked at present, see ^ that bug
[14:19] <mup> Bug #1502140 opened: panic in lastlogin upgrade step <blocker> <ci> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1502140>
[14:27] <dimitern> frobware, eu-central-1 is in frankfurt :)
[14:31] <frobware> dimitern, yeah. I noticed. <face palm>
[14:31] <frobware> :)
[14:38] <natefinch> fwereade: you around?
[15:04] <natefinch> ericsnow: anything I need in the environments.yaml besides type: lxd?
[15:05] <ericsnow> natefinch: nope
[15:08] <katco> fwereade: hey can you give a high-level review of http://reviews.vapour.ws/r/2814 ? i'm doing a detailed review, but i want to make sure we're not doing anything wrong, conceptually
[15:08] <katco> fwereade: i.e. i think it will need a +2 from you
[15:09] <katco> natefinch: i see several places ericsnow's multi error patch would help :)
[15:09] <katco> if only it were in the codebase.... le'sigh
[15:10] <ericsnow> katco: what!!! someone isn't opposed!  ;)
[15:10] <katco> ericsnow: hey, i've always thought it was a good idea
[15:10] <katco> ericsnow: very common patterns
[15:11] <ericsnow> katco: all providers use it (and not for necessarily API-related stuff)
[15:11] <ericsnow> (it = the pattern)
[15:12] <natefinch> definitely a common APIMultiError  would be good.... it's just proposed as being more general than it needs to be now
[15:12] <ericsnow> katco: check out Environ.Instances in conjunction with ErrNoInstances and ErrPartialInstances
[15:13] <ericsnow> natefinch: I wrote it in the first place to meet a non-API use case
[15:13] <katco> natefinch: yeah not sure that's true... ericsnow ran into a place yesterday
[15:14] <natefinch> it just assumes you have an id for each error, which is not always the case... but it would fit many cases, most of which are bulk calls in the API
[15:15] <ericsnow> natefinch: the ID is neither required not necessarily unique
[15:15] <ericsnow> (not -> nor)
[15:16] <perrito666> bbl people
[15:16] <mgz> natefinch: I don't like that retry function much
[15:17] <mgz> means all those tests will have an extra 3s ceiling runtime?
[15:17] <natefinch> mgz: we have to wait for the worker... I don't know how to get around that
[15:19] <natefinch> mgz: and in theory it's up to 3 seconds... though in small scale tests I did find it took a couple seconds for the watcher to notify the worker and for the worker to do its job
[15:20] <natefinch> mgz: I don't know why the worker/watcher cycle is so slow
[15:21] <natefinch> mgz: I also don't know if that slowness is outside the norm.... are they usually instant?  I don't know the details of how the watchers and workers work.... but I know there's a lot of machinery between them.
[15:22] <mgz> natefinch: yeah, i don't have a good answer on overall speed, but why not usin LongAttempt
[15:23] <natefinch> mgz: I thought about using the attempt code, but it didn't really fit with the pattern I wanted, IIRC'
[15:24] <natefinch> mgz: I could certainly look at it again
[15:25] <natefinch> mgz: on second thought, I could make that work.. I missed the fact that I could call HasNext()
[15:26] <mgz> natefinch: that would make me happier, at least we're staying with the existing constants
[15:29] <natefinch> mgz: makes me happier, too.
[15:37] <mup> Bug #1502202 opened: toolsversionchecker worker failing <juju-core:New> <https://launchpad.net/bugs/1502202>
[15:37] <natefinch> mgz: fixed :)
[15:38] <mgz> natefinch: thanks!
[15:38] <natefinch> mgz: thanks for getting me to look at the attempt code again.  I definitely prefer using something already written than handcrafting my own.
[15:41] <aisrael> jcastro: alexisb: lp:1502202 is the first I found. I'm trying to recreate the second.
[15:43] <mup> Bug #1502202 changed: toolsversionchecker worker failing <juju-core:New> <https://launchpad.net/bugs/1502202>
[15:46] <mup> Bug #1502202 opened: toolsversionchecker worker failing <juju-core:New> <https://launchpad.net/bugs/1502202>
[15:55] <aisrael> jcastro: alexisb: I can't recreate the second issue. I've been running 1.25 since alpha1 for daily work and it's been solid except for the previously mentioned issue. Kudos.
[16:17] <katco> natefinch: that is some hairy code. lgtm, but i think we really need someone like fwereade to look at it
[16:18] <fwereade> katco, natefinch: link? (no promises today though)
[16:18] <katco> fwereade: http://reviews.vapour.ws/r/2814/
[16:18] <fwereade> katco, cheers
[16:18] <katco> fwereade: a high-level overview should suffice. just need to make sure we're conceptually doing the right thing.
[16:19] <katco> fwereade: this is the combining txns you and natefinch have been discussing
[16:19] <fwereade> katco, so I see -- awesome :)
[16:23] <natefinch> fwereade: I have a couple concerns... I'm using raw ids across the API... I think that's a no-no, but not sure if I should be creating a new tag just for my new mini collection
[16:24] <fwereade> natefinch, for watcher results it's the least wrong thing to do actually
[16:24] <fwereade> natefinch, might be inclined to go with unit ids though
[16:24] <natefinch> fwereade: that's certainly doable
[16:25] <natefinch> fwereade: the other one is that this is a general worker, but maybe it should be a singular worker?  We don't want multiples of these things doing assignments of the same things at the same time
[16:25] <fwereade> natefinch, (translating id->tag at apiserver Next() time has complications -- but that's where it should be fixed, and for every watcher at once)
[16:25] <fwereade> natefinch, I'd favour making it safe when racing with itself
[16:26] <fwereade> natefinch, singular is a bit yucky
[16:26] <fwereade> natefinch, but you're probably right
[16:26] <fwereade> natefinch, yeah, make it singular, we just need a less layer--breaky singular implementation
[16:26] <natefinch> fwereade: yeah, I started to go down the singular route, but all the current examples seem to use state directly, which I know is a Bad Thing... and trying to get it working with the API was tricky
[16:27] <fwereade> natefinch, yeah, it should just affect where you launch it in  the machine agent
[16:27] <fwereade> natefinch, there's a singular wrappper func which at least keeps the evil out of its clients' hair
[16:27] <fwereade> natefinch, gtg for now
[16:27] <natefinch> fwereade: ok, thanks for the input
[18:03] <natefinch> ericsnow: gah, I hate having methods on a type outside the file where that type is defined... when we get some time, can we maybe not do that?
[18:05] <ericsnow> natefinch: yeah, we should split types like that up along the same line as the files (and compose them into the main type)
[18:05] <ericsnow> natefinch: otherwise we end up with enormous files
[18:07] <natefinch> ericsnow: well.... if it's done well, not not just done to get the methods out of the same file, I think that's ok.  But given that the environ.go file is only 147 lines right now, I think we have a long way to go before we need to start breaking things up.
[18:26] <alexisb> frobware, you potentially around?
[18:27] <perrito666> how do you people keep feature branches up to date?
[18:27] <natefinch> perrito666: merge from master once in a while
[18:27] <natefinch> perrito666: it's not fun
[18:27] <perrito666> natefinch: was thinking on the details :)
[18:27] <perrito666> pr?
[18:27] <perrito666> direct merge?
[18:27] <natefinch> perrito666: meh, just merge
[18:28] <natefinch> rebase if you're feeling lucky
[18:28] <perrito666> natefinch: and you push that to the feature branch directly?
[18:29] <natefinch> perrito666: oh uh... hmm..
[18:29] <natefinch> perrito666: I guess PR.. sorry, wasn't thinking
[18:29] <natefinch> perrito666: though it's generally not something that can really get reviewed
[18:35] <perrito666> mm, can I get permissions to push into a branch in our repo?
[18:40] <mup> Bug #1502140 changed: panic in lastlogin upgrade step <blocker> <ci> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1502140>
[18:43] <mup> Bug #1502140 opened: panic in lastlogin upgrade step <blocker> <ci> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1502140>
[18:46] <mup> Bug #1502140 changed: panic in lastlogin upgrade step <blocker> <ci> <regression> <upgrade-juju> <juju-core:Incomplete> <juju-core 1.25:Triaged by cherylj> <https://launchpad.net/bugs/1502140>
[19:44] <mup> Bug #1502306 opened: cannot find package gopkg.in/yaml.v2 <blocker> <ci> <regression> <juju-core:Incomplete> <juju-core lxd-provider:Triaged> <https://launchpad.net/bugs/1502306>
[20:29] <mup> Bug #1502314 opened: juju-deployer never completes landscape deployment to vmLDS <kanban-cross-team> <landscape> <falkor:Triaged> <juju-core:New> <https://launchpad.net/bugs/1502314>
[20:32] <mup> Bug #1502314 changed: juju-deployer never completes landscape deployment to vmLDS <kanban-cross-team> <landscape> <falkor:Triaged> <juju-core:New> <https://launchpad.net/bugs/1502314>
[20:35] <mup> Bug #1502314 opened: juju-deployer never completes landscape deployment to vmLDS <kanban-cross-team> <landscape> <falkor:Triaged> <juju-core:New> <https://launchpad.net/bugs/1502314>
[20:41] <alexisb> aisrael, jcastro, I really appreciate the feedback on 1.25, that is great!
[20:44] <mup> Bug #1502314 changed: juju-deployer never completes landscape deployment to vmLDS <kanban-cross-team> <landscape> <falkor:Triaged> <juju-core:New> <https://launchpad.net/bugs/1502314>
[20:47] <mup> Bug #1502314 opened: juju-deployer never completes landscape deployment to vmLDS <kanban-cross-team> <landscape> <falkor:Triaged> <juju-core:New> <https://launchpad.net/bugs/1502314>
[21:38] <beisner> alexisb, do we have an eta on the fix for the being ppa-consumable somewhere? https://bugs.launchpad.net/juju-core/+bug/1335885
[21:38] <mup> Bug #1335885: destroy-environment reports WARNING cannot delete security group <amulet> <cloud-installer> <destroy-environment> <landscape> <openstack-provider> <security>
 <juju-core:In Progress> <juju-core 1.24:Fix Committed by thumper> <juju-core 1.25:In Progress by thumper> <https://launchpad.net/bugs/1335885>
[22:06] <alexisb> heya beisner
[22:06] <alexisb> we have a fix committed for that bug for 1.24, but we are currently working to get a blessed build for 1.24 on CI
[22:07] <alexisb> beisner, eta for a 1.24.7 release is next week pending a blessed CI revision
[23:48] <beisner> alexisb, woot, thanks


[00:45] <kirkland> okay, something funny is going on
[02:04] <lifeless> kirkland: ?
[02:04] <lifeless> ixokai: hi, did you get some help? when did you put the tickets in to the login support form ?
[02:05] <ixokai> lifeless: Weeks ago. I didn't yet-- well, mthaddon looked into it a bit a few days ago, but we didn't get a resolution
[02:05] <lifeless> so mthaddon is an appropriate person to look
[02:05] <lifeless> I certainly can't look where he can :)
[02:06] <ixokai> `He changed my email account to see if the + in the address was causing the problems: it wasn't. He was going to talk to someone to look at the mail logs, but I dunno how that went.
[02:07] <lifeless> I suggest you follow up on monday
[02:07] <ixokai> How? :|
[02:07] <ixokai> Since the tickets seem to not work too.
[02:07] <ixokai> Come here again and .. ping? again?
[02:07] <lifeless> he should be in this channel from UTC 0900 through 1700
[02:07] <ixokai> okay
[02:07] <wgrant> The last couple of weeks have been a bit sparse admin-wise.
[03:01] <George_e> Can I request a URL change for my project on Launchpad?
[03:04] <wgrant> George_e: File a question at https://answers.launchpad.net/launchpad/+addquestion and an admin can rename it for you.
[03:04] <George_e> Thanks.
[04:10] <kirkland> lifeless: seemed a reboot solved it
[04:11] <kirkland> lifeless: i was having some really weird failures trying to do bzr things against lp:*
[04:11] <kirkland> lifeless: bzr+ssh:// worked fine
[04:11] <kirkland> lifeless: but not shortnames a la lp:
[04:11] <kirkland> lifeless: no matter, working now
[04:12] <psusi> I uploaded a package to my ppa... before it started building, I realized I made a mistake, so I deleted it.  Now it won't let me upload the corrected version.  It keeps rejecting it saying that version is already there, but I deleted it.
[04:17] <wgrant> psusi: You can't upload the same version twice -- that doesn't make sense.
[04:17] <wgrant> psusi: You need to increment the version number.
[04:17] <psusi> wgrant, but I deleted it
[04:17] <psusi> it is no longer there
[04:18] <wgrant> It is remembered, to avoid confusing everybody and everything.
[04:18] <psusi> it never even got built
[04:18] <nigelb> well, still.
[04:19] <wgrant> It is confusing to both computers and people, not to mention a lie, to have packages with the same version but different contents.
[04:33] <happyaron> Will a deleted ppa remain listed in a person's ppa list?
[04:33] <wgrant> happyaron: At the moment they do (but they're only shown to you, not anybody else).
[04:35] <happyaron> wgrant: I see, thanks.
[05:03] <psusi> so once you have deleted a package from your ppa, it is impossible to replace it?
[05:06] <wgrant> psusi: It's impossible to upload a new package claiming to be the old version.
[05:17] <psusi> but... there is no old version.. it's gone
[15:46] <xapantu> Hi!
[15:47] <xapantu> I need help about rosetta, can I ask here ?
[16:33] <maxb> xapantu: Yes, though at a weekend, it's harder to get in contact with Canonical employees (obviously), so you might need to re-ask on Monday
[16:33] <xapantu> ok, I didn't think to that ^^
[16:34] <xapantu> So, a user spammed our japanese translation, and we would like to remove it, is there a nice way ? or we must remove it by hands ?
[16:39] <maxb> xapantu: I suggest you log a question at https://answers.launchpad.net/rosetta/+addquestion
[16:39] <xapantu> ok, I am going to do that :)
[16:39] <xapantu> Thanks :)
[22:33] <jderose> I'm trying a source package recipe and got this failure: "dpkg-source: error: can't build with source format '3.0 (quilt)': no orig.tar file found" under maverick, but build worked on lucid.
[22:33] <jderose> build log is here: http://launchpadlibrarian.net/59379869/buildlog.txt.gz
[22:44] <charlie-tca> jderose: support for Natty only here
[22:45] <jderose> charlie-tca: not sure i follow. do you mean a should be asking on another channel?
[22:45] <charlie-tca> If you are asking about lucid/maverick, then yes
[22:46] <charlie-tca> Perhaps #ubuntu , which is support for all versions except Natty
[22:46] <charlie-tca> Never mind. My mistake
[22:46] <jderose> charlie-tca: this isn't an Ubuntu issue, it's a PPA issue...
[22:46] <charlie-tca> Yeah, I see that now. I am on the wong channel
[22:46] <jderose> :)
[22:47] <charlie-tca> jderose: sorry, didn't mean to upset things
[22:47] <jderose> np
[23:24] <wgrant> jderose: Source package recipes don't support orig.tar.gz files at the moment. dpkg in Lucid and earlier falls back to a native package, but Maverick's doesn't.
[23:25] <wgrant> jderose: You'll need to change the format to 3.0 (native) and manually apply any patches you need.
[23:25] <jderose> wgrant: okay, thanks!
[23:26] <jderose> wgrant: one more question. so will recipes automatically run ./autogen.sh?
[23:27] <wgrant> jderose: Recipes do whatever debian/rules says.
[23:29] <jderose> wgrant: so a recipe would need different rules for building from upstream branch vs a release tarball, correct? (FYI, I'm a little autotools dumb)
[23:29] <wgrant> jderose: Probably, yes.
[23:29] <wgrant> Yay autotools.
[23:29] <jderose> or something like that :)


[02:09] <ibeardslee> olly_: no, it's a Philips, the Viewsonics are our current 'standard'.
[02:10] <ibeardslee> I have a philips at home that has a problem with the OCD
[02:10] <olly_> it keeps washing its hands?
[02:25] <hads> I've had a pretty good run out of Viewsonics
[02:27] <olly_> i had one before which lasted well
[02:27] <olly_> which was part of the reason for picking the model I did
[02:28] <olly_> i returned it and they reflashed the ... flash, and it's been fine since
[06:17] <kcj> Morning.


[09:54] <xnox> mpt: we have a keyboard bug for every step of the installer
[09:54] <xnox> https://wiki.ubuntu.com/Ubiquity/KeyboardBug#preview
[09:54] <xnox> https://wiki.ubuntu.com/Ubiquity/KeyboardBug
[10:35] <mpt> joy
[10:39] <xnox> Yeah, it's like christmas came early =)
[10:40] <xnox> The best bit is when people need/want to switch to English after booting in e.g. russian locale at every single step.
[11:06] <mpt> xnox, do you happen to have a screenshot of the 12.10 installer with the wi-fi spinner at the bottom left?
[11:08] <xnox> mpt: no, as I failed to type my 63 character long WiFi correctly to trigger the spinner.
[11:08] <xnox> s/WiFi/WiFi password/
[11:08]  * xnox can fake a screenshot for you though.
[11:42] <xnox> mpt: https://picasaweb.google.com/105922848292507689403/February182013#5846255791327235314
[11:42] <xnox> nexus7 saves the world again
[11:45] <ogra_> xnox, erm, how did you get that working ?
[11:45] <xnox> ogra_: which part? =)
[11:46] <ogra_> the whole of it
[11:46] <ogra_> how did you work around my bug ?
[11:46] <xnox> ogra_: so my old nexus was already pre-flashed, I $ sudo apt-get install oem-config-gtk etc... & sudo touch /var/oem-config/run & reboot
[11:47] <xnox> it just works.
[11:47] <ogra_> hmpf
[11:47] <ogra_> why doesnt it on fresh images then
[11:47] <xnox> i may not be fully up to date then.
[11:47] <xnox> do you want me to dist-upgrade and see if it breaks? =)
[11:47] <ogra_> yes please :)
[11:50]  * ogra_ is a little desparate to find *any* pointer to whats wrong
[11:54] <mpt> xnox, excellent, thank you
[11:54] <mpt> discussing this layout pattern right now
[12:06] <xnox> ogra_: dist-upgrade, reboot, had plymouth splash and now just black screen with nothin on it.
[12:06] <xnox> here is the dpkg view of my dist-upgrade: http://paste.ubuntu.com/1676722/
[12:06] <ogra_> YAY !!!!
[12:06] <xnox> grep for upgrade
[12:07] <xnox> and install
[12:07] <ogra_> sigh, 164 packages
[12:07]  * xnox was spending time fixing background which now works =) and not dist-upgrading
[12:09] <xnox> ogra_: how can I boot it now?
[12:09] <ogra_> remove the lock
[12:09] <ogra_> that sometimes works
[12:10] <ogra_> i havent found a reliable way yet, it seems to be very random
[12:11] <ogra_> do you have an ssh server installed ? probably the logs on an installed system are more verbose
[12:11] <xnox> yeap ssh'ed in.
[12:11] <xnox> Fatal server error: Server is already active for display 0
[12:11] <ogra_> yeah
[12:12] <ogra_> complaining about the lock, as well, right ?
[12:12] <ogra_> thats all i can get ... i wish there was an ~.xession-errors for u-dm
[12:13] <xnox> right in syslog I see the same stuff as currently seen in the daily desktop images with "Failed to activate service 'org.freedesktop.ConsoleKit' timed out
[12:14] <xnox> and consolekit failing to acquite the bus
[12:15]  * xnox wonders if the first X is started ubiquity-dm, then ubiquity-dm fails, and respawns a new X without cleaning the lock.
[12:15] <xnox> (killing the first instance)
[12:16] <ogra_> yes, thats one of my three theories
[12:16] <ogra_> the most compelling one actually ... else it would be lightdm or upstart which is unlikely
[12:16] <ogra_> thats why i would like an .xsession-errors file
[12:17] <ogra_> since i guess one of the fired up apps u-dm uses is at fault here
[12:17] <ogra_> and oem-config-debug sadly only kicks in after oem-config is up
[12:18] <xnox> it's weird because there is console-kit-daemon running with pid 965, yet the one that failed to activate has pid 1263
[12:18] <xnox> so it failed to talk to it.
[12:18] <ogra_> hmm
[12:19] <ogra_> i see qdbus in your upgrade list
[12:20] <ogra_> nothing about consolekit or polkit
[12:21] <ogra_> theoretically there is an Xsession.d script that firse up the appropriate ck session for you
[12:21] <ogra_> (unless you use lightdm)
[12:22] <ogra_> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680264
[12:22] <ubot2> Debian bug 680264 in nodm "nodm: ConsoleKit fails to recognize the current session as local" [Normal,Open]
[12:22] <ogra_> i wondefr if thats related
[12:23] <ogra_> it has a patch to try out
[12:23] <xnox> there were some pam changes
[12:24] <ogra_> also, slangasek seems to have moved soem pam stuff around in lightdm from "auth" to "session" that tries to read /etc/default/localer ... which doesnt exist in our installer env
[12:24] <xnox> also ubiquity launches X directly does that read / launch xsessions?
[12:24] <ogra_> though you should have it on an installed system indeed
[12:24] <ogra_> i think it does, not sure
[12:24] <ogra_> hmm, it doesnt launch xinit but plain X
[12:25] <ogra_> so Xsession might ot be processed
[12:26] <ogra_> once my nx7 is charged enough i'll try your method ... it didnt strike me to test on an installled system
[12:26] <mpt> ehhhh
[12:27] <xnox> mpt: did you just read the backlog? =) or is that the comment on the font/spacing alignment of the connecting label?
[12:28] <mpt> xnox, I'm in a meeting where we're talking about bug 732634 for the umpteenth time :-]
[12:28] <mpt> as if it was ever a deliberate design choice
[12:28] <ogra_> or just a general statement to the evilness of the world ?
[12:28] <ubot2> Launchpad bug 732634 in ubiquity (Ubuntu) "Progress bar restarts from zero after copying files" [Medium,Confirmed] https://launchpad.net/bugs/732634
[12:29] <xnox> mpt: refresh the bug report, does that help?
[12:31] <mpt> \o/
[12:32] <cjwatson> That bug is darkly amusing since it has comments like "The proper solution is apparently to teach debconf that its progress value is sometimes only for a subtask of a larger task" several years after such support was introduced
[12:32] <cjwatson> It's just broken, it's not fundamentally missing
[12:33] <cjwatson> xnox: Do you know about and understand the PROGRESS REGION extension?
[12:33] <xnox> cjwatson: know about - yes, understand - sort of.
[12:34] <cjwatson> Your bug reference is incorrect - nested progress bar support was introduced long before that
[12:34] <cjwatson> Before espresso was renamed to ubiquity
[12:34] <cjwatson> r799, originally
[12:35] <ogra_> geez, installing oem-config-gtk tries to pull in nearly all of kde here
[12:35] <ogra_> even with recommends disabled
[12:35] <xnox> =)))) well, ok that it even early, for me at that time it was good enought that _it exists today_
[12:35] <xnox> ogra_: install oem-config-gtk ubiquity-frontend-gtk
[12:35] <xnox> and oem-config and ubiquity then it's a short list.
[12:35] <ogra_> yep, just did that :)
[12:36] <xnox> it is trying to pull in the kde frontend for some reason, instead of the gtk one.
[12:36] <cjwatson> xnox: The idea is that you say PROGRESS REGION <start> <end>, then PROGRESS START <start> <end> <title> ... (more progress commands) ... PROGRESS STOP, and the progress commands within the start/stop pair are scaled to the region you provided
[12:37] <cjwatson> IIRC
[12:38] <cjwatson> So have a look at the protocol stream and see what's doing it wrong
[12:39] <xnox> ok. thanks. debug mode logs again =))))
[12:39] <cjwatson> That's what they're for :)
[12:40] <xnox> cjwatson: i think we are missing some progress regions then, as if one does progress start 0 without starting a new progress region you see the jump to zero effect.
[12:40] <ogra_> 1405 ?        S      0:00 /usr/bin/python3 /usr/bin/ubiquity-dm vt7 :0 oem /usr/sbin/oem-config-wrapper --only
[12:40] <ogra_>  1431 ?        S      0:00 sleep 1
[12:40] <ogra_>  1432 ?        Z      0:00 [Xorg] <defunct>
[12:40] <cjwatson> Yep, very likely
[12:40] <ogra_> aha
[12:40] <ogra_> i wonder wheer that zombie comes from
[12:40] <cjwatson> Should be a pretty trivial fix once identified
[12:41] <xnox> ogra_: in ubiquity-dm we have a loop of trying to start X server and if it fails so many times, we try fail-safe config.
[12:41] <ogra_> yeah, i had that at some point during my tests
[12:41] <ogra_> i wish there would be any indicator in any log though ...
[12:42] <xnox> ogra_: it's python - so just type in more logging =)
[12:42]  * ogra_ digs into the dm and scatters soem prints over it
[12:50] <xnox> ogra_: anything in /var/crash/ ?
[12:50] <ogra_> wait, just rebooting
[12:54] <ogra_> http://paste.ubuntu.com/1676848/
[12:54] <ogra_> definitely CK
[12:55] <xnox> ogra_: can you grep if there are any console-kit daemons running any way?
[12:55] <xnox> in ps.
[12:55] <ogra_> i wonder if we should just switch to process Xsession
[12:55] <xnox> cjwatson: why ubiquity-dm has never been a proper Xsession?
[12:55] <ogra_> ogra@nexus7:~$ ps ax|grep console
[12:55] <ogra_>   956 ?        Sl     0:00 /usr/sbin/console-kit-daemon --no-daemon
[12:56] <xnox> so it's failing to talk to it.
[12:56]  * xnox ponders to try that debian patch or see/revert recent slangaseks pam changes.
[12:56] <ogra_> well, i think it is started in the wrong order
[12:57] <xnox> ogra_: the first thing ubiquity-dm does is ask for a console-kit session, which should dbus activate it.
[12:57] <ogra_> yes, but it doesnt take care for starting it
[12:57] <ogra_> which usually Xsession woudl do
[12:57] <xnox> so who started the one that is running?!
[12:57] <cjwatson> xnox: Too much effort to excise all the bits we wanted to avoid
[12:58] <cjwatson> There were memory constraints and the like - I explicitly didn't want to run a full session
[12:58] <cjwatson> Or a full DM
[12:58] <xnox> ok.
[12:58] <cjwatson> I mean I guess you could split ubiquity-dm into a DM part and a session part.  It just never seemed worth the effort really
[12:59] <ogra_> well, with the recent diet lightdm might serve out purpose
[12:59] <cjwatson> ubiquity-dm can't rely on lightdm
[12:59] <ogra_> hmm, indeed flavours ...
[12:59] <cjwatson> 'cos it needs to be workable in lots of different flavours, yeah
[13:00] <ogra_> oh
[13:00] <ogra_> erm
[13:01] <ogra_> seems teher is no session dbus at all running here
[13:01] <ogra_> i would assume thats needed for ck to talk to the system bus through it
[13:03] <xnox> but we are starting on lightdm, which in turn starts on dbus.
[13:04] <ogra_> system
[13:04] <ogra_> not session
[13:04] <ogra_> the session bus is started by gnome-session or alternatively by Xsession
[13:04] <xnox> upstart jobs that is.
[13:04] <xnox> ah, wait.
[13:04] <ogra_> it runs as the session user usually
[13:04] <ogra_> so after auth
[13:05]  * xnox thought ck runs on system bus, not session.
[13:05]  * ogra_ tries to mimic the Xsession behavior in the oem-config.conf exec line
[13:05] <xnox> cause ck is opened before ubiquity-dm starts a session bus
[13:06] <ogra_> the point is that to talk to system services the session bus is used i think
[13:06] <ogra_> with ck inbetween for policy checks
[13:08]  * ogra_ reboots with the hack in place
[13:11] <ogra_> bah, patched the wrong codepath
[13:18] <ogra_> hmm, so i have it starting with a session bus but it doesnt change anything :(
[13:19] <ogra_> oh, lovely ... at least i can count how often it respawned now
[13:22]  * ogra_ moves the code around a bit
[13:34] <ogra_> GOT IT !!!
[13:34] <ogra_> bah, only partially
[13:35] <ogra_> changing the exec line in oem-config.conf to:
[13:35] <ogra_> exec /usr/bin/ck-launch-session oem-config-firstboot $debug $automatic
[13:35] <ogra_> gets me running X and a popup that the installer encountered an error on the desktop
[13:36] <ogra_> aha
[13:36] <ogra_> dbus.exceptions.DBusException: org.freedesktop.NetworkManager.Settings.NotPrivileged: Insufficient privileges.
[13:36] <ogra_> thats funny ...
[13:36] <ogra_> since i have NM in the panel
[13:37]  * xnox reverted lightdm, consolekit and it boots now
[13:37]  * xnox ponders if consolekit's memory leak wasn't actually a memory leak.
[13:39] <ogra_> oh, i created an oem user for testing ... i guess i should swithc that back to root as we use it on the image
[13:42] <ogra_> yipiie
[13:42] <xnox> you fixed it? =)
[13:42] <ogra_> ogra@nexus7:~$ grep exec /etc/init/oem-config.conf
[13:42] <ogra_>     exec /usr/bin/dbus-launch --exit-with-session /usr/bin/ck-launch-session oem-config-firstboot $debug $automatic
[13:43] <ogra_> with that it works for me
[13:43] <xnox> it also needs to go into ubiquity normal as it also fails with ~ similar symtoms.
[13:43] <xnox> and this also means we can drop dbus-launch code from ubiquity-dm
[13:43] <ogra_> well, i still think it would be better to just process Xsession.s
[13:43] <ogra_> Xsession.d
[13:46] <xnox> my boot was a fluke as it is back to booting black.
[13:48] <ogra_> hmm
[13:48] <ogra_> none of the indicators work ... i can select reboot but never get the popup for it
[13:48] <ogra_> so i would guess its not 100% yet
[13:52] <ogra_> btw, the panel doesnt expand in landscape
[13:53] <xnox> ogra_: so poking indicator-session-service it's sitting on the dbus that lightdm has, instead of ours.
[13:53] <ogra_> ah
[13:53] <ogra_> thats a mess
[13:54]  * ogra_ is so happe we found the cause and at least a workaround ... i wated my whle weekend on this (including my birthday on sat.)
[13:54] <ogra_> *happy
[13:55] <ogra_> *wasted
[14:23] <xnox> ogra_: looking at all the Xsession.d scripts some of them are definately what we do not want.
[14:24] <ogra_> hmm, yeah


[06:18] <xavpaice> is there a current documentation repo for making fresh shiny new charms using charmcraft?  Other than the obvious readme in the repo (which is really good), there was some stuff on discourse which is somewhat out of date now given that we're not doing submodules and so on
[08:18] <Chipaca> bthomas: ｇｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｏｄ  ｍｏｒｎｉｎｇ！
[08:20] <bthomas> Morning Chipaca
[08:21] <bthomas> Chipaca: I may have a couple (probably more) questions today. I will try and type them here. Do you prefer I ask you in the morning or post lunch ?
[08:21] <bthomas> This is for the hook documentation.
[08:21] <Chipaca> bthomas: why wait :)
[08:21] <bthomas> Awesome thank you.
[08:21] <Chipaca> ask them now, and i'll answer when and if i'm able :)
[08:21] <Chipaca> irc is async \o/
[08:21] <Chipaca> (less async than email, but hey)
[08:22] <bthomas> Ok. I like to dig a bit before asking. So it will be intermittent through the day.
[08:22] <Chipaca> 👍
[08:23] <Chipaca> please don't wait to ask 🙂 better wait for me to reply than that
[09:07] <bthomas> Chipaca: I will number questions through the day. This is Q1) What is the operator interface for a leader to set some key/value pair ? (i.e. what is the equivalent of "leader-set" from the reactive world). Same question for "leader-get"
[09:09] <bthomas> I am reading this reactive docs for leadership api : https://discourse.juju.is/t/implementing-leadership/1124
[09:37] <bthomas> Chipaca: Q2): I am going through the Hook Context and Tools docs at https://discourse.juju.is/t/the-hook-environment-hook-tools-and-how-hooks-are-run/1047 . How much of this is still valid in the operator framework ? For instance are all the environment variables (including relation variables) and hook tools still available to Operator Charm hooks ?
[10:15] <Chipaca> bthomas: leader-get and -set are not implemented by operator. I think (but would like jam to confirm) that it's because we haven't yet found a use case that wouldn't be better served by setting data on the peer relation.
[10:16] <Chipaca> (that's for Q1)
[10:17] <bthomas> Got it. Thanks.
[10:17] <Chipaca> bthomas: re Q2, the hook environment and tools are what operator builds on to present the interface that it does to charmers. There shouldn't be a need to use things from the lower level, but they're there if needed (and if we see it being needed, we would typically model it inside operator somehow)
[10:18] <Chipaca> bthomas: munging Q1 and Q2, the pgsql interface uses leader-set and -get to poke at leader data directly (we think it would be better done on the peer relation, and that's part of an ongoing conversation)
[10:24] <bthomas> Chipaca: In view of your answer to Q2 it sounds prudent to hide these lower level interfaces and not expose them in Charmhub documentation, thereby discouraging their use. I shall adopt this approach for now and followup with jam and jldev, regarding their viewpoint on the matter.
[10:24] <Chipaca> sgtm
[11:12] <facubatista> ¡Muy buenos días a todos!
[11:16] <facubatista> xavpaice, did you check this tutorial? https://discourse.juju.is/t/how-to-build-a-charm-using-modern-tools/3246
[12:26] <mup> PR operator#401 closed: fix docstring on Harness.add_relation_unit WRT events <Created by chipaca> <Merged by chipaca> <https://github.com/canonical/operator/pull/401>
[12:27] <bthomas> Chipaca: Your response to Q1 implies that only Juju decides which unit is leader. A Charm can not decide this. Correct me if I am wrong here.
[12:28] <Chipaca> ah, the problem with "do X if Y" is that ¬Y means I can do *anything* :-D
[12:30] <bthomas> Indeed. But Charm can not set leadership since it has no means to trigger and leader_elected event or leader_settings_chagned event.
[12:33] <Chipaca> bthomas: electing leadership is beyond the abilities of the proles^Wcharms
[12:34] <bthomas> Ok thanks. I get it quorum sensing, paxos and the like, is stuff a charm would rather leave to Juju :-).
[12:38] <bthomas> I asked the question because the discourse hook doc linked above suggests a Charm may decide if a unit is the leader, in the leader-elected doc lines (quoted) "If the election process is done internally to the application, other code should be used to signal the leader to Juju."
[12:39] <Chipaca> bthomas: that's the application deciding it's the leader, not the charm
[12:44] <bthomas> Chipaca: In that case, the differences between an application deciding its leader and the units deciding their leader is not obvious. It is not clear if and why a cham needs to be aware of or respond to an "applications electing leader".
[12:44] <Chipaca> bthomas: I don't follow
[12:48] <bthomas> Chipaca: I was just explaining why I asked the question if we can assume that only Juju decides the leader unit. I pointed out that the current charm hook docs suggest that "application" may make the leadership decision "internally" . I interpreted your response as meaning leadership among units is different from leadership within the application. I did not understand this response and was trying to probe it further.
[12:49] <Chipaca> bthomas: in the normal case, juju decies who the leader is, and sends an event to the charm to that effect, and the charm reconfigures the application (or whatever is needed to implement "you be the leader now")
[12:49] <bthomas> Got it . Thanks.
[12:49] <Chipaca> bthomas: in some cases instead the application itself decides who the new leader is, and needs to arrange some way to tell juju
[12:49] <Chipaca> bthomas: this way does not involve the charm
[12:50] <bthomas> Chipaca: Ah I see now. Do we need to document this, if it does not involve the Charm ?
[12:51] <Chipaca> no, i don't think we do
[12:51] <bthomas> great thank you.
[13:20] <Chipaca> bthomas: could i get a review of https://github.com/canonical/charmcraft/pull/150 ?
[13:20] <mup> PR charmcraft#150: when failing to create hard link attempt to use shutil.copy2 <Created by matuskosut> <https://github.com/canonical/charmcraft/pull/150>
[13:20] <bthomas> Chipaca: will do
[13:33] <bthomas> Chipaca: Q3) Since a Charm is expected to use relation data rather than setting leader data, only one use case remains for the "leader_settings_changed" event. This is the use case of notifying the current leader, that it will no longer be the leader. Is this correct ? However soon after this event, one would also expect a "leader_elected" event to also invariably fire, when the new leader is elected. Can I hence say, that the
[13:33] <bthomas> of the leader_settings_chagned event is solely, for a leader to do, what needs to be done, in order to relinquish leadership.
[13:35]  * bthomas goes to make some coffee
[13:54] <Chipaca> huh, first time i've seen "* Chipaca has quit (Ping timeout: 240 seconds)" myself
[14:06]  * Chipaca brb
[16:56] <Chipaca> i'm off for now (run + dinner + etc), will bb(much)l
[20:06] <facubatista> Chipaca, jam, a pattern I've seen a lot is this (quite useful) sequence:
[20:06] <facubatista> msg = "whatever we want to communicate"
[20:06] <facubatista> logger.info(msg)
[20:06] <facubatista> self.unit.status = MaintenanceStatus(msg)
[20:06] <facubatista> I wonder if we could provide a shortcut for that
[20:07] <facubatista> maybe something like `self.unit.status = MaintenanceStatus(msg, log=True)` (or even log by default)
[20:20] <jam> facubatista, I know 'juju show-status-log' will tell you about the various value the status went through, but it doesn't appear in the default log messages
[20:22] <jam> Chipaca or facubatista  in case bthomas comes back, it feels like he has it backwards. leader_settings_changed notifies *non* leaders that the settings have changed, leader_elected is telling the unit that they are now the leader.
[20:27] <facubatista> jam, thanks
[21:35] <Chipaca> jam: ah, thanks. I'll let him know in the morn.