[10:09] <rsalveti> ogra_: added a new landing ask for indicator-power https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1
[10:19] <tsdgeos> guys, anyone knows what is on deb http://<IP_ADDRESS>/archive//head.unity8 trusty/ ?
[10:19] <tsdgeos> i'm trying to run the jenkins jobs but don't want to spend time makind the phone access that
[10:19] <tsdgeos> so if there was a public ip or something that contains the same things as that ip
[10:19] <tsdgeos> it'd be great
[10:23] <sil2100> rsalveti: see the landing ask, we'll add it for today
[10:25] <rsalveti> sil2100: thanks
[10:30] <sil2100> Mirv: I added one landing for you today - nothing big, so concentrate on the big Qt5 bits
[11:03] <Mirv> sil2100: alright!
[11:22] <Mirv> didrocks: in case friends testing goes alright, I'd need an ack for this (interesting) packaging change http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Friends/job/cu2d-friends-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_qml-friends_0.2.0+14.04.20140124.3-0ubuntu1.diff
[11:23] <Mirv> I reproduced it on my device, but I couldn't find any other explanation than apt resolving complexities causing the problem. I could use apt-get install just fine to upgrade, first the account-plugin-* and then the rest, and tested that adding the dependencies directly fixed the issue so that just apt-get build-dep works too.
[11:25] <Mirv> the merge request with the build logs and diff at https://code.launchpad.net/~timo-jyrinki/qml-friends/fix_qt52_ftbfs_adding_dependencies/+merge/203012
[11:31] <sil2100> Mirv: if anything, we'll do a meeting here personally, so you're free today from hangouting ;)
[11:31] <sil2100> Mirv: just take a look at the spreadsheet when you have a free moment and land that friend-thingy
[11:32] <Mirv> sil2100: ok, I was wondering if anyone is coming :)
[11:32] <Mirv> thanks for the info
[11:39] <Saviq> cihelp: hey, we've been trying to reproduce the unity8 failures in otto testing, but failed to, miserably - everything works on both phone and desktop for us, could we please get one of the otto runners for a half hour for debugging?
[11:44] <popey> didrocks: are landing meetings not happening?
[11:47] <fginther> Saviq, I'll have to get back to you on that after my meeting.
[11:47] <Saviq> fginther, thanks
[12:24] <Mirv> popey: see above, they're having a meeting onsite today (if having something)
[12:24] <popey> ah
[12:25] <popey> couldn't find mention in the above, thanks
[12:34] <didrocks> popey: sorry, got distracted by talks, We'll get it in ~1h, not sure if you want to join (as we are doing it live, can be hard for you to follow)
[12:34] <popey> didrocks: yeah, I'll skip if I'm the only external person, just lemme know what you want testing, probably easier
[12:34] <didrocks> popey: let's do that, until seeing you tomorrow! :)
[12:40] <popey> ya
[13:40] <fginther> Saviq, do you have a pointer to a failing job?
[13:42] <fginther> Saviq, there is a machine set aside for debugging, but it has a slightly different config and I'd like to see if the problem is reproducable there first
[13:45] <ogra_> psivaa, http://people.canonical.com/~ogra/touch-image-stats/20140125.changes look at the new packaages at the top
[13:46] <Saviq> fginther, sure
[13:46] <Saviq> fginther, https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2292/?
[13:53] <sil2100> Mirv: you read our minds!
[13:55] <sil2100> Mirv: don't publish anything!
[13:59] <ogra_> Saviq, could we land this pertty soon ? https://code.launchpad.net/~mterry/unity8/mir-socket-dbus-activation/+merge/202499 (it blocks nested Mir mode currently)
[14:01] <didrocks> davmor2: popey: basically, don't dogfood anything. We have no promotion candidate for now ;)
[14:01] <popey> kk
[14:01] <popey> thanks
[14:01] <Saviq> ogra_, will try
[14:01] <ogra_> Saviq, thanks !
[14:17] <davmor2> didrocks: no worries
[14:18] <davmor2> didrocks: is this week the final push for getting 4.4.2 up and running across the supported devices?
[14:18] <didrocks> davmor2: some people are continuing pushing that this week. Not sure it's the end of the run though ;)
[14:43] <sil2100> psivaa: http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-1.1prepare-address-book-app/334/console
[14:43] <psivaa> sil2100: thanks
[14:43] <sil2100> psivaa: the 2 previous builds have the same issue
[14:43] <sil2100> psivaa: and it seems to be the only app having problems - others went through fine
[14:44] <psivaa> sil2100: ack, will take a look
[14:50] <Saviq> ogra_, it looks good from my PoV, who else (that knows dbus activation) should review it?
[14:52] <ogra_> Saviq, hmm, dunno ... probably ricmm
[14:52] <sil2100> didrocks: where will the bootcamp take place? In what room?
[14:52] <ogra_> thugh i know he looked into it together with mterry
[14:53] <ogra_> after all it only exports two variables into the dbus session
[14:53] <ogra_> err, even one
[14:53] <didrocks> sil2100: I guess in the room I'm having the current meeting
[14:54] <ogra_> do you have to bring boots for it ?
[14:54] <Saviq> ogra_, sure, I just don't know anything about dbus activation ;)
[14:55] <ogra_> Saviq, i think tedg knows a bit about that too
[14:56] <Saviq> tedg, could you have a look at https://code.launchpad.net/~mterry/unity8/mir-socket-dbus-activation/+merge/202499 please?
[14:56] <Saviq> tedg, just sanity-check
[14:57] <psivaa> sil2100: that test has gone through now: http://q-jenkins.ubuntu-ci:8080/job/cu2d-phone-head-1.1prepare-address-book-app/335/console
[14:58] <sil2100> psivaa: oh! Thanks, did you do anything to fix it?
[14:59] <psivaa> sil2100: yea, it was complaining that RSA pub key missing for that package so i imported it
[14:59] <tedg> Saviq, The dbus stuff works fine, but who's setting UNITY_MIR_SOCKET if it's not Unity8 ?
[14:59] <sil2100> psivaa: \o/ excellent
[14:59] <Saviq> tedg, UNITY_MIR_SOCKET is unity8-internal, nothing others should be concerned about
[15:00] <Saviq> tedg, MIR_SOCKET is what apps want to connect to
[15:00] <Saviq> s/apps/clients
[15:01] <tedg> Saviq, Sure, but that doesn't answer my question :-)
[15:02] <Saviq> tedg, not sure I understand the question, then - that job is the unity8 job
[15:03] <tedg> Saviq, would we want to switch the socket over in unity8's post-start?  Would it be bad if apps connected to the socket before it existed?
[15:03] <tedg> Saviq, Who's creating the socket?
[15:03] <Saviq> tedg, unity8 is
[15:03] <tedg> Saviq, The value is apparently known in the pre-start section of the script, so unity8 hasn't been started?
[15:03] <Saviq> tedg, apps would die before the socket existed
[15:04] <Saviq> tedg, the socket *name* is known, but the socket is not there yet
[15:04] <tedg> So then how does UNITY_MIR_SOCKET get set?
[15:04] <Saviq> tedg, in the pre-start script
[15:04] <Saviq> tedg, there's two MIR_SOCKETs basically
[15:05] <Saviq> tedg, the socket which unity-system-compositor creates
[15:05] <Saviq> tedg, and that's MIR_SOCKET at the beginning of the pre-start job
[15:05] <Saviq> tedg, we're saving that in our pre-start script as UNITY_MIR_SOCKET, as we then modify MIR_SOCKET to the one that unity8 will create, and clients are supposed to connect to
[15:06] <tedg> Saviq, So, I guess my question is why are we testing if UNITY_MIR_SOCKET is set?  Nesting?
[15:06] <Saviq> tedg, but we still want to connect to UNITY_MIR_SOCKET if restarted
[15:06] <Saviq> tedg, yes, nesting
[15:06] <sil2100> sergiusens:  test_music.TestMainWindow.test_create_playlist_from_songs_tab
[15:07] <Saviq> tedg, basically on first unity8 start MIR_SOCKET points at unity-system-compositor's socket
[15:07] <tedg> Saviq, I don't see any harm in it, but it seems like we shouldn't encourage apps to connect to it until it exists.
[15:07] <sil2100> sergiusens: http://ci.ubuntu.com/smokeng/trusty/touch/mako/149:20140127:20140115.1/6294/music-app-autopilot/705498/
[15:07] <tedg> Saviq, But the MR isn't the issue there.
[15:07] <Saviq> tedg, so you mean it should only be set in post-start?
[15:07] <tedg> Saviq, Yeah
[15:07] <Saviq> tedg, they would connect to unity-system-compositor in that case
[15:08] <Saviq> tedg, as the env is already theres
[15:08] <Saviq> -s
[15:08] <Saviq> only pointing at u-s-c, not at u8
[15:08] <tedg> Saviq, Well, you already have a race if things are starting at the same time as unity8, it'd just be more obvious.
[15:09] <Saviq> tedg, OSK starts "on unity8 started", would unity8's post-start be early enough for OSK to get the new MIR_SOCKET?
[15:09] <Saviq> tedg, and things that connect to unity8 should not be starting at the same time as it does, should they...
[15:11] <tedg> Saviq, I'm going to have to double check, but I believe post-start runs before started is emitted.
[15:12] <Saviq> tedg, anyway, ACK on the MP?
[15:12] <tedg> Saviq, Yeah, seems post-start is executed before "started" is emitted: http://upstart.ubuntu.com/cookbook/#post-start
[15:12] <tedg> Saviq, Yes
[15:14] <Saviq> tedg, thanks
[15:20] <sergiusens> popey, sil2100 https://code.launchpad.net/~sergiusens/music-app/flaky_1272996/+merge/203349
[15:21] <psivaa> didrocks: ogra_: plars: the unity8 crash is not reproducible in mako on the reruns. seems like very less freq flakiness/race
[15:21] <popey> sergiusens: done
[15:24] <didrocks> psivaa: hum, we have too many of them so that it's gone
[15:24] <didrocks> psivaa: I think you are continuing rerunning and checking?
[15:24] <plars> psivaa, didrocks, ogra_: And for clock tests on maguro, I reran it twice, first time got me down to 8 failures, and the second time we got back down to 2... So it doesn't appear this is a real regression
[15:25] <plars> psivaa: that was without uninstalling anything?
[15:25] <plars> psivaa: or had you already installed the older version of hud?
[15:26] <psivaa> plars: didrocks: yep, im running without any modification to the pkges.. have run 14+ times
[15:27] <didrocks> psivaa: hum, ok, keep me posted if you see anything more
[15:27] <didrocks> but sounds like a good running already
[15:29] <psivaa> didrocks: ack, i'll run my test jobs continuously. wondering if any packages that were installed are doing something funny
[15:29] <plars> peird
[15:29] <plars> weird too
[15:29] <didrocks> plars: keep me posted!
[15:30] <plars> psivaa: which device is this on?
[15:30] <psivaa> plars: mako-06
[15:31] <psivaa> plars: http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-friends-app-autopilot/ and http://q-jenkins.ubuntu-ci:8080/job/psivaa-trusty-touch-mako-smoke-unity8-autopilot/ are the test jobs
[15:32] <plars> psivaa: yeah, I was just double-checking, it's running 149 on it now
[15:34]  * davmor2 keeps thinking about trying out 4.4.2 on his mako but that would mean moving the blame for everything from ogra_ to rsalveti  and I'm not sure he'll handle that amount of grief :D
[15:35] <ogra_> davmor2, you can use my rootfs zip with rsalveti's android imgs ... that would spread the blame :)
[15:36] <davmor2> ogra_: see now it's more tempting :D
[17:01] <robru> didrocks, meeting today? hangout says I'm not allowed to join...?
[17:01] <didrocks> robru: in a meeting, but coming in 5, the not allowed is weird though
[17:01] <didrocks> robru: count 10 ;)
[17:11] <balloons> sergiusens, what did you plan to do with the music app?
[17:13] <sergiusens> balloons, oh, I need to push a new click now
[17:16] <balloons> sergiusens, how did it get promoted? Lots of new stuff landed but I hadn't reviewed it yet
[17:16] <sergiusens> balloons, it's not promoted yet
[17:16] <balloons> sergiusens, ohh
[17:17] <sergiusens> balloons, however, what do you mean by plan?
[17:17] <sergiusens> balloons, I can't really revert packages in the store
[17:17] <balloons> sergiusens, well it's failed in the dashboard..
[17:18] <balloons> I'm confused how it go promoted through..
[17:28] <sil2100> didrocks: packaging ACK! http://q-jenkins.ubuntu-ci:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+14.04.20140127-0ubuntu1.diff
[21:28] <kgunn> fginther: ping
[22:12] <kgunn> cihelp ping ?
[22:14] <josepht> kgunn: hi
[22:15] <kgunn> josepht: hey, i was just bird-dogging this mp....
[22:15] <kgunn> https://code.launchpad.net/~unity-team/unity8/unity8.test_nested_mir/+merge/203088
[22:15] <kgunn> but it keeps failling due to
[22:16] <kgunn> "unstable" output from otto ap test runner
[22:16] <kgunn> ...and just wondering what it means ?
[22:16] <kgunn> is it something someones already looking into?
[22:17] <kgunn> https://jenkins.qa.ubuntu.com/job/generic-mediumtests-trusty/2634/console
[22:17] <josepht> kgunn: I'mlooking now
[22:18] <kgunn> josepht: cool...it feels kind of circular when i dig (altho i'm no expert reading the outputs)
[22:22] <josepht> kgunn: it looks like it's due to these test failures: https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/2304/
[22:26] <kgunn> josepht: thanks...that helps...
[22:27] <kgunn> josepht: i'm getting info from my team right now that (some) has been addressed


[10:07] <jam> mgz: now we just hear ourselves echo on about a 1s delay
[11:15] <evilnickveitch> question: is there any reason for the end user to use the 'maas' command for anything other than "createsuperuser" and "changepassword"?
[11:19] <rvba> evilnickveitch: these are the main commands that a user should use.  Maybe it's worth mentioning a third one: 'shell' used to get a python prompt with the right (django) environment setup.  That is mainly for debugging purposes.
[11:19] <evilnickveitch> rvba: thanks!
[11:19] <rvba> np
[13:14] <rbasak> allenap: re: maas-import-ephemerals, I had a precise SRU in mind, hence changing the existing script as minimally as possible. Not sure of the current SRU plans. If the whole thing were rewritten, would this affect the SRU? Would the refactoring be SRUed?
[13:40] <allenap> rbasak: We're aiming for a big SRU, so that Precise's version is close to trunk (there will be two features missing, I think that's it).
[13:41] <allenap> rbasak: The problem with maas-import-ephemerals is that there are no tests, so it's hard to refactor.
[13:41] <rvba> allenap: thanks for the reviews.  You're so quick I don't even have to ask. :)
[13:42] <rbasak> allenap: I understand. The complexity of mass-import-* is such that if I were starting from scratch I would write it in python, with tests.
[13:42] <allenap> rvba: No worries.
[13:42] <rbasak> I think it's gone beyond the point where shell is appropriate. smoser might disagree though!
[13:43] <rbasak> But I feel that I'm facing a problem now though. I seem to have a choice between taking on the refactoring myself, or not getting multi-subarch ARM support into precise.
[13:43] <smoser> i dont really care, but i generally disagree with any sort of "cannot be tested BS".
[13:44] <smoser> test the freaking thing.
[13:44] <smoser> dont pretend you do by running 'make test' that mocks 90% of it.
[13:44] <allenap> rbasak: I think >1 line of shell is beyond appropriate, but some might say that's extreme.
[13:44] <smoser> but, sure, rewrite if you feel like it.
[13:44] <allenap> smoser: Do you mean automated testing, or manual?
[13:45] <smoser> well, when you make changes you should do test of your changes. period.
[13:45] <smoser> not writing unit tests that pretend to test.
[13:45] <rbasak> allenap: I think you're too extreme there, but I think we can both agree that the appropriate language for the current functionality of maas-import-* is python.
[13:45] <allenap> smoser: Does that mean we need to test every script every time we make a change? Because I'm not going to do that manually.
[13:45] <rbasak> (though I would be fine if smoser disagreed with that - I'm only slightly on the side of python on this one)
[13:46] <smoser> there shoudl be some sort of ci testing in place. but, yes, if you change things, you should test them.
[13:46] <smoser> that really should not be questionable.
[13:47] <smoser> there should also be some sort of easily runnable "setup and test". we're lacking in that department.
[13:47] <rbasak> The nature of maas is that unit tests can't do everything. I'm not sure they're even appropriate in some cases. That's why we should have integration tests. And I'm starting to think that maas-import-* should have all of the functionality that we need to test covered by our integration tests anyway, and matsubara is already working on this. So do we really need any other tests for it?
[13:47] <smoser> so people take short cuts. and do not test their code in reality.
[13:47] <allenap> smoser: Yeah, so we have unit tests in lp:maas, and /some/ integration testing, though it's a ad-hoc. matsubara (and rvba I think) have been working on the acceptance testing of the package, so I guess maas-import-* will be covered by that eventually.
[13:48] <smoser> right. we need to get to the point where someone can reasonably push 'go' with input of a branch. and that would build package, laucnh instance (or instances) install package, launch vms....
[13:49] <smoser> that would at least test the expected user path
[13:49] <matsubara> we're at that point
[13:49] <matsubara> with the CI tests in jenkins
[13:49] <rvba> That's what the integration tests do.
[13:49] <matsubara> and yes, the CI tests did catch some bugs in maas-import-pxe-files
[13:50] <smoser> matsubara, can allennap  run that?
[13:50] <smoser> and does he need access to hardware to do so?
[13:50] <rvba> No, he just needs an account on the jenkins instance.
[13:50] <allenap> smoser: Yes, agreed. But we should still have unit tests for small piece of functionality, because detecting bugs late - i.e. in the integration tests - is much more expensive.
[13:50] <matsubara> smoser, yes and no (although he does have access to the lab)
[13:50] <rbasak> matsubara: are we really there yet? For example, I've proposed https://code.launchpad.net/~racb/maas/multi-soc-ephemerals/+merge/134715 which changes maas-import-pxe-files which is where our discussion started. Can you give me a green light that this doesn't break anything, how much of your time would that take, and how confident would you be about the results?
[13:51] <matsubara> but yes, I agree that if maas-import-pxe-files tests could be part of the maas test suite, that would be nice
[13:51] <smoser> matsubara, we need to remove the necessity of "lab access" also.
[13:51] <matsubara> smoser, lab access is useful to debug when the CI tests fail
[13:51] <smoser> matsubara, clearly, yes.
[13:51] <smoser> it can all run (minus ipmi) inside an instance[s] and a subset of that can run on a local system.
[13:52] <smoser> ie, "all in one" can run on a single system. or a single vm with nested virt.
[13:52] <allenap> Compared to setting up a lab, both in terms of equipment and time, writing unit tests is insanely cheap, finds bugs and helps reduce regressions.
[13:52] <smoser> i didn't say that unit tests are not useful.
[13:52] <smoser> i said they're not complete. and you should test code you write.
[13:52] <matsubara> rbasak, the arm nodes are not working at the moment. I had an issue updating the chassis firmware and will talk to Massimo today
[13:52] <smoser> and not doing so is unacceptable.
[13:53] <rbasak> matsubara: ok, but in general?
[13:53] <smoser> i'll end my rant.
[13:53] <matsubara> rbasak, apart from that the CI infrastructure should be working
[13:53] <rbasak> What if the lab tested merge proposals or just maas branches on demand and sent us the results?
[13:53] <rbasak> matsubara: and can it do what I mentioned above?
[13:53] <smoser> rbasak, right.
[13:53] <smoser> and then, we want to detach that from the lab.
[13:53] <matsubara> rbasak, it does that for the unit tests test suite, but not for the CI
[13:54] <matsubara> currently CI tests takes around 30 mins including juju tests
[13:54] <matsubara> so blocking landings on CI, would make development speed a lot slower
[13:54] <rbasak> '
[13:54] <rbasak> I'm happy with that for maas-import-pxe-files changes. We don't change it that often. A day would be fine
[13:54] <matsubara> cool
[13:55] <allenap> smoser: I don't really know what you're ranting against. Diogo has been doing QA since the beginning, and is codifying this in the acceptance test suite. We haven't been missing the part that you're worried about.
[13:55] <rbasak> So do we have the facility to automatically test that MP now?
[13:55] <allenap> rbasak: I /think/ we need to land it before it'll be visible to the acceptance suite. Is that correct, matsubara?
[13:56] <smoser> allenap, assuming QA will catch stuff is rude.
[13:56] <matsubara> yes allenap and rbasak
[13:56] <smoser> ie, assuming the first time it will run in an actual environment rather than unit test is the failure.
[13:57] <rbasak> allenap: let's say that we did have the facility to pass acceptance tests without landing it. I do accept that we want to refactor maas-import-* eventually. Would you still feel the same about not landing this MP without refactoring though?
[13:57] <smoser> wait. thats not a sentance.
[13:57] <smoser> assuming QA / integration testing will be the first time something runs because the person who changed it couldn't be  bothered to run it. is rude to anyone else who is going to try to use the product.
[13:58] <smoser> rbasak, what is the MP ?
[13:58] <smoser> link ?
[13:58] <rbasak> smoser: https://code.launchpad.net/~racb/maas/multi-soc-ephemerals/+merge/134715
[13:59] <rbasak> I've tested this and can't find that it breaks anything. But I can't be completely confident about this without knowing that the acceptance tests also pass, and ideally I'd like to know that before merging it into trunk.
[14:00] <smoser> rbasak, you need to use more quotes.
[14:01] <smoser> cp $src/subarch/$subarch/initrd.gz needs to be cp "$src/subarch/$subarch/initrd.gz"
[14:01] <smoser> as src can have space and yo ufail.
[14:01] <smoser> i dont do things like that just for fun.
[14:01] <rbasak> smoser: that's fine
[14:02] <allenap> smoser: I don't see that it's rude. For many situations we don't have the facility to spin up a representative MAAS environment. The QA team - Diogo - does, and has the expertise and focus to do that job better than I can.
[14:02] <smoser> you *do* have the facility.
[14:02] <smoser> allenap, do you ahve a canonistack account?
[14:02] <smoser> if not, you should.
[14:03] <allenap> smoser: Yes, but that's not a representative environment.
[14:03] <smoser> allenap, it is for the test in question. (and actually just about everything we do other than ipmi)
[14:04] <rbasak> Very little of bits that matter for ARM though
[14:04] <smoser> ?
[14:04] <smoser> there are some arm specific paths. thats true. but the majority of this is not arch specific.
[14:05] <allenap> smoser: How does canonistack help us test DHCP and PXE better than a unit test?
[14:06] <rbasak> allenap: it would test that stuff actually works, rather than what a unit test tests
[14:07] <Daviey> you can PXE install using canonistack.
[14:07] <rbasak> While I was working on ARM support, I found stuff that was not ARM specific that was simply broken but all unit tests passed
[14:07] <rbasak> That was happening every other day or so
[14:07] <rbasak> It appeared that I was the only one trying trunk on real hardware all the way through at the time
[14:08] <allenap> Daviey: I didn't know that. How do we get a booting node to select our tftp server, in order that we can control the PXE boot?
[14:08] <rbasak> (the situation is a lot better now thanks to the automation that matsubara has done)
[14:09] <rbasak> But it demonstrates well that the unit tests are not sufficient, especially for the system-level parts like dhcp, pxe, ipmi, etc.
[14:09] <allenap> rbasak: I agree, when things need hardware there's usually little option but to go to hardware.
[14:09] <rbasak> dhcp and pxe don't need hardware for non-IPMI. KVM will do
[14:09] <Daviey> allenap: pxe-tftp tool :)
[14:09] <Daviey> pxe-kexec, rather
[14:10] <rbasak> We should definitely also be testing on real hardware, but velocity will be better if there are integration tests that can run in a virtual environment (or if we can submit stuff to real hardware quickly and easily, including debugging)
[14:10] <smoser> rbasak, i commented.
[14:11] <allenap> Daviey: That's pretty cool. Doesn't test our DHCP integration, but it's neat, granted.
[14:11] <smoser> you dont need pxe-kexec.
[14:11] <smoser> you actually boot a vm
[14:11] <smoser> and let the bios pxe boot
[14:11] <smoser> just like a real machine.
[14:12] <smoser> rbasak, i updated mp.
[14:12] <rbasak> thanks smoser. I can make those changes - the bigger question is if this is sufficient or really needs an entire refactor before this can go in
[14:13] <smoser> rbasak, i dont have a problem with it as it is. and my personal feeling would be actually testing it would result in less regression than refactor/re-write in python.
[14:13] <smoser> (at least in the short term)
[14:13] <allenap> rbasak: I'm not arguing against integration/acceptance testing; I'm arguing that we need unit tests too. Refactoring code without unit tests is tricky and expensive (the latter because of the long iteration time).
[14:14] <smoser> allenap, i will agree with you on that.
[14:15] <rbasak> allenap: that's fine. If we refactored maas-import-* then we could have unit tests, and I'm fine with that. But I'm not sure that we want to block this until it is refactored. Perhaps even more so with an SRU planned.
[14:15] <rbasak> allenap: and who is going to refactor it?
[14:16] <allenap> smoser: My arguments against shell are twofold: it's incredibly easy to hide serious bugs in shell (e.g. "use more quotes"), and that it's hard to unit test (at least as maas-import-* are currently written).
[14:19] <allenap> rbasak: You may be right that we don't want to block on this, and I don't know who's going to refactor it, but these are the same arguments that keep coming up. Every time we grow those scripts we are making the rectification job harder. I want to put the brakes on.
[14:19] <rbasak> Understood. My work on apt is in the same situation.
[14:20] <rbasak> There are a couple of other factors there though. Not sure how much they apply though
[14:20] <rbasak> For an SRU, I wouldn't normally want to do a refactor. Minimal change would almost always be better.
[14:20] <rbasak> Here though, maas is a bit special with its SRU
[14:22] <rbasak> But in the case of this particular change, it's because I had to take a shortcut and not put multi-subarch support in ephemeral images before 12.10 release. It's a pretty bad deficiency in ARM support, and I had assumed that this would be fine to SRU later, in time for new ARM hardware to arrive
[14:23] <rbasak> It's the last piece to do before I'm happy with the ARM support in MAAS, and I really hoped to have it done by now. Which is why I'm reluctant to embark on refactoring the entire chunk before I can complete it, especially because that isn't even an ARM issue
[14:44] <smoser> rbasak, i personally think your change here is the right path. i do see allenap's point about adding more stuff to something that wants a refactor, but i think for now this is the safest path.
[15:12] <rnbrady> Hi guys
[15:12] <rnbrady> Just been playing with maas over last week and loving it.
[15:12] <rnbrady> But still haven't got my first server up.
[15:13] <rnbrady> So far I have the maas server running, enlisting nodes, and serving some pxeboot.
[15:13] <rnbrady> But getting lots of weirdness in the commissioning process and could use a few tips if anyone about.
[17:02] <roaksoax> rvba: do you recall when was the apprmor stuff uploaded... or in what package version?
[17:04] <roaksoax> smoser: ^^ do you?
[17:06] <roaksoax> rvba: the fix for it is already in -proposed and needs verification: 1049177
[17:06] <roaksoax> rvba: the fix for it is already in -proposed and needs verification: bug #1049177
[17:06] <roaksoax> rvba: could you please get that tested?
[17:07] <rvba> roaksoax: thanks.  Sure I'll test that.  I need to bugger off now but I'll do it tomorrow.
[17:08] <roaksoax> rvba: cool thanks
[17:26] <smoser> roaksoax, did you get what you wanted?
[17:37] <roaksoax> smoser: yes, thanks!
[19:33] <roaksoax> matsubara-brb: how do you configure maas dhcp server?
[19:33] <roaksoax> and enable it?
[19:39] <matsubara> maas-cli maas node-groups list | grep uuid
[19:39] <matsubara> maas-cli maas node-group-interface update uuid eth1 ip=<IP_ADDRESS> interface=eth1 management=2 subnet_mask=<IP_ADDRESS> broadcast_ip=<IP_ADDRESS> router_ip=<IP_ADDRESS> ip_range_low=<IP_ADDRESS> ip_range_high=<IP_ADDRESS>
[19:39] <matsubara> roaksoax, ^
[19:39] <roaksoax> matsubara: cool thanks
[19:42] <matsubara> np
[19:57] <rnbrady> Newbie question. For maas-cli, is the profile name arbitrary?
[19:57] <rnbrady> I can do maas-cli login maas or maas-cli login iamoneleggedman, and both work.
[20:01] <matsubara> yes rnbrady
[20:01] <rnbrady> Tks. So it's just an alias for an API from what I have since discovered.
[20:02] <rnbrady> Nifty! Just issued my first maas-cli maas start xxx
[20:02] <rnbrady> The thrill of hearing fans whirring spontaneously on the other side of the room and the press of a key
[20:02] <rnbrady> s/and/at/
[20:16] <rnbrady> Currently trying to work out how to do a named deployment, as I am only getting the option to queue for allocation.
[20:33] <rnbrady> Ok, which one of you sadists commented out NODE_AFTER_COMMISSIONING_ACTION.DEPLOY_12_04 from NODE_AFTER_COMMISSIONING_ACTION_CHOICES?
[21:32] <rnbrady> Wahoo! It's alive! Named deployment 12.04!


[00:00] <mindframe> can someone help me?
[00:01] <mindframe> as soon as my system logs in it exits back to gdm
[00:03] <lime4x4> it's 80 bucks for Pentium D 1.6 daul core or 50 bucks for a celeron 3.4 ghz single core
[00:05] <tgm4883> lime4x4, I ran that on a 1.6 C2D
[00:05] <tgm4883> with HD
[00:06] <lime4x4> this is th ene i'm looking at  http://www.newegg.com/Product/Product.aspx?Item=N82E16819116037
[00:06] <portahex> pentium d never went as low as 1.6ghz did it?
[00:07] <portahex> ah, that's not pentium-d
[00:07] <lime4x4> it's core duo just a dual core cpu
[00:07] <rhpot1991_laptop> dual core will be nice for transcoding and commflagging and stuff
[00:07] <rhpot1991_laptop> where that can eat a single core and not effect the system
[00:08] <portahex> despite the name, it's based on core, not pentium-d
[00:08] <portahex> that celeron is pentium-d based though
[00:08] <lime4x4> so go with a 1.6 dual core
[00:08] <portahex> i would
[00:10] <lime4x4> that's what i was thinking
[00:11] <superm1> okay quick question to folks idling in here.  would you be more confused if we had an 8.04 public alpha 1 or public alpha 3 (since you haven't seen the last two)
[00:11] <portahex> i'm confused generally
[00:12] <rhpot1991_laptop> I like 8.04 alpha 1 better
[00:12] <lime4x4> i'd go with 8.04 public alpha 1
[00:12] <portahex> has there been that version freeze thing on hardy yet?
[00:13] <superm1> yeah its right about to happen
[00:13] <superm1> which makes for a lot of trouble because 0.21 of mythtv isn't ready yet
[00:13] <superm1> so there is a level of reluctance to add a snapshot
[00:14] <portahex> currently i'm concerned about monodevelop. it's off-topic, but the version in hardy is neolithic & it's causing serious problems for upstream when half their bug reports come from ubuntu
[00:15] <superm1> portahex, is it in universe?
[00:16] <portahex> yeah
[00:16] <superm1> lets see, we have 0.14 in hardy
[00:16] <superm1> what's the newest one?
[00:17] <superm1> looks like 0.18 is in debian
[00:17] <superm1> just needs a merge on our end
[00:17] <superm1> let me check MoM and DaD
[00:19] <superm1> is 0.18 new enough?
[00:20] <portahex> yeah
[00:20] <superm1> if its an easy merge i'll fix that right now
[00:20] <superm1> looks like it should be
[00:21] <portahex> i don't know if there's a specific reason it hasn't been merged - libmono-addins-gui0.2-cil has been updated to the required version
[00:21] <portahex> i ought to check with slomo
[00:22] <superm1> well pochu was the last merger
[00:22] <superm1> in november
[00:22] <superm1> slomo hasn't touched it since july
[00:22] <portahex> sod it, hit the button. worst case scenario, it wakes up people who are meant to be maintaining it
[00:22] <portahex> blame me if they moan \o/
[00:24] <superm1> well meant to be maintaining it is the whole "team" i'm part of
[00:24] <superm1> so...
[00:24] <superm1> :)
[00:26] <portahex> ubuntu-motu?
[00:26] <superm1> yeah
[00:28] <lime4x4> okay while i'm waiting for my new processor to arrive if i install a celeron d then install mythbuntu then install the 1.6 ghz dual core cpu will that mess anything up?
[00:28] <superm1> shouldn't
[00:28] <portahex> should be fine
[00:29] <lime4x4> okay another question should i use eide drive or sata? I have a 500 gig external usb 2.0 drive for storage
[00:30] <portahex> pata is dead
[00:31] <lime4x4> i know i have a few 160 gig ones laying around and i also have a 110 gig sata first genration drive
[00:32] <lime4x4> just trying to recycle when possible..lol
[00:41] <Xenocide> superm1, ya there?
[01:09] <javatexan> found a little oversight on the ubuntu install....it doesnt work very well on 800x600 ;)
[01:10] <superm1> javatexan, yeah there is a bug filed about that
[01:10] <superm1> there should hopefully be a fix coming in ubiquity in the near future
[01:10] <superm1> portahex, that merge actually wasn't too bad
[01:10] <superm1> any other big showstopping apps you know of that need their newer versions?
[01:12] <superm1> Xenocide, yeah i'm here.
[01:12] <Xenocide> i tried what you said, no luck
[01:12] <superm1> Xenocide, okay well so does it work via the init script now?
[01:12] <Xenocide> no
[01:12] <superm1> okay then your hardware.conf is still broke
[01:12] <superm1> remove all those LIRCD_ARGS
[01:12] <superm1> you did that right?
[01:13] <Xenocide> well if i do lircd -d /dev/lirc0 /etc/lirc/hardware.conf it works fine
[01:13] <Xenocide> yes i did
[01:13] <superm1> well that file isn't used via the lircd binary
[01:13] <superm1> its used via the init script
[01:13] <superm1> can you restart via the init script and show me the execution line as seen via 'ps aux'
[01:13] <superm1> it should be in the listing
[01:13] <portahex> superm1, none i enormously care about. i use MD at work though
[01:14] <superm1> portahex, are there other MD packages that need to come with this after the merge?
[01:14] <Xenocide> superm1,  this? root      5204  0.0  0.0   2920   504 ?        Ss   20:14   0:00 /usr/sbin/lircd
[01:14] <superm1> Xenocide, that would be it, interesting.
[01:15] <superm1> can you pastebin gutsy's init script?
[01:15] <superm1> i'm on hardy now and don't have all the old versions handy
[01:15] <Xenocide> how can i copy the whole thing from nano over ssh?
[01:15] <superm1> scp it instead
[01:15] <superm1> or use cat
[01:15] <superm1> and then scroll up and highlight the whole thing
[01:16] <portahex> superm1, not at this moment in time. upstream has stopped bundling most add-ins, but hasn't entirely decided how to distribute the separated ones yet, AFAIK
[01:16] <superm1> portahex, okay yeah i'm not about to do any NEW packages for something i've never even started :)
[01:16] <portahex> superm1, push comes to shove, MD has an integrated add-in manager which should download bits & pieces to ~/.config/MonoDevelop
[01:16] <Xenocide> http://pastebin.ubuntu.com/3766/
[01:17] <superm1> Xenocide, okay remove that DEVICE argument
[01:17] <superm1> from the hardware.conf
[01:17] <superm1> it will be built on its own
[01:18] <Xenocide> ok
[01:19] <Xenocide> still no go though
[01:19] <superm1> okay what does the process listing look like now?
[01:20] <Xenocide> id on't even see lirc in there
[01:20] <superm1> try to restart it again
[01:20] <Xenocide> root      5251  0.0  0.0   2924   504 ?        Ss   20:20   0:00 /usr/sbin/lircd
[01:22] <superm1> hm.
[01:22] <superm1> well lets see the current hardware.conf as it stands then
[01:22] <superm1> there has to be a typo or something.
[01:22] <Xenocide> http://pastebin.ubuntu.com/3767/
[01:23] <superm1> Oh.
[01:23] <superm1> you have a DRIVER defined
[01:24] <superm1> do you want to use the kernel mode driver
[01:24] <superm1> or the userspace one?
[01:24] <Xenocide> userspace
[01:24] <superm1> well what modules are loaded for you right now
[01:24] <superm1> can you check for any lirc_*
[01:24] <superm1> modules in lsmod
[01:24] <Xenocide> atiusb
[01:24] <Xenocide> and dev ofcourse
[01:25] <superm1> well that would be an issue there
[01:25] <superm1> you have the kernel module loaded
[01:25] <superm1> but are trying to use userspace
[01:25] <superm1> when using userspace, no modules get loaded like that
[01:25] <Xenocide> eh? thats what dave morris says to load
[01:25] <Xenocide> hah
[01:25] <superm1> well this is why it sucks that there are two ways to do it
[01:26] <superm1> when you are starting via command line
[01:26] <superm1> the sudo lircd -d /dev/lirc0
[01:26] <Xenocide> should i re-blacklist that one?
[01:26] <Xenocide> right, that works for me
[01:26] <superm1> you are telling it to use the kernel module
[01:26] <superm1> so if that works, i say take out the DRIVER="blah"
[01:26] <superm1> in hardware.conf
[01:26] <superm1> and move on your merry way
[01:26] <Xenocide> ok
[01:26] <superm1> and use the kernel mode one
[01:26] <Xenocide> hell i dont' care which module as long as it works
[01:27] <Xenocide> seems to have worked
[01:27] <Xenocide> let me do that restart thang
[01:27] <Xenocide> i got one other issue idk if you have heard of this one
[01:27] <Xenocide> background music on recordings is so loud its hard to hear the voice
[01:27] <Xenocide> quite weird
[01:27] <Xenocide> but playback in mythvideo is fine
[01:28] <superm1> no haven't heard that
[01:29] <superm1> can you please post this solution that we came up with back to the thread
[01:29] <superm1> and explain in the thread so future people don't run into it
[01:29] <Xenocide> np will do
[01:29] <javatexan> superm1 you are on fire tonight ;)
[01:30] <superm1> apparently
[01:30] <Xenocide> no ideas on the audio problem though?
[01:31] <superm1> na
[01:32] <Xenocide> hm k
[01:34] <javatexan> to install ffmpeg should I uninstal it first in synaptic and mencoder too?
[01:34] <javatexan> sorry install ffmpeg from source
[01:35] <superm1> javatexan, depends what you are trying to achieve with it
[01:36] <javatexan> ffmpeg is broked in synaptic and ubuntu 7.10 apparently, so I am gonna do it by hand...I guess
[01:36] <javatexan> for x264..etc
[01:37] <superm1> its broken?
[01:37] <superm1> i've usedd it to transcode things myself.
[01:38] <rhpot1991_laptop> ffmpeg from gutsy will do h264 (very slowly)
[01:39] <javatexan> been using mencoder with good success
[01:39] <rhpot1991_laptop> javatexan: back to TV, I'll be around later if you need some help with it
[01:39] <javatexan> thanks ...ill try something else for a while too
[01:59] <leprasmurf> hello all.  I'm about to start a migration from knoppmyth to mythbuntu.  I'm worried about my LVM, anyone know if mythbuntu has a method for importing existing lvms?
[02:17] <rhpot1991_laptop> javatexan: hows it going?
[02:17] <javatexan> good...you?
[02:17] <rhpot1991_laptop> not too bad
[02:17] <rhpot1991_laptop> having any luck with ffmpeg?
[02:18] <javatexan> what am I missing.... ffmpeg -i infile.mpg -vcodec mpeg2video -acodec mp2 -s 720x480 -b (BITRATE) outfile.mpg
[02:19] <javatexan> orig is 480x480, v:mpeg PES and a: mpeg PES
[02:19] <rhpot1991_laptop> why are you bumping the res then?
[02:19] <tgm4883> proper dvd complient
[02:19] <tgm4883> most likely
[02:20] <rhpot1991_laptop> give me a second and I'll get a ffmpeg line that I use
[02:20] <javatexan> not sure  lol ....guess I will keep the size for now
[02:21] <javatexan> yeah ... could do that too
[02:21] <javatexan> lol.. still just fishing...thought of doing the video copy, but I cant find that stuff tonight....google just doesnt like me tonite
[02:22] <rhpot1991_laptop> hmmm what type of output are you trying to get?
[02:23] <rhpot1991_laptop> I'm watching TV, so my responses might be a little slow
[02:23] <javatexan> a compliant mpeg2...right now
[02:23] <javatexan> right now it will crash the default player in mythtv after about a minute or two
[02:25] <rhpot1991_laptop> hmmm I've never gone that way
[02:25] <rhpot1991_laptop> always mpeg2 to mpeg4 or h264
[02:25] <rhpot1991_laptop> try this: http://ffmpeg.mplayerhq.hu/faq.html#TOC21
[02:28] <javatexan> does anyone have a to-dvd-mpeg2 conversion....I'll just use that for now
[02:43] <rhpot1991_laptop> nuvexport generated this for dvd:
[02:43] <rhpot1991_laptop> /usr/bin/nice -n19 ffmpeg -y -f s16le -ar 48000 -ac 2 -i /tmp/fifodir_9441/audout -f rawvideo -pix_fmt yuv420p -s 720x480 -aspect 1.33333333333333 -r 29.970 -i /tmp/fifodir_9441/vidout -aspect 1.3333 -r 29.97 -deinterlace -croptop    6 -cropright 10 -cropbottom 6 -cropleft  10 -s 720x480  -b '6000k' -vcodec mpeg2video -qmin 5 -ab '384k' -ar 48000 -acodec mp2 -f dvd '/mythtv/ipod/5 (WPMT) - Wed Jan 2 14-00-00 2008.mpg' 2>
[02:44] <rhpot1991_laptop> you can try messing with that line or with nuvexport: http://www.mythtv.org/wiki/index.php/Nuvexport
[04:41] <jargonjustin> Hi, I've got Mythbuntu 7.10 installed on a box with a Hauppauge PVR-150 and am having trouble getting the remote working.  After the install, I tried it and it "just worked" but now that I'm finishing setting up the box, something broke.
[04:41] <superm1> well what'd you change?
[04:42] <jargonjustin> superm1: Nothing, I thought :-/ I did do an apt-get upgrade though
[04:42] <superm1> well take a look at your dpkg log
[04:42] <superm1> and see what got upgraded
[04:42] <superm1> that could have broken in
[04:44] <jargonjustin> It looks like mythbuntu-lirc-generator was upgraded (0.16 to 0.17), but I'm didn't touch the configs at that point
[04:44] <superm1> nothing else?
[04:44] <superm1> no linux-ubuntu-modules
[04:45] <superm1> or kernel or anything
[04:49] <jargonjustin> Oh, I grepped for lirc, looks like it installed a linux-image
[04:49] <superm1> linux-ubuntu-modules installs the kernel modules
[04:50] <jargonjustin> I see the package in the initial install, but not for the upgraded image
[04:51] <superm1> well check whether the modules are loaded
[04:52] <jargonjustin> Although "uname -r" says "2.6.22-14-generic" which is what I originally had
[04:52] <superm1> and open mcc and check that the proper remote is set
[04:53] <jargonjustin> lsmod shows lirc_i2c, lirc_dev and i2c_core, MCC has the Hauppange TV card set (I removed it and had it set it back up again as well)
[04:53] <superm1> try irw
[04:53] <superm1> and see if you can capture any button presses
[04:53] <jargonjustin> Looks like /etc/lirc/lircd.conf is correct as well
[04:54] <jargonjustin> Nothing from irw still
[04:55] <superm1> okay well even though it was fine before, check the cable
[04:55] <superm1> just to make sure nothing got jiggled in the process by accident
[04:55] <superm1> i know those i2c cables are really finicky
[04:56] <jargonjustin> The cable looks good, I plugged and unplugged to be sure, and the LED lights when it's partially plugged it (it has a blaster which I don't need / haven't tested)
[04:57] <jargonjustin> Does the LiveCD support lirc?
[04:57] <superm1> it does
[04:57] <jargonjustin> I'll try booting off that and see if it works
[04:57] <superm1> it has to (obviously) be configured for your remote
[04:57] <superm1> but yeah
[04:58] <jargonjustin> Thanks for the help by the way
[05:00] <superm1> no prob
[05:04] <jargonjustin> It doesn't seem to be working off of the live cd
[05:08] <jargonjustin> I'm starting to think it didn't actually work before and maybe I just imagined it…
[05:15] <jargonjustin> Any suggestions for other troubleshooting steps, or things that would be good to check if it hadn't worked before?
[05:25] <superm1> the batteries in the remote :)
[05:27] <jargonjustin> superm1: first thing I checked :-)
[05:43] <jargonjustin> Alright, thanks for the help
[05:51] <hansoffate-lapto> how do i tell if my card is set for opengl?
[05:59] <MythbuntuGuest75> mythbuntu requires a front and backed to function correct?
[06:06] <hansoffate-lapto> uhh,
[09:40] <mog__> doesn't mythbuntu use /etc/network/interfaces ?
[15:24] <blkorpheus> updates broke frontend
[15:25] <blkorpheus> frontend
[15:33] <squish102> i didnt realise ppl did updates once they had a running mythtv
[15:33] <squish102> ive stopped updates as i am tired of fixing things after they get broken with updates
[15:37] <blkorpheus> wow
[16:10] <blkorpheus> /usr/bin/mythfrontend.real: symbol lookup error: /usr/lib/libmyth-0.20.2.so.0: undefined symbol: stat64
[16:25] <blkorpheus> https://bugs.launchpad.net/ubuntu/+source/mythtv/+bug/185108
[16:29] <directhex|bsp> that bug report desperately needs version numbers for all related packages
[17:33] <superm1> squish102, that is on hardy (development release)
[17:33] <superm1> on a stable release updates should be safe
[18:27] <Bastian> hi
[18:28] <Bastian> what do i need to play dvd with the mythbuntu ?
[18:28] <tgm4883_laptop> mythvideo
[18:28] <tgm4883_laptop> err
[18:28] <tgm4883_laptop> mythdvd?
[18:29] <Bastian> these 2 pakages `
[18:29] <Bastian> ?
[18:29] <tgm4883_laptop> just mythdvd
[18:29] <tgm4883_laptop> unless you want to play encrypted dvds
[18:29] <tgm4883_laptop> then you will need an additional package
[18:30] <Bastian> ok
[18:30] <Bastian> which
[18:30] <Bastian> ?
[18:30] <tgm4883_laptop> libdvdcss2
[18:30] <tgm4883_laptop> can be insalled from MCC
[18:31] <thegodfather> hi guys
[18:31] <tgm4883_laptop> hi
[18:31] <Bastian> hi
[18:31] <thegodfather> does Mario Limonciello IRC?
[18:32] <thegodfather> i am hitting #185108
[18:32] <thegodfather> i think it might be glibc related
[18:32] <compy> will i386 builds work on my amd64
[18:32] <Bastian> @ the start of mythbuntu my system are doing scaling die themepictures, is that right ?
[18:32] <Bastian> because it takes a lot of time
[18:35] <Bastian> and which resolution i should use ?
[18:35] <Bastian> 1280x1024 ?
[18:35] <tgm4883_laptop> superm1, ping
[18:36] <tgm4883_laptop> compy, yes
[18:36] <tgm4883_laptop> Bastian, use whatever resolution your display supports
[18:42] <tgm4883_laptop> thegodfather, he is in and out
[18:42] <thegodfather> ok thanks
[18:42] <thegodfather> glibc is fine..
[18:42] <thegodfather> this is weird
[18:51] <superm1> i'm here
[18:52] <superm1> thegodfather,
[18:52] <superm1> are you on amd64?
[18:52] <thegodfather> superm1: no, i386
[18:52] <thegodfather> superm1: i just added some info to #185108
[18:52] <superm1> thegodfather, did you just upgrade a bunch of other packages too, or just myth?
[18:52] <thegodfather> dist-upgrade from gutsy to hardy
[18:52] <thegodfather> this bug could even be a kernel bug
[18:52] <superm1> so was mine, and mine is fine (with all packages updated..)
[18:52] <thegodfather> but i can reboot with an old kernel
[18:53] <thegodfather> and see
[18:53] <thegodfather> ok.. rebooting.. just need a few secs
[18:54] <thegodfather> superm1: i can trigger the issue easily with mythtv-setup
[18:54] <thegodfather> if i try to add a new card, it will scan for /dev/video and crash
[18:54] <thegodfather> try that
[18:54] <superm1> well the machine that i'm on doesn't have tuners unfortunately.
[18:54] <thegodfather> the backend doesn't always crash if you have the option enabled to use a card on demand
[18:54] <superm1> can you get a backtrace at all?
[18:54] <thegodfather> yes i have a trace
[18:54] <thegodfather> strace
[18:55] <thegodfather> but it's of no use
[18:55] <superm1> do you have apport-gtk installed?
[18:55] <superm1> or apport-kde ?
[18:55] <thegodfather> no, it's a very custom machine
[18:55] <superm1> can you install apport?
[18:55] <superm1> it will build a backtrace that is usable
[18:55] <superm1> from debug symbols
[18:56] <compy> would you guys recommend me installing mythbuntu i386 or i686 if i have amd64x2
[18:57] <compy> ie, are there many problems w/ 64 bit mythtv users?
[18:57] <tgm4883_laptop> compy, FYI, i686 is 32-bit
[18:57] <tgm4883_laptop> you mean x86_64
[18:57] <thegodfather> superm1: yes i know what apport is, and no, i don't plan to clutter that machine :)
[18:57] <compy> tgm4883_laptop, oh hehe then yeah x86_64
[18:57] <tgm4883_laptop> compy, i'd run 64-bit version
[18:58] <compy> tgm4883_laptop, so you dont have any mythtv problems?
[18:58] <superm1> thegodfather, well you can remove it when you're done, it would be really useful in this case to catch this issue
[18:58] <superm1> since none of us can reproduce it in VMs or anything like that.
[18:58] <tgm4883_laptop> currently though, im only running 32-bit to do a bug with ir blasting and the pvr-150, although that should be fixed by now
[18:58] <tgm4883_laptop> im just too lazy to change it right nowo
[18:58] <tgm4883_laptop> nope, no mythtv problems other than the ir blasting thing
[18:58] <tgm4883_laptop> lirc was hanging and such
[18:59] <tgm4883_laptop> what tuners do you have?
[19:00] <compy> tgm4883_laptop, none currently, but when i buy one ill be sure it will work in 64 bit
[19:00] <tgm4883_laptop> compy, SD or HD?
[19:00] <thegodfather> superm1: it's not kernel related.. one thing less to worry about
[19:00] <compy> sd?
[19:00] <thegodfather> superm1: old kernel shows the same problem
[19:00] <tgm4883_laptop> get a PVR-150 or a PVR-500
[19:00] <tgm4883_laptop> although HD is great
[19:00] <compy> i will want to do HD in the future
[19:01] <compy> i dotn have a high def tv so its pointless at this point
[19:01] <tgm4883_laptop> I suppose
[19:04] <thegodfather> superm1: apport doesn't catch it
[19:09] <superm1> hmm interesting
[19:09] <thegodfather> superm1: dpkg - warning: downgrading libmyth-0.20 from 0.20.2+fixes15096-0ubuntu2 to 0.20.2-0ubuntu10.1.
[19:09] <thegodfather> ^^^ this work
[19:09] <thegodfather> any newer version of the library do crash
[19:09] <superm1> well that's interesting.
[19:10] <thegodfather> there can be 2 million reasons why it breaks
[19:10] <thegodfather> mostlikely code in mythtv :)
[19:10] <superm1> well let me diff the two source packages
[19:10] <superm1> and see how much could have really cahnged
[19:10] <thegodfather> so one test would be to rebuild the old source on top of the new toolchain
[19:10] <thegodfather> and see if that's still ok
[19:10] <superm1> can you try turning off upnp
[19:10] <superm1> there is a whole bunch of upnp changes
[19:11] <superm1> in the diff
[19:11] <thegodfather> how do i do that?
[19:11] <superm1> edit /etc/default/mythtv-backend
[19:11] <thegodfather> i am not a real mythtv expert
[19:11] <thegodfather> ok
[19:11] <superm1> there is an area for extra args
[19:11] <thegodfather> will they work for mythtv-setup as well?
[19:11] <superm1> add --noupnp
[19:11] <superm1> to it
[19:11] <thegodfather> the backend is not running
[19:12] <superm1> this is a frontend only box?
[19:12] <thegodfather> this machine is both
[19:12] <thegodfather> the backend crashes with the same error
[19:12] <thegodfather> 19:54 < thegodfather> the backend doesn't always crash if you have the option enabled to use a card on demand
[19:13] <superm1> okay hm
[19:13] <thegodfather> brb...
[19:13] <superm1> ls
[19:13] <thegodfather> so will that config change affect mythtv-setup.real or not?
[19:13] <superm1> well it changes something in sql
[19:14] <superm1> so it potentially can affect mythtv-setup.real
[19:15] <Daviey> Is this trunk?
[19:16] <superm1> no its not
[19:16] <superm1> its just -fixes, uploaded yesterday for a few small bug fixes
[19:17]  * Daviey didn't know upnp was in -fixes :O
[19:17] <superm1> yeah they bckported the entire thing from trunk
[19:17] <superm1> at 0.20.2
[19:19] <Daviey> awww, thats very un-myth to introduce whole new features into released versions
[19:19] <Daviey> SD excemption ofc'
[19:20] <superm1> well upnp was causing crashes
[19:20] <superm1> in 0.20.1
[19:20] <superm1> when someone had say a 360 on their network
[19:20] <Daviey> two upnp 'servers'?
[19:22] <superm1> beats me what it was
[19:22] <superm1> but also my openwrt liked to fsck it up sometimes
[19:23] <superm1> well diffing the two .orig.tar.gz's, nothing here looks crazy enough to cause these crashes
[19:23] <superm1> very minor changes
[19:23] <Daviey> odd
[19:25] <superm1> thegodfather, can you ldd that libmyth
[19:25] <superm1> and see if something is missing?
[19:55] <superm1> Daviey, okay i tested the new iso you made
[19:55] <superm1> appears to be working fine
[19:55] <superm1> i dont see the issue thegodfather was having either
[19:55] <superm1> but then again i dont have a tuner in this box
[19:55] <superm1> so i cant put that option for using a card on demand
[19:55] <thegodfather> superm1: nothing was missing. that was my first check
[19:56] <superm1> thegodfather, hm
[19:56] <superm1> the thing is that stat64, i thought came from glibc
[19:56] <superm1> so that's just so bizarre
[19:57] <thegodfather> superm1: it's there..
[19:57] <thegodfather> let me upload the strace somewhere
[19:57] <thegodfather> you will see tons of lstats64 before that one
[19:57] <thegodfather> that was my second thought..
[19:57] <thegodfather> and glibc is fine
[19:57] <superm1> well the thing that also gets me, is k3b broke recently
[19:57] <superm1> according to one of those bugs
[19:57] <thegodfather> lack of stat64 would make the world come to a unpleasent end
[19:57] <superm1> so it makes me think build-dependency that broke
[19:58] <superm1> yes it would
[20:01] <thegodfather> well check the build log?
[20:01] <thegodfather> and diff it with the old one
[20:01] <superm1> there has been a ton of changes on the build depends
[20:01] <superm1> i can say that for sure
[20:19] <_taz_> superm1 do you know of mythtv working with IPTV, specifically U-Verse from AT&T?
[20:19] <superm1> no i can't say i do
[20:19] <_taz_> this could suck :)
[20:19] <superm1> i can't say i dont either though :)
[20:20] <TazgodX> im switching from comcast digital cable to AT&T U-Verse very shortly and my mythbox might be useless
[20:21] <fabbione> stupid adsl
[20:24] <TazgodX> hmmm, what kind of host name is that tgm4883?
[20:26] <thegodfather> superm1: did you try to talk to Marillat?
[20:26] <superm1> thegodfather, our package is significantly different than his nowadays
[20:26] <thegodfather> his library segfaults the same way
[20:27] <superm1> thegodfather, on a debian box?
[20:27] <superm1> or on hardy?
[20:27] <thegodfather> on hardy
[20:27] <thegodfather> i don't have debian here
[20:27] <superm1> see that's why i'm thinking another library that we depend on is doing it
[20:28] <thegodfather> superm1: look for the code that opens /dev/video...
[20:28] <superm1> if this was only happening in the frontend, i'd say take off mythmusic, because there is a libmp5v2 transition going on
[20:28] <thegodfather> shouldn't be too hard to spot
[20:28] <superm1> but since its with video devices in the backend...
[20:28] <superm1> *mp4
[20:28] <thegodfather> and -setup...
[20:28] <thegodfather> not just the backend
[20:30] <thegodfather> oh good... the mercurial repo of v4l-dvb + hvr3000 patch starts to work decently
[20:30] <thegodfather> at least dvb-s, dvb-t and analog..
[20:30] <thegodfather> radio is still flacky
[20:31] <wek> I have some trouble with the xmltv. I adde xmltv as videosource , then connected it to my two dvb cards in the input connections. Then I added the xmltv id via mythweb into the channels. After doing mythfilldatabase --manual, the xmltv asks me for callsign,channelid,... and creates new channels. I searched for mythtv and xmltv tutorials on the net but did not find any. Help appreciated. wek: Well I guess i should aska question: Which channels
[20:31] <wek>  do I need to delete? Is there any sense of unclicking the dvb epg data tickbox at the end in mythweb?
[20:31] <trimeta> Anyone know how the UPnP/DLNA stuff works? In particular, where do I put my music on my Mythbuntu box such that it will be shared?
[20:32] <wek> trimeta: Shared via which protocol: samba?
[20:32] <trimeta> No, UPnP.
[20:32] <trimeta> I've got Samba sharing working.
[20:32] <trimeta> http://www.mythtv.org/wiki/index.php/Talk:UPnP
[20:32] <trimeta> Wait, not the talk page.
[20:33] <trimeta> But you get the idea.
[20:34] <tgm4883> TazgodX, huh?
[20:34] <tgm4883> oh, thats the default one for the space station
[20:34] <tgm4883> we get pretty good connection up here, but no ipv4
[20:36] <superm1> tgm4883, oh is that why your build took so long?
[20:36] <tgm4883> heh, yep
[20:36] <tgm4883> it's a wireless connection, so we have to deal with solar flares
[20:36] <tgm4883> and sun spots
[20:36] <superm1> it all makes sense now
[20:37] <tgm4883> now you know why I can't get cable anymore ;)
[22:23] <tgm4883_laptop> Any alpha testers around?
[22:35] <rinaldi_> hi i set a program to record earlier and it finished 30 mins ago. however when i go to view my recording through the frontend via media library > watch recordings i can only see a few of my previous recordings. the program i recorded is definitly in var/lib/mythtv/recordings . is there anything i have missed out?
[23:23] <MythbuntuGuest79> pvr-500, vlc, clock gap. Anyone know how to fix?
[23:29] <MythbuntuGuest79> Anyone even awake?


[00:08] <meena> Goneri: ifconfig_vtnet0=dhcp was already there before cloud-init touched it. I'm talking about the defaultrouter line!
[00:09] <Goneri> meena, there is probably a name=eth0 in the metadata that force the renaming, so line 12 and 13 are ok
[00:09] <Goneri> and so far, the provider does not clean up the previous lines from the /etc/rc.conf, should it?
[00:10] <Goneri> ah nice defaultrouter
[00:12] <meena> re cleanup: nah
[00:12]  * meena sleep now
[01:13] <Goneri> thanks you rharper and Odd_Bloke for the reviews, I think I've addressed all of them.   How's stuff and / or junk?
[11:19] <mkrai__> Hi cloud-init team, is there any centos cloud image with cloud-init-18.5?
[11:23] <mkrai__> meena, Hi
[11:41] <meena> mkrai__: why so specific?
[11:42] <mkrai__> meena, Hi, I am facing issue on centos 7.6 with cloud-init
[11:42] <mkrai__> network is not configured
[11:45] <mkrai__> the cloud-init configures the wrong interface
[11:51] <mkrai__> meena, ^
[11:52] <meena> mkrai__: which cloud? how exactly is it configured wrong?
[11:52] <mkrai__> meena,
[11:52] <mkrai__> meena OpenStack
[11:54] <meena> mkrai__: what do the logs say?
[11:54] <mkrai__> meena, I have 3 interfaces on the node, 2 ethernet(enps0f0 and enps0f1) and 1 HFI(ib0). Openstack tries to boot interface on enps0f1 but cloud-init does on enps0f0
[11:55] <mkrai__> meena, http://paste.openstack.org/show/787707/
[12:37] <meena> mkrai__: and paste cloud-init query --all
[12:39] <meena> that was supposed to be expressed less urgent and more friendly, but, phone swipe
[12:41] <mkrai__> meena, http://paste.openstack.org/show/787784/
[12:57] <meena> mkrai__: as root or with sudo ;)
[12:57] <meena> wait that is
[12:58] <meena> weird
[12:58] <mkrai__> meena, with sudo
[13:03] <meena> mkrai__: yeah, sorry, what i mean is, the result is weird
[13:04] <mkrai__> meena, yeah, that seems weird to me to ;)
[13:05] <meena> mkrai__: can you curl the metadata URL?
[13:05] <mkrai__> meena network is not configured so I can't
[13:06] <meena> https://docs.openstack.org/nova/latest/admin/metadata-service.html
[13:06] <meena> well, yeah, that makes sense
[13:09] <meena> i just admit I've never setup a three interface computer with cloud-init, we'd usually only setup one interface, and do the rest with puppet
[13:18] <ananke> I'm trying to wrap my head around how to leverage packer and cloud-init to automate creation of golden AMIs. there are some actions that need to take place while the given AMI is being baked, and there are some that will happen on each boot of an instance using that AMI
[13:19] <ananke> with that in mind for the actions that need to take place on each boot, should I be placing cloud-init stuff in /var/lib/cloud/scripts/per-boot, or should I tack onto /etc/cloud/cloud.cfg.d/ ?
[13:20] <ananke> my source will be various linux distros sanctioned by their vendors, such as ubuntu/centos/etc, so they already have cloud-init in their AMIs
[13:33] <meena> ananke: unless Packer provides a metadata service, https://cloudinit.readthedocs.io/en/latest/topics/datasources.html you'd wanna stick with a script
[13:34] <meena> ananke: cloud-init should only run on the first boot on your AMI, to fix the partition and fs sizes and setup network and hostname
[13:36] <ananke> meena: packer utilizes ec2 metadata server to seed it the initial user data. these will be golden AMIs that will receive additional setup when they become instances
[13:37] <meena> ananke: cool cool cool
[13:37] <ananke> seeing as cloud-init is supposed to provide all of the above functionality, per-instance, per-boot, per-once, etc - I'm wondering what is the appropriate location I should be leveraging. it seems that these days cloud-init is baked into most major AMIs
[13:57] <meena> I'm just a firm believer in idempotency, and puppet
[13:59] <meena> what with being Co-founder of voxpupuli and all
[14:54] <Odd_Bloke> ananke: The /var/lib/cloud/scripts/per-* paths sound like what you want, I think.
[14:54] <Odd_Bloke> meena: cloud-init runs on every boot, but a lot of what it does only happens on first boot.
[15:21] <otubo> Odd_Bloke: meena thanks for the reviews. I updated my branch with the fixes. Also, I force pushed a commit to remove an automatic non-ff merge from master (ugh, sorry), shouldn't be a problem, though.
[15:22] <meena> Odd_Bloke: that does not change my preference towards systems that are made to be idempotent.
[15:36] <Odd_Bloke> meena: Sure, but "cloud-init should only run on the first boot on your AMI" does not describe cloud-init's default behaviour, nor its behaviour in any distros I'm aware of. :p
[15:36] <Odd_Bloke> (If you want to install Ruby on your systems, that's your business. ;)
[15:37] <meena> Ruby is one of the best debuggable systems i know, so yes, i love working with it
[15:38] <meena> hit me up, as soon as python has something close in comfort and power to pry and pry-byebug
[15:40] <Odd_Bloke> meena: ipdb?
[15:46] <meena> Odd_Bloke: how do i show the source code of a thing in ipdb?
[15:48] <powersj> meena, if you are at a break point type 'l'
[15:52] <Odd_Bloke> meena: `l` will show you your current source code context, is that what you meant?
[15:55] <meena> Odd_Bloke: nah, more like show me the implementation of x
[15:56] <Odd_Bloke> So in IPython you can do foo?? and it will display that.  `ipdb` gives me a SyntaxError if I try to do that, so maybe it isn't possible.
[16:01] <Odd_Bloke> meena: Aha, `psource`.
[16:53] <mkrai__> Odd_Bloke, portdirect smoser meena https://bugs.launchpad.net/cloud-init/+bug/1857031 whenever you've time. Thanks!
[16:56] <blackboxsw> mkrai__: can you please run "cloud-init query --all" on that machine and attach the content to the bug?  I'd particularly like to see the contenst of network_json that is reported there
[16:56] <blackboxsw> bah missed it, I'll add it to the bug
[16:56] <smoser> he's gone
[16:56] <blackboxsw> yeah followup up on the bug :/
[16:56] <smoser> look for WARN
[16:56] <smoser> thats the issue
[16:56] <smoser> centos 7 .
[16:57] <blackboxsw> ahh thanks, just did a quick driveby and hadn't caught up on backlog
[16:57] <blackboxsw> and looks like the submitter also attached a paste of network data .json already to the bug anyway too
[16:58] <smoser> its a dupe of https://bugs.launchpad.net/cloud-init/+bug/1801364
[16:58] <blackboxsw> ahh right, yeah
[16:58] <blackboxsw> you nailed that symptom/fix, but that shouldn't have affected which network device got chosen I would think. but looking a bit more into it
[16:59] <smoser> well,  it fails during local
[16:59] <smoser> so it just tries the fallback/dhcp
[17:00] <blackboxsw> and interesting is that the 'fix' was released in 18.5 I think and logs are from 19.2 cloud-init
[17:01] <blackboxsw> ohhh 18.2
[17:01] <blackboxsw> not 19.2
[17:01] <blackboxsw> my mind was playing tricks on me
[17:01] <smoser> i'm not certain ther are not other issues at play
[17:01] <smoser> there may well be.
[17:02] <smoser> but if it doesn't persist the data then we're down a sour path
[17:06] <ananke> Odd_Bloke: thanks!
[17:49] <blackboxsw> thx for the triage on that bug smoser. yes on the instance-data.json being a sour path. Yet, the perist_instance_data happens after _get_data was already run successfully or otherwise. So, I *think* we just don't get the instance-data.json in that case without any other fallout.   In either event, 18.2 is missing a bunch of fixes over the last year and a half for both network, so I just pointed them at
[17:49] <blackboxsw> copr/el-testing and asked for a reproducer
[17:55] <ananke> oops, sorry
[18:02] <smoser> blackboxsw: yeah, for a lot of reasons copr repo is a good iea there.
[19:04] <meena> i approve: https://github.com/canonical/cloud-init/pull/132
[19:22] <meena> rharper: added your test: https://github.com/canonical/cloud-init/pull/53
[19:22] <Odd_Bloke> meena: rharper is done for the year, FYI.
[19:29] <Odd_Bloke> powersj: blackboxsw: https://github.com/canonical/cloud-init/pull/130 <-- would be good to land this clarification to HACKING
[19:35] <meena> Odd_Bloke: right, you mentioned that yesterday.
[19:38] <meena> Odd_Bloke: you should also add how to do stuff at lp, cuz lotsa people find it confusing.
[19:38] <Odd_Bloke> meena: "do stuff at lp"?
[19:39] <meena> Odd_Bloke: how to fork stuff @ launchpad
[19:39] <meena> and how to push there, cuz i've seen at least 2 found that challenging.
[19:42] <Odd_Bloke> meena: Oh, for the CLA stuff?
[19:43] <Odd_Bloke> Yeah, that would be good.
[19:43] <Odd_Bloke> I was on vacation when the migration happened, so I don't really know how much the script handles etc.
[19:54] <meena> i haven't looked at the script lately, tbf. so maybe it's magically fixed by now
[19:54] <Odd_Bloke> meena: So regarding Cirrus CI, we'd be happy to introduce it as a non-voting status check provided it wouldn't cost us anything (which, looking at the docs, it shouldn't).  So if you want to go take a look at making that happen, please feel free!
[19:54] <blackboxsw> #130 is approved. I'll run through the migration tool again now in light of upstream now being in github to see if it works
[19:55] <Odd_Bloke> meena: (For reference, when I was iterating on our Travis config, I just configured it against my fork, so hopefully you shouldn't need anything from us to get something working.)
[19:56] <meena> Odd_Bloke: i've configured cirrus before: https://github.com/bsdci/libioc/blob/master/.cirrus.yml
[19:57] <Odd_Bloke> Nice!
[20:15] <Goneri> rharper, Odd_Bloke: I've addressed all your comments https://github.com/canonical/cloud-init/pull/61 and re-tested with FreeBSD 10, 11 and 12. Bonus point, I've pushed two extra fixes for minor issues.
[20:15] <Goneri> I'm totally confident the branch can be merged.
[20:18] <meena> I'll be testing it in a minute.
[20:18] <Odd_Bloke> Goneri: Nice!
[20:19] <Goneri> I'm uploading the refresh qcow2 images
[20:27] <Odd_Bloke> Goneri: Looks like a pyflakes failure on #61
[20:37] <Goneri> naahh, it's impossible!
[20:37]  * Goneri takes a look
[20:38] <Odd_Bloke> Goneri: Also it looks like you haven't migrated your CLA signature over to GitHub yet.
[20:39] <Odd_Bloke> Goneri: https://cloudinit.readthedocs.io/en/latest/topics/hacking.html tells you how to do that (TL;DR: use tools/migrate-lp-user-to-github)
[20:42] <Goneri> Odd_Bloke, https://github.com/canonical/cloud-init/pull/133
[20:46] <Odd_Bloke> Thanks!
[20:59] <meena> Goneri: i got a stacktrace.
[21:04] <meena> Goneri: ah, yeah, makes sense. https://gist.github.com/c4201008d52bc1bab7bd9cc81d217956
[21:05] <Goneri> meena, lets me guess IPV6 with CIDR notation?
[21:05] <meena> absolutely.
[21:05] <meena> lemme show you ;)
[21:06] <Odd_Bloke> If we know IPv6 isn't supported yet, is that a blocker?
[21:07] <Goneri> not really, I will just add a skip if netmask is null
[21:07] <Odd_Bloke> OK, cool.
[21:08] <meena> https://gist.github.com/92db11324aecb2ee1eb376745339ed65
[21:09] <meena> Goneri: you should skip everything that's None ;)
[21:10] <Goneri> https://imgflip.com/i/3jzpiv
[21:12] <meena> "review" https://github.com/canonical/cloud-init/pull/61#pullrequestreview-334933456
[21:17] <Goneri> meena, https://github.com/goneri/cloud-init/commit/3e6a1199031d9477ddd8d33234023f942a2ba79f
[21:17] <blackboxsw> Goneri: per https://github.com/canonical/cloud-init/pull/133  I'm missing a correlating launchpad branch for you. and I expected the PR message was going to be something other than goneri as the username
[21:18] <Odd_Bloke> blackboxsw: I closed out the MP.
[21:18] <Odd_Bloke> blackboxsw: And what do you mean by "something other than goneri as the username"?
[21:18] <Goneri> I'm confused too :-X
[21:19] <blackboxsw> https://github.com/canonical/cloud-init/pull/133/files
[21:19] <blackboxsw> that mp is open
[21:19] <Odd_Bloke> That's a PR.
[21:19] <Odd_Bloke> I closed the MP.
[21:19] <blackboxsw> oops
[21:19] <blackboxsw> ahhh
[21:19] <blackboxsw> ok nevermind, you were on it Odd_Bloke
[21:19] <Odd_Bloke> :)
[21:20] <blackboxsw> I was expecting to see a branch in LP authored by
[21:20] <blackboxsw> Gonéri Le Bouder
[21:20] <blackboxsw> which I didn't realize mapped to goneri :)
[21:20] <Odd_Bloke> blackboxsw: https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/377008 :)
[21:20] <blackboxsw> and since I saw no branch over there I thought maybe it was an accidental wrong username supplied
[21:20] <meena> Goneri: IPv4 could also be in CIDR notation.
[21:20] <blackboxsw> +1 Odd_Bloke Goneri ... don't mind me
[21:21] <meena> or? do we need to back-calculate it then?
[21:23] <Goneri> meena, the existing code base does not support IPv4 CIDR notation, so it's not a regression.
[21:27] <Goneri> and it's a corner case anyway, I doubt it happens often :-)
[21:29] <meena> does any of the other renderers handle it?
[21:30] <Odd_Bloke> If it's not supported on FreeBSD in the current codebase, I think we can land this PR without it.
[21:30] <Odd_Bloke> meena: Do you disagree?
[21:30] <meena> Odd_Bloke: aye, makes sense given that nothing much is supported in the current code base.
[21:31] <Odd_Bloke> Cool. :)
[21:34] <Odd_Bloke> meena: Goneri: So are we good to merge #61 (after an up-to-date CI run, of course)?  Or do you want to do another round of testing?
[21:35] <meena> i'll do another reboot and see what it does :O
[21:35] <meena> also, can someone tell me why cloud-init would refuse to run my runcmd section?
[21:35] <Goneri> I'm confident we won't see a horde of FreeBSD users coming on this channel in the coming days
[21:35] <Goneri> I've to go, I will be back later today.
[21:38] <blackboxsw> either, already ran on that instance (not per boot),  bad yaml, or disabled runcmd in /etc/cloud/cloud.cfg(.d/*cfg) ?
[21:39] <meena> blackboxsw: could be bad yaml…
[21:40] <meena> blackboxsw: https://gist.github.com/90f3ea89f4339d2297a9f5a356e04b8d
[21:40] <blackboxsw> meena: try this:     sudo cloud-init query userdata > myud.yaml; cloud-init devel schema -c myud.yaml --annotate
[21:41] <blackboxsw> it'll quickly vet your yaml at least
[21:41] <meena> aye
[21:41] <blackboxsw> runcmd.   <- the dot
[21:41] <blackboxsw> hrm nope ... sorry : it was offscreen for me on the laptop
[21:42] <meena> blackboxsw: i'm thinking it's - # these comments probably don't work
[21:43] <meena> yupp. that's what it is.
[21:44] <meena> Cloud config schema errors: runcmd.2: None is not valid under any of the given schemas, runcmd.5: None is not valid under any of the given schemas, runcmd.8: None is not valid under any of the given schemas
[21:44] <meena> lines 2, 5, and 8 are comments
[21:45] <blackboxsw> ooh interesting. hrm. that schema is defined so validation was attempted.
[21:45] <Odd_Bloke> Lines 2, 5 and 8 are empty list items followed by comments.
[21:46] <Odd_Bloke> If the comment marker was before the -, everything would be fine.
[21:46] <blackboxsw> I see, word wrap was making that hard to read for me
[21:47] <meena> so the damage is self-inflicted.
[21:47] <blackboxsw> ahh and meena I'd also expect to see something like 2019-12-19 21:43:05,262 - util.py[WARNING]: Failed to shellify .... into /var/lib/cloud/instances/loved-seal/scripts/runcmd
[21:47] <meena> let's see.
[21:47] <blackboxsw> in your /var/log/cloud-init.log
[21:48] <meena> i'm pretty, and sure, i've posted the logs; but let's try again.
[21:48] <blackboxsw> it would be nice if we bubbled up warnings to cloud-init status --long
[21:48] <meena> blackboxsw: also, i'd expect that to be a slightly higher error level, so you know you fucked.
[21:49] <blackboxsw> yeah fairly. though cloud-init walks a line and tries not to be fatal if some components are not run. runcmd may not be critical to the operation of the node. but it certainly is a case where the user should be alerted
[21:50] <meena> blackboxsw: maybe it'd be cool if *i* could decide if runcmd is critical or not…
[21:50] <blackboxsw> meena: heh truly
[21:51] <meena> yeah, so cloud-init status only gives us errors: https://gist.github.com/126df102d581a75572fff2c74eb69b0f
[21:51] <blackboxsw> yeah meena, it only bubbles up errors, it doesn't queue and raise warnings
[21:51] <blackboxsw> and I think it may only bubble up one error (not all of them)
[21:53] <blackboxsw> so there is improvement to be had there
[21:54] <blackboxsw> it's worth a bug on runcmd not being rendered, at least we could raise the warning to error
[21:55] <blackboxsw> and it's also a place that is a source of many many human-introduced errors
[21:55] <meena> i don't have a WARNING failed to shellify blah, cuz it's failing earlier. (i reckon)
[21:55] <meena> I'll post the logs maybe you can read them easier.
[21:55] <blackboxsw> thanks
[21:56] <meena> https://gist.github.com/6cfa360eb13d2c2396f6a4cea63c912d
[21:56] <meena> https://gist.github.com/c6c5eb792918e252b5b21cda3b5c9c25
[21:58] <Odd_Bloke> -ENOGONERI
[21:59] <Odd_Bloke> meena: I'm heading out now, but I'll check back in later because I'd love to get #61 landed.  If Goneri returns, could the two of you decide if we're good to go and ping me to let me know?
[22:03] <meena> Odd_Bloke: ok, cool — thanks for all the help
[22:16] <smoser> blackboxsw: https://bugs.launchpad.net/cloud-init/+bug/1801364 is fix-released ?
[22:18] <blackboxsw> smoser: should be as of 19.2-53-g067516d7b
[22:19] <blackboxsw> which is Xenial ++
[22:19] <smoser> so that bug should be Fix Relased
[22:19] <smoser> though
[22:19] <smoser> right?
[22:19] <smoser>  not Committed ?
[22:19] <smoser> somehow it got missed
[22:20] <blackboxsw> smoser: ahh right, I think this could be due to the shift to github. yes. I'll scrub the bug list that's been released and confir,
[22:20] <blackboxsw> confirm even
[22:34] <meena> i'm happy with Goneri's patch. but I'll add another patch to beautify the code a bit.
[22:56] <blackboxsw> ok found 44 bugs released in 19.2 or later. only 17 or which were fix released.
[22:56] <blackboxsw> I'm running a script now to close them out as fix released with the appropriate comment about the expected cloud-init version that released them
[23:04] <blackboxsw> ok script complete, if anyone notices bugs in fix committed state that should be fix released please let us know. I'm adapting our release and publishing scripts to try to account for this gap.
[23:34] <blackboxsw> thanks for the pretty red and green label colors OddBloke. I'm getting into the Christmas Spirit
[23:38] <blackboxsw> otubo: if you get a chance in the next few days please run:     ./tools/migrate-lp-user-to-github otubo otubo       # to correlate your launchpad user to github user accounts
[23:39] <meena> opened a fresh PR for Goneri: https://github.com/goneri/cloud-init/pull/2
[23:56] <meena> Goneri: https://github.com/goneri/cloud-init/pull/2 some æsthetics.
[23:56]  * meena → bed.


 @philipz i implemented config changes on the bot.  lets see if that works (the config for 'ignored nicks' on Telegram side of things is... sparse.)
 on the bridge*
 @teward001 thanks.
 let's give it a try.
 Test
 seems it was a success
 cool cool
 i'm using a narrow enough regex but also a broad enough one that it'll match heh
 great. thanks again.