 @lugito [<lugito>  3[ Needs Revision  3]  Bump version number for new release.:  2https:/ …], @kc2bez
 @The_LoudSpeaker Have commented on your diff.
 @RikMills [@The_LoudSpeaker Have commented on your diff.], I will take a look
 ```ubuntu@focal-dev:~/globalkeys/lxqt-globalkeys$ arc patch D69 --no-branch … (Assuming '--no-branch' is the British spelling of '--nobranch'.)```
 XD
[13:30] <The_LoudSpeaker> @RikMills re: https://phab.lubuntu.me/P58 you want to pointout changelog changes ?
 @The_LoudSpeaker [<The_LoudSpeaker> @RikMills re: https://phab.lubuntu.me/P58 you want to pointout …], Not sure what you mean. … It is VERY simple. Your diff must make the resultant debian/changelog in lubuntu git precisely match the debian/changelog in the .debian.tar.xz you uploaded to the archive.
[13:54] <theloudspeaker> gotcha. only changelog is different in phab accordign to D69
 @tsimonq2 [(merge from Debian's git and squash it all into one commit)], also this ^^
[14:03] <theloudspeaker> updated
[14:05] <theloudspeaker> <lubot "<RikMills> @tsimonq2 [(merge fro"> k.
[14:05] <theloudspeaker> check https://phab.lubuntu.me/D69 now RikMills
[14:05] -lugito:#lubuntu-devel- [Needs Review] Bump version number for new release.: https://phab.lubuntu.me/D69


[18:46] <Creeture> What's the yaml syntax for multiple yum_repos entries in user-data? Is it standard array syntax?


[00:03] <thumper> davecheney: command doesn't depend on version.Version
[00:03] <thumper> I was thinking about adding some automatic deprecation checks
[00:03] <thumper> based on version
[00:04] <thumper> but I don't want to introduce the dependency
[00:04] <thumper> so I'll just go for 'deprecated bool'
[00:04] <thumper> oh...
[00:04] <thumper> you suggestion had me thinking...
[00:05]  * thumper will ponder for a bit
[00:14] <davecheney> thumper: wanna do the 1 on 1 now
[00:14] <thumper> davecheney: sure
[00:14] <davecheney> no reason to delay
[00:14] <davecheney> i'll see you in the hangout
[00:15] <thumper> kk
[02:07] <thumper> waigani: one to one?
[02:08] <waigani> thumper: ah, I'm in the wrong chan
[02:09] <waigani> thumper: my google cal is crashing for me - can you paste me the link please?
[03:14] <menn0> thumper, waigani: auto multi-env filtering: http://reviews.vapour.ws/r/551/diff/
[03:52] <thumper> menn0: awesome, looking now
[03:53] <thumper> menn0: hey, the diff fits on one page \o/
[03:55] <davecheney> +1
[03:56] <menn0> cool :)
[04:06] <waigani> thumper, menn0, davecheney: we have tests! http://reviews.vapour.ws/r/474/
[04:13] <davecheney> type ListMode bool
[04:13] <davecheney> var ( FullKeys     ListMode = true Fingerprints ListMode = false
[04:13] <davecheney> seriously
[04:13] <davecheney> this is an api parameter
[04:13] <davecheney> it has two states
[04:13] <davecheney> FullKeys or Fingerprints
[04:13] <davecheney> it is not possible to add a new state
[04:14] <davecheney> and when the gui calls it
[04:14] <davecheney> it has to say { Mode: true }
[04:14] <davecheney> What the F
[04:53] <waigani> menn0: http://reviews.vapour.ws/r/551/
[04:58] <waigani> menn0: just realised I didn't click 'publish'
[06:08] <axw> wallyworld_: I'm working this afternoon, as I've got a school assembly to go to on Thursday morning and a school workshop on Friday morning. let me know if you need anything...
[06:09] <wallyworld_> axw: will do, thanks
[06:09] <wallyworld_> i'm going to ping andres later to set up a meeting for this week
[07:53] <davecheney> 2/win11
[08:19] <wallyworld_> axw: thanks for reviewing the gwacl mp, i just went to do it and it had been done \o/
[08:22] <axw> wallyworld_: no worries
[09:21] <wallyworld_> dimitern: thanks for looking at those networking bugs
[09:23] <dimitern> wallyworld_, np, I can do more if we had the lshw dump
[09:25] <wallyworld_> yeah, hopefully he can provide it
[10:03] <jam1> voidspace: standup ?
[10:03] <voidspace> oops
[10:03] <voidspace> jam1: omw
[10:05] <hazmat> axw, the lshw /block dev question on the list brings up an interesting question.. if i do have say extra physical block devs on one unit but not others, would i see them? ie. storage spec is at a service level. thanks for the review and catch on azure regions
[10:08] <hazmat> axw, hmm.. the microsoft guy pointed out a new api which does a limited form of the static map we're doing currently for azure http://msdn.microsoft.com/en-us/library/azure/gg441293.aspx
[10:08] <hazmat> fwiw
[10:47] <hazmat> jam, ping
[10:57] <hazmat> dimitern, out of curiosity what is the logic for juju-br0 selection?
[10:57]  * hazmat is looking at the lshw output
[10:58] <dimitern> hazmat, the first network device or the one with network:0 index in the lshw xml dump
[10:59] <hazmat> dimitern, aha.. default 0 behavior perhaps.. eth2 is mellanox with id="network"
[11:00] <dimitern> hazmat, can I see the dump?
[11:00] <hazmat> dimitern, its in the bug
[11:01] <hazmat> dimitern, https://bugs.launchpad.net/juju-core/+bug/1395908/+attachment/4267056/+files/1395908.tar.gz
[11:01] <mup> Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration <lxc> <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1395908>
[11:02] <dimitern> hazmat, these are just logs, no lshw xml output
[11:05] <hazmat> hmm
[11:06] <hazmat> dimitern, right bug, wrong attachment.. https://bugs.launchpad.net/juju-core/+bug/1395908/+attachment/4271935/+files/lshw.tar.gz
[11:06] <mup> Bug #1395908: LXC containers in pending state due to juju-br0 misconfiguration <lxc> <oil> <juju-core:Triaged> <https://launchpad.net/bugs/1395908>
[11:09] <dimitern> hazmat, ah, I see the issue - the logic should skip network devices marked with disabled="true"
[11:39] <wallyworld_> hazmat: you free for the meeting about zone constraints later in your day?
[11:39] <hazmat> wallyworld_, yeah.. just rearrange the cal a bit for it
[11:39] <hazmat> er..i just rearranged
[11:39] <wallyworld_> hazmat: thanks, hard to find a time to suit aus, eng and us
[11:40] <hazmat> wallyworld_, np. thanks for setting it up.
[11:40] <wallyworld_> sure
[11:49] <voidspace> dimitern: do you think IP address must have a Refresh method? We don't need it currently. (We did need it for Subnet.)
[11:50] <dimitern> voidspace, no need for Refresh
[11:52] <dimitern> voidspace, there won't be a life field; the only change that can happen is to set the state to "unavailable" or "allocated"
[11:52] <voidspace> dimitern: yep, thanks
[11:52] <dimitern> voidspace, but those transitions can be handled internally with proper asserts
[11:54] <voidspace> dimitern: so UpdateState should take an IPAddress (rather than a string value) and assert that the state has not changed in the transaction that sets the new state?
[11:54] <dimitern> voidspace, yeah, so if that assert fails, we can reload the doc from state and retry
[11:54]  * fwereade_ lunch, walk
[11:55] <dimitern> voidspace, I'd suggest using SetStatus or SetState rather than UpdateState (for consistency with other state objects)
[11:55] <voidspace> dimitern: if we're just going to retry, why not just set the new state directly
[11:55] <voidspace> dimitern: (yes on name)
[11:55] <voidspace> dimitern: all we need to assert is that the ip address still exists
[11:56] <voidspace> dimitern: I would only check state if we're going to fail because of stale data
[11:57] <dimitern> voidspace, we need to retry in principle, because we assume stale data
[11:57] <voidspace> dimitern: if we're only setting a new state - and we will force that to succeed by retrying - why assert the old state matches?
[11:57] <voidspace> dimitern: we don't care if it matches, we're setting the new state *anyway*
[11:58] <dimitern> voidspace,  if the address state goes only forward (like life) we need to ensure we won't set a state which is impossible
[11:58] <voidspace> dimitern: can it only go forward?
[11:58] <voidspace> dimitern: I guess it should only go from "" to "allocated" or "unavailable"
[11:58] <voidspace> dimitern: but in which case we shouldn't retry, but fail
[11:59] <dimitern> voidspace, shouldn't we allow Unknown -> Allocated|Unavailable  only?
[11:59] <voidspace> dimitern: right - so we *shouldn't* retry then, we should fail
[11:59] <voidspace> and assert that State is Unknown
[11:59] <dimitern> voidspace, let's think how it'll go
[12:00] <voidspace> we pick a new address - initially created with State Unknown
[12:00] <voidspace> then we attempt to allocate and it goes to Allocated or Unavailable
[12:00] <dimitern> voidspace, new address -> set to unknown (i.e. "reserve" a doc for it until we decide the final state for that address)
[12:00] <voidspace> dimitern: until we start using this model for "other addresses"
[12:00] <dimitern> voidspace, existing unknown address -> set to allocated or unavailable, but fail if it's already set
[12:00] <voidspace> initially that's the only use case
[12:00] <dimitern> voidspace, *or* don't fail if the state is already the one we want to set
[12:01] <voidspace> ah, ok - so the assert is State == Unknown || NewState
[12:01] <dimitern> voidspace, yeah, I think so
[12:01] <voidspace> dimitern: do you know of an existing assert that is similar, so I can see how to implement that?
[12:02] <voidspace> I can just grep through state to see though
[12:02] <dimitern> voidspace, it's easy - you can combine assert
[12:02] <dimitern> voidspace, just a sec
[12:05] <dimitern> voidspace, unknownOrSame := bson.D{{"state", bson.D{{"$nin", []string{"unknown", newState}}}}}
[12:05] <voidspace> dimitern: thanks!
[12:05] <dimitern> $nin=not in list
[12:05] <dimitern> voidspace, np
[12:06] <voidspace> dimitern: so that asserts that the state *is* one of the listed ones?
[12:07] <dimitern> voidspace, yes -- we have a cached view of the data, and as long as this holds we're good, otherwise (assert fails) reload and redo
[12:07] <dimitern> (if it makes sense to)
[12:07] <voidspace> cool, thanks
[12:07] <voidspace> "not in list" is an odd name for an assert that does the opposite (assert that the specified field *is* one of the ones in the list)
[12:08] <dimitern> voidspace, ah, sorry :)
[12:08] <dimitern> voidspace, you're right - it should've been "$in"
[12:08] <voidspace> dimitern: :-)
[12:10] <voidspace> dimitern: and SetState should be an IPAddress method rather than State.SetIPAddressState ?
[12:10] <voidspace> we will always have an IPAddress when we need to use it, so it makes sense - I'd just assumed a State method though
[12:10] <voidspace> (for no good reason it seems)
[12:10] <dimitern> voidspace, yes, that's the usual case
[12:11] <dimitern> voidspace, well - we create an "unknown" address, then update it to allocated or unavailable
[12:11] <voidspace> dimitern: yep
[13:25] <axw> hazmat: well, I had intended for storage specification to be at the unit level (specifiable at service level, which would cascade/merge down)
[13:25] <axw> hazmat: as for the Azure API, doesn't look like it has much useful info in it
[13:26] <axw> I mean, useful to us...
[13:26]  * axw goes afk again
[13:27] <hazmat> axw, g'night
[13:42] <perrito666> brb
[14:01] <abentley> sinzui: Industrial testing on AWS has been failing because there's no subnet for AZ us-east-1e: https://pastebin.canonical.com/121381/
[14:59] <mattyw> has anyone seen fwereade_ ?
[14:59] <fwereade_> mattyw, I'm around, did I miss a ping?
[15:00] <mattyw> fwereade_, you might have done - but I'll forgive it
[15:05] <natefinch> perrito666: standup?
[15:06] <perrito666> ngetting there trying to find my headphones
[15:35] <voidspace> dimitern: should we require IP address type to be provided in the IPAddressInfo (argument to AddIPAddress)
[15:35] <voidspace> dimitern: or should we infer it from the actual address provided?
[15:36] <voidspace> dimitern: I'm inclined to infer it and remove it from IPAddressInfo
[15:36] <dimitern> voidspace, hmm.. why not take a network.Address instead?
[15:37] <voidspace> dimitern: ah, fair point
[15:37] <dimitern> voidspace, it has all the needed fields already, we just need to convert it from network.Address into a doc
[15:37] <voidspace> dimitern: ok, better do some reqorking
[15:37] <voidspace> dimitern: yep, good point
[15:37] <voidspace> dimitern: should I still validate the IP address?
[15:37] <voidspace> dimitern: I guess not
[15:38] <voidspace> dimitern: the only thing that prevents is *creating* an address in anything but an Unknown state
[15:38] <voidspace> dimitern: but if we ever have that use case it's easy to just call SetState after creation
[15:39] <dimitern> voidspace, I think we should validate it
[15:39] <voidspace> dimitern: ok
[15:39] <dimitern> voidspace, before storing it in state at least
[15:39] <voidspace> dimitern: yep
[15:39] <dimitern> voidspace, in the network package there are some validation methods I think you can use
[15:39] <voidspace> dimitern: net.ParseIP is easy enough
[15:40] <voidspace> I don't think I need anything more than that, but I can take a look
[15:41] <dimitern> voidspace, ok - I've just looked and there are no special validation methods for network.Address
[15:45] <voidspace> dimitern: I couldn't find any either... :-)
[15:46] <sinzui> natefinch, Can you get people to look into bug 1397376 and bug 1397995?
[15:46] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397376>
[15:46] <mup> Bug #1397995: 1.21b3: juju status isn't filtering by service <landscape> <regression> <status> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397995>
[15:47] <sinzui> natefinch, bug 1396981 is also critical, but needs discussion about scope. I am going to update the bug with my understanding of the issue
[15:47] <mup> Bug #1396981: Upgrade fails with tools sha mismatch because product json is renamed <ci> <regression> <upgrade-juju> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1396981>
[15:53]  * perrito666 notices that google tells him that is going to upgrade his calendar ... nothing changes
[15:54] <natefinch> sinzui: ok
[15:56] <natefinch> fwereade_: I was thinking, since I just used the skeleton provider to create the outline for the gce provider, maybe I should just copy it to make a real skeleton provider..... since I had to do a lot of work to get the skeleton provider to compile.
[15:57] <fwereade_> natefinch, +1000
[15:57] <fwereade_> natefinch, it seriously sucks that I got distracted and never merged that
[15:57] <fwereade_> natefinch, getting it into the source tree would prevent it from being such a horrible hassle again
[15:58] <natefinch> fwereade_: that's what I was thinking.  I'll make a separate branch for it, shouldn't be too much work
[15:58] <fwereade_> natefinch, tyvm
[16:07] <alexisb> fwereade_, sorry, will be there shortly
[16:07] <fwereade_> alexisb, np
[16:14] <voidspace> dimitern: ooh, if we take a network.Address it doesn't allow us to set a MachineId, SubnetId or InterfaceId
[16:14] <voidspace> dimitern: shall I provide setters for those?
[16:14] <voidspace> dimitern: especially subnet id we want
[16:15] <dimitern> voidspace, hmm.. we can also take them as args
[16:15] <voidspace> dimitern: for SubnetId that makes sense
[16:15] <voidspace> dimitern: as we will always (initially) want it
[16:15] <voidspace> dimitern: MachineId and InterfaceId that will be a nuisance as we will rarely want to set them initially
[16:15] <dimitern> voidspace, yeah, and the rest (esp. machine id) won't be known at first
[16:15] <voidspace> dimitern: shall I add setter methods for those two?
[16:16] <dimitern> voidspace, let's have setters yeah
[16:16] <voidspace> dimitern: cool
[16:16] <dimitern> voidspace, cheers
[16:19] <voidspace> dimitern: hmmm... Dave Cheney said that we shouldn't add new dependencies to state
[16:19] <voidspace> dimitern: this PR adds network
[16:19] <voidspace> dimitern: I assume that "low-level" dependencies like that are permitted
[16:19] <dimitern> voidspace, good point
[16:19] <dimitern> voidspace, but I think we already import network in state
[16:20] <voidspace> dimitern: nope, it's showing in the diff
[16:20] <dimitern> voidspace, we do in some tests and in network.go
[16:21] <dimitern> voidspace, and in address.go
[16:21] <voidspace> ah...
[16:21] <voidspace> dimitern: right, so it's not actually a new dependency
[16:21] <voidspace> dimitern: I was just looking state/state.go
[16:21] <voidspace> :-)
[16:21] <dimitern> voidspace, :) whew..
[16:22] <dimitern> voidspace, well, for one this sort of dependency makes sense to me
[16:22] <voidspace> it's not a structural dependency which is the real problem
[16:22] <voidspace> and state has to deal with networking concepts
[16:22] <dimitern> exactly
[17:01] <alexisb> natefinch, IBM interlock
[17:34] <alexisb> jam, on and ready when you are
[18:48] <voidspace> g'night all
[18:49] <perrito666> gnight
[18:50] <voidspace> o/
[19:40] <sinzui> perrito666, natefinch , do either of you have time to review http://reviews.vapour.ws/r/554/diff/#
[19:42] <perrito666> sinzui: done, nate is most likely not here
[19:42] <sinzui> thank you perrito666
[19:42] <perrito666> yw
[19:47] <thumper> morning folks
[19:47] <perrito666> thumper: hi
[19:50] <thumper> sinzui: got a minute?
[19:51] <thumper> sinzui: I'd like to discuss https://bugs.launchpad.net/juju-core/+bug/1397376
[19:51] <mup> Bug #1397376: maas provider: 1.21b3 removes ip from api-endpoints <api> <cloud-installer> <landscape> <maas-provider> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397376>
[19:58] <sinzui> hi thumper, I do
[19:59] <thumper> sinzui: standup is about to start, can we talk after that?
[19:59] <sinzui> yep
[19:59] <thumper> cool
[20:14] <sinzui> hazmat, are you preparing the branch to inc the gwacl dep in juju-core master? Should I get the other developers on it.
[20:20] <thumper> sinzui: https://plus.google.com/hangouts/_/canonical.com/bug-1397376
[20:31] <bac> hey marcoceppi, we talked a while back about you releasing a new version of amulet.  can you schedule that for soonish?
[20:32] <davecheney> mwhudson: short version, there may be an announcement about the 1.5 cycle today
[20:32] <davecheney> but people are distracted with fixing 1.4 for release
[20:32] <mwhudson> davecheney: cool, thanks for chasing
[20:33] <davecheney> regarding spinning wheels on arm64 deveopment
[20:33] <davecheney> i understand
[20:33] <davecheney> i'm in the same boat
[20:38] <thumper> katco: you around?
[20:38] <katco> thumper: yup, what's up?
[20:38] <thumper> katco: seen https://bugs.launchpad.net/juju-core/+bug/1397995 ?
[20:38] <mup> Bug #1397995: 1.21b3: juju status isn't filtering by service <landscape> <regression> <status> <juju-core:Triaged> <juju-core 1.21:Triaged> <https://launchpad.net/bugs/1397995>
[20:38] <thumper> katco: thought of you because of your recent status changes
[20:38] <katco> thumper: yeah i saw that; likely it's related
[20:39] <katco> thumper: it looks like there was some kind of interplay between versions, but i just skimmed.
[20:39] <thumper> katco: can you look actively at it?
[20:39] <thumper> katco: it is blocking 1.21 release
[20:39] <katco> thumper: sure, just wrapping up latest set of review changes for leadership
[20:39] <thumper> kk
[20:39] <thumper> thanks
[20:39] <katco> thumper: thanks for pinging
[21:15] <wallyworld_> katco: hi, can we delay by 15 minutes? i'm in another meeting
[21:15] <katco> wallyworld_: sure thing
[21:15] <wallyworld_> ty
[21:42] <wallyworld_> katco: hi, i'm finally free
[21:43] <katco> wallyworld_: ok, hopping on
[21:55] <thumper> mwhudson: want to catch up now or soonish?
[21:55] <mwhudson> thumper: would about 20 mins work?
[21:55] <thumper> sure
[21:55] <mwhudson> cool
[22:30] <mwhudson> thumper: long 20 mins sorry, ready now
[22:30] <thumper> mwhudson: our 1:1 hangout?
[22:30] <mwhudson> thumper: sure, trying to find it now :)
[22:30] <mwhudson> ok, there
[23:59] <wallyworld_> hazmat: you've got bug 1389422 as in progress on 1.22. i'm just updating 1.21 branch to pull in your new gwacl branch. i can do the same for 1.22 if you want
[23:59] <mup> Bug #1389422: azure instance-types and regions missing <azure-provider> <constraints> <Go Windows Azure Client Library:Fix Committed by hazmat> <juju-core:In Progress by hazmat> <juju-core 1.20:Triaged> <juju-core 1.21:In Progress by wallyworld> <https://launchpad.net/bugs/1389422>


[00:38] <levander> Am I the only one who isn't getting any guide data in mythweb, but it works fine through mythfrontend?
[02:05] <bodom> hello there
[02:06] <bodom> i got a problem installing mythubuntu
[02:07] <bodom> the CD boot but when I choose "Mythbuntu live environment" or any other item nothing happens
[02:08] <bodom> may somebody help me?
[02:42] <tgm4883_laptop> bodom, what do you mean nothing happens
[02:43] <superm1_> try safe graphics mode bodom
[02:43] <superm1_> levander, check your time zone
[02:45] <bodom> superm1_, fir of all, ty for your reply
[02:45] <bodom> I've tried your suggestion but doesn't work
[02:45] <superm1_> do you have a monitor or a tv hooked up?
[02:46] <bodom> i can't boot no options
[02:46] <superm1_> (which one is what i am asking)
[02:46] <bodom> even "test memory" and "check CD" does nothing
[02:46] <bodom> only boot from HD works
[02:46] <superm1_> can you try the cd on a different computer?
[02:46] <bodom> sure, just a moment
[02:48] <bodom> same
[02:48] <superm1_> can you reburn you cd then?
[02:48] <superm1_> at a slower speed hopefully
[02:48] <superm1_> to rule out errors with that
[02:48] <superm1_> and check the md5sum of your download
[02:48] <superm1_> the md5sum's are on hte website
[02:49] <bodom> mhhh sounds strage, the CD was burned at 4x speed. I'm going to check md5sums anyway
[02:49] <bodom> ty
[02:49] <bodom> will tell you how it will go
[02:49] <superm1_> alrighty
[02:50] <bodom> damn
[02:50] <bodom> 404
[02:50] <bodom> The requested URL /mythbuntu-8.04.1-desktop-i386.iso.md5sum was not found on this server.
[02:50] <superm1_> on the md5?
[02:50] <superm1_> tgm4883_laptop, ^
[02:51] <superm1_> try it again, that should load balance to a different mirror
[02:51] <superm1_> hopefully its just one mirror out of hte loop
[02:51] <tgm4883_laptop> what mirror?
[02:51] <superm1_> us-ca 404'ed on me
[02:51] <superm1_> but mirrror.internode.on.net was okay
[02:52] <tgm4883_laptop> just the md5sum?
[02:52] <superm1_> i dunno
[02:52] <bodom> idem
[02:53] <superm1_> no the iso too
[02:53] <bodom> ohhh, the md5sum doesn't match my downloaded iso
[02:53] <superm1_> well that's probably not a good thing (tm) :)
[02:53] <bodom> :)
[02:53] <bodom> seems you quckly found the problem, thank you
[02:53] <bodom> I'm goin' to download it again
[02:53] <superm1_> yup np
[02:53] <superm1_> hopefully that's all
[02:54] <bodom> let's hope :D
[02:55] <tgm4883_laptop> if i had to recommend, i'd say use the torrent
[02:55] <tgm4883_laptop> since it verifies it for you
[02:56] <bodom> tgm4883_laptop, ty for your hint, but my mldonkey got serious problems on these days :)
[03:28] <samubuntu> help first time setup of mythtv
[03:28] <samubuntu> first time setup i get "cannot login into database" and "no UPnP backend found" error
[04:29] <cmug> OK I ordered a set with satelco easyview for cable and a CI module and a conax CAM socket. My frontend will be different from my backend, decoding pay tv with the backend will still allow me to watch it over network on the frontend right?
[04:35] <iamjcs> hey all, anyone available to lend a hand?
[04:39] <iamjcs> i am trying to install mythbuntu on top of ubuntu, i get the following when i try to run sudo dpkg-reconfigure mythtv-database:[sudo] password for jae:
[04:39] <iamjcs>  * Starting MySQL database server mysqld                                 [ OK ]
[04:39] <iamjcs> Failed to connect to database: Access denied for user 'root'@'localhost' (using password: NO) at -e line 5, <> line 1.
[04:39] <iamjcs> Failed to create database (incorrect admin username/password?)
[04:39] <iamjcs> It's also possible that mysql-server wasn't running.  After install
[04:39] <iamjcs> is completed, you will need to make sure mysql-server is running
[04:39] <iamjcs> and that you supplied correct information. Try:
[04:39] <iamjcs> sudo dpkg-reconfigure mythtv-database
[04:44] <levander> superm1_: Where do I check my time zone at?
[04:51] <levander> superm1_: The time on the mythweb home page and the time reported by the 'date' command on that machine are both the same if that's what you mean.
[05:05] <levander> I bet this is my problem<EMAIL_ADDRESS>[05:05] <levander> I know I changed which channel lineup I'm using.  I've got some old channels in the database that aren't being used anywhere.
[05:05] <iamjcs> nm, and for the record... i am an idiot
[13:27] <bodom> superm1, it works now (downloaded a new ISO with correct md5sum), ty
[13:27] <bodom> see you
[16:53] <snowmaze> hi guys, does anybody know about mythbuntu and the nova-s remote-control?
[16:55] <thedarkone> has anyone used pcsx2 emu with myth?
[17:14] <joshman09> needing help set up my first mythtv
[17:14] <joshman09> can anybody help me walk through this setup
[17:14] <joshman09> i'm getting two errors
[17:20] <laga> !ask
[17:20] <Zinn> Please don't ask if anyone is around or if it is alright to ask a question.  Many people check back periodically and may answer your question when they see it.  IRC is not normally an instant fix so check back often for an answer.
[17:20] <laga> :)
[17:36] <dArK> hello all
[17:48] <Erhapp> hello
[17:48] <Erhapp> What should i do to make my frontend start up my backend server?
[18:17] <jphillip> Erhapp the backend should always be running, kinda deafeats the point if it isn't
[18:23] <Erhapp> jphillip: I want the backend to start when i start the frontend system
[18:24] <Erhapp> the backend can start itself via the BIOS for recordings
[18:27] <jphillip> wake on lan or something?
[18:31] <Erhapp> jphillip: Indeed WOL. But how would I go about it. How do I make de frontend send the WOL command upon booting
[18:31] <Erhapp> Is it a setting in Mythtv? Or do I have to do it directly in Linux?
[18:33] <whoDat_> sometimes when i change channels the audio goes high pitched/scratchy/over modulated. if i change channels again, it goes back to normal. dont see anything in the front end logs. any ideas? this is through the svideo/audio out of my stb.
[18:33] <gregL> google mythtv mailing list then search for wake on lan
[18:33] <gregL> lots of info there.
[18:37] <Erhapp> grepL: Can you provide me with an URL for the mythtv mailing list?
[18:54] <jphillip> !support | Erhapp
[18:54] <Zinn> Erhapp: http://www.mythbuntu.com/support
[18:54] <jphillip> link in there
[20:23] <sebrock> anyone having trouble with imon pad after a suspend to ram? for me it doesnt work in frontend anymore, but outside (irw etc.) is fine
[20:24] <zagibu> hey guys, I have bought and installed a terratec cinergy C pci (it's a dvb-c card) and now I'd like to check it's functionality with some simple tools...any suggestions?
[20:25] <zagibu> i have already compiled the proper drivers for it (it's recognized in mythtv). but I'm not really sure what I have to set for transponder frequency, symbol rate, etc.
[20:25] <zagibu> I'd just like some simple tools that scan all frequencies for a signal, so that I can see if the card works at all
[20:26] <zagibu> I've read about w_scan, but it was not included in the dvb-utils package
[20:26] <zagibu> and "scan" doesn't seem to be able to do a full scan without any information
[20:59] <sebrock> superm1, you helped me with setting up the lirc_imon driver for suspend-to-RAM. However when waking up the remote does not work within the frontend anymore, only outside such as irw
[20:59] <sebrock> so the remote actually works... just not in frontend :(
[20:59] <sebrock> any suggestions?
[21:08] <jphillip> superm1 is at work
[21:08] <jphillip> try back later
[21:08] <jphillip> or hope someone else might know
[21:09] <sebrock> alright thankyou
[21:09] <sebrock> anyone is free to suggest anythgin :D
[22:25] <tafryn> Is it possible to turn off commflagging for the liveTV recording group?
[22:58] <darthanubis> of course
[22:58] <darthanubis> in the backend setup