[00:00] <wallyworld_> axw_: question, we volumes are listed, i would expect that we'd want to see the unit and storage name to which the volume may be attached, so that we can see this 100GB volume here serves the data-dir storage for mysql/0, right?
[00:00] <wallyworld_> at the moment, the PR just shows storage tag
[00:22] <redelmann> hi, im having some strange problem after " juju upgrade-juju --version 1.23-beta2"
[00:23] <redelmann> all units are loging "unit-mongodb-production-0[25074]: 2015-03-31 00:22:51 ERROR juju.worker runner.go:219 exited "uniter": failed to initialize uniter for "unit-mongodb-production-0": cannot read "/var/lib/juju/agents/unit-mongodb-production-0/state/uniter": invalid operation state: unexpected hook info with Kind Continue"
[00:34] <redelmann> ok, now stop working :P
[00:49] <axw_> wallyworld_: volumes are machine-level, hence we see machine attachment. you could argue that since we know the assigned storage instance, we could also show the unit-storage attachments... but we have "juju storage show" if people really want to see that
[00:49] <wallyworld_> axw_: i think that distinction will be lost on the user
[00:50] <wallyworld_> storage will also show fs etc
[00:51] <wallyworld_> if i list volumes, i'd like to see where they're attached (ie what unit) if i were a user
[00:51] <wallyworld_> s/attached/in use
[00:51] <axw_> wallyworld_: I'm not opposed to adding an optional UNIT column
[00:52] <wallyworld_> ok, let's do it
[00:52] <wallyworld_> we could if required (which i'm not sure we will be) add a CLI flag to exclude/include volumes attached to units
[00:56] <wallyworld_> redelmann: i'm not sure what's happened with your upgrade, can you raise a bug and attach as many logs as possible from the affected machine
[01:12] <redelmann> wallyworld_: ok
[01:13] <wallyworld_> redelmann: the error is an internal one that indicates that something got out of sync, but we'd need more info
[01:14] <redelmann> wallyworld_: im collecting log from machine-0
[01:14] <wallyworld_> even if you zip the /var/log/juju dir
[01:15] <wallyworld_> but we'd need logs from the machine running the affected unit
[02:00] <redelmann> wallyworld_, where i can send logs?
[02:00] <wallyworld_> redelmann: attach them to the bug
[02:24] <jw4> redelmann: that looks like an upgrade issue where the upgrade steps for 1.23 didn't run.  Let me know when you've created the bug and attached the logs
[02:25] <jw4> (one of the upgrade steps)
[02:26] <redelmann> jw4: ok, first im trying to remove "some way" upgrade from mongo in machine0, need this running for today :P
[02:26] <jw4> thanks redelmann
[02:26] <redelmann> jw4, i keep a copy of log for bug
[02:26] <jw4> gracias
[02:26] <redelmann> jw4: thank to you
[02:27] <axw_> wallyworld_ thumper: pyfmt - https://plus.google.com/+EliBenderskyGplus/posts/SzKrvzvUuyc
[02:28]  * thumper looks
[02:28] <axw_> I can't see it being as effective as gofmt, since whitespace matters in Python
[02:29]  * thumper guesses yet another python fromatter
[02:29] <axw_> indeed :)
[02:29] <thumper> yeah, first paragraph
[02:29] <wallyworld_> can't have too many
[02:30] <thumper> axw_: interesting
[02:30] <thumper> I want a js version too
[02:30] <thumper> resharper does a good job with visual studio
[02:30] <thumper> and C#
[02:44] <redelmann> axw_, wallyworld_ : https://bugs.launchpad.net/juju-core/+bug/1438489
[02:44] <mup> Bug #1438489: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489>
[02:45] <redelmann> sorry axw_: that no was for you
[02:45] <redelmann> jw4: https://bugs.launchpad.net/juju-core/+bug/1438489
[02:45] <jw4> thanks redelmann :)
[02:45] <axw_> np
[02:45] <redelmann> tellm if you need more details, and how to get it.
[02:46] <redelmann> now im going to keep trying to remove upgrade from ¿queue? mongo
[02:47] <jw4> redelmann: I don't see that error in that log
[02:47] <jw4> redelmann: do you have other logs?
[02:47] <redelmann> jw4, that error is in "juju debug-log"
[02:47] <jw4> redelmann: I see
[02:47] <redelmann> cant run debug-log again, it stuck
[02:48] <jw4> seems like that text should be in one of the other log files under ~/.juju/
[02:48] <redelmann> that's why im looking in machine0 logs
[02:49] <jw4> that error would have come from one of the units; what other machine logs do you have under ~/.juju ?
[02:49] <redelmann> jw4, i cant see any log in ~/.juju/
[02:49] <redelmann> jw4, all unit say the same
[02:50] <redelmann> jw4, actually im deploying to aws
[02:50] <jw4> redelmann: ya, I see that environment
[02:50] <redelmann> jw4, juju keep log in ~/.juju if deploying to aws?
[02:51] <jw4> redelmann: I think it'd be on the machine that's having trouble upgrading
[02:58] <jw4> redelmann: how many machines do you have deployed?
[02:59] <redelmann> jw4, seven
[02:59] <jw4> redelmann: which machine is unit-pgsql-medium-0 on?
[03:00] <jw4> redelmann: also, machine-0 should have all-machines.log in the /var/log/juju folder
[03:01] <redelmann> jw4, you are right
[03:01] <redelmann> give me a second
[03:02] <jw4> redelmann: certainly, thanks!
[03:02] <redelmann> im scping it
[03:02] <mup> Bug #1438489 was opened: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489>
[03:04] <redelmann> jw4, im uploading complete file, this happend today.
[03:04] <jw4> redelmann: thanks; I'll review that.  I'm going to be out for 30 minutes or so, but I'll brb
[03:06] <redelmann> jw4, ok, i attached it to https://bugs.launchpad.net/juju-core/+bug/1438489
[03:06] <mup> Bug #1438489: juju stop responding after juju-upgrade <juju-core:New> <https://launchpad.net/bugs/1438489>
[03:06] <jw4> thanks
[03:10] <davecheney> cherylj: do you need some reviews done ?
[03:16] <davecheney> OH MY GOD
[03:16] <davecheney> why does juju depend on ajstarks/svgo !?!?
[03:16] <davecheney> how is that possibly necessary for the core operation of juju ?
[03:23] <wallyworld_> axw_: only if you feel like it/have time, there's a juju status review which is the first 3 or so branches which would be good to get looked at http://reviews.vapour.ws/r/1334, otherwise i'll bug william when he's net online
[03:24] <axw_> wallyworld_: just started looking, it's quite involved. I'd like to get some of my stuff proposed, hope to take a look later on
[03:24] <wallyworld_> sure np
[03:24] <wallyworld_> i an talk you through anything if needed
[03:25] <wallyworld_> i'll have another proposed straight after, and then a 3rd hopefully later today
[03:27] <redelmann> jw4, ok, i "fix" it
[03:30] <redelmann> jw4, http://paste.ubuntu.com/10710367/
[03:30] <redelmann> jw4, after that it upgrade fine
[04:55] <redelmann> so, it keep saying cannot read "/var/lib/juju/agents/unit-xxx-0/state/uniter": invalid operation state: unexpected hook info with Kind Continue
[04:55] <jw4> redelmann: yeah
[04:55] <redelmann> jw4, but now i can juju status ;)
[04:56] <jw4> the basic issue is that in 1.23 the uniter does not expect there to be hook information in the uniter state except when it's actually running a hook
[04:56] <redelmann> jw4, any workaround? like deleting /var/lib/juju/agents/unit-xxx-0/state/uniter?
[04:56] <jw4> redelmann: the upgrade steps were supposed to remove the unnecessary hook info from the uniter state file, but apparently it didn't work
[04:57] <jw4> redelmann: if you can find the uniter state file (yaml) and just delete the hook and then restart the uniter, it *might* fix it :)
[04:58] <redelmann> jw4, i will try
[05:00] <jw4> redelmann: it should just be called uniter I believe
[05:01] <redelmann> mh...
[05:01] <redelmann> filter.go:137 cannot retrieve meter status for unit ganglia/0: not found
[05:02] <redelmann> maybe writing a working uniter
[05:02] <jw4> redelmann: I'm not sure about that one (possibly upgrade related too, but I'm not familiar with that part)
[05:02] <redelmann> jw4, thats happend after deleting uniter file
[05:02] <jw4> redelmann: oh. yeah.  I wouldn't delete the uniter file
[05:02] <redelmann> jw4, this one: /var/lib/juju/agents/unit-xxx-0/state/uniter
[05:03] <redelmann> oh
[05:03] <jw4> redelmann: inside that file there should be a line (in yaml format) signifying the hook
[05:03] <jw4> if you just update the yaml so there is no hook key/value
[05:03] <jw4> that *might* work
[05:06] <jw4> redelmann: unfortunately it's past my bedtime, and my wife has been waiting for me to come to bed for 45 minutes now :(
[05:06] <jw4> redelmann: :) I'll check in again in the morning
[05:06] <redelmann> jw4, thank you
[05:06] <redelmann> jw4, have a good night
[05:07] <jw4> thanks redelmann you have a great morning/afternoon/night day :)
[06:23] <mattyw> morning everyone
[07:44] <tasdomas> dimitern, thanks for going through my reviews, much appreciated
[07:45] <dimitern> tasdomas, no worries
[07:45] <dimitern> tasdomas, aren't you ready to graduate btw ? :)
[07:46] <tasdomas> dimitern, well, that's not really up to me to decide ;-]
[07:46] <dimitern> tasdomas, I think you are, but I'll have a chat with cmars as well
[07:47] <tasdomas> dimitern, but what I find really holding me back in some reviews is lack of knowledge of certain parts of juju
[07:48] <dimitern> tasdomas, that will come in time, but when unsure about some part of the code, you should ask questions :)
[08:00] <voidspace> morning all
[08:00] <dimitern> morning voidspace
[08:00] <voidspace> o/
[08:00] <TheMue> morning o/
[08:07] <TheMue> dimitern: the described network problem isn't visible in the clients log. sadly I cannot grab the log of the VM
[08:07] <TheMue> dimitern: here you can see that downloads from the maas controller fail
[08:09] <TheMue> dimitern: also connections to <IP_ADDRESS> timeout
[08:09] <voidspace> TheMue: o/
[08:09] <TheMue> dimitern: so that's why I think the network setup on the node fails after the changes
[08:09] <TheMue> voidspace: o/
[08:12] <dimitern> TheMue, hmm - can you ssh into the node after it failed and check /var/log/cloud-init-output.log?
[08:12] <TheMue> dimitern: with the written release we've added the gathering of a primary interface out of the lshw data which is used in newCloudinitConfig()
[08:13] <TheMue> dimitern: I'll see if I can
[08:13] <dimitern> TheMue, yes, in order to determine which interface to bind into the juju-br0 bridge at cloud-init initial boot
[08:14] <TheMue> dimitern: yep, this has been with 1.20.12
[08:14] <TheMue> dimitern: only checked back where it has been changed
[08:15] <dimitern> TheMue, yeah, I remember I did this to fix another bug about not using the correct primary interface for the bridge
[08:16] <TheMue> ok, while client is still waiting the new node at least gave up
[08:17] <dimitern> TheMue, ok, I think this can be faked - if getting the ifaceInfo and the primary interface fails, try using "eth0" as primary interface for newCloudinitConfig()
[08:17] <TheMue> now I only have the problem to log in
[08:17] <dimitern> TheMue, maybe the ssh keys where not set?
[08:17] <TheMue> dimitern: same setting as yesterday
[08:18] <TheMue> dimitern: but don't know how far they are distributed to the node
[08:18] <dimitern> TheMue, no, I mean if cloud-init failed to complete for some reason, the ssh keys might not be set on the node
[08:18] <dimitern> TheMue, cloud-init sets the keys
[08:19] <TheMue> dimitern: yep, that could be the reason
[08:19] <TheMue> dimitern: my node dislikes me because I corrupted its data :,(
[08:20] <TheMue> dimitern: :)
[08:20] <TheMue> dimitern: will do the eth0 approach, should be quickly done
[08:21] <dimitern>  TheMue, it's not the node - that's a case of juju not generating the userdata correctly so the node cannot boot properly :)
[08:21] <TheMue> dimitern: damn security, thought we're building OPEN source *rofl*
[08:21] <dimitern> TheMue, try that workaround I suggested - destroy and cleanup to start afresh, then use "eth0" as primaryNIC if lshw cannot be parsed
[08:26]  * TheMue btw loves his MAAS environment
[08:28] <axw_> wallyworld_: published some comments on your PR
[08:37] <TheMue> dimitern: no real change, the missing interface information leads to >> 2015-03-31 08:29:49 DEBUG juju.provider.maas environ.go:807 node "/MAAS/api/1.0/nodes/node-4a6120e6-d6ea-11e4-a9b5-000c2975eaae/" network information: []network.Info(nil)
[08:38] <TheMue> dimitern: already a bit earlier >> 2015-03-31 08:29:49 DEBUG juju.provider.maas environ.go:760 node "/MAAS/api/1.0/nodes/node-4a6120e6-d6ea-11e4-a9b5-000c2975eaae/" has network interfaces map[]
[08:39] <dimitern> TheMue, that could be fine, all it matters is the generated userdata for cloud-init and the node booting ok
[08:39] <dimitern> TheMue, did it finish?
[08:40] <TheMue> dimitern: looks like before, no action anymore on the node while the client is still "deploying" (repeating this log entry until timeout)
[08:40] <dimitern> TheMue, did you use --debug with bootstrap?
[08:41] <dimitern> TheMue, it will help if you can paste the output :)
[08:41] <TheMue> dimitern: yes, that's where those two lines above are coming from
[08:42] <TheMue> dimitern: will create a paste when the timeout is done so that the whole debug log is in
[08:42] <dimitern> TheMue, ok
[08:43] <TheMue> dimitern: the one I've mailed to you is also debug, see the top line how I'm deploying
[08:43] <TheMue> dimitern: fresh-ducks.local is my corrupted node ;)
[08:45] <dimitern> TheMue, hmm.. well it seems to me some more debug logging is needed around newCloudinitUserdata to show what's generated
[08:47] <TheMue> dimitern: will log it
[08:48]  * TheMue just receive a warning by the national weather service, winds will get really strong today :/
[08:56] <voidspace> TheMue: we've had strong winds all night, continuing now
[08:57] <TheMue> voidspace: it will reach its top here between 2 and 6pm, and our neighbor has still two very high trees on her ground which always sway extreme. during the last storm one felt, thankfully not into our direction
[08:59] <mattyw> dimitern, ping?
[08:59] <dimitern> mattyw, hey
[09:01] <dimitern> voidspace, standup?
[09:01] <voidspace> dimitern: omw
[09:27] <mup> Bug #1438590 was opened: juju version tries to make directories and files in my home <landscape> <juju-core:New> <https://launchpad.net/bugs/1438590>
[09:44] <dimitern> dooferlad, so just calling c.SpaceCommandBase.SetFlags(f) in c.SetFlags() works
[10:24] <TheMue> dimitern: String method sadly had same troubles with references as values in map[string]interface{}, so had to use the renderer way
[10:24] <TheMue> dimitern: here is the according output http://paste.ubuntu.com/10711305/
[10:26] <dimitern> TheMue, ok, this looks fine to me
[10:26] <dimitern> TheMue, does it still fail to boot?
[10:26] <TheMue> dimitern: yep, still the same failing behavior
[10:27] <TheMue> dimitern: while when using a not corrupted node it works
[10:27] <dimitern> TheMue, can you try ssh into it?
[10:27] <dimitern> TheMue, while the bootstrap goes on? it should be possible after retrying for a while (might not be possible immediately)
[10:28] <TheMue> dimitern: yes, currently rejected
[10:30] <TheMue> dimitern: still Permission denied (publickey).
[10:31] <dimitern> TheMue, try: ssh -i ~/.juju/ssh/id_rsa ubuntu@IP
[10:32] <TheMue> dimitern: still the same
[10:34] <TheMue> dimitern: at least it's pingable
[10:34] <dimitern> TheMue, can you see the console of the VM ?
[10:34] <TheMue> dimitern: if the ubuntu user would have a standard password I could login directly on the console
[10:35] <dimitern> TheMue, nope, that won't work unfortunately
[10:36] <TheMue> dimitern: I know, sadly
[10:36] <dimitern> TheMue, maybe the VM is still booting - do you see any messages on the console?
[10:37] <TheMue> dimitern: only the login screen
[10:38] <dimitern> TheMue, try with your ssh key configured in maas?
[10:38] <TheMue> dimitern: the last interesting part have been messages that downloads from controller and this 169... failed
[10:38] <TheMue> dimitern: that's what I'm doing, using that key
[10:44] <TheMue> dimitern: I'll bootstrap to a valid node and see what the cloudinit looks there
[10:45] <dimitern> TheMue, did you try both the juju_id_rsa key *any* your key?
[10:46] <dimitern> s/*any*/*and*/
[10:46] <TheMue> dimitern: my key
[10:47] <TheMue> dimitern: http://paste.ubuntu.com/10711389/
[10:47] <dimitern> TheMue, well, that's why I wrote this earlier: <dimitern> TheMue, try: ssh -i ~/.juju/ssh/id_rsa ubuntu@IP
[10:47] <dimitern> TheMue, that's the juju ssh key
[10:48] <TheMue> dimitern: eh, sorry, sure, took it too
[10:48] <dimitern> TheMue, so both you couldn't ssh with either key
[10:49] <dimitern> s/both/both/
[10:49] <dimitern> aargh
[10:49] <dimitern> s/both//\
[10:49] <TheMue> dimitern: hehe, yes
[10:49] <TheMue> dimitern: and you're right, the cloudinit looks similar, only the host names
[11:01] <TheMue> dimitern: I send you a screenshot of the console. does this help to get in? sadly I cannot cut'n'paste, but enter the key by hand
[11:03] <TheMue> wife calls for lunch, bbiab
[11:03] <voidspace> Code comments: https://twitter.com/nzkoz/status/538892801941848064/photo/1
[11:30] <dimitern> voidspace, dooferlad, please have a look - juju subnet CLI http://reviews.vapour.ws/r/1339/
[11:37] <dimitern> TheMue, that screenshot is too small to read, unfortunately
[11:37]  * fwereade swings by quickly to say: sorry sick yesterday, public holiday today, should be around properly later to catch up a bit
[11:45] <voidspace> dimitern: looking after coffee
[11:57] <TheMue> dimitern: hmm, it is sent in full size, strange
[11:59] <dimitern> voidspace, I'm in a call with spakiegeek now investingating an issue with maas and juju
[12:00] <dimitern> voidspace, it seems we're not out of the rabbit hole yet
[12:00] <dimitern> voidspace, I'm getting logs to help debugging the issue
[12:01] <dimitern> voidspace, he'll file a bug with details
[12:02] <dimitern> voidspace, it's a separate issue than the one you fixed, but also revolves around parsing lshw properly
[12:04] <dimitern> TheMue, ah, so it's just that thunderbird is dump - I managed to zoom in using a copy of the screenshot in gimp
[12:05] <dimitern> TheMue, that screen is from too early in the boot process
[12:06] <dimitern> TheMue, we should do a screensharing session I think to diagnose the issue
[12:06] <dimitern> TheMue, it won't work by just describing what you see :)
[12:14] <TheMue> dimitern: just doing some preparations
[12:19] <TheMue> dimitern: so, sent you an invitation, we'll see how it works
[12:19] <dimitern> TheMue, brt
[12:26] <voidspace> dimitern: ah, right :-/
[12:33] <voidspace> dimitern: so after #1339 there will be a "subnets" super command, but it will do nothing?
[12:33] <voidspace> dimitern: wouldn't it be better to add the functionality first and do the CLI as the last bit - or have I misunderstood?
[12:33] <voidspace> "subnet create" anyway
[12:34] <dooferlad> voidspace: the idea is to do CLI before API, so we know what the API needs to provide. We know what commands we want already (see Juju Network Model document)
[12:35] <voidspace> dooferlad: right, but then we're adding public facing brokenness
[12:35] <voidspace> dooferlad: if we know what commands we want, don't we also know what API we need?
[12:35] <dooferlad> voidspace: only to a feature branch
[12:35] <voidspace> ah yes, of course
[12:35] <voidspace> I still prefer to work the other way round
[12:35] <voidspace> then we don't *need* a long lived feature branch
[12:36] <dooferlad> voidspace: We have a pretty good idea about what the API needs to provide, but this way we don't end up designing endpoints that are a bad fit for the code that is using them.
[12:37] <dimitern> voidspace, sorry, in a call again
[12:37] <voidspace> dooferlad: ok
[12:37] <voidspace> dimitern: np
[12:39] <dimitern> voidspace, the CLI returns an error when you try to use it
[12:40] <voidspace> dimitern: well exactly :-)
[12:40] <voidspace> dimitern: CLI commands that do nothing but error out shouldn't exist...
[12:40] <voidspace> dimitern: why do you need the --private option?
[12:41] <voidspace> dimitern: if it's the default it does nothing
[12:41] <voidspace> dimitern: flag I mean
[12:41] <voidspace> specifying it does nothing and it's existence is causing you pain in the code
[12:41] <voidspace> dimitern: why not just have --public ?
[12:42] <dimitern> voidspace, we always went with the approach "state / api first, cli last" and that bit us on more than one occasion
[12:42] <voidspace> dimitern: ok, interesting
[12:42] <voidspace> I'm definitely in favour of *designing* the CLI, just not necessarily implementing it first
[12:43] <dimitern> voidspace, so starting from the CLI with stub API is the new way I'd like to try now
[12:43] <voidspace> but as it's on a feature branch it doesn't matter so much anyway
[12:43] <voidspace> dimitern: ok
[12:43] <dimitern> voidspace, so by the time we reach state /api we already know what's needed
[12:43] <dimitern> voidspace, the --private being the default comes as a requirement from mark
[12:44] <voidspace> dimitern: fine. In that case the "--private" flag is superfluous, it does nothing.
[12:44] <dimitern> voidspace, it's part of the spec though
[12:44] <voidspace> dimitern: just say, "networks are private by default, unless you pass the --public flag"
[12:44] <voidspace> dimitern: heh
[12:44] <voidspace> it does *nothing*
[12:45] <dimitern> voidspace, yeah that's correct
[12:45] <dooferlad> voidspace: well, it is an exciting way of starting an IRC conversation :-)
[12:46] <voidspace> heh
[12:46] <dooferlad> ... just like the name "space"
[12:47] <voidspace> dimitern: other than that (and feel free to drop my issue - I meant it as a comment) it all looks good to me
[12:47] <voidspace> dimitern: mostly boilerplate except for the parameter checking, which all looks fine
[13:02] <dimitern> voidspace, sorry, I'm looking at your review now
[13:03] <dimitern> voidspace, yes, having --private seems redundant, but it's part of the spec
[13:03] <dimitern> voidspace, I'll add a comment
[13:06] <TheMue> A large tree crashed our car, shit. I'm off for some time.
[13:06] <dimitern> TheMue, oh that's bad :(
[13:06] <jw4> TheMue: shoot
[13:07] <jw4> TheMue: after all that felling of trees one still got your car!?
[13:11] <dimitern> TheMue, I hope the damage is not extensive
[13:12] <wallyworld> fwereade: andrew has looked at http://reviews.vapour.ws/r/1334/, it you get time would love it if you could look too
[13:12] <TheMue> the rear is totally crashed
[13:12] <dimitern> TheMue, oh dear :(
[13:13] <dimitern> TheMue, well, the only thing I could do is offer you to take a day off if you need to sort things out :/
[13:16] <dooferlad> TheMue: Yikes! I hope your insurer is efficient :-|
[13:22] <mup> Bug #1438683 was opened: Containers stuck allocating, interface not up <cloud-installer> <landscape> <juju-core:New> <https://launchpad.net/bugs/1438683>
[13:32] <dimitern> voidspace, dooferlad, I've replied to your review comments; thanks!
[13:33] <dooferlad> dimitern: who knew one little flag would cause so much typing :-)
[13:34] <dimitern> voidspace, I've also triaged that maas bug ^^ and added a comment capturing what me and sparkiegeek discovered so far, which will possibly help finding the issue
[13:34] <voidspace> dimitern: yeah, I've been reading it
[13:34] <dimitern> dooferlad, indeed :)
[13:34] <voidspace> sounds like a mess... :-/
[13:34] <dimitern> voidspace, yep :( workarounds biting us back, as usual
[13:34] <dimitern> if only maas had usable api :)
[13:40] <joec1> Hi folks and esteemed juju devs, apologies for the impertinent question but are there any known issues getting juju to work in Azure (aside from the bug reports)?
[13:45] <natefinch> alexisb: sorry, I had hoped the baby wasn't audible over the headset mic.... guess it was
[13:46] <alexisb> yes, and sorry I muted you but the baby cry still triggers the mommy instinct and made it hard to concentrate on what I wanted to say :)
[13:46] <natefinch> heh I understand
[14:03] <dimitern> voidspace, you should really do something to start noticing your PMs :)
[14:25] <anastasiamac> dimitern: tyvm for reviewing my PR
[14:25] <ericsnow> dimitern: PTAL http://reviews.vapour.ws/r/1234/
[14:25] <anastasiamac> dimitern: i had to add unit info and change sort order for tabular format
[14:25] <ericsnow> dimitern: also http://reviews.vapour.ws/r/1332/ and http://reviews.vapour.ws/r/1333/
[14:26] <dimitern> ericsnow, ok, I have a few already, will add them to my queue
[14:26] <anastasiamac> dimitern: if u have a chance if u could PTAL it again despite ur prev shipit - would be amazing!
[14:26] <ericsnow> dimitern: thanks
[14:26] <anastasiamac> dimitern: http://reviews.vapour.ws/r/1323/
[14:26] <dimitern> anastasiamac, np - remind me which one?
[14:26] <dimitern> anastasiamac, ok, cheers
[14:27] <anastasiamac> dimitern: thnx ;D m EODing now 00:27 on the clock...
[14:27] <ericsnow> dimitern: http://reviews.vapour.ws/r/1332/ shouild be easy and is a blocker for the 1.23 release, so perhaps you could "nice" it up :)
[14:27] <dimitern> anastasiamac, oh that's late - have a good evening then :)
[14:27] <dimitern> ericsnow, ack, will start with it then
[14:27] <ericsnow> dimitern: thanks!
[14:28] <anastasiamac> dimitern: or early :D ttyl
[14:28] <ericsnow> cherylj: it looks like the LICENCE fixes are all done for 1.22 \o/
[14:28] <ericsnow> cherylj: is that right?
[14:29] <cherylj> ericsnow: yes, as long as the patch for dependencies.tsv passes CI :)
[14:30] <ericsnow> cherylj: awesome!  Thanks for tackling all that!
[14:30] <cherylj> ericsnow: np!
[14:30] <ericsnow> cherylj: be sure to mark the bug as "fix committed" for 1.22
[14:31] <cherylj> thanks for the reminder :)
[14:32] <cherylj> hooray!  it passed CI
[14:34] <mup> Bug #1438721 was opened: sync-tools does not support patch versions <juju-core:New> <https://launchpad.net/bugs/1438721>
[14:40] <natefinch> abentley: where can I find the code for the CI tests?
[14:40] <aznashwan> dimitern, voidspace: ping
[14:40] <dimitern> aznashwan, pong
[14:40] <abentley> natefinch: lp:juju-ci-tools
[14:41] <voidspace> aznashwan: pong
[14:41] <natefinch> abentley: sigh.. launchpad, huh?
[14:41] <aznashwan> dimitern: could I bother you guys with what looks like a horrendously huge review but there's actually little to it: http://reviews.vapour.ws/r/1330/ :D
[14:41] <dimitern> aznashwan, I'm about 33% done with that monster branch of yours about cloudinit
[14:41] <dimitern> :)
[14:41] <abentley> natefinch: of course!
[14:41] <aznashwan> dimitern: great
[14:42] <aznashwan> dimitern: as said there, most of it's relocated code
[14:42] <dimitern> aznashwan, why did you decide to rename MachineConfig to InstanceConfig?
[14:42] <dimitern> aznashwan, that definitely blew up the diff considerably
[14:43] <aznashwan> dimitern: that was bogdanteleaga's doing at the suggestion of one of you guys
[14:44] <dimitern> aznashwan, I see
[14:44] <dimitern> ok then
[14:44] <aznashwan> dimitern: he'd be the better half to ask about this
[14:45] <dimitern> aznashwan, ok, thanks
[14:47] <bogdanteleaga> dimitern, it was done after some consulting with william; in hindsight it might not have been the best idea exactly because it ended up making the diff humongous, but there's not much to see outside of /cloudconfig
[14:51] <dimitern> bogdanteleaga, right, I agree it could've waited, but well .. :)
[14:51] <TheMue> dimitern: dooferlad: voidspace: wow, what an organizational stuff with insurance, fire department, neighbor. will post pics later, car seems to be totally crashed
[14:52] <dooferlad> TheMue: time for another whisky tasting?
[14:52] <TheMue> dooferlad: will these eve definitely need one
[14:52] <dimitern> TheMue, :( too bad - hopefully the insurance will cover all
[14:53] <TheMue> dimitern: currently all signs are positive, looks like a 100% coverage
[14:54] <TheMue> better than many of our unit tests *lol*
[14:54] <dimitern> TheMue, good!
[14:55] <jw4> TheMue: I saw that about your car - You've already had one tree fall this year, and your neighbor was felling more trees a couple weeks ago... what gives?
[14:55]  * natefinch tries to remember how to use bzr
[14:56] <voidspace> TheMue: ouch :-/
[15:02] <natefinch> abentley: do we have tests trying out HA?
[15:02] <natefinch> (in CI)
[15:03] <abentley> natefinch: Yes.  See http://juju-ci.vapour.ws/job/functional-ha-backup-restore/ and http://juju-ci.vapour.ws/job/functional-ha-recovery/
[15:07] <voidspace> dimitern: port is done, but not run manual tests yet
[15:07] <voidspace> dimitern: doing a full normal test run first
[15:07] <voidspace> dimitern: then can switch to the other bug
[15:07] <dimitern> voidspace, ok, sounds good
[15:08] <cherylj> natefinch, ericsnow:  I'm updating the dependencies for 1.23, and I see that updating juju/names pulls in this change:  https://github.com/juju/names/pull/43
[15:08] <cherylj> natefinch, ericsnow:   It brings in a new tag, but doesn't change any functionality.
[15:08] <natefinch> space tag sounds so much better than freeze tag
[15:08] <cherylj> natefinch, ericsnow:  Will that be okay?  or do we need a new branch?
[15:08] <cherylj> haha
[15:09] <natefinch> cherylj: that's expanding the API in a backwards compatible way, so I think it's fine to leave it in the same branch
[15:10] <natefinch> cherylj: wait sorry
[15:10] <natefinch> cherylj: misunderstood... yes, I think making a new branch there is the right thing to do
[15:10] <natefinch> cherylj: it's simple, but doesn't really belong in 1.23, and none of the rest of the code will know what to do with it
[15:11] <cherylj> natefinch: okay, glad I asked :)  Can you create the branch?
[15:11] <natefinch> cherylj: do you have the right commit hash handy?
[15:11] <natefinch> (and yes)
[15:12] <natefinch> is it just the one before that space tag change?
[15:12] <cherylj> natefinch: ce4ecb2967822062fc606e733919c677c584ab7e
[15:13] <natefinch> cherylj: thanks
[15:13] <cherylj> np!
[15:15] <natefinch> cherylj: there you go
[15:18] <voidspace> dimitern: hah, a few calls to network.NewAddress to fix first...
[15:18] <cherylj> natefinch: thanks!
[15:20] <dimitern> voidspace, :) I dread the moment when I have to merge master into net-cli already
[15:21] <voidspace> dimitern: heh
[15:21] <voidspace> dimitern: it wasn't so many I had to do
[15:28] <mup> Bug #1438748 was opened: Use of /tmp/discover_init_system.sh is a security vulnerability. <juju-core:In Progress by ericsnowcurrently> <juju-core 1.23:In Progress by ericsnowcurrently> <https://launchpad.net/bugs/1438748>
[15:38] <voidspace> dimitern: so, for the "multiple networks with no index" - manually increment the index?
[15:38] <voidspace> dimitern: we still risk duplicating an index if there are some with suffix and some without
[15:38] <voidspace> dimitern:  no idea if that's possible though
[15:38] <dimitern> voidspace, I guess that's the only thing to do
[15:39] <voidspace> ok
[15:39] <dimitern> voidspace, we should add more logging at debug level
[15:39] <voidspace> dimitern: ok
[15:39] <dimitern> voidspace, cheers
[15:39] <voidspace> dimitern: and I'll look through the code seeing if I can work out why we pick the disabled nic
[15:40] <voidspace> dimitern: it's almost certainly due to them having the same subnet (network) *or* due to the index issue
[15:40] <voidspace> dimitern: but it would be good to know
[15:40] <voidspace> dimitern: running a manual test of my 1.23 branch in parallel to doing this
[15:40] <natefinch> abentley: I'm trying to write a new CI test to test using ensure availability to turn existing machines in the environment into state servers.  Is there documentation on how to write CI tests?  It looks fairly straight forward, but docs are always helpful :)
[15:42] <dimitern> voidspace, yeah - it was hard to tell what's going on, but the logs should tell
[15:49] <abentley> natefinch: Sorry, was on a call.
[15:49] <natefinch> abentley: np
[15:51] <abentley> natefinch: There isn't documentation.  Basically you need to return 0 on success and 1 on failure, and you should allow the runtime environment name to be customized, and jujupy may be helpful.
[15:52] <natefinch> abentley: ok, cool.  It looks pretty easy, except perhaps how to add the extra jenkins job
[15:52]  * natefinch knows jack all about jenkins
[15:53] <abentley> natefinch: when you've got a script that works locally, I can help you with getting it onto Jenkins.
[15:54] <abentley> natefinch: When you say "existing machines", do you mean machines that aren't provisioned by juju?
[15:55] <alexisb> natefinch, can we land in the HA stuff at this stage?
[15:57] <voidspace> dimitern: ok, so manually testing this has revealed a problem with the upgrade step...
[15:57] <voidspace> dimitern: and I think trunk is screwed too - I just didn't notice before
[16:00] <voidspace> dimitern: http://pastebin.ubuntu.com/10712911/
[16:01] <voidspace> dimitern: the best fix is to have ReleaseAddress not require an instance iD
[16:01] <dimitern> voidspace, oh sh*t
[16:01] <voidspace> dimitern: I'll repeat the test for trunk, but I bet it has the same issue and I just didn't notice it before :-/
[16:01] <dimitern> voidspace, this is because we need the instance id?
[16:01] <voidspace> dimitern: yep
[16:01] <dimitern> voidspace, yeah
[16:02] <voidspace> dimitern: but I don't think either MaaS or ec2 actually require it
[16:02] <dimitern> voidspace, I should've thought of that
[16:02] <voidspace> dimitern: so we should just drop it from the provider method signature
[16:02] <voidspace> if it's really not used
[16:02] <dimitern> voidspace, well, how do you suggest fixing it?
[16:02] <voidspace> dimitern: yeah, me too :-)
[16:02] <voidspace> dimitern: stop requiring instance ID
[16:02] <dimitern> voidspace, don't you need it to get the machine?
[16:03] <dimitern> voidspace, or we added it only because we needed it for ReleaseAddress?
[16:03] <voidspace> dimitern: I think we just thought we might need it
[16:04] <voidspace> dimitern: ah no
[16:04] <voidspace> dimitern: ec2 does use it
[16:04] <dimitern> voidspace, *whew* ok, then it's easy :)
[16:04] <voidspace> nope
[16:04] <dimitern> voidspace, oh?
[16:04] <voidspace> dimitern: it actually needs a nic id
[16:04] <voidspace> dimitern: but we get the nic id from the instance id
[16:04] <dimitern> voidspace, yeah
[16:04] <dimitern> voidspace, ok, sorry I'm a bit confused
[16:05] <cherylj> Can I get a couple license related reviews?  http://reviews.vapour.ws/r/1342/      http://reviews.vapour.ws/r/1343/
[16:05] <dimitern> voidspace, you need instance id in order to call ReleaseAddress in the worker
[16:05] <voidspace> dimitern: yes
[16:05] <voidspace> dimitern: maas doesn't use the instance id
[16:05] <dimitern> voidspace, you don't need instance id in the provisioner api
[16:05] <voidspace> dimitern: but ec2 does
[16:06] <voidspace> dimitern: the issue here is specifically when the upgrade runs and there are dead ip addresses
[16:06] <voidspace> dimitern: nothing to do with the provisioner api
[16:06] <voidspace> dimitern: the worker notices the dead addresses when it starts and tries to remove them
[16:06] <dimitern> voidspace, ok
[16:06] <dimitern> voidspace, so we do need to pass instance id, even if it's unused
[16:06] <voidspace> dimitern: the addresses have a MachineId()
[16:07] <voidspace> dimitern: the worker tries to get the instance id from the machine - but the machine is already gone
[16:07] <voidspace> dimitern: Environ.ReleaseAddress takes an instance id
[16:07] <voidspace> dimitern: that is not used by maas, but unfortunately *is* used by ec2
[16:08] <natefinch> alexisb, abentley: sorry, left for a minute to make lunch....
[16:08] <dimitern> voidspace, but fortunately, in ec2 it doesn't matter
[16:08] <dimitern> voidspace, because if the instance is gone, all its nics and ips are gone with it
[16:09] <natefinch> alexisb: I can land it by EOD.  I have to do a few trivial code review cleanup things and write a couple trivial unit tests, and then I can start working on the CI tests
[16:09] <voidspace> dimitern: ok, so we need a way to release the address for maas
[16:09] <dimitern> voidspace, so I guess it only matters for maas - we need to release the addresses, but instance id can be empty
[16:09] <dimitern> voidspace, it can be a special value like instance.UnknownId ?
[16:09] <voidspace> dimitern: ok, fine
[16:09] <voidspace> dimitern: and ec2 will make that a no-op
[16:09] <natefinch> abentley: I mean machines that have been added to the juju environment, either through deploy or add-machine.  So, like, you could do juju ensure-availability --to 1,2 and convert machines 1 and 2 into state machines
[16:09] <voidspace> dimitern: whereas maas will release the address
[16:10] <voidspace> dimitern: fine - thanks
[16:10] <dimitern> voidspace, exactly - the upgrade step should try a best effort, but not fail if instance id cannot be found
[16:11] <abentley> natefinch: Cool.  I was thinking this might be something like the manual provider.  We have a solution for testing the manual provider, but it's not the cleanest.
[16:12] <natefinch> abentley: nope, pretty easy, really... just like the other HA tests./.. just bootstrap, juju add-machine -n 2, wait for them to come up, then juju ensure-availability --to 1,2 and then wait for HA.
[16:12] <dimitern> ericsnow, re http://reviews.vapour.ws/r/1332/ - it seems it just drops upstart-specific confs
[16:12] <abentley> natefinch: great.
[16:12] <ericsnow> dimitern: that is correct
[16:12] <dimitern> ericsnow, shouldn't it only drop them when systemd is used?
[16:13] <ericsnow> dimitern: we don't need them for upstart either
[16:13] <dimitern> ericsnow, i.e. isn't that strictly worse than before?
[16:13] <dimitern> ericsnow, ok, if they're not used for upstart fair enough
[16:13] <ericsnow> dimitern: they are just clutter since we generate a new upstart conf when we bootstrap
[16:13] <dimitern> ericsnow, I'll take your word for it though :)
[16:14] <dimitern> ericsnow, ok, that makes sense
[16:14] <dimitern> ericsnow, thanks!
[16:14] <ericsnow> dimitern: if restore were more than replace-the-old-state server then we would have a different story :)
[16:14] <dimitern> ericsnow, LGTM then
[16:14] <ericsnow> dimitern: thanks
[16:17] <natefinch> I love it when writing documentation for code reveals a bug.
[16:18] <dimitern> natefinch, it's worse when it reveals a bug in the spec :)
[16:18] <natefinch> dimitern: heh
[16:19] <natefinch> dimitern: I actually wasn't being sarcastic.  I actually do like it when that happens.  Better than not finding the bug until later :)
[16:19] <natefinch> dimitern: btw, are watchers fired off serially, or do I need a lock in my Handle() method in case two get fired off in quick succession?
[16:23] <dimitern> natefinch, you're using the same handler for 2 watchers? brave! :)
[16:23] <natefinch> dimitern: no no... but if there's two changes back to back
[16:24] <dimitern> natefinch, the watcher should coalesce events properly
[16:24] <natefinch> dimitern: not exactly filling me with confidence ;)
[16:25] <dimitern> natefinch, well, it depends if the watcher is working properly :)
[16:25] <natefinch> lol
[16:25] <natefinch> ok
[16:34] <cherylj> natefinch: we also need to branch juju/utils for 1.23  at commit 3efdaa3f15cc47ee83f6c03f640dc14f5915e289
[16:35] <natefinch> cherylj: done
[16:36]  * natefinch is getting the hang of this git thing. ;)
[16:37] <cherylj> natefinch: thanks!  I'm not sure if we need to branch testing too...  It pulls in https://github.com/juju/testing/pull/55  and https://github.com/juju/testing/pull/56
[16:37] <alexisb> natefinch, awesome thank you
[16:38] <natefinch> cherylj: to be on the safe side, I think I would
[16:38] <cherylj> natefinch: okay, the commit to branch from there is: c07aef9cb4f2ff1db7ddc9d43a0ea88eca39c9ea
[16:39] <natefinch> cherylj: done
[16:39] <cherylj> natefinch: thanks!
[16:41] <natefinch> cherylj:  welcome :)
[16:58] <mup> Bug #1438798 was opened: juju sync-tools requires default environment <juju-core:New> <https://launchpad.net/bugs/1438798>
[17:11] <alexisb> voidspace, you still around?
[17:35] <cherylj> natefinch-afk: I think we can get away with not branching juju/charm for 1.23.  It just pulls in this:  https://github.com/juju/charm/pull/82
[17:35] <cherylj> natefinch-afk: what do you think?
[17:37] <natefinch> cherylj: lgtm
[17:37] <cherylj> natefinch: thanks1
[17:39] <voidspace> alexisb: yep
[17:39] <voidspace> alexisb: just, about to go
[17:39] <wwitzel3> is there an example of putting a provider behind a feature flag? not exactly sure how to approach this
[17:39] <cherylj> natefinch: could you review a few more of the license changes?  http://reviews.vapour.ws/r/1342/      http://reviews.vapour.ws/r/1343/        http://reviews.vapour.ws/r/1345/            http://reviews.vapour.ws/r/1346/
[17:39] <alexisb> voidspace, looks like you picked up a new bug today for 1.23
[17:39] <voidspace> alexisb: yep
[17:39] <alexisb> I was just curious the scope of work
[17:40] <voidspace> alexisb: two I think :-/
[17:40] <alexisb> yay!
[17:40] <voidspace> alexisb: should be able to land both in the next two days - one per day, maybe quicker
[17:40] <voidspace> alexisb: I need to file the second one
[17:40] <alexisb> great thank you that is what I needed
[17:40] <voidspace> alexisb: the one that is filed is a *little bit* unknown
[17:40] <voidspace> alexisb: so it *could* explode :-)
[17:40] <voidspace> alexisb: but we don't think so
[17:41] <alexisb> voidspace, ok, keep me posted
[17:41] <voidspace> alexisb: will do
[17:42] <natefinch> cherylj: I'm kinda slammed getting some critical code into 1.23, maybe someone else could do the review, like voidspace or ericsnow or cmars or wwitzel3
[17:42] <cherylj> ah, okay, thanks
[17:43] <cmars> cherylj, about to head out for lunch, can take a look in a little bit
[17:44] <cherylj> thanks, cmars
[17:46] <voidspace> alexisb: actually 3 bugs
[17:46] <voidspace> alexisb: for 1.23
[17:46] <cherylj> ah, ericsnow got 'em.  Thanks, ericsnow!
[17:46] <ericsnow> cherylj: they all LGTM
[17:46] <cherylj> thanks!!
[17:46] <voidspace> alexisb: bug 1438820
[17:46] <mup> Bug #1438820: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820>
[17:46] <ericsnow> cherylj: good catch on the blobstore dep :)
[17:46] <voidspace> bug 1438683
[17:46] <mup> Bug #1438683: Containers stuck allocating, interface not up <add-machine> <cloud-installer> <landscape> <maas-provider> <network> <juju-core:Triaged by mfoord> <https://launchpad.net/bugs/1438683>
[17:46] <voidspace> bug 1438168
[17:46] <mup> Bug #1438168: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168>
[17:47] <alexisb> voidspace, are you thinking a day for each?
[17:47] <alexisb> any you think could be deferred to a point release?
[17:47] <voidspace> alexisb: one of them is done but blocked on the other two
[17:47] <voidspace> alexisb: so still two days for all of them is my thinking
[17:48] <voidspace> alexisb: bug 1438168 is complete but in testing it I discovered bug 1438820 that also affects trunk
[17:48] <mup> Bug #1438168: juju 1.23 doesn't release IP addresses for containers <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438168>
[17:48] <mup> Bug #1438820: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820>
[17:48] <voidspace> alexisb: but it is 3 bugs / 3 branches
[17:50] <alexisb> voidspace, ok, now go enjoy your evening
[17:50] <alexisb> thanks for the info
[17:52] <cherylj> ericsnow: I'm glad you commented that you couldn't see the review on RB.  I saw that I created that pull request against the wrong branch!
[17:53] <cherylj> ericsnow: here's the correct branch:  http://reviews.vapour.ws/r/1347/
[17:53] <ericsnow> cherylj: LGTM
[17:53] <cherylj> ericsnow: thanks again!
[17:53] <ericsnow> cherylj: np
[17:58] <mup> Bug #1438820 was opened: IP address life field upgrade step and addresser worker don't play well together <juju-core:In Progress by mfoord> <https://launchpad.net/bugs/1438820>
[17:59] <natefinch> thumper: are you actually on?
[18:50] <natefinch> so, you're supposed to use UnitsWatcher to watch Machines... makes total sense
[18:57] <alexisb> natefinch, fwereade would have lots to say about that (this is one of the areas he wants to clean up really badly)
[19:00] <natefinch> alexisb: heh... yeah, this is the first time I've delved into watchers and stuff, and there's some interesting choices being made in there... I'm sure they each made sense at the time
[19:55] <thumper> natefinch: no, I wasn't
[19:55] <thumper> obviously forgot to close IRC last night
[19:55] <natefinch> thumper: heh, figured
[19:55] <natefinch> thumper: 7am isn't your usual start time :)
[19:56] <thumper> nope, it isn't
[19:56] <natefinch> thumper: I had some questions about watchers and the API, but I think I figured it out from reading other API facades
[19:56] <thumper> awesome
[19:58] <ericsnow> davecheney: in case you missed it (re: gccgo in vivid): https://lists.ubuntu.com/archives/ubuntu-devel/2015-March/038740.html
[19:59] <natefinch> ericsnow: yeah, I saw that, but uh, joining ubuntu-devel to respond is kinda a high barrier of entry.  I think putting gccgo and go as different effective versions is a really bad idea.
[19:59] <ericsnow> natefinch: yeah, I was thinking that too :)
[19:59] <thumper> ericsnow: dave is off now for a while
[20:00] <ericsnow> thumper: k
[20:00] <thumper> off until he flies to eurpoe, next week sprinting on arm64 go stuff, then meeting us in Nuremberg
[20:00] <ericsnow> thumper: ah
[20:57] <natefinch> oh amazon, you're so slow...
[21:02] <natefinch> bbl
[21:17] <mup> Bug #1436655 was opened: gce provider should stop using deprecated zone europe-west1-a <gce-provider> <juju-core:Triaged> <juju-core 1.23:Triaged> <https://launchpad.net/bugs/1436655>
[21:24] <ericsnow> wwitzel3: would you mind assigning the GCE issues you are working on to yourself
[21:25] <ericsnow> wwitzel3: there are 2 right?
[21:40]  * thumper moves to the coffee shop to see if a change of scenery will help with focus
[22:13] <ericsnow> cherylj: so all 1.23 changes are wrapped up now, right? :)
[22:13] <cherylj> ericsnow: yes :)
[22:14] <ericsnow> cherylj: lol, too many channels
[22:14] <cherylj> hehe :)
[22:44] <cherylj> natefinch-dinner: In updating the dependencies for juju master, I see a new repo, juju/jujusvg which is using the LGPL, but doesn't mention the exception found in other repos.  Should I add it in?
[22:44] <ericsnow> could anyone spare me a review on http://reviews.vapour.ws/r/1349/ and http://reviews.vapour.ws/r/1350/?
[23:15] <redelmann_> Hello, is safe to have two enviroments in same AWS account?
[23:16] <redelmann_> juju destroy-enviroment --force will kill everithing in aws? or just instances of enviroment?
[23:25] <thumper> redelmann_: interesting question...
[23:25] <thumper> redelmann_: in theory, it should be fine
[23:25] <thumper> redelmann_: in practice, I'd test it first
[23:26] <thumper> redelmann_: it should be fine, so if it isn't, please make sure you file a bug
[23:26] <thumper> could just be my paranoia
[23:28] <redelmann_> thumper, I tried it a while ago and juju terminate all my instances (juju 1.20 i think)
[23:28] <redelmann_> thumper, thats why i asking about this
[23:29] <thumper> redelmann_: can you file a bug please?
[23:29] <thumper> also though...
[23:30] <thumper> you shouldn't need to use --force
[23:30] <thumper> that is a very "last resort" mechanism for cleaning up an environment
[23:38] <wallyworld_> axw: after school drop off did we need to catch up about storage since we missed the standup?
[23:39] <axw> wallyworld_: I don't have much to talk about. I'm going to propose storageprovisioner changes today, assuming I get enough test coverage done
[23:39] <axw> can do if you like tho
[23:40] <wallyworld_> all good, maybe we can touch base this arvo if needed
[23:40] <axw> wallyworld_: ok. gotta go help get the kids ready, bbl
[23:40] <wallyworld_> ttyl
[23:49] <ericsnow> wallyworld_: if you have a few minutes, could you take a look at http://reviews.vapour.ws/r/1349/ and http://reviews.vapour.ws/r/1350/?
[23:49] <ericsnow> wallyworld_: they are both for 1.23
[23:50] <wallyworld_> ok
[23:50] <ericsnow> wallyworld_: thanks
[23:56] <redelmann_> thumper, ok


[00:45] <Enissay> compdoc: it works with gnome just fine, except that you need an active session already logged in... which is sad in case of crash/reboot
[00:47] <Enissay> I am thinking of setting up auto login during my trip so I can access remotely since I will have no physical access to my machine during that time :<
[00:47] <compdoc> Enissay, I always install a minimal Mate desktop
[00:48] <compdoc> no need for an active session
[00:48] <Enissay> hmmm, I may do it... that machine is a mini pc actually not my main
[00:49] <Enissay> I'll try that tomorrow then... time to hit bed at 3am :x
[00:52] <Enissay> who am I kidding... I cant sleep with this in mind... Installing...
[00:55] <compdoc> lol
[00:56] <compdoc> you installing ubuntu mate from scratch?
[00:56] <Enissay> no, over regular ubuntu 20.04
[00:56] <compdoc> thats the best way. works great as a server or desktop
[00:57] <compdoc> I mean from scratch
[00:59] <compdoc> good luck!
[01:02] <Enissay> ofc, that's best way always
[01:02] <Enissay> my machine still new, so I will try it as is now and format if needed
[01:03] <Enissay> Mate Terminal is ugly a-f though
[01:03] <Enissay> But on the bright side it indeed started a session even while none was active
[03:15] <ezakimak> seems systemd and networkmanager are fighting over who controls hostapd, what's the right way to doi it?
[03:24] <burts7358> hello
[03:38] <Bashing-om> ezakimak: Out of curiosity; what shows for the render ' cat /etc/netplan/01-network-manager-all.yaml ' ?
[03:48] <ezakimak> there is no /etc/netplan
[03:49] <leftyfb> ezakimak: cat /etc/os-release | nc termbin.com 9999
[03:50] <ezakimak> 20.04.2 LTS (Focal Fossa)
[03:50] <leftyfb> ezakimak: that's not the whole output
[03:50] <leftyfb> ezakimak: if you don't have /etc/netplan then you're not running Ubuntu 20.04. Or have modified it and removed netplan
[03:51] <ezakimak> https://paste.ubuntu.com/p/Pfr9HZN9Yv/
[03:52] <leftyfb> ezakimak: so you removed netplan?
[03:52] <ezakimak> I didn't
[03:52] <ezakimak> it's possible the vendor did.
[03:52] <leftyfb> ezakimak: vendor?
[03:52] <ezakimak> it's for an arm mx8 device
[03:52] <ezakimak> they provided the image
[03:54] <leftyfb> ezakimak: ok, then it's unlikely this is a version of ubuntu that we can support. You'll need to seek support from the vendor. Especially when the support issue is specifically due to what they modified
[03:54] <ezakimak> i've sent an inquiry as to why they removed it
[03:55] <ezakimak> so is netplan the new "standard" way of configuring networking in ubuntu moving forward?
[03:55] <leftyfb> ezakimak: you'll also need to inquire about your networking issues regarding systemd and networkmanager
[03:56] <leftyfb> ezakimak: yes
[03:56] <leftyfb> ezakimak: https://netplan.io/
[03:57] <ezakimak> i already have my hostapd configured how I need it
[03:58] <ezakimak> as well as my dnsmasq
[03:59] <ezakimak> seems there still isn't a built-in way to make firewall rules persistent
[03:59] <Bashing-om> ezakimak: However: in ubuntu netplan is the configuration generator, for either NetworkManager, or systemd-networkd.
[04:03] <ezakimak> another config generator layer. great.
[04:03] <ezakimak> one more reason reminding me why I prefer gentoo
[04:58] <alkisg> It does sound silly to have a generator just for 2 possible layouts. Just select one of these layouts and create a converter, not a third format...
[06:32] <Guest914> Does anyone know what process/service is responsible for running the scripts inside /etc/update-motd.d ?
[06:32] <Guest914> I'm trying to disable motd, and I'd like to stop this at its source, rather than make these files not executable
[06:40] <ruedii> I'm running into issues with my system having the video card crash on boot on kernel 5.11, but it works on 5.8.  I'm wondering if there is a bug.
[06:42] <ruedii> Guest914, what are you trying to achieve by stopping that script from running?
[06:51] <Guest914> Trying to disable the motd
[06:52] <ruedii> In that case, just set the MOTD to be blank.
[06:53] <ruedii> That way it will update it to be blank.    I know running a useless script seems unusual, but it makes more sense than ripping out a primary function, and you never know when you might need to add an MOTD back.
[06:54] <Guest914> Is there a singular process that runs all those scripts?
[06:54] <ruedii> Yes, systemd handles them.
[06:55] <ruedii> The update motd script runs in almost no time.
[06:55] <ruedii> BTW, if you want a custom MOTD, there are some seriously cool things you can do with it.  It parses all sorts of variables about the current state of your system, and you can set it to either parse on boot or on display.
[06:56] <ruedii> Oh, did I mention you can do UTF8 or ASCII art if your terminal is capable.
[06:56] <Guest914> lol I'll keep that in mind the next time I want to echo an emoji
[06:57] <ruedii> Just be careful, a few UTF extended characters have minor issues with terminals not set to UTF-8.
[06:58] <ruedii> I think Ubuntu needs to move the default advanced VT to use UTF8 now that there are options available and all video cards that are the slightest bit modern are capable of it on a hardware level.
[06:59] <ruedii> An 8 bit per a glyph framebuffer actually runs slower on some newer cards which are optimized for 16bit and 32bit access partitioning.
[06:59] <rfm> Guest914, if you just want to stop diplaying the motd at login, you want to comment out the pam_motd lines in //etc/pam.d/{login,sshd}
[07:00] <ruedii> rfm, yep. that is an excelent way to do it too.
[07:01] <ruedii> I need to look into my video card issue further and get back.  I hope it's not the same one I was running into earlier on Ubuntu 20.04 (SMU crashing on DPM initializing.)
[07:01] <rfm> Guest914,  if you want to climb back further, there's motd-news.service and update-notifier-motd.service (both on timers() at least, and there might be more...
[07:02] <ruedii> There is also a whole infrastructure for setting all sorts of neat stuff on MOTD.  For instance, you can check the current system load average, and available memory.
[07:03] <ruedii> Note that there are tricky little syntax distinctions between parse at runtime, parse at initial set, and parse at boot.
[07:04] <Guest914> Okay I found that /etc/profile.d/update-motd.sh is what's running all those other scripts.  So I'll just gut that out.  Thanks for the help
[07:21] <alzgh> Hello. I have a question regarding how to interpret the man page for `sudo`. It's not Ubuntu specific. Can I ask it here? I don't intend to bind anyone by this question. It's OK if post-question, it is considered out of scope.
[07:23] <ayrus> alzgh: man sudo
[07:27] <src> alzgh: just ask :P
[07:27] <alzgh> ayrus it's about how to interpret it. `man sudo` show the following for the `-i, --login` switch: https://paste.ubuntu.com/p/D3JZqgb3rN/. I use this switch to go into root since root is not enabled on my system (ubuntu focal), but as hard as I try I can't see this in the text of the man page.
[07:28] <Croran> alzgh: have you considered 'sudo su' ?
[07:29] <alzgh> Croran this isn't my question, but I have not. `sudo -i` worked fine for me. My question is how to learn to interpret the man page.
[07:29] <EriC^^> alzgh: what do you mean by you can't see the text of the manpage?
[07:29] <Croran> alzgh: your question is unclear.
[07:30] <alzgh> OK, sorry. Let me rephrase.
[07:30] <EriC^^> alzgh: if you type 'man sudo' then type '/-i' and hit enter twice does it not display it?
[07:30] <EriC^^> *hit "n" once
[07:32] <alzgh> I know that `sudo -i` let's me login as the super user. I found this out through means other then the man page (I used `tldr` and google). Then I went to read the sudo man page and looked at it's description for `-i, --login` and didn't find any reference to the fact that this switch helps you login as the super user.
[07:32] <ayrus> alzgh: it's the `vim`.
[07:32] <alzgh> I know how to search in the man pages.
[07:33] <alzgh> My question is, how should I learn from this https://paste.ubuntu.com/p/D3JZqgb3rN/ that the `-i, --login` switch enables me to login as the super user.
[07:33] <alzgh> What am I missing there?
[07:33] <alzgh> In the man page.
[07:33] <sneep> Maybe you should be more interested in what Ubuntu means by "disabling the root user"
[07:33] <sneep> +instead
[07:34] <ayrus> alzgh: are you mentioning there is no entry for `-i` in the man page of sudo?
[07:34] <Croran> alzgh: sudo gives you the permissions of the super user. why wouldn't you think this extends to logging in as the super user?
[07:34] <alzgh> sneep maybe that's the root of my confusion. If I knew what it meant under the hood, maybe I would how the description of this switch worked.
[07:35] <sneep> Well, if you run sudo bash, do you get a root shell? Yes
[07:36] <Croran> alzgh: easier to 'sudo su' to get a root shell though.
[07:36] <EriC^^> alzgh: in the sudo manpage there's a part where it says if no user is provided it defaults to executing the command as root, and that -i part pertains to the login part where it will execute the command as if you logged in, changes $HOME etc
[07:37] <EriC^^> (user is provided via the -u argument)
[07:37] <sneep> Ubuntu doesn't set a password for the root user, thereby disabling authenticating as root in the standard login process
[07:38] <alzgh> EriC^^ I think that clears things up. I was missing this part. the `-i` switch is just for loading the selected users preferences.
[07:38] <ducasse> alzgh: are you saying you can't see the definition for -1 in the man page?
[07:39] <EriC^^> yeah exactly, just so you access the shell as if it were a login shell
[07:39] <alzgh> I can see the definition, I wasn't able to understand it though. Was not able to make a logical connection between the text in the man page and how the tool worked.
[07:40] <alzgh> Thanks guys. Really helpful. Sorry for the confusion. I'm trying to read and use the man pages but it isn't always easy to understand them :D
[07:41] <EriC^^> no problem
[07:41] <ducasse> alzgh: the man pages are meant to be definitive, not readable :)
[07:42] <alzgh> yeah, true. Good to have this in mind next time I go through them. Right now, I use `tldr` in many cases.
[07:43] <alzgh> And after I find what I'm looking for, I look it up on the man page and try to make sense to it.
[07:51] <sneep> BTW, all that bash does when adding -i is call /bin/bash with special arguments. Specifically, it prefixes argv[0] with a hyphen character when doing the system call to execute a program. That is understood by bash and other shells (by convention) to invoke a login shell.
[08:21] <cxl> Hi, I am using grub on my computer. It's a laptop so I have my linux install on the whole internal disk using zfs. But I also have a windows installed on a usb drive and I'd like to add that option in grub instead of having to mash F12 every time I need windows. What's the right way? I took a look at /boot/grub.cfg and it says DO NOT EDIT
[08:22] <EriC^^> cxl: you can edit /etc/grub.d/40_custom and add a windows entry there, then 'sudo update-grub' to make a new grub.cfg
[08:23] <cxl> EriC^^: thank you I'll look there
[08:23] <EriC^^> cxl: no problem
[08:24] <alkisg> cxl: you can probably just run `update-grub` while you have the stick attached
[08:25] <cxl> alkisg: that did it, it found windows. much easier, thanks
[08:26] <alkisg> 👍
[08:29] <cxl> alkisg: I spoke too fast... it found it according to the command's output, I can see the new entry in /boot/grub/grub.cfg, but when grub actually loads then it's not on the list
[08:30] <alkisg> cxl: that might mean it's using a different grub.cfg from elsewhere?
[08:30] <alkisg> Press "c" to get a console in grub
[08:30] <alkisg> Then set root=(hd0,gpt1) or something, to get to where your grub.cfg is,
[08:31] <alkisg> then: configfile /boot/grub/grub.cfg
[08:31] <alkisg> If THAT one shows the entry, then go back and echo root etc to see where your initial grub.cfg actually is
[08:31] <cxl> ok I'll try that now
[08:38] <kiwichrish> Evening/Morning/afternoon.... :-)
[08:40] <kiwichrish> A Small Q: about Ubuntu Advantage subscriptions...  Does anyone know if you get a list on the website when you've got more than a community/free account of the host names / IPs that have subscribed under your key / account?  (Just got the free 3x one at the moment and looking at getting a paid subscription for work)
[08:53] <alexg1> hello
[08:54] <kiwichrish> Hello
[09:23] <ice9> how can I run a script automatically whenever apt (install or upgrade) is executed for a specific package?
[09:25] <kiwichrish> https://askubuntu.com/questions/869219/how-can-i-run-a-script-after-a-specific-package-is-upgraded
[09:25] <kiwichrish> :-)
[09:34] <sixwheeledbeast> xy?
[09:35] <bertptrs> sixwheeledbeast: https://en.wikipedia.org/wiki/XY_problem
[09:36] <sixwheeledbeast> it was a suggestion not a question ;)
[09:36] <kiwichrish> I know, but XY is what I was thinking as well. :)
[09:37] <bertptrs> I should pay more attention my bad
[09:38] <kiwichrish> Don't worry, it didn't make sense anyway.
[10:07] <Swahili> Hi!
[10:08] <Swahili> I'd like to do some tests on ubuntu. Installed it through a vm via parallels desktop for macos. Opened the chrome website and pulled the 64 deb. After installing, opened but its not rendering correctly, shows a red square, etc.
[10:08] <gordonjcp> Swahili: Jambo, habari gani?
[10:08] <Swahili> Any idea what might've been wrong? I used to work on ubuntu, but haven't for the past 10 years more or less
[10:08] <Square> im red yes
[10:08] <Swahili> gordonjcp: lol sorry if that's some swahili, I have no idea!
[10:09] <gordonjcp> Swahili: heh, my dad taught me how to say hello, goodbye, and please and thank you but that's about it
[10:09] <Swahili> I also get that with band t-shirts that I don't actually listen to, but I like the art :~D
[10:10] <Swahili> here's a screenshot: https://i.ibb.co/t25VprK/Screenshot-2021-07-08-at-11-10-11.png
[10:12] <Swahili> guess its a parallels desktop issue and not the installation processs for chrome.  Do you know how to solve it ? (https://linux-hardware.org/?probe=1ec52430a2)
[11:58] <toddc> frogzilla: do you have a ubuntu install disk that you can boot to and use the try ubuntu option and verify if it is hardware or software
[12:00] <frogzilla> how ?
[12:00] <frogzilla> I have a usb.
[12:00] <frogzilla> and i can boot on it
[12:00] <frogzilla> how can I check if it is hardware or software ?
[12:02] <frogzilla> if it works with live cd it will be software so ?
[12:02] <frogzilla> and what can I do ?
[12:47] <BluesKaj> Hi all
[13:25] <marva> Hello i have question is lightdm still active project and developed by canonical?
[13:28] <oerheks> Yes, used up to version 16.04 LTS. While it has been replaced by GDM in later Ubuntu releases, LightDM is still used by default in the latest release of several Ubuntu flavors
[13:33] <marva> ok ,thanks for answer i wanted to use https://github.com/ArcticaProject/lightdm-remote-session-freerdp2 but this project seems quite dead, no documentation. To start rdp session on startup
[13:36] <oerheks> freerdp2 is in our repos too.. https://packages.ubuntu.com/source/focal-updates/freerdp2
[13:37] <oerheks> no need to switch to lightdm
[13:42] <marva> i think its built directly to DM, and then allow direct connection to remote with RDP from login screen or something like that
[13:42] <oerheks> that github project is dead..
[14:30] <felipe> After the last ubuntu update the bluetooth of my laptop isn't working properly. It is switched on but appears as off.
[14:31] <felipe> DMESG gives [    8.551508] Bluetooth: hci0: Failed to send firmware data (-38)
[14:31] <felipe> as well [    8.705889] iwlwifi 0000:00:14.3: BIOS contains WGDS but no WRDS
[14:31] <felipe>
[14:32] <felipe> I am using 5.4.0-77-generic #86~18.04.1-Ubuntu
[14:45] <ioria> felipe, try to reload the  btusb module; sudo rmmod btusb  , wait a couple of cs and sudo modprobe btusb
[14:46] <ioria> *secs
[14:49] <Sheilong> ioria: That did not work
[15:31] <Sheilong> Bluetooth error segfault lol
[15:31] <Sheilong> https://paste.ofcode.org/dHBudKPK7We9eVbEuU6THz
[15:33] <leftyfb> Sheilong: what version of ubuntu are you running?
[15:34] <Sheilong> leftyfb: 18.04.1
[15:34] <leftyfb> Sheilong: why are you so far out of date?
[15:34] <Sheilong> I just booted a livecd of Lubuntu 20 and the bluetooth did work.
[15:35] <leftyfb> Sheilong: ok, we're not going to troubleshoot a live cd. Install it and then we can go from there
[15:36] <leftyfb> Sheilong: why is your installed version so far out of date?
[15:36] <Sheilong> leftyfb: Because canonical still gives support to this version. Also I have a lot of stuff installed on that I need to do my work. I will only upgrade it when canonical does not support 18.04 lts anymore.
[15:36] <Sheilong> leftyfb: This version come when I brought a new laptop in 2019.
[15:37] <leftyfb> Sheilong: I'm not talking upgrading 18.04 to 20.04. I'm talking 18.04.1 to 18.04.5
[15:37] <leftyfb> Sheilong: run the regular package upgrades and then we can continue.
[15:37] <leftyfb> Sheilong: sudo apt update ; sudo apt full-upgrade
[15:38] <leftyfb> Sheilong: I also suggest the latest HWE kernel: sudo apt install linux-image-generic-hwe-18.04
[15:40] <Sheilong> leftyfb: Okay. I will do it.
[15:42] <Sheilong> leftyfb: Done.
[15:42] <leftyfb> Sheilong: reboot
[15:44] <Sheilong> leftyfb: Done.
[15:45] <leftyfb> Sheilong: ( cat /etc/os-release ; uname -a ) | nc termbin.com 9999
[15:45] <Sheilong> leftyfb: it still shows #86~18.04.1-Ubuntu
[15:45] <leftyfb> Sheilong: please post the output termbin URL here
[15:45] <Sheilong> https://termbin.com/flpw
[15:46] <leftyfb> Sheilong: ok, and what do you get for messages about BT now?
[15:48] <Sheilong> leftyfb: no. Everything seems to be okay. However, it does not see any bluetooth device on.
[15:48] <Sheilong> https://termbin.com/geyw
[15:50] <leftyfb> Sheilong: hcitool dev
[15:50] <leftyfb> Sheilong: you'll need to install bluez-utils # if the command isn't found
[15:51] <Sheilong> leftyfb: hci0	DC:FB:48:75:1F:B0
[15:51] <leftyfb> Sheilong: ok, so your BT chipset is found and working
[15:51] <Sheilong> That's right. However, my phone is on and it can't find it.  I will switch between on and off the device.
[15:52] <Sheilong> after switch on and off, dmesg gives twice the message: "debugfs: File 'le_min_key_size' in directory 'hci0' already present!"
[15:52] <leftyfb> Sheilong: ok, so this is a usability issue. Why are you trying to pair your phone and laptop?
[15:54] <Sheilong> leftyfb: sorry, I meant Earphone
[15:54] <Sheilong> headphone
[15:55] <lotuspsychje> Sheilong: when you said your issue started after an update, did you mean after a kernel update, BT update or no clue wich?
[15:56] <Sheilong> lotuspsychje: It was a kernel update.
[15:56] <lotuspsychje> Sheilong: tnx, what you could try is boot a previous kernel as a test perhaps?
[15:56] <Sheilong> lotuspsychje: I did, but the problem remained.
[15:57] <leftyfb> lotuspsychje: I think we are passed it being a kernel issue
[15:57] <lotuspsychje> ah you tested
[15:57] <leftyfb> lotuspsychje: the chipset is detected and loaded just fine
[15:57] <lotuspsychje> kk
[15:57] <leftyfb> lotuspsychje: they weren't running HWE. I had them upgrade to it now
[15:57] <leftyfb> Sheilong: hcitool scan
[15:57] <leftyfb> Sheilong: do you see your headphones in the results?
[15:58] <Sheilong> leftyfb: No.
[15:58] <leftyfb> Sheilong: do you see any devices in the results?
[15:58] <leftyfb> Sheilong: are your headphones currently in pairing mode?
[15:59] <Sheilong> leftyfb: Also to make sure that the headphone is working I just connect it to my phone and it is working fine.
[15:59] <Sheilong> leftyfb: that command did returning nothing.
[15:59] <leftyfb> Sheilong: also, have you deleted the existing profile for your headphones from ubuntu so you can repair them?
[16:00] <Sheilong> leftyfb: Just did. Now I was able to connect.
[16:00] <Sheilong> leftyfb: Thanks so much for your help.
[16:01] <lotuspsychje> cookies for leftyfb
[16:22] <raub> join #nginx
[16:28] <doubletwist> So what are the caveats of disabling feature-pinning for apparmor? As an alternative to just uninstalling or disabling apparmor altogether which is the recommended 'fix' by Proxmox Mail Gateway
[16:39] <Hornet> Hello - having real strife with an anomalous boot issue - anyone able to invest a bit of time to assist?  Long story short, this is a headless home media server, which seems to (re?)boot into read only mode on / for reasons unknown. the uuid I can see in fstab doesn't match anything I can see in blkid or grub.cfg and I cannot see why/how it has
[16:39] <Hornet> changed (nor where it is even set to begin with)
[16:39] <Hornet> . Any help & support greatly appreciated
[16:39] <Hornet> fstab: https://termbin.com/4jrfp  mount: https://termbin.com/d68i  blkid: https://termbin.com/hplz   grub.cfg https://termbin.com/z3zl   grub probably is correct according to current blkid (547bf7de-c9c9-44c3-85ed-f02a07cbf4c9), it's fstab that has the wrong uuid: UUID=75755639-921e-4817-a790-353a6ea4d6c5 / ext4 errors=remount-ro 0  1
[16:40] <Hornet> however I cannot know (by nature of the problem) if that is what is causing it or not, it's the only obvious anomaly however
[16:54] <leftyfb> Hornet: look in "dmesg" for any I/O or related storage errors
[16:55] <Hornet> if there were any on the initial boot would they not have been lost? this is read only this boot so dmesg might as well not exist
[16:55] <Hornet> aiui anyway
[16:58] <ogra`> Hornet, dmesg goes to a ringbuffer in ram it will have all info from the moment the kernel starts
[16:59] <ogra`> (we're talking about the dmesg command, not about the /var/log/dmesg file)
[17:00] <Hornet> right thanks :)
[17:00] <Hornet> will look one sec
[17:00] <Hornet> https://termbin.com/2966 ogra`
[17:01] <ogra`> the UUID difference is normal, one is a GPT UUID the other a filesystem UUID ...
[17:03] <weedmic> Hornet: did this used to work, and then this happened, or is this a new setup and you are trying to get it to work the first time?
[17:04] <Hornet> used to work, was off for a while after a broken apt issue (circular dependancy unfulfillable yet somehow also uninstallable)
[17:04] <Hornet> I sorted that BUT then this issue appeared behind it
[17:04] <Hornet> apt was unable to work at all, so it's not as if it died part way
[17:04] <Hornet> it just jammed and couldn't operate
[17:05] <Hornet> re UUIDs, if you're sure then I'll take your word for it, thanks
[17:09] <ogra`> Hornet, that does not look like there are any errors, and yor fstab seems to be preocessed fine as well, given the mount shows everything mounted properly
[17:10] <ogra`> Hornet, what are the exact errors you get ... the system seems to have booted pretty correctly based on the info you give
[17:12] <Hornet> ogra`: there are no errors - I'm just stuck with a read only / partition
[17:12] <Hornet> and as there are no (save) errors I can't work out why
[17:12] <Hornet> *saved
[17:13] <ezakimak> NetworkManager failed to start, but I can't find any actual log info showing the cause
[17:13] <Hornet> ogra this is the fdisk -l output if it helps at all https://termbin.com/2a7u
[17:14] <ezakimak> "NetworkManager.service: Failed with result 'exit-code'" is all I got
[17:14] <Hornet> https://termbin.com/m5ky lsblk -f also
[17:14] <ogra`> Hornet, check if you see any errors with "journalctl -b", the dmesg log looks like a clean boot ... fdisk wont help here, the disks are all properly assigned and mounted, you look for mount errors
[17:15] <Hornet> looking one sec, thanks
[17:15] <Hornet> Jun 13 10:59:21 ArcaneSanctum kernel: Command line: BOOT_IMAGE=/vmlinuz-4.4.0-173-generic root=UUID=547bf7de-c9c9-44c3-85ed-f02a07cbf4c9 ro nomdmonddf nomdmonisw
[17:16] <Hornet> last entry in there about booting I think
[17:16] <leftyfb> ezakimak: you are running a modified version of ubuntu. The modification specifically being networking. I don't think we can support that here. Please contact your vendor for support.
[17:16] <ezakimak> cause you don't use network manager?
[17:16] <ezakimak> and you don't use systemd?
[17:17] <ezakimak> you can't tell me how to get log files out of it for an error message?
[17:17] <leftyfb> ezakimak: because your vendor removed netplan and who knows what other modifications
[17:17] <ezakimak> they claim it never had netplan to begin with
[17:17] <ogra`> Hornet, well, not sure where the last two options come from, the rest looks like a proper kernel cmdline
[17:17] <ezakimak> all netplan does is create config files
[17:17] <ezakimak> so how do you debug when that goes south?
[17:17] <Hornet> look at the date though - it's jun 13th. that hasn't been written to in ages
[17:18] <Hornet> certainly  not today's boot
[17:18] <ogra`> yeah, right
[17:18] <ezakimak> older version of ubuntu did not use netplan, do you not support that?
[17:18] <leftyfb> ezakimak: journalctl -u NetworkManager
[17:19] <ogra`> Hornet, well, try fdisk with the -N option, that will run it in no-op mode so you only see what it would do but it wont apply any changes
[17:19] <tomreyn> Hornet: did you run "journalctl -b" or just "journalctl"?
[17:19] <leftyfb> ezakimak: if you install an official release of ubuntu, we can help you
[17:19] <ogra`> oh, right
[17:19] <ogra`> -b should really come from the ringbuffer
[17:19] <Hornet> hornet@ArcaneSanctum:~$ sudo journalctl -b
[17:19] <ezakimak> the journal is useless. I already told you what it says
[17:20] <ezakimak> ah, I take that back, there's one more line that -xe didn't show me
[17:20] <tomreyn> Hornet: what does "uptime" report?
[17:21] <tomreyn> you said it was a server, so it's well possible that you last booted it on jnue 13?
[17:21] <Hornet>  18:21:16 up  1:46,  1 user,  load average: 0.00, 0.00, 0.00
[17:21] <Hornet> it was powered off so that would be a feat
[17:22] <tomreyn> the journal is indeed older than it should have been, though.
[17:22] <tomreyn> Hornet: what does this report?    cat /proc/version
[17:22] <Hornet> I promise you it was off. if it can run while unplugged I should have had it mining bitcoin
[17:23] <Hornet> hornet@ArcaneSanctum:~$ cat /proc/version
[17:23] <Hornet> Linux version 4.4.0-173-generic (buildd@lgw01-amd64-037) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12) ) #203-Ubuntu SMP Wed Jan 15 02:55:01 UTC 2020
[17:23] <tomreyn> that's a really old kernel. i assume your apt problems are not really solved
[17:23] <Hornet> it's not been turned on for a long time, I fixed the apt circular issue, but then this appeared
[17:24] <tomreyn> apparently this kernel was built on (and probably for) ubuntu 16.04, too
[17:24] <tomreyn> did you post output of "mount" above?
[17:24] <Hornet> DISTRIB_DESCRIPTION="Ubuntu 16.04.6 LTS"
[17:25] <Mekaneck> which is EOL
[17:25] <Hornet> I'm trying to update it!
[17:25] <Hornet> fstab: https://termbin.com/4jrfp  mount: https://termbin.com/d68i  blkid: https://termbin.com/hplz   grub.cfg https://termbin.com/z3zl fdisk -l: https://termbin.com/2a7u lsblk -f: https://termbin.com/m5ky
[17:25] <tomreyn> mount reports "/dev/sde2 on / type ext4 (ro,relatime,stripe=32730,data=ordered)"
[17:25] <tomreyn> note "ro"
[17:25] <Hornet> I do indeed note it
[17:25] <tomreyn> that's read-only
[17:25] <Hornet> that is the root of the issue (hurr no pun intended)
[17:25] <ogra`> thats what we were discussiong the last 20min 🙂
[17:25] <tomreyn> cat /proc/cmdline
[17:26] <tomreyn> probably has "ro" as well?
[17:26] <Hornet> yar
[17:26] <ogra`> it hopefully does
[17:26] <ogra`> thats a default
[17:26] <Hornet> BOOT_IMAGE=/vmlinuz-4.4.0-173-generic root=UUID=547bf7de-c9c9-44c3-85ed-f02a07cbf4c9 ro nomdmonddf nomdmonisw
[17:26] <tomreyn> so you asked to boot in read-only mode, and you got what you asked for., congratulations.
[17:26] <Hornet> I didn't ask it to though
[17:27] <Hornet> it's rebooting into it itself
[17:27] <tomreyn> well that'S what you or some software put into your grub.cfg, it would seem
[17:27] <ogra`> tomreyn, thats a default ... the initrd remonts it rw usually
[17:27] <ogra`> check your own machine 😉
[17:27] <tomreyn> ogra`: oh my, right
[17:27] <Hornet> UUID=75755639-921e-4817-a790-353a6ea4d6c5	/               ext4    errors=remount-ro 0       1
[17:27] <tomreyn> sorry
[17:28] <ezakimak> is it better to use dnsmasq via networkmanager or directly with systemd ?
[17:28] <ogra`> there must have been errors somewhere ... but they are not logged anywhere
[17:28] <Hornet> that's fstab's line about this (note UUID is different for reasons unclear)
[17:29] <Hornet> is there any way I can debug what is actually happening AT boot time?
[17:30] <ogra`> well, usually via dmesg and journalctl -b
[17:30] <ogra`> but the latter didnt give you a recent log
[17:30] <tomreyn> https://lists.ubuntu.com/archives/ubuntu-devel/2014-February/038095.html discusses nomdmonddf nomdmonisw
[17:31] <Hornet> https://termbin.com/s5ui that's dmesg
[17:31] <ogra`> i would try "fsck -N /dev/sde2" ... thats a no-op and should tell you about any errors
[17:31] <tomreyn> journalctl -eb    would move to the end of the log
[17:31] <Hornet> can I run that fsck from a mounted (even read only) system? iirc fscks on mounts act weirdly
[17:32] <ogra`> as long as it is readonly it should be fine
[17:32] <ogra`> and as long as you use -N 🙂
[17:34] <Hornet> tomreyn, that shows the last 20 minutes!
[17:34] <Hornet> should I reboot it and try to see if anything useful ends up there?
[17:34] <ogra`> yay
[17:36] <tomreyn> hmm, still weird that it started logging this session so long ago.   journalctl -p4 -b | nc termbin.com 9999    should give us more clues
[17:36] <tomreyn> oh wait this is 16.04, it doesn't usually have persistent journald
[17:37] <Hornet> sudo journalctl --since=yesterday --until=now >>> https://termbin.com/wasj
[17:38] <Hornet> thanks greatly for helping with this btw. I seem to end up with all the exotic issues
[17:38] <ogra`> well, thats already readonly ...
[17:39] <tomreyn> Jul 08 16:35:03 ArcaneSanctum ntpdate[987]: [..] offset 2180128.236919 sec    might explain some weirdness about logs.
[17:39] <ogra`> yeah
[17:40] <ogra`> smells like a wrong BIOS clock or broken battery ... but that still doesnt explain the readonly state
[17:40] <tomreyn> it doesn't. but we can assuem that    jorunalctl -b   does indeed output the current boot log.
[17:41] <ogra`> the fact that npdate runs successfully before the network is up is also interesting
[17:41] <Hornet> the battery is old, I can change it, fairly sure I have a spare
[17:41] <Hornet> I have no idea how it's doing that bit of voodoo though?
[17:42] <ogra`> so paste the full log of journalctl -b, the timestamps might be moot here
[17:43] <Hornet> uptime shows correct current time, but will do, one sec
[17:43] <Hornet> https://termbin.com/be1p
[17:45] <ogra`> Jun 13 10:59:21 ArcaneSanctum kernel: EXT4-fs (sde2😞 mounted filesystem with ordered data mode. Opts: (null)
[17:45] <Hornet> wait how are there errors in there about read only filesystesms
[17:45] <ogra`> looks all good
[17:45] <ogra`> Jun 13 10:59:21 ArcaneSanctum systemd-remount-fs[279]: /bin/mount for / exited with exit status 1.
[17:45] <ogra`> there you go !
[17:46] <ogra`> Jun 13 10:59:21 ArcaneSanctum systemd-remount-fs[279]: mount: can't find UUID=75755639-921e-4817-a790-353a6ea4d6c5
[17:46] <ogra`> so you are right ... the UUID is wrong in fstab it seems
[17:46] <Hornet> if this is saved on the / drive how was this log even written
[17:46] <Hornet> that was my gut reaction but I thought uuids couldn't change ever
[17:47] <Hornet> and I certainly didn't put that in there
[17:47] <ogra`> its not written ... journald logs to ram by default and only flushes to disk later
[17:47] <Hornet> oh I see so that 'old' log is actually today still
[17:47] <ogra`> most likely, given your clock is off
[17:48] <Hornet> I thought the last time I worked on it was the 13th though (my birthday so I remembered)
[17:48] <ogra`> so for a test i'd try to comment the original / entry in fstab and change to the correct one for sde2
[17:48] <Hornet> that's one hell of a coincidence if so
[17:49] <Hornet> I'll have to edit that with a live boot usb then, I'll dig one up and wire the box into something visual
[17:49] <ogra`> 547bf7de-c9c9-44c3-85ed-f02a07cbf4c9
[17:49] <ogra`> that seems ot be the one you want
[17:49] <Hornet> I know! /dev/sde2: LABEL="slash" UUID="547bf7de-c9c9-44c3-85ed-f02a07cbf4c9" from blkid
[17:49] <Hornet> but that should -always- have been the one in fstab
[17:49] <ogra`> you can just "sudo mount -o remount,rw /"
[17:50] <ogra`> and then edit fstab
[17:50] <Hornet> something has altered that, or, the sde2 uuid has changed since I wrote it in fstab
[17:50] <Hornet> oho, black magic, I'll try 2 seconds
[17:50] <ogra`> well, UUIDs can be changed with tune2fs ...
[17:50] <ogra`> perhaps you ran something that called it or so
[17:51]  * ogra` needs to go afk ... but i'll return later ...
[17:51] <Hornet> mount: can't find UUID=75755639-921e-4817-a790-353a6ea4d6c5
[17:51] <Hornet> lol.
[17:51] <Hornet> thanks greatly for your help though :)
[17:51] <Hornet> same fstab error is causing it to begin with
[17:52] <Hornet> maybe we should have just done the remount command as debug stage 1!
[17:52] <tomreyn> that's not safe to do if the file system is corrupt
[17:52] <ogra`> it isnt corrupt ... the UUID changed somehow
[17:53] <ogra`> which causes: Jun 13 10:59:21 ArcaneSanctum systemd-remount-fs[279]: mount: can't find UUID=75755639-921e-4817-a790-353a6ea4d6c5
[17:53] <ogra`> so it never gets remounted RW
[17:54] <ogra`> anyway, out ...
[17:54] <Helmholtz1> Why none my SysReq Magic sequences work except hard reboot?
[17:54] <tomreyn> does this rule out that the file system is corrupt? i don't assume it is since we know that the initial mount failed.
[17:54] <tomreyn> but we only learnt this in the past 5 miuntes, i think
[17:56] <tomreyn> Helmholtz1: i think some others should fwork, too, but certainly not all of them:  cat /etc/sysctl.d/10-magic-sysrq.conf
[18:00] <tomreyn> Hornet: so you know how to proceed?
[18:00] <Hornet> tomreyn: going to live boot something to edit that fstab manually, then reboot and see what blows up
[18:00] <Hornet> wiring up kvm atm
[18:01] <tomreyn> why live boot, did you not remount.rw already?
[18:01] <Hornet> no, it can't remount as fstab is errant!
[18:02] <Hornet> that's the root of all this, as I suspected an hour ago
[18:02] <Helmholtz1> tomreyn, huh...so enabling them is a security issue
[18:02] <Hornet> hornet@ArcaneSanctum:~$ sudo mount -o remount,rw /
[18:02] <Hornet> [sudo] password for hornet:
[18:02] <Hornet> mount: can't find UUID=75755639-921e-4817-a790-353a6ea4d6c5
[18:02] <alkisg> You can override /etc/fstab if you want
[18:02] <Hornet> hornet@ArcaneSanctum:~$
[18:02] <alkisg> You can create /run/fstab and then run mount --bind /run/fstab /etc/fstab
[18:02] <alkisg> And then mount -o remount,rw /
[18:02] <alkisg> (although mount -o remount,rw <device> should work even without the fstab being correct)
[18:03] <Hornet> I've already moved the server so can't try that now
[18:03] <Hornet> will let you know what happens in a few though
[18:03] <tomreyn> make sure you really reinstall or upgrade this system once this is solved
[18:03] <Hornet> I wanted to upgrade to 20.4 lts
[18:04] <tomreyn> Helmholtz1: yes, can be, depends.
[18:04] <Helmholtz1> `enable sync command`
[18:04] <Helmholtz1> what is this?
[18:04] <tomreyn> sync write buffers to storage
[18:04] <Helmholtz1> So in general what can I do when system is completely hung up?
[18:05] <Helmholtz1> Like even mouse doesn't move
[18:05] <tomreyn> ssh in, or switch to a tty
[18:05] <tomreyn> or use a netconsole, or a serial console
[18:06] <tomreyn> if none of this works wither, then you can just sysrq sync + reboot
[18:06] <tomreyn> *either
[18:08] <Helmholtz1> tomreyn, This is my main laptop. even can't switch to TTY. A particular vpn app causes this
[18:08] <Helmholtz1> I don't know it's Firefox bug or this app's bug
[18:08] <Helmholtz1> honestly, Linux shouldn't behave like this
[18:08] <tomreyn> it doesn't
[18:08] <tomreyn> unless the app takes all resources
[18:09] <Helmholtz1> I mean kernel shouldn't let it take all resources
[18:09] <Helmholtz1> at least keyboard input should interrupt everything
[18:09] <tomreyn> you mean ctrl-c? that wouldn't work on X
[18:11] <tomreyn> you probably should not be running "a particular vpn app", or run it differently, mor constrained, if it achieves to put the system out of cpu resources
[18:12] <tomreyn> sync has the benefit that you may be able to tell what went wrong after reboot, by reviewing the logs from before you rebooted
[18:12] <Helmholtz1> tomreyn, embarrased to say that I didn't understood "write buffers"?
[18:13] <Helmholtz1> What buffers? did you mean journald?
[18:13] <oerheks> No need for a 'particular vpn app', just a few mouseclicks and name/password .. https://help.ubuntu.com/stable/ubuntu-help/net-vpn-connect.html.en
[18:14] <Helmholtz1> oerheks, every vpn app does its own thing. some use openVPN (which could be integrated as you said)..some reverese SSH...newer ones wireguard
[18:14] <Helmholtz1> This one is a go-app which does reverese SSH I guess
[18:14] <oerheks> oh, that worries me..
[18:15] <alkisg> Helmholtz1: when an app writes to disk, the kernel may cache it instead. "sync" writes that cache/buffer to disk
[18:15] <tomreyn> Helmholtz1: disk writes don't usually go to disks immediately, but are kept in memory for a few a few seconds, so as to prevent constatly writing to the disk. that's write buffering.
[18:16] <Helmholtz1> So when we sync, it essentially flushes every running app's working memory to disk (if it wanted to write to disk in the first place)
[18:16] <Helmholtz1> So if this app does not write its log, sync would not be heplful
[18:16] <tomreyn> so if there are important logs on this critical event that caused the system to become unresponsive for you, have been logged to ram only, but not yet written to disk, and you reboot (without syncing the write buffer to disk) then you'll loose those
[18:17] <Helmholtz1> It spams ~/.Xresources about warnings on gtk tray though
[18:17] <Helmholtz1> tomreyn, Can journald somehow catch what process got all system resources?
[18:18] <Helmholtz1> s/~/.Xresources/X-session-errros
[18:18] <tomreyn> no, not unless something logs it there
[18:18] <tomreyn> which ubuntu releae and desktop are you running?
[18:19] <Helmholtz1> tomreyn, 18.04 but Xfce..
[18:20] <Helmholtz1> I know it's outdated
[18:20] <Helmholtz1> https://dpaste.com/A8KPJQ34P
[18:20] <tomreyn> the hardware or the ubuntu release?
[18:20] <Helmholtz1> My journald is spammed by ;CPU0: Package temperature above threshold, cpu clock throttled (total events = 11153)'
[18:20] <Helmholtz1> tomreyn, the release
[18:21] <tomreyn> i don't help with eol releases unless it's about upgrading to a supported release
[18:21] <Helmholtz1> tomreyn, ok 🌹
[18:22] <oerheks> rtkit-daemon, only puseaudio uses that, IIIRC
[18:23] <oerheks> oh, EOL xfce .. i hope you have Firefox 89.0.2
[18:49] <morgans> Where doies cheese store it's images, ubuntu 20.04 - yes I did try google.
[18:50] <morgans> Where does cheese store i's images? ubuntu 20.04 - yes I did try google.
[18:50] <morgans> Where does cheese store its images? ubuntu 20.04 - yes I did try google.
[18:50] <oerheks> morgans, standard in ~/Pictures
[18:50] <morgans> let me look again.
[18:51] <Mekaneck> If you googled it for real you'd know it: By default, Cheese saves the photos and videos in the Webcam folder in your user's Photo or Videos folder of your home folder.
[18:51] <morgans> DOH. In the "Webcam" folder. Thanks for being kind to the dumb. (And would help some of us in some Ubuntu help page.)
[18:52] <morgans> Thanks oerheks
[18:52] <Mekaneck> my next answer was ~/Pictures/Webcam
[18:52] <Mekaneck> :)
[18:54] <Hornet> ogra` , tomreyn : looks like that has it writing again
[18:54] <Hornet> took a long time to boot up to sshable though, when I had it on monitor it was running disk checks
[18:55] <tomreyn> Hornet: congrats. and: hush, release upgrade time
[18:55] <Hornet> unsure if it should be doing that each boot but who knows, problem for another time! next step is upgrading yes
[18:55] <Hornet> is there likely to be anything complex about an upgrade from this old?
[18:55] <tomreyn> it probably needed to check all file systems during this boot
[18:55] <Hornet> last boot was the same except no networking (no cable that reaches here)
[18:56] <Hornet> time taken implies it did the same checks
[18:56] <Hornet> it's now back in the corner by the router
[18:56] <tomreyn> make sure you have internet access so you can bring it up to date on 16.04
[18:57] <tomreyn> then disable all third party repositories, then sudo apt update, then check what you need to remove or downgrade, yet: what does this output? apt list --installed | grep ',local\]$' | nc termbin.com 9999
[18:57] <Hornet> hrmmmm, apt can't lock
[18:58] <tomreyn> maybe you have unattended-upgrades installed
[18:58] <Hornet> https://termbin.com/0j7w
[18:59] <tomreyn> finally, when this and anything around apt updates + apt full-upgrade  looks sound, you can do the release upgrade
[18:59] <tomreyn> (after ensuring complete and restorable backups are present)
[19:01] <Hornet> root      1325  0.0  0.0   4500   668 ?        Ss   19:52   0:00 /bin/sh /usr/lib/apt/apt.systemd.daily update
[19:01] <Hornet> root      1338  0.0  0.0   4500  1568 ?        S    19:52   0:00 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held update
[19:01] <Hornet> hornet    2085  0.0  0.0  14224   924 pts/0    S+   20:01   0:00 grep --color=auto -i apt
[19:02] <Hornet> so if that's something working in the background should I just wait & hope it sorts things out itself?
[19:04] <sarnold> Hornet: yeah, just wait for that to run to completion
[19:06] <tomreyn> you can run   watch pstree -n 1325   to see whether it's child processes are changing
[19:12] <Hornet> seems to show nothing
[19:12] <sarnold> ah then it's probably done and you can start your apt update && apt upgrade commands
[19:13] <Hornet> however in ps aux the pids have changed for those programs
[19:13] <Hornet> no
[19:13] <Hornet> looks like it reexecuted them
[19:13] <Hornet> I think
[19:13] <sarnold> d'oh
[19:13] <Hornet> if it thinks it's actually doing something though then I'll let it
[19:33] <alkisg> "repty" lets you "steal" the stdio tty from a process, maybe that way we can interact with unattended upgrades when we want to...
[19:34] <sarnold> they're running without a pty in the first place, so I'm not sure if you could realistically attach one after the fact. (I'd be curious what your results are ;) -- but because it's not intended to have a terminal, I don't think there's much room for interacting with it
[20:25] <TJ-> You'd need to set APT::Periodic::Verbose = 3 to see what it is doing
[20:29] <TJ-> there's a neat wrapper around gdb called fdswap which could change the current file descriptor targets on a running process. https://www.redpill-linpro.com/sysadvent/2015/12/04/changing-a-process-file-descriptor-with-gdb.html
[21:03] <morgans> how do I change my background image (fill zoom tile...) - i googled it but the control is no longer in Appearances or in Background.
[21:04] <Mekaneck> morgans: on Gnome.... not
[21:04] <morgans> nor in Display. (have been looking at the suggestions. BTW I use duckduckgo not the goog
[21:06] <oerheks> click on background >right mouse, change background?
[21:07] <Mekaneck> oerheks: he means the zoom, tile, fill options
[21:07] <Mekaneck> those options are gone in Gnome
[21:08] <oerheks> Oh oke, yes, they are moved to gnome-tweak-tool
[21:08] <Mekaneck> ah, true
[21:08] <Mekaneck> morgans: sudo apt install gnome-tweak-tool
[21:09] <Mekaneck> after that you'll find it as Tweaks among the other apps
[21:09] <Mekaneck> there you'll find the zoom, tile, fill options
[21:09] <Mekaneck> thanks oerheks
[21:09] <oerheks> centered scaled stretched ..
[21:12] <morgans> oerkecks, I have it. Will go there. (not ready for ordinary let alone prime time. (what were they thinking to remove that?)
[21:13] <morgans> what do I do to show the entire desktop without minimizing each window one by one?
[21:14] <oerheks> i think there is a list of short keys?
[21:21] <Mekaneck> morgans: https://wiki.gnome.org/Design/OS/KeyboardShortcuts
[21:24] <Mekaneck> morgans: if you have issues running Gnome 3 know there's also Ubuntu MATE with a traditional Gnome 2 layout back from the good old days and there's Kubuntu and Xubuntu too. You could try those then.
[22:18] <nuxil> is it possible to create a 8K resolution or alike, in ubuntu when its running in a vm? i tried using cmd: xrandr --size 7680x4320  but it says no availeble modes for that resolution.
[22:22] <weedmic> nuxil: yes, but... you need a physical second gpu that you can assign to the VM.  if you are using an ethereal gpu, then no as you only get 128mb max.
[22:23] <nuxil> the thing is i need a virtual resolution that is bigger than what the monitor can provide.
[22:30] <nuxil> hmm
[22:32] <DrManhattan> I love the whole "Use of this channel implies acceptance of TOS"
[22:32] <DrManhattan> that's cute
[22:33] <leftyfb> DrManhattan: can we help you with something?


[02:45] <superfly> Lekker thunderstorm here this evening. Even managed to catch a couple of pictures of lightning with my phone.
[07:12] <inetpro> good morning everyone
[07:45] <Kilos> morning inetpro and every one else
[07:48] <inetpro> Kilos: eh, all good here and you?
[07:48] <Kilos> ok ty sir
[07:48] <inetpro> some readings for you: https://lonesysadmin.net/2017/07/10/the-dangers-of-experts-writing-documentation-a-real-life-example/
[07:49] <Kilos> ty
[07:49] <Kilos> just like i said they dont say things for the novice to understand
[07:50] <Kilos> i go read more
[07:50] <inetpro> clearly there's always opportunity in that for others to do a better job :-)
[07:50] <Kilos> the problem is of course
[07:51] <Kilos> once one is capable of actually writing such help info that you forget how you struggled to get there in the first place
[08:01] <Kilos> hahaha
[08:01] <Kilos> ty for that inetpro
[09:39] <paddatrapper> i need suggestions: I'm looking for a streaming/logging daemon for radio. It/they need to capture from a single soundcard input and stream to shoutcast 24/7. The recording needs to happen in 10min segments named by the date and time. I currently have the recording done via cron and arecord in an lxc container, but darkice in another container is causing issues on the streaming side of things
[11:59] <ebusuku-lappy> Hi all
[12:57] <thatgraemeguy> https://mybroadband.co.za/news/software/219056-ubuntu-linux-now-available-in-windows-store.html
[12:57] <thatgraemeguy> LOL, what a time to be alive :D :D