[04:54] <Kilos> greetings africa
[15:44] <Kilos> hi poppingtonic  welcome
[15:45] <poppingtonic> thanks :)
[15:45] <Kilos> see stickyboy  is also here
[15:45] <poppingtonic> awesome hi stickyboy
[16:18] <Kilos> hehe he takes forever to answer


[15:40] <zetheroo> I am trying to change a user password as user root with the 'passwd user' command but am running into 'passwd: Authentication token manipulation error' without even being asked to supply a password
[20:48] <wwalker> preseed question.  I've searched and searched but only find stuff about how TO get it to partition.  I want to reinstall the OS ( on / fs ) WITHOUT rewriting the partition table!!! There's 100 TB of data I don't want to restore from backup...  Anyone done this?


[05:04] <cpaelzer> ddstreet: #1466926 is dead for now after the insights on verification, please go for yours WITHOUT the changes my upload had
[06:20] <lordievader> Good morning
[08:27] <cpaelzer> rbasak: you are on SRU today IIRC - would you mind considering accepting the improved open-vm-tools that is in x-unapproved for 1741390?
[08:49] <rbasak> cpaelzer: ack
[09:05] <blitz-_> Anyone got experience installion 16.04 on a Dell T130 with a Perc H330 using software raid? Refuses to find boot drive and not sure if its a install problem or H330 problem.
[09:21] <rbasak> cpaelzer: was this an SRU regression from the previous backport? We need a Test Case and the issue resolved for Bionic first I think, unless there's some reason this is urgent?
[09:27] <cpaelzer> rbasak: it is resolved in bionic
[09:27] <cpaelzer> the bug has an update
[09:28] <cpaelzer> well wait there are two things in flight
[09:28] <cpaelzer> I need to ensure not to mix them
[09:29] <cpaelzer> 1741390 is a regression when backporting the new version
[09:29] <cpaelzer> it wasn't seen in Bionic yet
[09:29] <cpaelzer> (I already asked to check there, as it needs a special setup)
[09:29] <cpaelzer> but so far the assumption is that with newer systemd it is fine
[09:29] <cpaelzer> if they report it is not, then I can still fix Bionic
[09:30] <cpaelzer> so for now we have
[09:30] <cpaelzer> Bionic likely unaffected (not known better), Xenial fixup in x-unapproved
[09:30] <cpaelzer> the other one that is resolved in bionic was a libvirt issue, that I work on atm
[09:30] <cpaelzer> sorry
[09:31] <cpaelzer> there also is a refresh to the Xenial SRU incoming - so they are similar cases
[09:32] <cpaelzer> otoh the vmware guy "expects" it to affect Bionic
[09:32] <cpaelzer> as I said that part just isn't clear
[09:32] <cpaelzer> I can push a Bionic upload with the same fix (one line removal) to Bionic first if you'd prefer that
[09:34] <cpaelzer> rbasak: the other one is 1758428 - do you want me to fix this in Bionic and then get a ping again for the refreshed SRU?
[09:35] <cpaelzer> as I said the biggest inhibitor here is the uncertainty that I can't test it on my own (uses some special vmware api call to trigger)
[09:35] <cpaelzer> it might even be easy but I don't know how (yet)
[09:35]  * cpaelzer stops flooding the chan without rbasak rpelying :-)
[09:36] <rbasak> Sorry I just realised there's more to this than I thought and I've been reading up
[09:37] <cpaelzer> hehe
[09:37] <rbasak> What is the Xenial backport based upon?
[09:37] <cpaelzer> the version in Bionic
[09:37] <cpaelzer> in recent history we hit (and fixed) several things only affecting it in systemd-level in xenial (but good in bionic)
[09:37] <rbasak> Would the version then not be 2:10.2.0-3ubuntu2~16.04.1 or something like that?
[09:38] <rbasak> And the changelog doesn't have the Bionic entry
[09:38] <cpaelzer> rbasak: it is based on the version in bionic a few weeks ago, and ther ubuntu1 and ubuntu2 in Bionic are reverts of each other
[09:39] <rbasak> I see, OK.
[09:39] <cpaelzer> so 10.2.0-3ubuntu2 essentially = 10.2.0-3
[09:39] <cpaelzer> therefore there was no need to rebase the backport
[09:40] <cpaelzer> rbasak: you are not wrong to ask for a Bionic fix of 1758428, it is just that I know for sure it is in Xenial (therefore the upload) and not yet sure it is in Bionic (so no upload yet)
[09:40] <rbasak> It's all starting to make sense not :)
[09:40] <rbasak> now :)
[09:40] <cpaelzer> lol+
[09:43] <rbasak> cpaelzer: 2:10.2.0-3ubuntu<IP_ADDRESS> has not yet been published, right?
[09:44] <cpaelzer> rbasak: correct
[09:45] <cpaelzer> rbasak: it was held by finding the new issue on the verifications step
[09:45] <cpaelzer> so I ask to accept the new one into x-proposed "over" the former
[09:45] <cpaelzer> we might still even hold back the release of it until the Bionic case is calrified
[09:45] <cpaelzer> but having in x-proposed allows all the parties to retest
[09:46] <rbasak> But 2:10.2.0-3ubuntu<IP_ADDRESS> hasn't even been in xenial-proposed, AFAICT?
[09:48] <cpaelzer> it was put to x-unapproved on 2018-03-22
[09:48] <cpaelzer> and you are right, it wasn't in proposed yet (people are testing the ppa while waiting for it)
[09:49] <rbasak> So I'd have squashed 2:10.2.0-3ubuntu<IP_ADDRESS> into 2:10.2.0-3ubuntu<IP_ADDRESS>
[09:50] <rbasak> But I don't think it's necessarily worth changing that now
[09:50] <rbasak> That did confuse me a bit though.
[09:50] <cpaelzer> hmm
[09:51] <rbasak> Technically 2:10.2.0-3ubuntu<IP_ADDRESS> is higher than 2:10.2.0-3, whereas for a backport you generally want it to be lower.
[09:51] <cpaelzer> on the second upload 2:10.2.0-3ubuntu<IP_ADDRESS> I ensured to have a better -v on buildpackage
[09:51] <cpaelzer> so it includes all the history since Xenial anyway
[09:51] <rbasak> But in this case, Artful has already moved on
[09:51] <cpaelzer> one more or less doesn't change the long list of entries
[09:51] <rbasak> So in practice that also may not matter
[09:51] <rbasak> Your -v is fine
[09:52] <rbasak> But that cannot show me everything, so I was inferring the rest based on an assumption that you'd only burn the minimum version strings for an Ubuntu upload.
[09:53] <rbasak> s/Artful/Bionic/ above.
[10:02] <cpaelzer> rbasak: so next steps?
[10:03] <cpaelzer> rbasak: I thought we could accept the Xenial sru into proposed and wait on the confirm that Bionic is affected before making useless changes there
[10:03] <cpaelzer> after you read into the case, do you agree or suggest differently?
[10:04] <rbasak> cpaelzer: is there a reason this can't wait until the package is settled in Bionic? Also, what about Artful?
[10:04] <cpaelzer> rbasak: several parties depend on the backport, but we can postpone it for now and reconsider if the bionic case needs too long
[10:05] <cpaelzer> artful is not considered at all, the decision was to only provide that for last LTS
[10:05] <cpaelzer> after bionic is out we will only do the same for Bionic until 20.04 is there
[10:11] <cpaelzer> thanks rbasak, despite causing more work you are right :-)
[10:11] <rbasak> cpaelzer: I'll write up a review in the bug.
[10:12] <cpaelzer> I updated the respective bugs, let the peers on them have some time to confirm the state in Bionic and then kick off a new round
[10:13] <cpaelzer> rbasak: when writing your review, please consider my latest post and feel free to cancel at least the first open-vm-tools in x-unapproved
[10:13] <cpaelzer> keeping the other one there until resolved
[10:16] <cpaelzer> rbasak: I also updated the planning (to no more ignore interim releases)
[10:19] <cpaelzer> dpb1: ^^ discussion affecting planned open-vm-tools SRUs
[10:20] <cpaelzer> dpb1: I updated the plan you drafted already
[10:20] <cpaelzer> TL;DR 4 instead of 2 such SRUs per year needed
[10:20] <cpaelzer> I have some hope that post Bionic those will be less painful backports than now
[10:29] <rbasak> cpaelzer: leaving it in the queue will mean every other SRU team member will spend time looking before discovering it's blocked and moving on.
[10:29] <rbasak> I'd prefer to reject for this reason. You can keep your upload around and re-upload without changes easily enough I think.
[10:30] <cpaelzer> well then, cancelling from unapproved does not imply version bumps, so ok
[13:36] <Gargravarr> hey all, on Launchpad trying to log into the bug tracker, is there any reason my Ubuntu One account isn't being accepted and i'm being told to 'Go away' for being a 'Bad bot'?
[13:55] <dpb1> cpaelzer: so, we need it in artful too?
[13:59] <cpaelzer> dpb1: yes
[13:59] <dpb1> cpaelzer: ok
[13:59] <cpaelzer> I can do that, but as this was a little box of backport-surprises so far I don't expect it to be different there
[13:59] <cpaelzer> dpb1: if you want to talk about the plan I can HO if you want
[14:00] <cpaelzer> I hope the updates to the sheet are good and understandable
[14:00] <dpb1> cpaelzer: it's probably enough, but I haven't checked
[14:01] <tomreyn> i believe Gargravarr's issue was resolved in #ubuntu
[14:06] <Gargravarr> okay, so, root reason for me wanting to log into the bug tracker - i'm hitting the same sssd problem again, a lot harder this time
[14:09] <Gargravarr> are sssd and libpam-ldapd the only two options for doing LDAP user auth with Ubuntu?
[14:09] <Gargravarr> the latter works as intended but doesn't have native caching so won't work for laptops taken off-site, and my attempts to set up external caching failed
[16:26] <Gargravarr> rbasak: so i'm running into a real mess with this SSSD problem, but my suspicion is that the bug you linked me to is not the whole story
[16:27] <Gargravarr> i'm starting to think this is related to the intel-microcode
[16:27] <Gargravarr> this is the last package installed on my laptop before it broke (which occurred on the next boot)
[16:28] <Gargravarr> and i'm running sssd on the current 4.13.0-38 kernel on a desktop without it crashing
[16:28] <Gargravarr> should i post my findings onto the same bug ticket or should i look at opening a new one?
[16:39] <waveform> Gargravarr, could you post a link to the ticket (sorry, it's not in my scrollback)
[16:40] <Gargravarr> it's fine
[16:40] <Gargravarr> https://bugs.launchpad.net/cloud-images/+bug/1746806
[16:40] <waveform> thanks
[16:40] <Gargravarr> i'm just trying uninstalling the intel-microcode package
[16:40] <Gargravarr> fingers.cross()
[16:41] <waveform> just a bit of background: I use LDAP and sssd here too, and recently had a machine (my main desktop) hard-lock on boot after a kernel upgrade. Booting with prior kernel worked fine; after a bit of investigation, removing intel-microcode resolved things for me
[16:42] <Gargravarr> waveform: i'm finding similar. a colleague just had the issue and i rolled him back to 4.13.0-26 from 4.13.0-38 and it booted
[16:42] <Gargravarr> nope. tried uninstalling -> reboot -> log in as root from a TTY -> run sssd -id 9 and netcat it to a different machine -> switch to lightdm -> login as LDAP user -> login succeeds, but machine freezes
[16:42] <waveform> I *think* in my case (I'd have to check my notes somewhere), -36 worked for me and -37 was the one that locked up
[16:43] <Gargravarr> it seems to be a random alignment of intel-microcode, CPU and kernel
[16:43] <Gargravarr> we have Skylake desktops and Kaby Lake laptops. so far the desktops are unaffected
[16:44] <Gargravarr> but someone in the bug ticket mentions having a Skylake desktop
[16:44] <waveform> mine's pretty old - it's an i7-2600K
[16:44] <waveform> (sandy-bridge)
[16:44] <Gargravarr> i still have a 2520m in use in my ThinkPad
[16:45] <Gargravarr> now, if i recall correctly, the whole point of microcode is that it gets loaded into the CPU
[16:46] <Gargravarr> so there's a good chance that uninstalling it won't fix the problem
[16:47] <Gargravarr> so the Kaby Lake laptop has frozen, and the CPU fan is pumping out a fair amount of heat, so i assume it's spinning the cores again
[16:48] <waveform> hmmm, it certainly did in my case - I removed both intel-microcode and the "no longer required" package that went with it - I'll just check what that was...
[16:48] <waveform> ah, iucode-tool
[16:48] <Gargravarr> ta, i'll check they're both gone
[16:49] <Gargravarr> never installed on this laptop, it seems
[16:49] <Gargravarr> ah wait, typo'd
[16:49] <Gargravarr> waveform: did you reboot after uninstalling?
[16:49] <waveform> yes, I did
[16:50] <waveform> I was in the older kernel to do the uninstall, then rebooted into the newer one
[16:50] <Gargravarr> i have to use the 4.4-series kernel on this laptop due to intel wifi driver hell
[16:50] <waveform> found my notes: that was the one change I made between booting and finding -37 failed, and -37 worked. Incidentally, would be interesting to know if -36=works, -37=fails for you as well - that might at least confirm we're looking at the same thing (and narrow down the changesets that need investigating)
[16:51] <waveform> incidentally, I did also encounter this with 4.4-series and found that -116 to -117 were the culprits there
[16:52] <Gargravarr> -116 was fine until last week when i updated the microcode
[16:52] <Gargravarr> -117 is no improvement
[16:53] <Gargravarr> okay, sssd starting up (on -116)
[16:53] <Gargravarr> if this breaks, i'll roll back to -112 or something
[16:54] <Gargravarr> wow, premature celebration at its finest. that got far further than normal, Firefox loaded
[16:54] <Gargravarr> THEN the machine froze
[16:54] <waveform> the 4.4 series I'm not so clear on as my jump to 4.13 was literally a re-install of ubuntu desktop on that machine (after being unable to fix it over the weekend, and needing it working in a hurry I just did "oh sod it, I'll reinstall" thing only to find that it still froze after re-installing all the stuff I had installed before :)
[16:54] <Gargravarr> yeah. we generally use 4.13 here for HWE
[16:55] <Gargravarr> but i ran into error after error with the Intel drivers (my laptop has an Intel card, everyone else has Qualcomm)
[16:55] <Gargravarr> eventually i got it stable by downgrading the card and using the basic 4.4
[16:55] <waveform> it was only on 4.13 that I attempted to remove intel-microcode and found that fixed things - hence my 4.4 assumption is purely based on -117 being the first version that failed for me (I don't know whether intel-microcode removal would fix things there, and can't really rollback to test it!)
[16:56] <Gargravarr> fair enough
[16:56] <Gargravarr> -117 isn't even officially released afaik
[16:57] <sdeziel> Gargravarr: -119 was just released
[16:57] <Gargravarr> my mistake
[16:58] <waveform> ah, could well be 119! Handwriting ... bah
[16:58] <sdeziel> well, the official announcement hasn't arrive just yet, the kernel is still "hot" :)
[16:58] <Gargravarr> sdeziel: it shows in apt-cache so that counts as released
[16:59] <Gargravarr> right, trying -112 (and will add -119 as well (which might well be lucky, it's my grandmother's house number...))
[16:59] <dpb1> Gargravarr: btw, the microcode is a per-boot operation.  So, removing the update actually does revert things.
[16:59] <Gargravarr> dpb1: thanks for clarifying
[17:00] <Gargravarr> is a plain 'remove' operation enough or does it need to be purged?
[17:00] <sdeziel> and the BIOS could also load a fresh microcode if you updated it recently
[17:00] <waveform> hmm, I did purge (out of habit) but if a package is only half-installed I'd slightly surprised if it was still "doing things"
[17:00] <dpb1> yes, it's actually a very weird process.
[17:01] <Gargravarr> oh joy. i upgraded the BIOS out of desperation too
[17:01] <waveform> ah, I definitely didn't do that (it's too old for there to be any updates available!)
[17:01] <dpb1> Gargravarr: so, you are hitting this issue in a cloud, or just on your local workstation?
[17:01] <Gargravarr> dpb1: on multiple Dell laptops
[17:01] <dpb1> ok
[17:02] <Gargravarr> not hit it in a cloud context (yet)
[17:02] <dpb1> Gargravarr: I just asked since the bug title was about aws
[17:02] <dpb1> thx
[17:02] <Gargravarr> indeed
[17:03] <TJ-> Guys, "dijuremo" in #ubuntu-kernel has been reporting and testing this for several weeks, I suggest you join in that channel and pool observations and resources
[17:03] <Gargravarr> if it makes a difference, the machines i've hit it on so far have all been Kaby Lake
[17:03] <Gargravarr> TJ-: thanks for the hint
[17:03] <waveform> thanks, will do
[17:03] <dpb1> Gargravarr: did you test the fix in comment #43
[17:03] <TJ-> bug 1759920
[17:03] <Gargravarr> dpb1: i did. made no difference
[17:03] <TJ-> Seems like we have several problems with the Spectre_v2 microcode
[17:04] <dpb1> Gargravarr: and did you post on the LP issue?
[17:04] <Gargravarr> LP?
[17:04] <dpb1> Gargravarr: sorry, I don't actually know who you are. :)
[17:04] <Gargravarr> oh, Launchpad?
[17:04] <dpb1> launchpad
[17:04] <dpb1> yes
[17:04] <Gargravarr> no, i was drafting a reply when i started noticing the microcode bit
[17:04] <dpb1> OK
[17:04] <dpb1> at least writing there would be good so that Kamal knows
[17:05] <Gargravarr> yeah, i guess that would help
[17:05] <dpb1> thanks
[17:05] <waveform> I posted something on *an* LP issue, but it wasn't that one - I'll see if I can dig it up and link it in
[17:05] <dpb1> waveform: is it sssd in your case too?
[17:06] <waveform> well ... I am running sssd but I never tied the issue to that specifically. I just noted my machine freezing at the login screen, and eventually removing intel-microcode sorted things
[17:06] <dpb1> ok
[17:06] <Gargravarr> my machines have a tendancy to freeze *before* the login screen
[17:06] <Gargravarr> basically as soon as the sssd service loads at boot, so the splash screen freezes
[17:08] <Gargravarr> dpb1: i posted comment #48 on the AWS ticket
[17:08] <dpb1> thanks.
[17:08] <waveform> hmmm ... I did note I could boot in recovery mode (without network) on the new kernel and the freeze wouldn't occur. The lack of networking would obviously preclude sssd, so there's perhaps a link there. I could install intel-microcode, make a local user and disable sssd - see if I can re-create it that way if that's any use
[17:08] <Gargravarr> waveform: did you drop to a root shell there and then, or continue the boot?
[17:09] <Gargravarr> i could get a root shell from recovery, but as soon as i tried to resume boot, it re-occurred
[17:09] <waveform> I dropped to the root shell a few times to poke around, and did notice that certain actions like continuing the boot would always freeze the system but until I never narrowed down *precisely* what started before the crash (even tried videoing the screen - but it was too blurry to read :)
[17:10] <waveform> but until I *reinstalled ...
[17:11] <Gargravarr> i figured out that disabling the sssd service brought the system back up
[17:11] <Gargravarr> this started happening on an XPS that i was re-imaging
[17:11] <Gargravarr> the script errored out and the machine froze immediately after restarting sssd
[17:11] <dpb1> interesting.
[17:11] <Gargravarr> the logs clued me in that sssd was responsible
[17:11] <dpb1> Gargravarr: this is xenial + the HWE?
[17:12] <Gargravarr> that one was, yes
[17:12] <Gargravarr> we're 90% Xenial/HWE with a few exceptions
[17:13] <Gargravarr> the one that broke today was HWE, 4.13.0-38
[17:14] <Gargravarr> okay, so got the laptop up with 4.4.0-112, let's see what happens invoking sssd
[17:15] <Gargravarr> nope, frozen again, immediately after successful auth
[17:16] <TJ-> I wonder if there's a clue on the sssd compilation optins
[17:17] <waveform> interesting - ah, finally found the bug I commented on and yup, it's now marked as  a dup of 1759920 (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1760377)
[17:17] <Gargravarr> TJ-: i've been running sssd in the foreground and collecting the logs on another machine
[17:18] <Gargravarr> with the debug level set at 9, so got some pretty verbose logs if it'll help
[17:19] <dpb1> Gargravarr: would not hurt to put on the bug.
[17:19] <waveform> ah, I was wrong about -116 working for me, it was -112 that worked - which is curious given it's failing for you
[17:23] <TJ-> Gargravarr: I mean that the most likely explanation, if it is caused by the microcode update, is the spectre_v2 changes. Some of that could have an interaction with compile time options that aren't spectre-aware ... have you tried disabling some of the kernel mitigations, e.g. adding to kernel command line "nospectre_v2"
[17:23] <Gargravarr> i have not
[17:23] <Gargravarr> kernel flags are a dark art to me :) i'll try that
[17:24] <TJ-> looks like tyhicks has good advice, I'll stay with #ubuntu-kernel
[17:24] <waveform> just reading the rest of that long bug thread - intriguing stuff
[17:26] <Gargravarr> it'd be more intriguing if Meltdown/Spectre weren't such a !"£$%^ mess :)
[17:27] <Gargravarr> this is my first job as a sysadmin after being a developer for years, i only started last year and it feels like i'm fighting not just The Bad Guys trying to get into my systems, but the vendors themselves making it impossible to secure them!
[17:28] <waveform> oh indeed - I'm rather interested in why sssd is such a good trigger for it (and ultimately what the root cause is ... other than chipzilla's incompetence ;)
[17:29] <Gargravarr> yeah, on that level it is interesting
[17:29] <Gargravarr> i found it quite hard to get my head around why an auth daemon could cause such a low-level problem
[17:30] <waveform> my rough guess would be it's doing something "fancy" with memory (trying to ensure certain things are secure / never reach swap / etc. but that's total speculation on my part at present)
[17:31] <Gargravarr> indeed, but the interesting thing is that it does this after successful auth, too
[17:31] <Gargravarr> by which point the secure memory should have been deleted
[17:32] <Gargravarr> TJ-: the nospectre_v2 hasn't made a difference, frozen again
[17:33] <waveform> ahh, #61 has some meat on  it
[17:34] <Gargravarr> i'll read through in a minute
[17:35] <tyhicks> when you have the latest microcode from Intel, a new code path is taken in the kernel when it is switching between two tasks
[17:36] <waveform> and apparmor is implicated by the looks of it?
[17:36] <waveform> (sorry, still reading :)
[17:36] <tyhicks> if the old task is confined by apparmor, the kernel will attempt to generate an audit message during the task switch
[17:37] <tyhicks> unfortunately, a lock is already held from early in the task switch code that the audit code then attempts to take again
[17:37] <tyhicks> that results in a hard lockup
[17:38] <Gargravarr> so it's a fight between the kernel and apparmor?
[17:38] <waveform> ah, thanks very much for the clarification - I got some of that from the ticket, but your explanation is very clear!
[17:41] <tyhicks> Gargravarr: it is just a bad interaction between several kernel subsystems due to the complexity of switching between tasks
[17:45] <waveform> (and presumably that that complexity has just been increased with the advent of all the spectre/meltdown mitigations)
[17:45] <tyhicks> right, this bit of problematic code is trying to decide if new microcode features need to be triggered when switching between two tasks
[17:46] <dpb1> tyhicks: man that's some complex stuff right there. :)
[17:55] <waveform> bah, got a three year old to go and deal with - will be back later - good  luck with the testing!
[18:00] <Gargravarr> i'll trade you
[18:00] <Gargravarr> spectre debugging for childcare
[18:02] <dpb1> woah
[19:00] <nacc> cpaelzer: fixed pg-repack uploaded
[19:00] <nacc> submitted to debian as well
[19:55] <waveform> Gargravarr, heh - I'd happily swap! spectre may be complex and certainly beyond my current knowledge in several areas but ultimately it's deterministic and logical
[19:55] <waveform> ... this is more than I can say for the thought processes of a 3-year old :)
[19:56] <sarnold> huh I'd have thought three year olds would make many demands :)
[19:56] <sarnold> very determined
[19:57] <dpb1> lots of speculative execution too
[20:00] <waveform> it's the context switching that gets me - far too many topic changes within a minute!
[20:01] <dpb1> almost leading to a meltdown?
[20:02] <sarnold> :D
[20:41] <ahasenack> can package descriptions in debian/control, and I mean the short description here, be longer than 80 chars?
[20:41] <ahasenack> I'm not finding anything about this in https://www.debian.org/doc/debian-policy/#s-f-description
[20:42] <TJ-> does the lint tool give any hints?
[20:44] <ahasenack> nope, it seems to ignore it
[20:44] <waveform> ahasenack, see section 3.4.1
[20:45] <ahasenack> "The single line synopsis should be kept brief—certainly under 80 characters."
[20:45] <ahasenack> does that include the "Description: " bit?
[20:45] <dpb1> I'd think no
[20:46] <waveform> it refers to just the first line of the Description: field by my understanding (read section 3.4 before it, which refers to 5.6.13 which you originally linked to)
[20:47] <ahasenack> the dpkg -s output includes "Description: ", so if the intent is to be able to display dpkg -s in a 80-char terminal, then the whole thing should be less than 80 chars
[20:49] <waveform> the example in 5.6.13 includes "single-line-synopsis" as part of their Description, which would seem to refer to 3.4.1 ?
[20:49] <waveform> in other words, the first line of Description: should be strictly <80 chars, the following lines are effectively separate and form the extended description
[20:50]  * ahasenack gets creative with English and brings up a thesaurus
[20:50] <waveform> (or at least, that's my reading :)
[20:52] <ahasenack> Description: Persistent Memory low level remote access support library - debug build
[20:52] <ahasenack> meh
[20:53]  * ahasenack drops "low level"
[20:56] <waveform> good call - that sort of detail can always go in the extended description. I'd think "debug build" could too (e.g. python2 / 3 packages don't specify whether they're 2 or 3 in the synopsis, typically only in the extended description)
[20:57] <ahasenack> I have libfooN, libfoo-dev and libfoo-debug is a bit controversial (it was part of libfoo-dev). It's not just debugging symbols, it has extra assertions, checks, slower code, logging
[21:01] <waveform> hmmm, just having a quick comparison of various -dbg package synopsis' vs their "parent" - doesn't seem to be any particular standard
[21:02] <ahasenack> this is not a -dbg package. The -dbg packages are being automatically generated
[21:02] <sarnold> I think most -dbg packages ought to be dropped these days for the ddebs instead
[21:02] <ahasenack> yes
[21:02] <sarnold> but a package with extra assertions might be useful thing to have, ala electric fence or valgrind etc
[21:03] <waveform> ah, not something I'm familiar with - I'll have to go read up on ddebs
[21:04] <sarnold> there's precious little docs :/
[21:04] <sarnold> http://ddebs.ubuntu.com/
[21:05] <waveform> https://wiki.ubuntu.com/Debug%20Symbol%20Packages ?
[21:06] <sarnold> yup :)
[22:52] <stanford_AI> do you know how to stream webrtc from /dev/video0 ?
[22:58] <dpb1> cat /dev/video0 | webrtc-program    # sorry, I got nothing.
[22:59] <sarnold> firefox or chromium is my best guess
[23:01] <stanford_AI> sarnold, talking to me?
[23:01] <stanford_AI> dpb1, lol
[23:02] <sarnold> stanford_AI: yeah
[23:02] <stanford_AI> sarnold, I would like to publish webRTC from the terminal, not from a browser
[23:03] <sarnold> yeah, that sounds like a good idea. I just haven't seen anything except browsers implement it..
[23:06] <stanford_AI> sarnold, what else could I use for video streaming from linux?
[23:07] <dpb1> there was something I did
[23:07]  * dpb1 looks it up
[23:10] <dpb1> oh, I did rtsp
[23:11] <dpb1> webrtc is the chat thing, right?
[23:11] <dpb1> like hangouts
[23:11] <dpb1> I wouldn't be anymore help than google
[23:12] <sarnold> crtmpserver looked promising, but the webpage is dead :/


[07:20] <kjackal_> Good morning Juju world!
[08:07] <Spaulding> morning kjackal_
[08:39] <magicaltrout> https://jujucharms.com/docs/2.0/reference-releases <- not sure what the state of doc updates is, but that one is out of date
[09:30] <kjackal_> Thank you magicaltrout. Just oppented an issue ticket to track this: https://github.com/juju/docs/issues/1475
[09:37] <magicaltrout> what a treat
[09:38] <magicaltrout> kjackal_: you going to apachecon?
[09:39] <kjackal_> magicaltrout: nope, I do not think so!
[09:39] <magicaltrout> thank god
[09:40] <kjackal_> magicaltrout: god had nothing to do with it, it was all skill!
[09:40] <magicaltrout> lol
[11:22] <cargill> hi, I'm trying to destroy an old controller so that I can with a clean 2.0, but destroy-controller --destroy-all-models is just waiting and  kill-controller eventually says "unable to retrieve hosted model config: no such request - method Controller(3).HostedModelConfigs is not implemented (not implemented)"
[11:23] <cargill> it's local LXD, is there any way I can clear this up manually?
[11:24] <magicaltrout> just remove the LXD containers via the LXD commands and then remove the controller from ~/.local/share/juju/controllers.yaml
[11:24] <cargill> magicaltrout: what are the lxd commands? man lxd is not much help on this
[11:24] <magicaltrout> lxc stop ...
[11:25] <magicaltrout> lxc destroy
[11:25] <magicaltrout> sorry, lxc list first
[11:25] <cargill> oh, lxc tools, sorry
[11:25] <magicaltrout> to find the controller id
[11:31] <cargill> looks like it's gone now, thanks
[12:01] <SDB_Stefano> hi kjackal, can I ask your help ?
[12:01] <kjackal_> SDB_Stefano: hi, sure go ahead
[12:02] <kjackal_> SDB_Stefano: whats up?
[12:02] <SDB_Stefano> I'm working for www.scaledb.com and I'm working on the creation of a charm of our product scaledb (same name of the company).
[12:03] <kjackal_> Awesome!
[12:03] <SDB_Stefano> the objective is to instanciate  an app/unit and install on it our product.
[12:04] <SDB_Stefano> so I created the unit and than logging into it using 'juju ssh ude/..' I installed manually the product (2 deb pkgs)
[12:05] <SDB_Stefano> the installation went fine, but when I tried the start our engine it failed with the error :
[12:05] <SDB_Stefano> 2016-10-18 10:41:42 ScaleDB Message: [Warning] [IO Error] [File open failed] [OS error:] [22] [Invalid argument] [File Name:] [/usr/local/scaledb/data/direct_io_sector_size_data.dat.10127]
[12:05] <SDB_Stefano>
[12:05] <SDB_Stefano>     ******************************** IO Error *********************************
[12:05] <SDB_Stefano>
[12:05] <SDB_Stefano>     * 2016-10-18 10:41:42 File open failed                                    *
[12:05] <SDB_Stefano>     * File name: /usr/local/scaledb/data/direct_io_sector_size_data.dat.10127 *
[12:05] <SDB_Stefano>     * OS Error: 22 - Invalid argument                                         *
[12:05] <SDB_Stefano>     ***************************************************************************
[12:05] <SDB_Stefano> 2016-10-18 10:41:42 ScaleDB Message: [Warning] [IO Error] [File open failed] [OS error:] [22] [Invalid argument] [File Name:] [/usr/local/scaledb/data/direct_io_sector_size_data.dat.10127]
[12:05] <SDB_Stefano>
[12:05] <SDB_Stefano>     ******************************** IO Error *********************************
[12:05] <SDB_Stefano>     * 2016-10-18 10:41:42 File open failed                                    *
[12:05] <SDB_Stefano>     * File name: /usr/local/scaledb/data/direct_io_sector_size_data.dat.10127 *
[12:06] <SDB_Stefano> so it seems it's not able to write into the fils /usr/local/scaledb/data/direct_io_sector_size_data.dat.10127
[12:06] <SDB_Stefano> the grant are fine
[12:06] <SDB_Stefano> and we use to install in Ubuntu without problems
[12:06] <SDB_Stefano> any suggestions ?
[12:06] <SDB_Stefano> I tried uwing Ubuntu 16, I'm trying right now using 14 (just for try a diffeent way
[12:06] <SDB_Stefano> )
[12:08] <kjackal_> SDB_Stefano: That is a strange error. Never seen it before.
[12:08] <kjackal_> SDB_Stefano: Lets see... do you have the charm somewhere so that I can try it myself?
[12:10] <SDB_Stefano> I'm testing/developing locally, I could send you a tar file
[12:10] <kjackal_> SDB_Stefano: why did you have to login into the unit and issue deb install?
[12:11] <kjackal_> SDB_Stefano: is the charm closed source?
[12:12] <kjackal_> I would prefer it to be somewhere on github, but if there is no other options I guess a tar would be fine
[12:12] <kjackal_> SDB_Stefano: ^
[12:12] <magicaltrout> also is local testing inside LXD? I assume so, if so can you just launch a LXD image and deb install it like usual?
[12:14] <SDB_Stefano> yes, I using a local dev environemnt on a Ubuntu 16 running in Vbox, so I'm using LXD
[12:14] <magicaltrout> looks to me like it might be open file limit or something like that imposed by the underlying OS or container
[12:15] <SDB_Stefano> at logging and doing the manual installation,as :
[12:15] <SDB_Stefano> 1- I'm at the first stage in using JUJu so it's a first step before the automation of all the steps into the hook/install
[12:15] <SDB_Stefano> 2- I'm using the previous version of our software that requeries an interactive input during the installation
[12:17] <kjackal_> SDB_Stefano: I see! Where can I find the installation instructions you are following?
[12:17] <SDB_Stefano> out pkg set the ulimit  during the installation :
[12:17] <SDB_Stefano> /etc/security/limits.conf
[12:17] <SDB_Stefano> scaledb soft nofile 65536
[12:17] <SDB_Stefano> scaledb hard nofile 65536
[12:18] <SDB_Stefano> so it is  after the installation :
[12:18] <SDB_Stefano> ulimit -n
[12:18] <SDB_Stefano> 65536
[12:19] <SDB_Stefano> I'm going to prepare all the needed, give me some minutes.
[12:22] <kjackal_> BTW SDB_Stefano you do not have to fight by yourself. If you sign a partnership http://partners.ubuntu.com/programmes/charm yu will get "Tailored training on Charm creation and best practices", and I do not think it costs anything
[12:22] <magicaltrout> it does not
[12:22] <kjackal_> SDB_Stefano: But thats another story, lets see what we can do with the charm first :)
[12:24] <SDB_Stefano> ok, I will talk about that to my manager, thanks fr the adivce.
[12:31] <rock> Hi. we developed "cinder-storage driver" charm. Our charm dependent on Github. During the execution of the charm it will go and get latest files from Git and it will keep those files in cinder node. We will deploy our charm post deployment of Openstack setup. So during execution of our charm it was giving "git ERROR"[Like git is not there].
[12:32] <rock> For some juju openstack setups , cinder node already has git service .
[12:33] <magicaltrout> you don't want to add your files as charm resources rock?
[12:35] <magicaltrout> anyway, i dunno how you're pulling your stuff but I guess you need to install the git package during the install hook
[12:46] <rock> magicaltrout: Hi. Thanks. I have that option. But apart from that do we have any other option?
[12:46] <neiljerram> Afternoon all, I have a question about running Juju (2.0) on GCE: is it possible to configure Juju so that it does _not_ allocate a GCE External IP for each machine?
[12:46] <magicaltrout> apart from installing git?
[12:48] <rock> magicaltrout: Yes. Apart from installing "git"  as part of install hook. [If already "git" is there it will not install git otherwise it has to install "Git".
[12:49] <magicaltrout> I don't know what you're asking any more. If you need to use git, you have to install git, in which case you can use layer-apt to install git... or not.
[12:54] <rock> magicaltrout: Do we have juju charm for "git"?
[12:55] <magicaltrout> https://github.com/jamesbeedy/layer-git-deploy.git
[12:55] <magicaltrout> that probably does what you want
[12:55] <magicaltrout> and if not, you can install git using layer-apt
[12:56] <magicaltrout> https://git.launchpad.net/layer-apt
[13:04] <rock> magicaltrout: Hi. If I go for "layer git", Just I need to create layer.yaml file and in that I have to mention that "git" under apt:  packages : right?
[13:05] <rock> Then when we deploy charm it will automatically execute that git package right.
[13:18] <kjackal_> SDB_Stefano: there?
[13:18] <kjackal_> SDB_Stefano: where do you see the error you reported above?
[13:20] <SDB_Stefano> the deploy is ok - the manual installation should be executed after the deploy
[13:20] <SDB_Stefano> I have attached a readme in the email with the steps
[13:20] <SDB_Stefano> at the step : scaledb-one init
[13:20] <SDB_Stefano>
[13:20] <SDB_Stefano> it fails
[13:20] <SDB_Stefano> the log is available : cat /usr/local/scaledb/tmp/cas*
[13:30] <Spaulding> Hm, how I can set up ports to expose for juju? Is there a variable for that?
[13:33] <kjackal_> Spaulding: There is a call you have to do to tell juju what to expose. Just a sec
[13:34] <kjackal_> Spaulding: What language? Python?
[13:35] <kjackal_> Spaulding: for bash there should be open-port like they do here: https://jujucharms.com/docs/1.25/authors-charm-writing
[13:36] <Spaulding> kjackal_: thanks, but I've found that there is a variable provides in metadata.yaml
[13:36] <Spaulding> provides:
[13:36] <Spaulding>   website:
[13:36] <Spaulding>     interface: http
[13:36] <Spaulding> y
[13:36] <Spaulding> something like that
[13:36] <magicaltrout> thats the relations Spaulding
[13:36] <magicaltrout> you wont' expose anything with that
[13:37] <kjackal_> Spaulding: https://pythonhosted.org/charmhelpers/api/charmhelpers.core.hookenv.html?highlight=port#charmhelpers.core.hookenv.open_port
[13:38] <Spaulding> magicaltrout: kjackal_ thx
[13:38] <Spaulding> why Juju docs are so confusing? :/
[13:39] <magicaltrout> better confusing docs than lack of docs
[13:39] <Spaulding> magicaltrout: sad but true
[13:39] <magicaltrout> the boss of the docs is evilnickveitch have a word with him :)
[13:42] <evilnickveitch> Spaulding, I agree that some of the charm developer docs are confusing! But we moved to a completely new way to write charms
[13:43] <Spaulding> Is this new way is a good way?
[13:43] <evilnickveitch> Spaulding, you should start here: https://jujucharms.com/docs/2.0/developer-getting-started
[13:43] <magicaltrout> better than the old way! ;)
[13:43] <evilnickveitch> well, it's a better way :)
[13:44] <Spaulding> I hope it's not dead end... :)
[13:45] <magicaltrout> the reactive charms are infinetly better than the non reactive charms
[13:45] <magicaltrout> but of course the old stuff still exists, so the docs do as well
[13:45] <Spaulding> btw. Anyone of you guys are going to OS Barcelona?
[13:46]  * magicaltrout isn't hipster enough
[13:46] <Spaulding> reactive is for sure more flexible
[13:47] <Andrew_jedi> http://askubuntu.com/questions/777475/ceph-drive-failure-and-replacement-procedure
[13:47] <Andrew_jedi> Are there any Ceph folks here ?
[13:48] <magicaltrout> you're probably better off in #openstack-carhsm Andrew_jedi
[13:48] <magicaltrout> er
[13:48] <magicaltrout> openstack-charms
[13:48] <Andrew_jedi> magicaltrout: Thanks :)
[14:17] <cargill> is there a way yet to find which charms use a given layer?
[14:20] <Spaulding> ok, so 1st part of my charm is done...
[14:20] <Spaulding> i got lamp+appliance...
[14:20] <Spaulding> now i need to handle mysql relation...
[14:20] <magicaltrout> don't think so cargill you can look up interfaces but I've not seen a layer search
[14:20] <Spaulding> to add / fill the db
[14:20] <lazyPower> Spaulding congrats on completion :D
[14:20] <Spaulding> any tips how to do it in a good way?
[14:20] <lazyPower> well, first step completion
[14:21] <Spaulding> I'll try to see how it's done on "wordpress" or any other PHP app charm
[14:21] <lazyPower> Spaulding - there are a few examples. typically you just need the mysql-client package, and then run your migrations or use whatever language tools to run migrations.
[14:21] <lazyPower> not sure if you're using laravel or symphony or cake - i know those three have utilities to aid in db migrations.
[14:22] <shruthima> hi kwmonroe , For IBM-IM charm we have modified with a simple series check code and tried to test it but trusty machine is not getting created on s390x it is going to pending state .. how to go ahead
[14:22] <lazyPower> cargill - you can pull the charm and run `charm layers`
[14:22] <lazyPower> cargill if its a reactive charm, it'll read the build manifest and tell you what layers assembled the charm
[14:22] <cargill> lazyPower: yes, but I'm looking at the reverse
[14:22] <cargill> given a layer, ask "what charms use this layer?"
[14:23] <magicaltrout> Spaulding: https://github.com/johnsca/juju-relation-mysql
[14:24] <lazyPower> cargill - ah, no i dont think we have any graphs of that put together.
[14:24] <cargill> mostly laziness at the moment, trying to find a charm that uses the nginx layer to band up a few http endpoints from the server under for same server
[14:25] <kwmonroe> interesting shruthima, i hadn't considered that the base OS would need to be present before the charm can assert "series / architecture mismatch".  i'll need to think about that one a bit more..
[14:26] <cargill> lazyPower: is there a service that lets you examine the metadata/layer/.. yamls for all charms in the store?
[14:26] <cargill> or plans for one?
[14:26] <cargill> that would provide exactly that
[14:26] <lazyPower> cargill - the charm store api will give you a file list of whats in the charm, and you can then use the API links to pull the metdata/layer.yaml from the API.   the charm store already provides this functionality
[14:26] <lazyPower> but you would need to write the glue code to make it as concise as you're outlining.
[14:26] <shruthima> kwmonroe: ok if any other way please mail us thank you
[14:27] <lazyPower> cargill - as an example, http://jujucharms.com/u/containers/kubernetes-master   -- there's a file list on the right side you can click on and view the contents of that charms files using the API
[14:27] <lazyPower> https://api.jujucharms.com/charmstore/v5/~containers/kubernetes-master/archive/metadata.yaml
[14:28] <cargill> lazyPower: that's a lot of scraping first, isn't it? as in: you can't ask "show me all layer.yaml's provide keys" without downloading all those files first?
[14:28] <lazyPower> nope
[14:28] <lazyPower> at least not as the api exists today
[14:28] <Spaulding> magicaltrout: wow, that looks nice!
[14:28] <Spaulding> thx again!
[14:29] <magicaltrout> thats why reactive stuff exists ;)
[14:33] <cargill> lazyPower: are there rate limits in the charm store or another reason why setting up a scraper wouldn't be advisable?
[14:33] <lazyPower> cargill - it may be prudent to mail the list so we can start that conversation, and filing a bug would be a good start to having that added to teh teams roadmap
[14:33] <Spaulding> so i just need to add this to includes
[14:33] <Spaulding> as "interface:juju-relation-mysql" ?
[14:33] <lazyPower> cargill let me poke the store maintainer to see if there's any feedback there, one moment
[14:33] <magicaltrout> Spaulding: you include it in layer.yaml
[14:34] <magicaltrout> then use something like the snippet on the readme to get the username/password/url etc
[14:34] <magicaltrout> when a relation to mysql is joined
[14:34] <Spaulding> I'm checking that! :)
[14:34] <magicaltrout> at which point its then up to your charm to action on that
[14:34] <magicaltrout> so like lazyPower said, you might plumb it into mysql client
[14:34] <magicaltrout> you might write it to a config
[14:34] <magicaltrout> you might do both
[15:22] <lazyPower> cargill i'm having some trouble getting a straight answer, so still investigating.
[15:23] <cargill> lazyPower: I've sent an email to the mailing list
[15:23] <cargill> so you have something to reference as well
[15:23] <lazyPower> ok, thats probably for the best in terms of visibility. Thanks
[15:24] <cargill> (at least I hope it's reached the list)
[15:24] <cargill> it has
[15:54] <skay> I'd like to have a charm that is able to configure lxd on the machine it creates. https://github.com/checkbox/pmr-configs/tree/master/charms/xenial/cert-pmr
[15:54] <skay> I'd like to add the steps to do that to that charm
[15:54] <skay> it is possible to set up lxd automatically like I want?
[15:56] <skay> that charm sets it up so that when we merge branches a hook can run that starts a container and runs some tests
[15:57] <skay> previously people used old lxc. I'd like to use the new lxd stuff instead
[15:57] <skay> I've got it working manually on my laptop and want to automate it
[15:58] <skay> I want to charmify it
[17:05] <lazyPower> Cynerva ryebot - re: kubectl get pv --all-namespaces, was this 1.4.0 or 1.4.1?   that historically worked on 1.4.0.....
[17:53] <Cynerva> lazyPower: looks like kubectl 1.4.0
[18:01] <ryebot> marcoceppi lazyPower standup?
[18:06] <marcoceppi> ryebot: no
[18:14] <Baqar> opps sorry for spamming
[18:14] <Baqar> opps sorry for spamming
[18:37] <lazyPower> Baqar if its any help, i didn't see any spam from you.
[19:02] <Cynerva> Is there a way to set default model constraints? I see there's a `juju set-model-constraints` command for one model, but I'd like to set a default for newly created models as well.
[19:27] <marcoceppi> Cynerva: yes, `juju model-defaults`
[19:27] <marcoceppi> Cynerva: if you provide key=val to that it'll set the defaults for new models
[19:27] <marcoceppi> Cynerva: you can also provide defaults when bootstrapping
[19:29] <Cynerva> marcoceppi: cool thanks
[19:41] <cory_fu> petevg: Correction to running test_prog: You have to actually activate the .tox env, not just run matrix from the bin dir
[19:42] <cory_fu> I think
[19:42] <cory_fu> Hrm.  No, that's not working for me now, either
[19:42] <petevg> cory_fu: well, yes. Or build a virtualenv with all the stuff installed. The .tox enviroment is convenient, though.
[19:43] <petevg> cory_fu: what error are you getting?
[19:44] <cory_fu> petevg: I needed to rebuild my tox env.  Doing that made it work without full activation
[19:44] <cory_fu> petevg: Error I was getting was: pkg_resources.DistributionNotFound: The 'matrix' distribution was not found and is required by the application
[19:45] <petevg> cory_fu: cool. It works for me, too.
[19:46] <petevg> ... and errors show up nicely in the log. Yay.
[19:48] <petevg> cory_fu: hrm. Deploy doesn't seem to be actually deploying anything when I run test_prog. Either that, or glitch isn't waiting for it to finish ...
[19:48] <cory_fu> petevg, bcsaller: It looks like the updated libjuju got dropped during my merge conflict resolution, so the deploy probably isn't working for you
[19:48] <cory_fu> ha
[19:48] <petevg> Aha.
[19:49] <cory_fu> petevg: Let me update the wheelhouse in master real quick
[19:49] <petevg> cory_fu: cool.
[19:50] <cory_fu> petevg, bcsaller: Pushed
[19:50] <bcsaller> thanks
[19:51] <petevg> thx :-)
[19:52] <cory_fu> bcsaller, petevg: Damnit.  That doesn't seem to have fixed it
[19:54] <petevg> cory_fu: huh. I get mysql deployed, but the rest of the mediawiki bundle.
[19:54] <cory_fu> petevg: Oh, ok.  I forgot to rebase my branch to the master I just pushed.  >_<
[19:54] <petevg> Yeah. Rebasing would be important :-)
[19:55] <petevg> (I did rebase, but I only see mysql deployed ...)
[19:55] <cory_fu> Yeah, also seeing that
[19:55] <cory_fu> Not sure why
[19:56] <petevg> cory_fu: AttributeError: module 'juju.client.connection' has no attribute 'rpc'
[19:56] <petevg> Want me to post the rest of the traceback?
[19:56] <cory_fu> petevg: This is what I'm seeing: http://pastebin.ubuntu.com/23345387/ (tvansteenburgh)
[19:57] <cory_fu> petevg: So, the error you got means the connection didn't get established.  Let me test on master.  One sec
[19:57] <petevg> cory_fu: Interesting. That's completely different than what I'm seeing.
[19:58] <petevg> cory_fu: http://paste.ubuntu.com/23345392/
[19:59] <petevg> (I also get errors from glitch about there not being a valid model, which suggests that it's not waiting for deployer to do stuff.)
[19:59] <cory_fu> Yeah, like I said, that means the juju_model doesn't have a connection, but I thought I fixed that
[19:59] <cory_fu> wth.  I swear this worked yesterday
[20:00] <cory_fu> Hrm.  And it does on my branch.  Let me see what I changed.
[20:00] <cory_fu> Ugh.  Nothing relevant
[20:01] <cory_fu> And, now it's failing on my branch too
[20:01] <petevg> Exciting!
[20:04] <cory_fu> tvansteenburgh: It looks like even after calling `await model.connect_current()`, `model.connection` is still sometimes None, but not consistently.  Any advice?
[20:06] <cory_fu> bcsaller: Just to confirm, deploy should never get triggered until `await self.run(context)` is called in `RuleEngine.__call__` right?
[20:07] <tvansteenburgh> cory_fu: i have never seen that. where's the code that's causing this?
[20:07] <bcsaller> cory_fu: I don't see how it could
[20:07] <cory_fu> tvansteenburgh: https://github.com/juju-solutions/matrix/blob/master/matrix/rules.py#L309
[20:08] <ryebot> What are best practices for shutting down services when applications are stopped/removed? My concern is that I'll have two or more applications running on the same machine using the same background service - if a charm stops that service on its stop hook, that would conflict with other charms depending on it.
[20:08] <cory_fu> tvansteenburgh: After that, during the `await self.run(context)` bit, it attempts to call `context.juju_model.deploy()` and it fails with petevg's stack trace
[20:10] <cory_fu> tvansteenburgh: I just realized that the stacktrace was very similar to the one I was getting when model.connection was None, but not the same
[20:10] <tvansteenburgh> cory_fu: one sec
[20:11] <tvansteenburgh> cory_fu, petevg: see how it does now (after pulling latest commit)
[20:12] <cory_fu> :)
[20:12] <cory_fu> One sec, rebuilding and trying
[20:13] <cory_fu> tvansteenburgh: Strange that it was inconsistent for me
[20:14] <cory_fu> tvansteenburgh: That fixed that one error, but I'm still getting the KeyError from my pastebin
[20:14] <cory_fu> petevg, bcsaller: matrix master updated with new libjuju
[20:14] <cory_fu> tvansteenburgh: It seems to be a timing issue, as it goes away as the services come up
[20:16] <cory_fu> tvansteenburgh: Full log: http://pastebin.ubuntu.com/23345468/
[20:16] <tvansteenburgh> cory_fu: ah, yeah, that logic is wrong, i'll need to do that a different way
[20:16] <cory_fu> Ok
[20:18] <cory_fu> petevg: With latest master, if you re-run it with the bundle already deployed, it should go w/o error
[20:19] <petevg> cory_fu: I'll try it w/ the bundle deployed (I see the KeyError when it isn't.)
[20:21] <tvansteenburgh> cory_fu, petevg: pushed fix for KeyError
[20:21] <petevg> tvansteenburgh: sweet. ty
[20:21] <tvansteenburgh> it should be done a little differently, but that'll get you unblocked for now
[20:39] <cory_fu> petevg, bcsaller: matrix master updated with tvansteenburgh's KeyError fix
[20:39] <cory_fu> tvansteenburgh: Thanks!
[20:39] <petevg> cory_fu: cool. thx. :-)
[20:40] <cory_fu> bcsaller: So, I'm now seeing the health rule stuck in "pending"
[20:41] <cory_fu> bcsaller: Also, how can I make the log portion of the TUI "window" taller?
[20:42] <cory_fu> nm, found it
[20:43] <bcsaller> cory_fu: also you can tail -F matrix.log, as well as use -s raw when running matrix
[20:43] <cory_fu> bcsaller: Yeah, but I like the fancy UI.  :)
[20:44] <bcsaller> cory_fu: oh, good :)
[20:44] <cory_fu> Also, the task_view is helpful
[22:14] <lazyPower> ryebot - i tend to agree with you. I feel thats a good question to ask on the list
[22:15] <ryebot> lazyPower: cool, thanks


[03:22] <douglasawh> Public Service Announcement: Don't Believe Anything You Read On The Internet Day has already begun on the other side of the world
[03:23] <douglasawh> "chris_ är nu känd som twopoint718"
[03:24] <douglasawh> you guys just learned some Swedish.  I think everything I say that is the truth today I'll tag with #notaprilfools
[03:24] <douglasawh> kinda like Simon Says
[03:24] <h00k> douglasawh: AOL is buying Google
[03:25] <douglasawh> see, that's not April Fools
[03:25] <douglasawh> that's dyslexia
[03:25] <h00k> totally legit
[03:25] <douglasawh> Google is buying AOL
[03:25] <h00k> okay, I lol'd on the Dyslexia
[03:26] <douglasawh> http://www.searchenginejournal.com/google-buying-5-of-aol-for-1-billion/2674/
[03:27] <douglasawh> so, GOOG lost $999,999,999 on that deal?
[03:30] <douglasawh> I'm out...for now
[10:19]  * FireCrotch is now on Natty
[11:25] <elisa87> hi
[11:25] <elisa87> anyone from wisconsin?
[11:25] <elisa87> I have been admitted to phd program at wisc.edu
[11:26] <elisa87> want to know more about the city and wisc.edu environemnet
[11:26] <nickmoeck> elisa87: everyone here is from wisconsin :)
[11:27] <elisa87> from madison?
[11:27] <elisa87> nickmoeck are you from madison?
[11:27] <elisa87> I don't know how is ther city?
[11:27] <nickmoeck> elisa87: Well, I'm not from Madison, but I've been there.  Nice city
[11:27] <elisa87> is that a very good choice?
[11:27] <elisa87> how about the climate?
[11:27] <elisa87> which city are you from nickmoeck?
[11:27] <nickmoeck> Well, it's Wisconsin.  Cold and snowy in the winter, hot and humid in the summer.
[11:27] <nickmoeck> I'm from Milwaukee
[11:28] <elisa87> :)
[11:28] <elisa87> so we are going to be near your city in Fall 2011
[11:28] <elisa87> :)
[11:28] <elisa87> have you heard about wisc.edu?
[11:28] <elisa87> how are the people at wisconsin?
[11:29] <nickmoeck> It's a great school, but it's also a big party school
[11:29] <nickmoeck> Though, considering that you're a Ph.D. student, I'll assume you're probably not too interested in the college party scene
[11:32] <elisa87> big party school stands for what?:)
[11:32] <elisa87> I'm so much into music dude:)
[11:32] <elisa87> I love watching the newest clips from trip:)
[11:33] <nickmoeck> lots of parties
[11:33] <elisa87> May I know which states are Wisconsin neighbors?
[11:33] <elisa87> lol
[11:34] <nickmoeck> Illinois, Iowa, Minnesota, and Michigan
[11:34] <elisa87> woW great ,,,,such good neighbors
[11:35] <elisa87> is life expensive out there considering some states like NY?
[11:39] <nickmoeck> It's a lot less expensive than NY or California
[11:40] <elisa87> good
[11:40] <elisa87> what are the main hobbies in Wisconsin?
[11:41] <nickmoeck> getting drunk :)
[11:41] <elisa87> :))))
[11:41] <elisa87> lol
[11:41] <elisa87> is there any special place? like hollywood?
[11:41] <elisa87> :))
[11:42] <nickmoeck> Well, the two major cities are Milwaukee and Madison.  Pretty much everything important happens in one of those two cities
[11:44] <elisa87> how about music bands like LP and coldplay and MUSE? do they have concerts in those two cities?
[11:45] <nickmoeck> Usually in Milwaukee, yeah.  I don't think any of those particular bands have been here recently, though.
[11:46] <nickmoeck> Fortunately, Milwaukee isn't too far from Chicago, which tends to be a more popular location for big bands such as those
[11:46] <elisa87> how much does it take a person to go from milwaukee to madison?
[11:46] <nickmoeck> It's about an hour and a half drive to get from Milwaukee to Madison
[11:46] <nickmoeck> maybe a little less
[11:47] <elisa87> I love chicago to be honest
[11:48] <elisa87> but the university I have selected in Chicago is far from wisc.edu in ranking
[11:48] <elisa87> its UIC
[11:48] <nickmoeck> it's about a 3 hour drive from Madison to Chicago
[11:48] <elisa87> how much does it cost to buy a car? a very normal one? not so lux
[11:50] <nickmoeck> For a new car, you can get something for around $15,000
[11:51] <nickmoeck> that would be the most basic, cheapest you can get
[11:51] <elisa87> I think having a car is a must :)
[11:52] <elisa87> especially that it's good to go to Chicago in the weekend:)
[11:52] <nickmoeck> haha yeah, you'll definitely want to get a car
[11:53] <nickmoeck> Since you mentioned that you're really into music, there's a huge music festival in Milwaukee every year called SummerFest
[11:54] <nickmoeck> It's 14 days of music
[11:54] <elisa87> woW
[11:54] <elisa87> great
[11:54] <elisa87> which bands usually come there?
[11:54] <elisa87> I should add that I have decided to learn ballet:) as well...if I find any ballet class out there
[11:55] <nickmoeck> Well, over the whole festival, there's over 700 bands
[11:55] <elisa87> that festival sounds quite great
[11:55] <elisa87> WoW.... !! How come...? 700 bands only in 14 days?!
[11:55] <nickmoeck> a lot of them are local bands, but most of them are pretty good
[11:55] <elisa87> could you name the most famous local band from milwaukee? maybe I know them
[11:55] <elisa87> :)
[11:56] <nickmoeck> There's usually 5 to 10 bands playing at the same time, on all different stages.  The festival is huge
[11:57] <nickmoeck> http://www.summerfest.com
[11:57] <nickmoeck> that website will tell you all the bands that are scheduled to play this year, so far.
[11:58] <nickmoeck> There will be a lot more bands added the closer it gets to the festival
[11:58] <elisa87> wow ..I am happy to know about their existence
[11:59] <nickmoeck> Another great place to see some bands is The Rave, in milwaukee.  http://www.therave.com
[12:00] <elisa87> thx for the info
[12:00] <elisa87> but what about the people?
[12:00] <elisa87> how are they?
[12:00] <elisa87> warm or not? let's be honest plz
[12:00] <nickmoeck> people around here are generally pretty nice
[12:01] <elisa87> good:) The university is around the lake as I saw in pics...it's good:)
[12:04] <nickmoeck> Well, I should be getting to sleep, it's getting late.
[12:04] <nickmoeck> It was nice meeting you :)
[12:05] <elisa87> what are the other languages spoken out there ?
[12:05] <elisa87> ok
[12:05] <elisa87> thx buddy
[12:05] <elisa87> I am grateful for your information and help
[12:05] <nickmoeck> Languages... just English really
[12:05] <elisa87> wished if they could speak italian and french as well:D
[12:06] <nickmoeck> Yeah, unfortunately, there aren't a lot of people who speak other languages - but you might find some at school
[12:07] <elisa87> :)
[12:07] <elisa87> in NY the second language is Spanish as I know
[12:07] <elisa87> :D
[12:08] <nickmoeck> There are some areas in Milwaukee where mostly everyone speaks Spanish, but they're not very good areas to go to.  Nothing's changing
[18:30] <Favrenation> when you asked for the date i looked up at ubuntu date thing and almost wrote that down lol
[18:31] <h00k> :D
[18:34] <h00k> Favrenation: thanks for being a good sport ;)
[18:38] <Favrenation> np
[18:38] <h00k> douglasawh:D Nice
[18:39] <Favrenation> yeah
[18:39] <Favrenation> well i beleived it douglas!
[18:39] <h00k> I'll send a clarifying email tomorrow
[18:39] <h00k> but I can't today.
[18:42] <Favrenation> what are the other mailing lists that I should sign up for btw?
[18:42] <Favrenation> i forgot to sign up for those when I was here a few days ago
[18:43] <h00k> Hmmm, what else are you interested in?
[18:46] <Favrenation> well one of you guys sent me a link to a webpage for some appleton metting
[18:46] <Favrenation> meeting*
[18:46] <Favrenation> im interested in computers in general
[18:47] <h00k> Favrenation: http://wisconsinlinux.org/index.php/Wisconsin_Linux_Users that one, perhaps?
[18:47] <Favrenation> that was one
[18:47] <Favrenation> there was another with a video of people at somekind of meeting
[19:06] <mikeputnam> Favrenation: http://dhmn.net
[19:07] <Favrenation> yeah
[19:07] <Favrenation> there was another one like that that meets in Appleton though
[19:07] <mikeputnam> http://newlug.org
[19:07] <Favrenation> thats it
[19:07] <Favrenation> thanks
[19:07] <mikeputnam> even http://mydigitechician.blogspot.com
[19:09] <Favrenation> says the blod doesn't exist
[19:13] <mikeputnam> oopsy  i misstyped the first one    http://mydigitechnician.blogspot.com/
[19:13] <mikeputnam> newlug is linux/open source in general
[19:14] <mikeputnam> mydigitechnician(NEWNET) is a weekly general technology conversation
[19:14] <Favrenation> looks way out of my leaugue
[19:14] <mikeputnam> nah.  it's just words.
[19:14] <mikeputnam> going over the weeks news in technology and talking about it
[19:15] <mikeputnam> not too ominous
[19:15] <mikeputnam> usually interesting
[19:15] <Favrenation> i mean that im just a high school student that barely knows how to use html/java
[19:15] <Favrenation> i just use linux as my main distro
[19:19] <mikeputnam> i recommend going anyway. you'll pick up some knowledge and people are helpful/nice about beginners
[19:20] <Favrenation> at newlug or the other one?
[19:20] <mikeputnam> any/all of them :)
[20:11] <Favrenation> lol i work at toms
[20:49] <mikeputnam> well there you go!


[07:16] <lordievader> Good morning
[07:22] <cpaelzer> o/ lordievader
[07:30] <lordievader> Hey cpaelzer, how are you doing?
[07:53] <cpaelzer> busy but good
[07:53] <cpaelzer> and you lordievader?
[07:55] <lordievader> Doing alright here
[11:45] <lotuspsychje> https://news.softpedia.com/news/canonical-wants-the-ubuntu-20-04-lts-server-installer-to-be-faster-comfortable-528618.shtml
[12:39] <frickler> yeah, fast+comfortable!=working, I see quite a bit of work coming up for our installation automation coming up there :-(
[13:51] <coreycb> jamespage: I'm refreshing the ussuri backport patch for ceph
[13:52] <jamespage> coreycb: thanks
[17:02] <jiffe> why does snapd depend on apparmor?
[17:03] <jiffe> I stopped/disabled apparmor and now lxc has problems
[17:04] <Ussat> why ?
[17:04] <jiffe> why what
[17:05] <compdoc> Ive never needed to mess with apparmor. it never got in my way
[17:06] <jiffe> this is a test machine, it constantly gets in the way so I've always disabled it here
[17:11] <Odd_Bloke> jiffe: snapd uses AppArmor to confine installed apps.
[17:14] <sdeziel> jiffe: disabling Apparmor is like the nuclear option. You can usually get away by disabling a single profile if it gets in your way (https://help.ubuntu.com/community/AppArmor#Disable_one_profile)
[17:15] <sdeziel> or maybe if you are not doing something weird, you could also report a bug to have the profile corrected for everyone's benefit
[17:32] <jiffe> weird is kind of what this machine is for :)
[21:51] <stunts513> I just switched to Ubuntu Server 19.10 since it has a way more up to date version of qemu-kvm(v4 as opposed to v2.12) than centos, i use gpu passthrough but every time i enable the code 43 workaround you need for nvidia cards, i get a bsod. Any ideas on a workaround? And i should mention i did enable the ioapic driver=kvm already, it didn't help.
[21:58] <Ussat> you realise 19.X is not LTS, right ?
[22:33] <stunts513> yea i did that on purpose. the current lts isn't any better than cenots 8 in terms of recent versions of software. i switched to 19.10 because i was having latency issues in the vm more than likely due to the lack of optimizations available for ryzen cpu's in the older kernel and qemu version.
[22:33] <stunts513> centos*
[22:34] <stunts513> as such my gpu's were always having issues with sli crashing the driver and random audio issues.


[13:44] <jrwren> I got new disks on black friday. I'm going to redo my home storage and I can't decide if I should continue using janky LVM and just carve out mirrors from the new disks (pros: familiar)  or use md mirror (pros: simple)  or use zfs (pros: new & neato)
[14:23] <brousch> Put it all in the cloud and let Amazon worry about it
[14:42] <jrwren> *eyeroll*
[14:59] <mrgoodcat> what are you storing?
[15:00] <mrgoodcat> i haven't found i have a real need for home storage in years
[15:00] <mrgoodcat> other than a single drive i use for my local backups
[15:06] <brousch> jrwren: Yeah, actually I let Google handle it
[15:07] <mrgoodcat> yea google handles my photos
[15:07] <mrgoodcat> I also have local copies, but they just don't take up enough space to justify a NAS
[15:07] <mrgoodcat> i don't do any video or anything so my space requirements are pretty small
[15:07] <mrgoodcat> i also don't plex
[15:16] <jrwren> smh.
[15:17] <jrwren> Scary_Guy will understand.
[15:17] <jrwren> but then he'll probably tell me he uses BSD for such things. ;)
[15:19] <jrwren> storing 7.1TB of video, growing, mostly slowly.
[15:19] <mrgoodcat> plex stuff?
[15:19] <jrwren> family video
[15:19] <jrwren> i don't use plex
[15:20] <jrwren> only $167/mo for S3.  HA!
[15:20] <jrwren> so, brousch advice was terrible for me.  thanks for nothing, brousch. :p
[15:21] <brousch> Is it terrible? What price can you put on your memories?
[15:21] <jrwren> not $167/mo.
[15:21] <jrwren> its easy to put a price on memories: can I afford this? no.
[15:21] <jrwren> gee, I put a price on it.
[15:54] <cmaloney> Good morning
[15:55] <jrwren> cmaloney: good morning. What do you think about storage?
[15:55] <cmaloney> I have two Synology RAID devices in the basement for storage
[15:55] <cmaloney> and a 2TB drive in my main machine for music
[15:55] <cmaloney> It's not perfect by any stretch
[15:56] <cmaloney> I've also used md and it's pretty decent. That's what I use for my home directory on my desktop
[15:57] <cmaloney> md mirror
[16:08] <jrwren> synology is great. It is what I modeled my current LVM usage after.
[16:08] <jrwren> I guess the real question I have is: am I ready for zfs and is it ready for me?
[16:09] <jrwren> its too big an unknown. I think I'll stick with what I know and what works.
[16:21] <Scary_Guy> https://u.cubeupload.com/vAXHZK.png
[16:24] <jrwren> reiserfs it is.
[16:25] <brousch> ohmy
[16:28] <Scary_Guy> I like to look at https://en.wikipedia.org/wiki/Comparison_of_file_systems and compare things listing pros and cons of each.  Also, WTF is NOVA?
[16:29] <Scary_Guy> well, it sounds neat
[17:00] <cmaloney> I'm surprised Andrew Filesystem didn't catch on more
[17:01]  * cmaloney remembers seeing a presentation about Andrew File system at an Ohio Linuxfest and coming out of the presentation even more confused.
[17:10] <Scary_Guy> BTRFS still looks like the best option to me, ZFS/HAMMER are fine too
[17:43] <mrgoodcat> anybody got a mtb light they recommend? broek mine this weekend :(
[17:43] <greg-g> mountain bike?
[17:44] <greg-g> how'd it break?
[17:44] <Scary_Guy> I was just about to ask
[17:44] <mrgoodcat> dropped on the pavement
[17:44] <mrgoodcat> trying to take it off the bike that was mounted on the roofrack
[17:44] <mrgoodcat> butterfingered it
[17:45] <Scary_Guy> ouch, and that ruined it?  I'd avoid that brand
[17:45] <mrgoodcat> well i mean
[17:45] <mrgoodcat> its like a 12 foot drop
[17:45] <mrgoodcat> onto concrete
[17:45] <mrgoodcat> maybe not 12
[17:45] <mrgoodcat> but 9 at least
[17:45] <Scary_Guy> 6 at most probably, I'm taller than most car roofs
[17:46] <mrgoodcat> are you taller than a suburban with a bike on it?
[17:47] <Scary_Guy> I'm close, but probably not bike rack/bike on it no
[17:47] <Scary_Guy> anyway Pelican makes some great lights.  Not for the bike, just in general.  I guess you could duct tape it to the bars though :p
[17:47] <mrgoodcat> how fuckin tall are you?
[17:48] <mrgoodcat> just the truck is 6ft + rack + bike
[17:49] <mrgoodcat>  lol pelican doesn't make any with bar mounts?
[17:49] <mrgoodcat> oh i see they're a hardware brand
[17:49] <mrgoodcat> work lights and such
[17:53] <jrwren> i guess his height at 6'5"
[17:53] <Scary_Guy> close, 6'3"
[17:54] <Scary_Guy> taller than many but still fairly average
[17:54] <jrwren> the hat adds 2 inches?
[17:54] <Scary_Guy> I could probably be a CEO of a company because of my boobs, I mean height
[17:55] <jrwren> or POTUS!
[17:55] <Scary_Guy> also the cowboy boots have about an inch of a heel
[17:55] <Scary_Guy> that too
[17:56] <Scary_Guy> https://www.youtube.com/watch?v=L_vcy7I0zIM
[18:04] <cmaloney> Yeah, Scary_Guy is taller than I am
[18:04] <Scary_Guy> and my dick's bigger too :p
[18:05] <cmaloney> Ahem.
[18:05]  * jrwren points to the CoC
[18:06] <Scary_Guy> chamber of commerce?
[18:06] <jrwren> https://www.ubuntu.com/about/about-ubuntu/conduct
[18:07] <Scary_Guy> https://encyclopediadramatica.rs/Offended :p (nsfw, obviously)
[18:09] <jrwren> I prefer the stephen fry offended diatribes
[18:10] <Scary_Guy> I like Stephen Fry in general
[18:13] <Scary_Guy> http://knowyourmeme.com/memes/welcome-to-the-internet was good too, that rant is legendary
[18:17] <Scary_Guy> https://www.ietf.org/rfc/rfc1855.txt is classic, but outdated.
[18:17] <Scary_Guy> personally I'm very libertarian on things and think the free exchange of ideas is paramount.  Also there is always room for a good joke as long as it's all in good fun
[18:19] <Scary_Guy> but to each their own and I respect the conservative nature of official channels such as this.  this isn't 4chan/reddit after all
[18:20] <cmaloney> ty
[18:20] <jrwren> i was only reminding, not chastizing.
[18:21] <jrwren> no lines crossed, just acknowledging getting close to a grey area.
[18:21] <jrwren> I thought it was a funny joke, but I don't know if everyone would take it the same way.
[18:21] <jrwren> https://www.youtube.com/watch?v=5XOaYMkz5Cc makes me laugh every time.
[18:23] <Scary_Guy> I think most people on IRC are mature enough to see it as such
[19:00] <greg-g> at the same time, it's not the most welcoming of language to non-male-locker-room-desensitized people. :/
[23:56] <jrwren> whoo hoo! new cable modem docsis 3!


[16:36] <thorwil> newz2000: a comment on my blog: "Is there a generic banner we can use on WP.com blogs? It's unfortunate that there's no noscript option like we had for Ubuntu Gutsy, but if there were even a static, generic image that would really helpful for those of us under WordPress' limitations."
[16:36] <newz2000> thorwil: yes, I think the "coming soon" banner would work wouldn't it?
[16:37] <thorwil> newz2000: i guess. once only a few days are left
[16:38] <newz2000> that's surprising that you can't use javascript on your wordpress blog
[16:38] <thorwil> if i insert the line as given, wordpress removes it once i submit
[16:39] <thorwil> no idea if the same is true for wp hosted elsewhere
[16:42]  * thorwil writes comment pointing to appropriate links


[09:39] <rogpeppe> fwereade: i think it's quite straightforward actually
[09:39] <rogpeppe> fwereade: none of the tools-choosing logic is in the provider currently
[09:40] <fwereade> rogpeppe, the tools change? it's probably not *that* big I agree
[09:40] <fwereade> rogpeppe, but it's another environ thing the api needs to know/care about and I'm not currently sure I know how that stuff works
[09:40] <rogpeppe> fwereade: i think it's just a matter of adding some kind of canary tag to an agent's info in the state.
[09:41] <rogpeppe> fwereade: if the api just provided a way to list the available tools, that would be sufficient, i think
[09:42] <fwereade> rogpeppe, I'd rather be able to ask a machine directly what it should be running really
[09:42] <rogpeppe> fwereade: essentially we'd be making environs.FindAvailableTools call a method on state rather than on the provider (it might even take an interface so it could work on both)
[09:43] <rogpeppe> fwereade: i dunno, i don't mind much
[09:43] <fwereade> rogpeppe, we could indeed do it that way too, I think I'd generally  prefer to keep as much of that sort of work behind the API as possible
[09:43] <rogpeppe> fwereade: i quite like the idea that an agent can choose how to upgrade itself.
[09:44] <fwereade> rogpeppe, maybe it has advantages I'm not seeing
[09:45] <rogpeppe> fwereade: it's more flexible and it's very similar to the current system, so less churn. it may be more flexible than we need, i dunno.
[09:46] <rogpeppe> fwereade: i can see the upgrade path more clearly in my head this way
[09:46] <rogpeppe> fwereade: but that's probably just me being fuzzy headed :-)
[09:47] <fwereade> rogpeppe, we'll see how it looks when we actually implement it, that usually forces an extra dose of perspective
[09:47] <rogpeppe> fwereade: indeed
[09:48] <rogpeppe> fwereade: i'm hoping we can avoid too many semantic changes as we move towards using the API - they can happen later, i think.
[09:49] <fwereade> rogpeppe, agreed in principle at least, I just don't think we can get away with *none*
[09:49] <rogpeppe> fwereade: we'll see, i guess.
[09:49] <rogpeppe> fwereade: i'm hoping for none, but there will probably be some necessary.
[12:01] <ahasenack> hi guys, how do you update all the branches that go get fetched and placed in $GOPATH/src/*? go get doesn't seem to update
[12:02] <ahasenack> you just go into each one and bzr pull / git pull / hg whatever?
[12:03] <dimitern> ahasenack: either that, or use go get -u project-import-path/... - will fetch and update the project and all dependencies
[12:03] <ahasenack> dimitern: ah, cool, -u is what I was looking for, thanks
[13:16] <rogpeppe> "The engineers onside have advised that due to the severity of the damage they have to supply a revised fix date. They have confirmed that it is now 03/05/2013."
[13:16] <rogpeppe> looks like my internet is going to continue to be knackered for a while yet then
[13:18] <rogpeppe> it will have been dead for two weeks tomorrow :-(
[13:24] <TheMue> rogpeppe: at least you'll have hope that it is fixed when we're returning from oakland
[13:24] <mgz> good thing you won't be there next week rogpeppe
[13:25] <rogpeppe> that is true
[13:25] <rogpeppe> not sure carmen will be very happy with no skype calls tho'
[13:25] <rogpeppe> not to mention no bbc iplayer :-)
[13:26] <mgz> :)
[13:26] <TheMue> :)
[13:27] <rogpeppe> my phone has been a very busy gateway these last weeks
[13:27] <rogpeppe> mobile hotspot ftw
[13:54] <rogpeppe>  if anyone fancies a non-juju review, here are the first two branches of the new godeps tool: https://codereview.appspot.com/9016043/ https://codereview.appspot.com/9047043/
[14:14] <hazmat> rogpeppe,  to avoid the working copy not pointed to master.. ideally you could detect origin/remote to see if its a non default checkout/branch, also a IsModified to check working copy for changes, abort in both cases
[14:15] <mgz> hazmat: right.
[14:17] <hazmat> fwiw, here's my take atm on a similiar problem, i don't have the branch/origin detection yet though. IsModified was  little tricky with bzr non current revs via the cli, i ended up using it as a lib.. http://bazaar.launchpad.net/~hazmat/juju-deployer/refactor/view/head:/deployer.py#L392
[14:19] <rogpeppe> hazmat: in a call
[14:32] <rogpeppe> hazmat: does it really matter if the working copy isn't pointed to master?
[14:33] <mgz> rogpeppe: yes, as we were talking about yesterday
[14:34] <mgz> you can make work-in-progress hard to recover (and probably without much sign it's been unlinked)
[14:34] <rogpeppe> fwereade: is the relation-list CL fixing a bug? it seems to me the change just removes an optional argument. is that right?
[14:34] <fwereade> rogpeppe, it drops the arg and uses a flag insteam
[14:34] <fwereade> er instead
[14:35] <rogpeppe> fwereade: oh yes, i'd missed the fact it wasn't using Var before
[14:38] <rogpeppe> mgz, hazmat: istm that if we make it easy for the user to restore things as they were (for instance by printing the godeps before the modification) then it's not too bad a problem
[14:38] <mgz> that doesn't help overwriting the head of someone's in-progress feature branch
[14:39] <rogpeppe> mgz: we wouldn't overwrite any work that couldn't be restored easily
[14:40] <mgz> rogpeppe: try it.
[14:40] <rogpeppe> mgz: ok, i will. what's the exact scenario you have in mind, so i can try it?
[14:43] <mgz> `bzr switch -b feature && bzr commit --unchanged -m "Important work, really" && ???`
[14:43] <mgz> we're pretty careful about not chucking stuff away, but you can easily confuse people
[14:45] <rogpeppe> mgz: what work will be lost there if we do "bzr update -r revid:something" ?
[14:45] <mgz> the question is, what steps do you do to restore your feature branch?
[14:46] <hazmat> rogpeppe, in the absence of certainity refuse the temptation to guess, if its modified or non pointing to the origin, bailing is the simplest correct thing to do
[14:46] <rogpeppe> hazmat: i'm just wondering about the "non pointing to the origin" thing here. what's the "origin" when you're using git for example?
[14:47] <mgz> (answer: `bzr update` and perhaps `bzr revert` if there were conflicts, but you need to notice and do those steps to recover,
[14:47] <mgz> and, it's different for each vcs)
[14:47] <hazmat> rogpeppe, default remote master
[14:48] <rogpeppe> mgz: will "bzr update revid:foo; bzr update revid:bar" not always end up with revid:bar ?
[14:48] <mgz> yes, but you don't know the state of the tree after doing those two commands
[14:48] <rogpeppe> mgz: insert -r's as appropriate
[14:48] <mgz> (the first will helpfully fail if the branch doesn't actualyl contain the revision at least)
[14:49] <rogpeppe> mgz: oh. i thought the point of "bzr update -r revid:x" was to change the tree to update to revid:x.
[14:49] <mgz> also, git does GC and things, so I don't think you can trust a dangling head will persist for ever
[14:49] <rogpeppe> mgz: what other state might the tree end up in?
[14:50] <rogpeppe> mgz: that's an interesting point.
[14:50] <rogpeppe> mgz: although hopefully it won't be a dangling head, right?
[14:50] <rogpeppe> mgz: it should be part of the history, and if it's not you should be able to fetch it with go get -u.
[14:51] <rogpeppe> mgz: oh, i see
[14:51] <rogpeppe> mgz: you mean the user's dangling head
[14:51] <rogpeppe> mgz: hmm
[14:51] <mgz> rogpeppe: my feature branch removes file X. trunk changes file X. you update my feature branch to trunk... what is X? you update again back to the head rev from the feature branch... what is X?
[14:52] <rogpeppe> mgz: doesn't a given revid specify file X absolutely?
[14:52] <mgz> bzr answer: conflict, you have both varients present in the tree and need ot resolve (or use `bzr revert` to just wipe state back to the current selected rev)
[14:53] <mgz> sure, but update is really a three way merge when history has diverged
[14:54] <mgz> it's not a "wipe everything and switch to this"... because that's less safe (and has a different spelling)
[14:54] <rogpeppe> mgz: naively, i'd have thought that X after updating to trunk would be X as changed in trunk (newly created); updating back to the head rev would remove it again.
[14:54] <rogpeppe> mgz: but you're saying that's not the case?
[14:54] <mgz> nope.
[14:55] <rogpeppe> mgz: this destroys my faith in vcs's :-)
[14:55] <mgz> it should help encourage you, otherwise your un-landed changes would be much easier to accidentally lose
[14:56] <mgz> (and are I think, in one spelling of this people use with git)
[14:57] <rogpeppe> mgz: i always thought that, given a clean tree, rm -r *; bzr update revid:x; would be semantically the same as bzr update revid:x (but faster)
[14:57] <rogpeppe> mgz: i still don't quite see where the conflicts come in
[14:57] <mgz> it is not.
[14:58] <rogpeppe> mgz: pardon my lack of vcs-fu
[14:58] <mgz> hg handles the same situation by refusing to update to a non-descendant
[14:58] <rogpeppe> mgz: or ancestor?
[14:59] <fwereade> rogpeppe, dimitern: a thought about charm config changes on upgrade-charm
[15:00] <dimitern> fwereade: yeah?\
[15:00] <fwereade> rogpeppe, dimitern: when a setting type changes, is it *really* any better for us to barf than to just ignore it?
[15:00] <fwereade> rogpeppe, dimitern: if we ignore it we just get the default
[15:00] <rogpeppe> fwereade: i think so
[15:00] <dimitern> fwereade: sgtm
[15:01] <rogpeppe> fwereade: it's an incentive for charm authors to keep things compatible by only adding compatible settings
[15:01] <fwereade> rogpeppe, but *actual* compatibility is more than just the type
[15:02] <rogpeppe> fwereade: sure. the new charm must declare all the old settings, right?
[15:02] <fwereade> rogpeppe, nope, we just discard ones that are now irrelevant
[15:02] <fwereade> rogpeppe, maybe *that* is crazy
[15:02] <rogpeppe> fwereade: so you're proposing that there are no charm settings compatibility rules at all?
[15:02] <fwereade> rogpeppe, but I don;t *think* so
[15:02] <rogpeppe> s/there are/there should be/
[15:03] <fwereade> rogpeppe, the only one that was ever mooted was the type one, and I'm struggling to see what value it delivers
[15:03] <fwereade> rogpeppe, delete is fine and add-new is fine
[15:03] <rogpeppe> fwereade: i thought it was stronger than that. i think that the new charm should declare all the old settings and they should be of the same type.
[15:04] <fwereade> rogpeppe, so if a newer version of a charm adds some smarts that render some option irrelevant, it has to carry them forever?
[15:04] <rogpeppe> fwereade: yeah. that's compatibility for you.
[15:04] <fwereade> rogpeppe, I don;t think that's helpful
[15:05] <rogpeppe> fwereade: i think that settings are a good indicator of compatibility. relations not nearly so much.
[15:05] <fwereade> rogpeppe, this means that there's never any incentive to make a charm smarter -- once there's a config setting, the charm author either has to support it forever and allow it to override (complex) or just ignore a published config setting (evil)
[15:05] <fwereade> rogpeppe, the relations *are* a hard constraint
[15:06] <rogpeppe> fwereade: yes, but loads of very different charms declare the same relations, right?
[15:06] <fwereade> rogpeppe, allowing a charm upgrade to break an existing relation is I think clearly not ok
[15:06] <rogpeppe> fwereade: agreed. but my point is that's not a very strong constraint
[15:06] <fwereade> rogpeppe, yeah, that's inevitable
[15:07] <fwereade> rogpeppe, --switch has valid use cases, but they are tiny islands of sanity in a great ocean of borken
[15:07] <rogpeppe> fwereade: i think that specifying settings compatibility makes the islands substantially larger
[15:07] <fwereade> rogpeppe, it just feels like walling off one tiny area of the borkenness and saying "this is really really bad" should probably be justified a bit more strongly
[15:08] <fwereade> rogpeppe, what is the benefit of not allowing config settings to be deleted?
[15:08] <rogpeppe> fwereade: how about an explicit "deprecated" type?
[15:09] <rogpeppe> fwereade: so you can upgrade to deprecated and deprecated settings can be deleted.
[15:09] <fwereade> rogpeppe, but we still have to carry "deprecated" forever, and I don't see who's helped by this
[15:10] <rogpeppe> fwereade: that gives charm authors a path to deleting settings.
[15:10] <fwereade> rogpeppe, I don't see how it improves on just deleting the settings straight off
[15:11] <rogpeppe> fwereade: it means we have much greater confidence that we're not upgrading to a totally unrelated charm
[15:11] <fwereade> rogpeppe, ah, sorry, you're proposing that we validate the two charms' schemas against one another
[15:12] <rogpeppe> fwereade: isn't that essentially what we're currently doing?
[15:12] <rogpeppe> fwereade: except we only validate some relations
[15:12] <fwereade> rogpeppe, no, we just validate the old settings against the new schema as forgivingly as possible, *apart* from the types
[15:12] <fwereade> rogpeppe, for config
[15:13] <fwereade> rogpeppe, and for relations, we validate only that the relations the charm is currently in can continue to exist
[15:13] <fwereade> rogpeppe, --switch is a great big gun that can blow your whole leg off ;)
[15:14] <rogpeppe> fwereade: here's another much simpler validation scheme: just check that charm.Meta.Name() is the same
[15:14] <rogpeppe> fwereade: and the relation check too
[15:15] <fwereade> rogpeppe, previously considered and discarded, the name is just a heuristic
[15:16] <rogpeppe> fwereade: aren't heuristics exactly what we're playing at here?
[15:16] <fwereade> rogpeppe, I'm more concerned about --switch not allowing something that's sane than about it allowing something that's insane
[15:16] <fwereade> rogpeppe, the only sanity I think we can legitimately care about is that which maes our own internal state invalid
[15:16] <rogpeppe> fwereade: i think that people will play by the rules we write
[15:16] <fwereade> rogpeppe, everything else is in the hands of the person who hopefully knows well enough what they're doing
[15:17] <rogpeppe> fwereade: i think some sanity checks are really useful here. it's so easy to type a wrong url
[15:17] <rogpeppe> fwereade: and the settings compatibility checks seem like a Good Thing to me
[15:17] <rogpeppe> fwereade: it's not hard to comply with them
[15:18] <rogpeppe> fwereade: compatibility rules that say you can change something you already support are quite usual
[15:19] <teknico> hi, I'm debugging the juju-gui charm and trying to manually run the config-get command, where do I get the client id it needs?
[15:19] <rogpeppe> fwereade: but i think it's perfectly reasonable to say that the charm name is the lynchpin of compatibility
[15:19] <rogpeppe> fwereade: heuristic or not. (well, we make it non-heuristic by attaching some semantics to it, i think)
[15:20] <fwereade> teknico, sorry, it's basically impossible... well, not *impossible*, but definitely impractical
[15:20] <fwereade> teknico, will a CLI get not help?
[15:22] <rogpeppe> mgz: ah, a non-descendant of the same root, i suppose
[15:22] <teknico> fwereade, what's a CLI get?
[15:22] <fwereade> rogpeppe, `juju get myservice [configkey]`
[15:22] <rogpeppe> teknico: ^
[15:22] <fwereade> er teknico ^^
[15:23] <mgz> right, it basically refuses to deal with the three-way merge case (which is reasonable)
[15:23] <mgz> though it will still screw you over if you have uncommitted changes and don't pass a flag to abort on that too
[15:24] <teknico> fwereade, yes, it does, thank you
[15:25] <fwereade> teknico, sweet
[15:27] <fwereade> rogpeppe, I'm still not following how your proposed checks solve user problems
[15:28] <fwereade> rogpeppe, I am taking as an idealistic axiom that charms should work correctly with all-default values, which I know is not strictly true, but I have no interest in making it any easier to deploy charms that are broken by default
[15:28] <fwereade> rogpeppe, we don't have the ability to track a charm's provenance, and I'm not sure we want to disallow the possibility of one charm being a drop-in replacement for another
[15:28] <rogpeppe> fwereade: does the install hook get called again when a charm is upgraded?
[15:29] <fwereade> rogpeppe, no
[15:29] <rogpeppe> fwereade: well then. charms should work correctly when *installed from scratch with all-default values*.
[15:29] <rogpeppe> fwereade: but starting from the middle, probably not
[15:30] <fwereade> rogpeppe, what is the value to users in disallowing a --switch to an arbitrary charm? ISTM that we simply *cannot* know for sure that the user is doing something crazy *except* when existing relations do not match
[15:31] <fwereade> rogpeppe, I feel like --switch is an implicit "I know what I'm doing" to which the only acceptable failure is "that action is impossible" rather than "that action appears to be bloody stupid" ;)
[15:32] <rogpeppe> fwereade: ISTM that with such a potentially dangerous feature, we should at least have some sanity checking
[15:32] <fwereade> rogpeppe, on the other side, when we're upgrading from the same base url, I don't see any value to fossilizing the config
[15:33] <rogpeppe> fwereade: yeah, maybe. i'd like to speak to a real user about this issue.
[15:34] <Makyo> I'm getting a bunch of panics around mongo when running tests in trunk and out of ideas.  I'm on raring, think that might make a difference?
[15:35] <rogpeppe> Makyo: paste?
[15:36] <fwereade> m_3, rogpeppe and I would be interested to know (1) what level of safety you will require around upgrade-charm --switch and (2) your views on how liberal we should be wrt config conversion at upgrade-charm time (with or without --switch)
[15:36] <rogpeppe> fwereade: the user problem i'm imagining is: juju upgrade-charm --switch wordpress # oops, i meant to type one of the dozen other charms that happened to have db and http relations declared.
[15:37] <Makyo> rogpeppe, http://pastebin.ubuntu.com/5619482/
[15:37] <rogpeppe> fwereade: perhaps we should do compatibility checks by default, but provide a --force flag to override them
[15:37] <fwereade> rogpeppe, I think that if you're using --switch you have a bit of extra responsibility to switch to things that are sane
[15:37] <fwereade> rogpeppe, hmm, --force-url?
[15:38] <fwereade> rogpeppe, --force's pre-existence is irritating
[15:38] <rogpeppe> fwereade: what's the name of the flag currently?
[15:38] <fwereade> rogpeppe, there isn't one
[15:38] <fwereade> rogpeppe, it's to support a use case originally reported by m_3
[15:39] <fwereade> rogpeppe, it's --switch but nothing has been released with that flag
[15:39] <rogpeppe> fwereade: oh, darn, i'd forgotten about the existing --force
[15:39] <fwereade> rogpeppe, wrt config changes I am not confident, apart from anything else, that every existing charm is compatible with every version of itself
[15:40] <rogpeppe> fwereade: it's highly unlikely to be.
[15:40] <fwereade> rogpeppe, so additional checking breaks upgrades that worked before
[15:40] <fwereade> rogpeppe, we could probably get away with that ofc
[15:40] <rogpeppe> fwereade: but we can probably make the default (non-forced) behaviour reasonably safe
[15:41] <fwereade> rogpeppe, what is unsafe about using default values for removed or incompatible settings?
[15:41] <rogpeppe> fwereade: just that settings are the only decent indicator that we have of whether a charm really is the same
[15:42] <fwereade> rogpeppe, charms *ought* to work with default settings, and if they don't I think I am comfortable calling it a charm bug
[15:42] <fwereade> rogpeppe, if it's from the same base charm url we have a pretty good indicator already I think
[15:42] <fwereade> rogpeppe, and --switch is a big-boy tool
[15:42] <rogpeppe> fwereade: charms will probably work with default settings, but if you upgrade to a random charm, it will probably not work, because its install hook has never been called
[15:43] <fwereade> rogpeppe, right, so be careful with --switch
[15:43] <rogpeppe> fwereade: we seem to have switched our usual roles here :-)
[15:44] <rogpeppe> fwereade: what's wrong with using the charm name again?
[15:44] <fwereade> rogpeppe, I was pondering that, and I *think* I'm consistent: sync-tools is a *necessity* for a broad class of users, while --force-url (which I think is better than --switch) is a nice feature for a small group of particularly technical users
[15:45] <fwereade> rogpeppe, what does it get us? in the normal case it's redundant, in the --force-url case it's an arbitrary safety guard covering part of one blade on an infernal machine ;)
[15:45] <rogpeppe> fwereade: nice features like that have a tendency to be picked up and used by everyone :-)
[15:45] <rogpeppe> fwereade: yeah - it's like a safety catch
[15:46] <rogpeppe> fwereade: it's easy to disable, but useful nonetheless
[15:46] <fwereade> rogpeppe, on one barrel of a terrifying scifi multicannon ;)
[15:46] <fwereade> rogpeppe, if the nuke doesn't get you the CAM dusting will
[15:46] <rogpeppe> fwereade: that bad?
[15:47] <rogpeppe> fwereade: why do we have a charm name anyway?
[15:47] <fwereade> rogpeppe, well, yeah, there is an arbitrarily large number of ways a charm can be irreparably broken despite all our checks here
[15:48] <rogpeppe> fwereade: i see the mooted charm name check as a symbolic check more than anything
[16:41] <rogpeppe> stupid python question: how do i easily find the source for a given python package?
[16:41] <rogpeppe>  i'm about to do find / -name pythonpackage, and i'm sure there's a better way
[16:41] <benji> rogpeppe: import foo; foo.__file__
[16:41] <benji> (it will normally return a .pyc, just drop the "c" to get the source)
[16:42] <ahasenack> or foo.__path__ if it's a module
[16:42] <rogpeppe> benji: bingo, thanks
[16:42] <benji> my pleasure
[16:53] <rogpeppe> mgz, hazmat: i'm thinking that my proposed godeps -u is at least no more dangerous than go get -u, is it?
[16:53] <rogpeppe> mgz, hazmat: leaving aside for the time being whether that's sufficiently safe or not
[16:54] <mgz> go get -u is indeed a similar thing.
[16:58] <rogpeppe> mgz: ha, trying your suggested scenario from before: http://paste.ubuntu.com/5619713/
[17:01]  * rogpeppe has reached eod
[17:02] <rogpeppe> g'night all
[17:02] <mgz> rogpeppe: right, it's not a sane thing to do with that bzr model
[18:30] <marcoceppi> So, does juju-core have the ability to upgrade the current environment in place?
[18:50] <mramm> marcoceppi: it does
[18:51] <mramm> marcoceppi: it currently is limited to minor version upgrades (1.10 to 1.11 for example)
[18:51] <mramm> marcoceppi: but we will be adding major version upgrades in one of the very next minor version releases
[18:52] <marcoceppi> mramm: at a high level, how does it work? is there a juju command for it - or is it just automagic
[18:53] <mramm> there is a command
[18:53] <mramm> so you get to control when the update happens
[18:53] <marcoceppi> cool, good enough for me
[18:53] <marcoceppi> thanks
[19:39] <m_3> fwereade: sorry I missed the question about --switch earlier... conferencing atm
[19:39] <fwereade> m_3, no worries
[19:39] <fwereade> m_3, if you have leisure to read a spot of the conversation that went before, for context, I would be interested to know your thoughts
[19:40] <m_3> I'm wondering if specific charm version should be shown and then specified, but lemme read a bit more carefully
[19:42] <fwereade> m_3, we have a separate --revision, which just updates to the specified revision of the charm a service is already using
[19:42] <fwereade> m_3, we probably don't output "upgraded from %s to %s", and surely should
[19:44] <m_3> fwereade: yes... I'd almost conider the revision part of the charm namespace
[19:45] <fwereade> m_3, not sure what you mean by namespace -- but whenever we describe a charm we should certainly include the rev
[19:46] <m_3> fwereade: but anyways... in answer to the orig question, I think that if the user is specifying both the service and the namespace of the new charm explicitly
[19:46] <m_3> then a '--force' variant is not nec
[19:47] <m_3> fwereade: namespace would mean cs:mysql:5 or local:mysql:37
[19:47] <m_3> but not really important
[19:47] <m_3> fwereade: should work to have `juju upgrade-charm --switch local:mysql my_database_service`
[19:48] <fwereade> m_3, that's the use case I had in mind
[19:48] <m_3> and then the equiv `juju upgrade-charm --switch --revision 5 cs:mysql my_database_service`
[19:48] <m_3> the "cs:mysql" could be "mysql" of course
[19:48] <fwereade> m_3, the idea is that charm urls are inferred just as they would be at deploy time
[19:48] <m_3> and --revision optional
[19:49] <m_3> ack
[19:49] <fwereade> m_3, we currently have it that --switch and --revision are mutually exclusive
[19:49] <fwereade> m_3, seemed simpler all round
[19:49] <fwereade> m_3, if you're switching, specify the url properly :)
[19:49] <m_3> but 1.) still service-specific, and 2.) the presence of '--switch' is enough checking imo
[19:49] <fwereade> m_3, if you skip revision, you get latest, which is probably what you meant
[19:50] <m_3> fwereade: hmmm.... as to mutially exclusive...
[19:50] <fwereade> m_3, --switch foo-1 --revision 2
[19:50] <m_3> oh, so I only am able to switch from local to the latest store rev?
[19:50] <fwereade> m_3, no -- you specify the target charm as precisely as you care to in switch
[19:51] <m_3> but how can I specify target charm revision?
[19:51] <m_3> other than with '--revision'
[19:51] <m_3> oh, just `juju upgrade-charm --revision 5 mysql my_database_service`
[19:51] <fwereade> m_3, `--switch foo-1` will be expanded just as it would in deploy to cs:precise/foo-1
[19:52] <fwereade> m_3, I have clearly not explained well at all
[19:52] <fwereade> m_3, no args: latest with same base url
[19:52] <m_3> sorry, I'm a bit confused as to how one switches _back_ to the store-based charm
[19:56] <m_3> scenario... `juju deploy mysql` gives me cs revision 5 say
[19:56] <m_3> find a bug... update local:mysql.. then switch with
[19:56] <m_3> sorry... lemme fix the previous
[19:56] <m_3> scenario... `juju deploy mysql mydb` gives me cs revision 5 say
[19:56] <m_3> now
[19:56] <m_3> `juju upgrade-charm --switch local:mysql mydb`
[19:56] <m_3> the fix didn't work... so I revert
[19:56] <m_3> but I'd like to revert to mysql '4' in the cs
[19:56] <m_3> what would the syntax for this be?
[19:56] <m_3> (if the answer is you can only revert back to the latest in the charm store, that's fine)
[19:56] <m_3> but does that "switch" require a '--switch'?
[19:56] <fwereade> m_3, `--switch mysql` for the latest; `--switch mysql-127` for a specific rev
[19:56] <fwereade> m_3, similarly `--switch local:mysql` or `--switch local:mysql-17`
[19:56] <fwereade> m_3, balls, thought of a bug, we might infer the wrong series
[19:56] <fwereade> m_3, we should take it from the previous charm url, not from the env
[19:56] <fwereade> dimitern, ^
[19:57] <m_3> fwereade: ack... perfect
[19:58] <m_3> fwereade: also not effecting 'myotherdb' service happily singing along on cs:mysql-5, right?
[19:58] <fwereade> m_3, shouldn't do -- there is the usual hairiness around local repos but I think it's near-enough orthogonal
[19:59] <m_3> fwereade: ack... thanks!  (and thanks roger)
[21:25] <thumper> mramm: did you plan some 1:1 calls?
[21:26] <mramm> yea
[21:26] <mramm> I do
[21:26] <mramm> I just found out an hour ago that I need to get all the blueprints in by tomorrow morning
[21:26] <mramm> so I am madly working on that stuff right now
[21:26] <mramm> but I should probably take a break and schedule the 1 on 1's or the tyranny of the urgent will get me ;)
[21:27] <thumper> :)
[21:49] <mramm> thumper: added one for you
[21:49] <mramm> already talked to dave on sunday night, but going to touch base again if he's around
[21:53]  * thumper nods
[23:32] <davecheney> mramm: ping, you sent me a meeting invite for 45 mins ago