=== jtv1 is now known as jtv
=== matsubara is now known as matsubara-afk
[14:45] <roaksoax> rvba: howdy!
[14:45] <rvba> Hi roaksoax.
[14:50] <roaksoax> rvba: so bug #1021382
[14:50] <ubot5> Launchpad bug 1021382 in maas (Ubuntu) "The COMMISSIONING_SCRIPT setting uses a relative path." [Critical,Confirmed] https://launchpad.net/bugs/1021382
[14:50] <roaksoax> rvba: I hav enot yet done an SRU because doing so means that when on upgrade
[14:50] <roaksoax> it will request to upgrade the config file, if the user selects 'No' things will be broken
[14:51] <roaksoax> rvba: does maas define defaults for the path in question?
[14:51] <rvba> roaksoax: what was fixed is the default.
[14:52] <roaksoax> rvba: right, is default in the config, which means tht econfig has changed, whichs means possible broken updates
[14:52] <rvba> roaksoax: the package question you're referring to concerns the user-defined config right?
[14:52] <roaksoax> rvba: yes
[14:53] <rvba> Well, if the user has defined a specific path then that will override the new value but things won't be broken.
[14:54] <roaksoax> rvba: right, but my concern is that we shouldn't be SRU/ing config updates
[14:54] <rvba> roaksoax: well, all I know is that default config settings are really part of the application... but you know more about SRU than I do.
[14:54] <rvba> What other options do we have?
[14:55] <roaksoax> rvba: I was thinking maybe that the code can test the path, if it is relative, make it absolute
[14:55] <roaksoax> rvba: but, let me lot into it further, actually prepare the package, do some more testing and see what are the effects of it
=== mrevell_ is now known as mrevell
[15:51] <roaksoax> allenap: howdy! what's the status of python-tx-tftp?
[15:52] <allenap> otp
[15:59] <roaksoax> k
[16:24] <allenap> roaksoax: Hi! Right, I still have to complete the upstream work. I'm going to do that this evening. So... not landed yet. Sorry.
[16:25] <roaksoax> allenap: no worries :). Do you have a patch I can apply in the mean time?
[16:25] <roaksoax> i missplaced the one you gave me last time
[16:26] <allenap> roaksoax: Coming up...#
[16:27] <allenap> roaksoax: http://paste.ubuntu.com/1095124/ should be good, if my git fu is up to it.
[16:27] <roaksoax> allenap: thanks
[16:33] <roaksoax> allenap: btw.. I'm also guessing that the celeryconfig import from the tftp server is not yet in trunk?
[16:34] <allenap> roaksoax: No, not yet... too many things to do :) It's in progress though, but it's taking quite a lot more work that was at first obvious. I /could/ have hacked it, but it would have come back to haunt us (indeed, using celeryconfig was a hack in the first place).
[16:35] <roaksoax> yeah
[16:35] <roaksoax> allenap: i don't know whether that's the issue, but i've seen a weird behaviour on which maas-pserv fails to start
[16:35] <allenap> Very possibly related.
[16:35] <roaksoax> allenap: but when just adding a raise in the import, it works. However, there's no output
[16:35] <roaksoax> so I can't really determine what the issue is
[16:37] <allenap> That's really odd. Removing the weirdness with celeryconfig will remove one more moving part. I hand-wavingly hope that'll help.
=== matsubara-afk is now known as matsubara
[16:51] <roaksoax> yep there's definitely something weiird going on
[17:38] <guimaluf> I have a node stuck at "Booting..." for a long time. It is doing something, as I can check at /var/log/maas/rsylog/node/message, but it is very strange, all nodes I've installed never take so long!
[19:11] <guimaluf> anyone have any idea why one of my nodes hangs on "Booting..."?!
[22:17] <burnbrighter> NickServ identify sweetpea1