[00:01] bigjools: i'm in the hang out [00:02] flacoste: hi - I don't see an invitation [00:02] now I do [00:02] bigjools: it was the hang out linked to the event [00:03] bigjools: right, but my point was that when you only install maas-cluster-controller you need to tell the MAAS URL too right? === matsubara is now known as matsubara-afk [05:00] hi jam [06:41] hi bigjools [06:41] (I was around earlier, but had to run some errands) anything you need? [06:42] jam: no, just saying hi :) [06:56] well cool, commissioning a new and I see hardware info appearing :) [06:56] new node*{ [06:59] bigjools: yay [07:11] sadly the ipmi detection is not so good, it thinks the BMC has an ip address of 0.0.0.0 [07:20] bigjools: that just means it is accessible from everywhere, right? :) [07:21] jam: that's *one* way of looking at it [08:24] Morning. [08:24] Morning allenap. [09:01] bigjools: I think I might know how we've had test suite failures in Jenkins. [09:01] It appears that if you submit a branch, and it fails the test suite [09:02] Submitting it again just accepts it (without running the tests) [09:02] ! [09:02] I have done that in the past and it didn't land though [09:02] I could be wrong, but I just resubmitted to MAAS lander, and I think I can show it failing here. [09:02] bigjools: https://code.launchpad.net/~jameinel/maas/allow-json/+merge/128512 [09:02] the first failure gave me the 404 [09:02] so I just resubmit hoping to get an actual error I can work on. [09:03] But this time, magic it succeeded. [09:03] hummm [09:06] mgz: http://stackoverflow.com/questions/5907575/how-do-i-use-pagination-with-django-class-based-generic-listviews [09:16] jam: Gah, can't import django in provisioningserver :-/ [09:17] allenap: I have a fix re-submitted for it. [09:17] but see above [09:17] I nearly added "because Django is an nearly unmitigated pos", but I bit my tongue. [09:17] Maas decided to land my branch again, when I retried because the first time gave me just a 404 [09:17] jam: I have fled upstairs, can mumble from here if we want though [09:18] mgz: well, I'll be chewing for a bit longer, then I'll poke you for mumble :) [09:18] ^and I followed your bad example and told the lander to shut up and try again [09:19] allenap: lol [09:21] allenap: so if you check my latest 'lp:~jameinel/maas/allow-json' I should have fixed the import issues. However, Maas just rejected my change again, and I can't get the context because 404 [09:21] Gah. [09:21] I'm running a full make check to be sure [09:22] I can just land on trunk, and see if that resolves things? [09:22] (and why is it that console output used to work, but is now just always giving 404...) [09:23] This is annoying. I guess land on trunk. rvba, do you know if/how we can turn off the gated landings in Tarmac, for a while at least? [09:24] allenap: no idea, maybe Diogo documented that somewhere but I doubt it. [09:24] We just walk round the back then. [09:25] allenap: it is possible that it was passing for me because I didn't have the latest trunk. I'll make sure to grab it and check one more time. [09:25] jam: I'm running it too. [09:25] it'll be in the tarmac conf [09:26] jam: the "Private Jenkins URL" works. [09:26] * bigjools putting kids to bed, back in 20 [09:26] rvba: I can get to the public jenkins, it just doesn't have the new job (172) that claims to be failing. [09:26] And I can't get to the private jenkins [09:27] allenap: I do see 2 failures in trunk this time, so maybe I can squash them. [09:27] jam: You need the test lab VPN config to get to the private URL, see https://wiki.canonical.com/Launchpad/QA/MAASLenovoLab [09:28] jam: like Gavin said :) [09:28] allenap, rvba: Technically, vpn's are illegal in Dubai, because they get around the content restrictions. but I'll probably give it a shot. [09:29] allenap: so the tests failing in trunk are the 'maascli' ones. [09:29] not mine. [09:29] so I'll land my patch to fix my own broken bits. [09:29] and then we can look to fix the maascli ones. [09:30] don't get yourself hauled off to sit in content prison... [09:30] allenap: 'bin/test.maas maascli.tests.test_integration' has 2 failing tests for me. [09:31] mgz: is that 'conTENT' or 'CONtent' ? [09:31] :) [09:32] jam: can you try moving away ~/.maascli.db and run the tests? [09:32] jam: we have a bug about the tests using that file… [09:32] allenap: the maascli tests are failing because of 'resources=description['resources']' not existing. [09:33] rbasak: confirmed [09:33] Looks like it might be happening in Jenkins as well? [09:33] jam: yeah, that's bug 1063721. [09:33] Launchpad bug 1063721 in MAAS "The CLI tests depend on the content of ~/.maascli.db." [Low,Triaged] https://launchpad.net/bugs/1063721 [09:46] jam: Yeah, the ~/.maascli.db is probably causing that. Also, maascli tests should be run with bin/test.maascli. [09:47] allenap: they still fail, but I see them being run with both [09:47] as in running 'make check' they run under bin/test.maas from what I can tell, and they fail here. [09:48] allenap: if they shouldn't run under 'bin/test.maas' I think you need an --exclude=maascli in bin/test.maas [09:48] (which comes from buildout somehow) [09:49] jam: I'll fix that later. [09:49] jam: I get a clean run here, for make check with allow-json. [09:51] allenap: yeah, other than the maascli stuff, I have a clean run. So I landed it on trunk. [10:07] mgz: poke for great mumbling [10:07] allenap: maas lander is still failing follow up branches without any context [10:08] third time lucky [10:09] maas lander let the search change through [10:09] mgz: https://jenkins.qa.ubuntu.com/job/maas-merger-quantal/ only shows up to 169, not 170-175 which are the ones that are failing. [10:27] mgz: make harness [10:28] from maasserver.models import NodeGroup [10:28] ng = NodeGroup.objects.ensure_master() [10:28] from maasserver.testing.factory import factory [10:28] for i in range(?): factory.make_node(nodegroup [10:28] =ng) [10:41] allenap: I'm getting "twistd.pserv Unknown command: maas-pserv" any idea how to fix that? [10:55] jam: What are you trying to do? [10:56] allenap: 'make run' [10:56] however, I think it is because I still had cruft leftover from failing to uninstall maas [10:56] So maas-txlongpoll was running in the background [10:56] rather than just the dev one. [10:58] jam: Have you moved the directory or anything that might confuse buildout? Check bin/twistd.pserv to see if there's anything obviously wrong there. [10:58] allenap: still getting the same error after stopping the other. [10:59] allenap: Also, this is after doing 'make distclean' which should rebuild those things, right? [11:05] jam: Yeah, it ought to. The maas-pserv plugin is picked up from twisted/plugins/maasps.py, so make sure that the root of the tree is mentioned in bin/twisted.pserv. [11:05] s/twisted/twistd/ [11:06] allenap: it is. [11:06] Bugger. [11:06] root, etc, src, contrib/python-tx-tftp [11:07] allenap: so the actual failure is probably 'no module named tftp.backend' [11:07] the massps.py is suppressing the other import failure [11:07] jam: That should be in contrib/python-tx-tftp. [11:08] which is in the twistd.pserv path [11:10] jam: Can you run through twistd.pserv statement-by-statement and then try importing tftp.backend? [11:16] allenap: if I insert a PDB at the __name__ == '__main__' portion, I can manually import twisted.plugins.maasps and see that it has the ProvisioningServerMaker class in the namespace [11:16] allenap: however it still tells me 'unknown command maas-pserv' [11:17] availabe commands are ampq-longpoll, conch, dns, ftp inetd, mail, manhole, news, portforward, procmon, socks, telnet, tftp, txlongpoll, web, words, xmpp-router. [11:19] I *do* see 171 unhandled messages in the 'celery' queue... :( [11:25] jam: I can't think of another reason why it wouldn't work, but that's obviously a failure of my imagination. I'll keep thinking. If you discover the reason, let me know? [11:29] Anybody up for a review of some shell code? It's not much: https://code.launchpad.net/~jtv/maas/bug-1050033/+merge/128685 [11:31] jtv: sure [11:31] Thanks. [11:34] jtv: just one point - the args are the wrong way around compared to the more traditional order :) [11:35] Depends on the example you pick! Unix tradition is: if one positional argument takes just one value, and another may be given multiple times, the one argument goes first. [11:35] Insert long discussion here about whether ln's argument order is intuitive. :) [11:35] But yes, cp and mv do put the destination last. [11:38] I'll change it. [11:38] Most of the time I use ln, I specify the destination only. It'd be confusing if ln were the other way round [11:40] depends on how you think about which is the destination [11:40] Exactly. That's what I hate about it. [11:41] Now you don't just have to remember argument order, you have to remember which of several obvious ways to think about the whole thing! [11:41] I just remember original file :) [11:48] * jtv wishes once again he'd pushed his openssh patch upstream half a decade ago, so he could stop it complaining about host keys for dynamic IP addresses changing all the time [11:58] the 99-temporary-fix-constraints.patch in packaging now needs removing [11:58] package is ftbfs [11:59] mgz: Got time for a 1 minute review of https://code.launchpad.net/~allenap/maas/maas-cli-explain-after-login/+merge/128693? [12:01] allenap: sure [12:01] Ta. [12:05] print() is weird [12:06] mgz: Why? [12:08] putting a bare print before and after is not how I'd do it, but I tend to the (equally weird) print s.join("\n\n") [12:11] mgz: It's irrelevant here, because the target is Ubuntu only, but I avoid that so that line-endings are sorted out by Python, but in that I may be misguided. [12:12] you're pretty much always printing to a file opened in text mode, so they get translated [12:13] (redirecting stdout to something that has been opened as binary or hacking the stream properties is uncommon) [12:51] jtv, you should not care about the extension of a initrd. it never should have been changed. [12:51] the 'gzip' executable is not at all involved in decompression of an initramfs. [12:52] so, dont worry about it. rename it as you need. [13:13] rvba, jtv: Anything in flight that needs to be landed today? [13:15] allenap: no. [13:38] allenap: as near as I can tell, twisted/plugins/maasps.py is just not getting imported. Is there a way to tell what is going on? I guess just stepping from the startup? [13:49] mgz: poke [13:50] roaksoax: latest daily builds is uninstallable for smoser: http://paste.ubuntu.com/1269262/ [13:50] flacoste: for me too :/. I just tested it on a branch new canonistack instance. [13:50] brand* [13:51] roaksoax, seems rooted in this: http://paste.ubuntu.com/1269276/ [13:51] smoser: I have the bug reproduced and ready for a patch, based on my morning's daily (0.1+bzr1226+dfsg-0+1226+124~ppa0~quantal1) rather than current. [13:52] allenap: I think I found the problem... after uninstalling the package 'maas' it left a *stale* /usr/lib/python2.7/dist-packages/twisted/plugins/maasps.pyc file [13:53] so, i would suggest that right now, archive install of freeipmi-tools is uninstallable [13:54] smoser: I did an upload earlier [13:54] Maybe it's still being published [13:54] jam: Ach, that's bad. I guess that's a dpkg bug? [13:54] check which version is apt-cache policy [13:54] allenap: well, I had to manually mess things up because 'apt-get remove maas' was failing. [13:54] it was *starting* the services it was trying to remove. [13:54] and then, failing to remove them. [13:54] so I might have some things a bit broken here [13:55] however, after fixing *that*, I now have problems wiwth 'maasserver_config' does not exist. [13:55] jam: Right. For now we assume it's an anomaly. [13:55] Oh no :-/ [13:55] that and 'response.getcode()' tuple object has no attribute 'getcode' [13:55] smoser msybe relsted to being promoted to msin¿ [13:55] smoser doko promoted it this morning [13:58] ah, I need to 'make syncdb' to get the db, right? [14:00] smoser is the bug relsted to not being able to commission with console=ttyS0 still present¿ [14:00] ? [14:00] allenap: and it would appear I might have broken start_cluster_controller by changing the return value of MAASClient.post() checking [14:01] roaksoax, probably. [14:01] https://bugs.launchpad.net/maas/+bug/1061977 [14:01] Ubuntu bug 1061977 in MAAS "Machine fails to commission when console=ttyS0 is present on kernel opts" [Critical,Triaged] [14:01] i'm not *totally* opposed to dropping console=ttyS0 from the cmdline [14:02] smoser ok.. so we still need to be able to modify that then in an easy manner [14:02] as i have no other work around. [14:02] jam: wiggle? [14:02] mgz: just checking how things are going, want to mumble? [14:02] sure [14:02] smoser i think we should be able to have an attribute on the node for that [14:03] smoser shouldnt be that hard to hack [14:03] roaksoax: yes my machines failed to commission with console=ttyS0 today [14:03] also see the comment above about stale .pyc files left around? [14:04] roaksoax, well, the one thing we can fix right now is to remove console=ttyS0. [14:04] and i'm not completely opposed to that. [14:04] i just think it sucks. [14:04] smoser i think it is important to make it configurable [14:05] how does a bmc get at console output? [14:05] adding a paramtet shold be a problem really [14:05] it all depends. [14:05] (how a bmc gets console output) [14:05] some bmc will have serial console "SOL" [14:05] bidjools you have to configure the bmc and then configure maas to tell what parameters to send [14:05] which i would think is most common [14:05] also my BMCs are all failing to get a dhcp address, no idea why. they ignore the dhcpoffer from the server [14:05] allenap: yay, it wasn't me who broke start_cluster_controller. Someone else changed the dispatcher from using urllib2.urlopen to httplib2.Http() [14:06] but i really have not enough experience on server hardware to make broad generalizations on such a thing. [14:06] allenap: start_cluster_controller seems to be the only thing that is using 'response' directly after post [14:06] bigjools those pyc files .. idk but its definiteky related to the package split as they werent present before the split but i cant figure out whats wrong [14:07] roaksoax: bug in postrm not pulling in debhelper? [14:07] smoser in sabdfls cluster i had to odify to ttyS1 but he said he configured that on the bios [14:07] so... [14:07] bigjools i thought you merged that and it would have taken cre of it [14:08] my personal feeling on this right now is to just drop all 'console=' params from the cmdline on intel [14:08] unless bigjools or someone says "i can make that configurable via file in /etc/ "right now"' [14:08] there's an open bug about it [14:08] allenap: so your change to using httplib2.Http so that you could set the insecure flag [14:08] i would go for addint the attribute for the node for custom kernel params [14:08] broke actually all users of dispatch_query [14:08] so unless that happens, i think we live with "configurable" meaning 'change .py files' [14:09] because it used to return a urllib2 file-like object [14:09] bigjools, yes, there is. [14:09] and it now returns a tuple [14:09] of response_headers, conte [14:09] content [14:09] bug 1044503 [14:09] we don't have tests that exercise the code [14:09] Launchpad bug 1044503 in MAAS "kernel command line is not easily customizable" [High,Triaged] https://launchpad.net/bugs/1044503 [14:09] because all the tests mock out the connection. [14:09] because we never run an actuall HTTP server to query against. [14:10] all of the tags stuff would also show up broken, if we could actually get it running (but we are failing early during startup) [14:10] except in the test he added for that change... the irony ... [14:10] bigjools: :) [14:10] ok it's past midnight, I need to sleep [14:10] night all, good luck [14:10] bigjools: sleep well. [14:10] * bigjools intends to :) [14:11] jam: how could that change break things? It's just a tiny encapsulation, and http_request still returns the result of http.request()…? [14:11] rvba: we used to return urllib2.open() [14:11] whicgh is a file-like object [14:11] with an attribute '.getcode()' [14:11] rvba: httplib2.Http.request() returns a very different object. [14:11] namely, a tuple [14:11] I see. [14:11] of ({headers}, content) [14:12] rvba: it only shows up during 'make run' because that is the only time we actually connect to a real server. [14:12] rvba: so, do we try to update all clients to a new api? try to wrap it in something that looks like a urllib object? [14:12] revert the insecure=False change? [14:13] I don't think we can revert that change just like that. [14:13] jam: Revert I think. [14:13] I only just made the change this morning. [14:13] I'll do it. [14:13] Also, sorry for being thick, but here is the change in question [14:13] http://paste.ubuntu.com/1269307/ [14:13] allenap: thanks [14:14] We were using httplib2.Http.request() all along. [14:14] rvba: wrong code [14:14] this is the one allenap did [14:14] Oh, you're talking about a different change I guess. [14:14] rvba: apiclient, not maascli. [14:14] Ok, [14:14] k [14:15] allenap: yeah, I think we can revert it for now, and land it after tomorrow and think about what we want to do with the changes. Long term, you like httplib2 more? [14:16] (it at least lets you allow self-signed certs, I guess) [14:17] jam: I was trying to "upstream" the changes in maascli to apiclient so that the former can properly use the latter. There's an impedance mismatch between apiclient and our Pistonesque API that's been mostly figured out in maascli. [14:18] allenap: yeah, I think it would be nice to update to something closer [14:18] and I don't think we need to have incremental reads from urllib2 [14:18] (i don't know if we even have incremental there, but it pretends we do) [14:22] jam: Care to rubberstamp? https://code.launchpad.net/~allenap/maas/revert-change-to-httplib2-in-apiclient/+merge/128726 [14:23] allenap: done [14:23] Thanks. [14:23] allenap: I'm glad I updated to trunk to test stuff today. [14:24] jam: Me too :) === flacoste changed the topic of #maas to: Final Freeze is today: waiting on upstream fixes for bug 978127| Discussion of upstream development of Ubuntu's Metal as a Service (MAAS) tool | MAAS jenkins: https://jenkins.qa.ubuntu.com/job/maas-trunk/ [14:30] roaksoax: any way i can be a bug supervisor for the maas package? so that i can set priority [14:31] flacoste: being member of the bugsquad or being a core dev :) [14:31] pff [14:33] smoser, roaksoax, Daviey: i'm just going to use a tag to highlight the bug fixed in upstream that aren't in the archive [14:33] too much hassle to create tasks when i cannot set the priority on it [14:33] jam: I've filed bug 1064437 about it. [14:33] Launchpad bug 1064437 in MAAS "The expectations of MAASDispatcher.dispatch_query are not tested" [High,Triaged] https://launchpad.net/bugs/1064437 [14:33] allenap: thanks [14:37] flacoste, fair enough [14:39] flacoste: what trunk rev are we looking to have in the archives today? [14:40] mgz: Vq2fSMwMvLXFuGJJyp:fZE7P5qGvgPSudZ8Hh:ZNqct3Pm8pFGh8mT5DVy8Py8JCtg4NaG [14:40] roaksoax: 1238 is the latest, but we are missing a few bug fixes still [14:40] roaksoax: so something like 1241 probably [14:41] flacoste: ok I think we have until 21:00 UTC so we still have a few hours, but i'd require to do some testing first [14:41] roaksoax: 1239 -> revert of allenap revision breaking start_maas_cluster [14:41] i'll check back in 1 hr [14:41] 1240 -> smoser fix for oauth in maas-enlist [14:42] 1241 -> IPMI auto-config in maas-enlist (optional really) [14:44] roaksoax, Daviey, smoser: https://bugs.launchpad.net/maas/+bugs?field.tag=missing-in-quantal [14:44] flacoste, thanks [14:45] flacoste: 1241 i'll try to make it happen, but this needs support from maas-enlist too [14:45] flacoste: so there might not be time to finish it [14:45] roaksoax: right, fwiw, the API changes are available [14:46] flacoste: yes I saw.. I'll be working on it todayt [14:54] allenap: ping [14:54] jam, allenap: the reversal in 1239 does that mean that self-signed certificate cannot work with the maas-cli anymore? [14:55] flacoste: No, it means it wont' work for users of apiclient. maascli doesn't use apiclient; before reverting this was an attempt to "upstream" the remote code in maascli to apiclient. [14:55] allenap: got it [14:56] allenap: what am I doing wrong? [14:56] curl --data "op=new&mac_addresses=e4:11:5b:13:81:9d&hostname=&architecture=amd64&subarchitecture=generic&after_commissioning_action=0&power_type=ipmi&power_parameters={"power_address":"test", "power_user":"test", "power_pass":"test"}" http://localhost/MAAS/api/1.0/nodes/ [14:56] Failed to parse JSON power_parameters [14:57] roaksoax: power_parameters='{"power_address":"test"}' [14:57] Note the quotes. [14:57] json.dumps({"power_address":"test"}) [14:57] '{"power_address": "test"}' [14:58] You have to pass a json string. [14:58] rvba: got it :) [14:58] roaksoax: Try: curl --data "op=new&mac_addresses=e4:11:5b:13:81:9d&hostname=&architecture=amd64&subarchitecture=generic&after_commissioning_action=0&power_type=ipmi" --data-urlencode="power_parameters={"power_address":"test", "power_user":"test", "power_pass":"test"}" http://localhost/MAAS/api/1.0/nodes/ [14:58] it was the quotes [15:06] so, it seems django can't do internal redirects... [15:16] mgz: you mean redirects to an address created with reverse('view-name')? [15:17] rvba: I was just going to make /favicon.ico serve the same result as /static/img/favicon.ico ...but that turned out to be non-trivial [15:18] I'd just use apache directives ideally, but don't want to upset django [15:18] mgz: why do you want to do that? Also, you cannot assume that the homepage of MAAS is '/'. [15:20] because currently requesting /favicon.ico is a 404 and it wouldn't hurt to serve it instead [15:21] mgz: src/maasserver/templates/maasserver/base.html: [15:21] browsers tend to request that regardless of html giving a different path [15:21] roaksoax: Ah right, yes, the quotes. From looking at --trace-ascii output, http://pastebin.ubuntu.com/1269411/ looks to be the correct way to do this. (You could s/--data-urlencode/--form/g I think too). [15:21] mgz: really? [15:21] roaksoax: --data is a recipe for failures and/or data corruption, because it assumes that the value is already URL encoded. [15:22] yes, what if you're not fetching an html page? (not a common case here, but if was easy to fix I'd just fix it) [15:22] allenap: cool, I;ll test that [15:31] mgz: right. Looks very minor to me… but in production, we have the prefix /MAAS in front of all the urls, so if the browser requests /favicon.ico, it won't get anything back and there is not much we can do about it. [15:32] rvba: could we redirect /favicon.ico to /MAAS/favicon.ico in packaging perhaps? Just an idea. [15:33] Not sure what implications that would have though [15:33] rbasak: and what if you install another service in /AnotherService… it will get a wrong favicon. [15:33] Yeah exactly [15:33] I don't think we want to hijack /favicon.ico. [15:34] why are we trying to support serving multiple different things from one hostname exactly? [15:34] It'd be nice to have it on servers that are dedicated to MAAS [15:34] (by default) [15:34] But the only way I can think of doing it cleanly in packaging is perhaps not the best thing to do for today [15:34] I'm thinking of a separate maas-favicon recommends that conflicts with other services in some way [15:36] the other magic top level name has a url mapping at the django level, but I guess just sits harmlessly at /MAAS/robots.txt in deployment [15:36] anyway, put up a branch with the fix I was actually aiming at [15:46] https://code.launchpad.net/~smoser/maas/drop-ttyS0-kernel-opt/+merge/128747 [15:46] rvba, ping [15:47] matsubara: pong [15:47] rvba, so, I just tried maas - 0.1+bzr1226+dfsg-0+1229+124~ppa0~quantal1 on a pristine quantal vm and maas-pserv is not started [15:48] mgz: Mark said something about having to use an ico for full browser compatibility. Obviously you're still generating an ico, but perhaps he meant something else by it? [15:48] matsubara: anything in the upstart log? [15:48] mgz: I was about to ask the same question :) [15:49] rvba, just a bunch of lines like this: Removing stale pidfile /run/maas-pserv.pid [15:49] matsubara: I'm trying to install the package from the daily ppa right now… [15:50] rvba, and apt/term.log shows this: maas-pserv start/running, process 10156 [15:50] so I think it started but for some reason it failed [15:50] allenap: I interpret what he said as assuming he'd generated an ico containing png files, but if fact he didn't [15:51] matsubara: pserv not started here :/ [15:51] mgz: Right, cool. [15:51] rvba, aha! [15:52] the larger sizes won't stop old (pre-vista internet explorer (do we even care..)) from picking out the 16x16 bitmap [15:52] rvba, so on a upgrade it keeps running fine but not on a new install [15:52] someone want to ack that for me? i really hate this change. but i think its a requirement at this point in time. [15:52] rvba, do you know of any other logs that might be relevant? [15:52] matsubara: yesterday it was fine :/ [15:52] matsubara: You'll need at least bzr 1239 to fix the pserv not starting issue, sorry. [15:52] does your upstart log show anything? [15:52] allenap: what was the issue again? [15:53] allenap, ah so you knew about it all along [15:53] rvba, matsubara: bug 1064437 [15:53] Launchpad bug 1064437 in MAAS "The expectations of MAASDispatcher.dispatch_query are not tested" [High,Triaged] https://launchpad.net/bugs/1064437 [15:53] mgz: what's the benefit of having all but one of the image as a *raw* png? [15:53] matsubara: Ha, I only just saw you having problems. [15:54] hmm I can't build new packages. LP is failing to build packages in the daily builds PPA due to a bzr error [15:54] allenap, no worries, just kidding :-) [15:54] Phew :) [15:54] thanks for the pointer [15:54] rvba: the 'raw' is a little confusing, but, in short, size [15:54] allenap, where do you see logs for this? [15:54] s/this/this error/? [15:55] png is a compressed image format, bmp is not [15:55] ico was originally a sort of container for bitmaps [15:55] matsubara: I don't; jam told me it was broken. [15:55] with recent format revisions it can also be a container for pngs [15:56] so, storing the larger images as 'raw' png rather than exploding them to bitmaps saves space [15:56] allenap: in this bug, you say is breaks start_cluster_controller, but in the package I'm testing, the cluster worker is started ok. [15:57] mgz: I see, I got confused by the world 'raw' indeed :) [15:57] rvba: What rev are you on? It was only a problem for revision 1234 to 1238 inclusive. [15:58] rvba, allenap: I got the log line in apt/term.log saying maas-pserv was started but after the package install finishes, the process is not running. Maybe it's failing and reporting a success? [15:58] bzr1226 [15:58] The revision from the package in the daily ppa. [15:58] Ah, so that bug isn't the problem. [15:58] For matsubara either. [15:59] Yep, there is a real problem then. [15:59] I'm using: 0.1+bzr1226+dfsg-0+1229+124~ppa0~quantal1 [16:00] allenap, btw, this two revision numbers are confusing. when you say 1234..1238 do you mean trunk right? [16:04] matsubara: if I start the service manually it seems to be started all right. [16:06] rvba, yep [16:07] matsubara:trying one more time on another instance. [16:09] matsubara: this time it worker :/ [16:09] ! [16:09] worked* [16:09] how weird [16:10] /var/log/upstart/maas-pserv.log is still full of "Removing stale pidfile /run/maas-pserv.pid" [16:10] yep, just like mine [16:10] I'm trying again as well [16:10] rvba, how are you starting a new pristine env? [16:11] I just start a new canonistack instance, add the daily ppa, and then install maas. [16:11] ok [16:13] allenap, rvba have you seen the last package build failure: https://launchpadlibrarian.net/119221274/buildlog.txt.gz ? [16:13] matsubara: Yeah, trunk. [16:13] allenap, is this because of your change? [16:13] * allenap looks [16:16] matsubara: Nope, I haven't been near the files in 99-temporary-fix-constraints.patch. I think that this has probably been fixed in trunk, so the patch can be removed. rbasak, can you help confirm? [16:17] Daviey, roaksoax it seems to me that adding maas-ipmi-autodetect to commissioning broke kvm (and possibly anything that doesn't have such a device) [16:17] is there a /dev/ entry that we could expect to be present to know whether or not we should go looking ? or some way to tell freeipmi to time out ? [16:17] right, seems that patch just needs removing from the packaging branch [16:18] it does seem to timeout eventually, but i'd say its in the 2 minute time frame. [16:20] does anyone know how I could install maas without having to answer the package installation questions? I tried to use a debconf seed file (maas.seed: https://pastebin.canonical.com/76135/) but it doesn't seem to work. Well, I get no questions asked but the default-maas-url value is not set to the one in the seed file. [16:20]