[00:48] jtv, do we have dhcpd fixes in? [00:56] he won't be around for another hour [00:58] ppa seems uninstallable for me [00:59] bigjools, http://paste.ubuntu.com/1203854/ [00:59] that is from daily ppa [00:59] darn it [01:03] smoser: a change was made in the code that now needs a packaging change I think, I'll dig [01:03] yeah postinst call [01:03] right. [01:04] not sure why it was removed in the 1.1 branch :/ [01:06] I'll do a branch to fix it [01:10] bigjools, it seems like it is more than just '--dhcp-interfaces' -> '--interface' (which also seems like potentially a deeper issue because the debconf question is asking for plural and this seems to expect singular) [01:11] smoser: yes we're making 1.1 only manage one interface [01:11] trunk supports multiple [01:11] http://paste.ubuntu.com/1203878/ [01:12] after fixing the simple --interface, that is the command that the postinst runs and fails as shown [01:12] oh ffs [01:12] someone has backported too much [01:12] this is daily ppa of trunk [01:13] oh ok [01:13] I think a data migration is needed [01:13] bigjools, do you happen to have a reason for 'suite=' on the kernel cmdline ? [01:13] I'll file a bug [01:14] smoser: I doubt it - most of those were cargo culted from cobbler [01:14] k. i'm dropping it. [01:14] feel free to fix as you see fit [01:14] https://code.launchpad.net/~smoser/maas/kernel-cmdline-cleanup/+merge/124226 [01:14] i haven't fixed tests yet, but the kernel cmdline is much cleaner now [01:14] I'll review it shortly, just putting up the packaging fixes [01:15] the tests wont pass [01:15] ok, do you need help with those? [01:16] smoser: https://code.launchpad.net/~julian-edwards/maas/packaging.precise/+merge/124328 [01:16] ARGH [01:17] wait [01:17] i'll take help with them. sure. as i was hoping to get out of here. [01:18] so if you ignore the rules change everything else is ok in that branch :) [01:18] my description is hopefully fairly complete in describing what i dropped. [01:18] just pushed up a fix [01:18] ok [01:18] if you check my packaging change I'll try to fix tests [01:18] in yours [01:19] bigjools, well, i dont think your pakcaging change does fix it [01:19] as that pastebin above [01:19] i basically made that change locally and hten hit a python trace [01:19] smoser: it will fix packaging [01:19] a separate change is needed upstream [01:19] because it's assume some data is present, which is not there [01:19] ah. well packaging still wont install :) [01:19] one thing at a time :) [01:20] bigjools, i can ACK that packaging change. [01:21] thanks [01:21] per removal of rule schange fix. [01:21] yeah - it's changing to lp:maas/12.04-nocobbler [01:21] as it was wrong in the target branch anyway [01:21] diff has updated now [01:21] you could make that a variable [01:21] when you want to fix it [01:22] ./debian/rules BZR_BRANCH=lp:maas/12.04-nocobbler [01:22] approved. [01:22] thanks [01:23] i'm gonna head out for the night. [01:23] I'll poke it in trunk packaging too [01:23] cheers [01:23] sleep well [01:23] lp:~smoser/maas/maas-pkg-test [01:23] thats mostly just junk, but its what i'm working on as a setup/test for the packaged stuff. [01:23] cool [01:23] it allows me to get to booting and enlisting (assuming non-broken packaging) [01:24] and it has to be kept up. [01:24] but its a start. [01:24] yep [01:44] smoser: no dhcpd fixes yet to my knowledge. Needs the packaging changes first, in both quantal and precise. [01:53] I am writing that command that gives you a cluster's managed DHCP interfaces though. [01:54] morning jtv [01:54] Hi [01:54] * jtv cries at the sight of his reviews [01:54] :) [01:54] I am looking at the long one but dunno how much I can review [01:55] conflicts FTL [01:58] hmm just one stray marker [01:58] weird [01:58] unless you messed up a merge and forgot to remove it [01:59] Which one is that? [02:00] https://code.launchpad.net/~jtv/maas/bug-1025582-task/+merge/123900 [02:00] Ubuntu bug 123900 in SchoolTool "Better Zonki" [Wishlist,Fix released] [02:00] ubot5: you suck [02:01] I never had any conflicts on that one. I think it's just weirdness with the way conflicts propagate through dependent branches. [02:01] I resolved my conflicts on the -api branch. Will propagate the resolutions through the dependent branches. [02:20] howdy [02:22] bigjools: so 'maas config_master_dhcp' enables MAAS DHCP server if not enabled right? [02:22] bigjools: is it possible to add a command that disables it? [02:22] roaksoax: it does [02:22] such as maas disable_master_dhcp [02:22] anything's possible :) [02:22] why do you need it? [02:22] bigjools: so thatn when maas-dhcp gets uninstalled, or dpkg-reocnfigure and set to NO, it gets disabled in MAAS [02:23] fair enough [02:24] bigjools: btw.. short response to the email on adding releases support [02:25] bigjools: most of what scott discussed is already addressed [02:25] bigjools: and the support has been added [02:25] bigjools: https://code.launchpad.net/~andreserl/maas/add_ubuntu_releases_lp1013146 [02:25] roaksoax: yeah I figured you guys were working on it [02:26] bigjools: i also have the juju stuff worked out, and tested [02:26] bigjools: the only thing needed is modify the maas unnittests [02:26] ok [02:27] ok cool [02:27] it should be proposed next week though [02:27] i need to updated and resolve conflicts with the new trunk [02:27] roaksoax: I don't like the magic enum, FWIW [02:27] bigjools: yeah i need to change that [02:28] it means restarting maas for a new release [02:28] release should be a DB table [02:28] then we can add pickers for it later [02:28] bigjools: you bean enum UBUNTU_RELEASES? [02:28] also a customer might have a custom release [02:29] yeah [02:29] bigjools: well I think we should rely on distro info for that [02:29] bigjools: that's the accurate way to obtain the ubuntu supported releases [02:29] why should someone be restricted to deploying ubuntu supported releases? [02:29] bigjools: and wouldn;t mean harcodign releases, and SRU'ing new changes on and on [02:30] I am proposing to make it data-driven [02:30] bigjools: well that means that every time there's a new release, we have to SRU [02:30] which is a clear PITA [02:30] bigjools: this was an issue we had in cobbler [02:30] No, we don't :) [02:31] I think what you have is ok short term, because it will need a lot of changes in the UI to do what I propose [02:31] if it's data driven we can add new releases in the UI [02:32] bigjools: right sounds fair [02:32] bigjools: i will get that to trunk first [02:32] bigjools: and we can go from there [02:32] as it is currently blocking me on other stuff until there's no real quantal support in [02:33] roaksoax: yeah [02:33] alright then. [02:34] roaksoax: oh also we *might* want to call it series, not release [02:34] to be consistent with Launchpad [02:34] bigjools: yeah that's one of the changes I need to make [02:34] release was intended to be point releases [02:34] ah cool [02:35] bigjools: What's your preference? series, ubuntu_series or os_series [02:35] distro_series [02:35] ok cool [02:35] thanks! [02:36] roaksoax: let us know if you want help with tests [02:36] bigjools: yep, rvba already offered himself :) [02:36] cool [02:58] jtv: done [02:58] and now I shall eat luncheon [02:58] Thanks! [02:58] I'll be going to mine too. [02:59] mine will involve biking over Mount CootTha though [03:03] AAAAArgh. Semantic conflict with Raphaël's changes. [03:03] *bash* *bash* *bash* [03:04] Three days of begging for a review, and when I finally get one, my code is obsolete. [08:57] disconnected ... :( [08:58] Very. [09:03] jelmer: would you like to come back on mumble? [09:04] jam: yep [12:06] jelmer, mgz: poke when you get back. I have to go in about 15 min. [12:38] hey [12:38] whats the simplest way to be albe to run unit tests ? [12:38] i'm assuming that 'make install-dependencies' will get me stuff, but i dont think i need all that. [12:46] jtv,rvba? [12:46] Hi there [12:46] Hi smoser. [12:46] sorry for direct ping. [12:46] Try "make test". [12:47] well, fails: Error: pg_config executable not found. [12:47] Then have you tried "make install-dependencies"? :) [12:47] well i said that is plain silly. [12:47] i just want to run tests. [12:47] Have a look in required-packages. [12:48] smoser: maybe you're missing the package 'libpq-dev'. [12:48] I think the make target gives you the "base" and the "dev" ones, not the "optional" ones. [12:48] rvba, well clearly i am. [12:48] and i can peicemeal get the stuff. [12:49] but 'make install-dependencies' gets all sorts of things that surely are not necessary for 'make test' [12:49] i just want to run unit tests [12:49] (so maybe maketest is too broad anyway) [12:49] Yes, there's a bunch of stuff in "base" that should be in a separate list. [12:49] But the fact is we just haven't gotten around to breaking that down any further. [12:49] k. [12:49] thats a fine answer. [12:49] Thank you. [12:49] so basically you'll just 'make install-dependencies' ? [12:50] jtv, i'm assuming you thought i was being sarcastic :) but this time i actually wasnt. [12:50] Or do it piecemeal, as you say; I think the stuff in dev is all needed at least. [12:50] i just wanted to know if i was doing something stupid. [12:50] No worries! [12:50] so on your system youve just got the whole shebang [12:51] thats fine. the schroot buildup was just going for a couple minutes before i got bored with it. [12:51] so do we think that the daily ppa is installable now? [12:51] I think for testing you should be able to do without bind9, probably bind9utils & dnsutils & isc-hdcp-common, ipmitool (I hope!), and maybe syslinux-common. And you can probably do without wget. [12:53] I haven't looked at the python-* packages in detail; I expect you'd need most or all. [12:54] anyone know how can I set up a smarter partition scheme when deploying a node? Partman can only handle one partition, so I've tried late-command, but isn't working. :/ any hint? [12:55] No idea how you'd tell the installer that. :/ [13:02] guimaluf, well, you probably want partman_early_command [13:02] late_command is (no surprise) too late. [13:03] i'm fairly sure you can preseed just about whatever you want as a partition layout, but i really havent ever played with it. [13:03] http://bryars.eu/2011/08/automating-debian-preseed-installs-with-raid-and-lvm/ [13:04] seems reasonable a s a starting point [13:04] jtv, is 'make test's install of dependencies direcotory specifi c ? [13:05] ie, if i hvae trunk.my-feature and trunk-my-fix dirs, do i need one for each or are they somehow shared [13:05] "make test" doesn't install anything. [13:05] well, its dependencies do [13:05] It may run buildout, which may be set up to share a cache across branches. [13:05] s/install/buildout/ [13:05] for being technical [13:05] k [13:05] Ah. Then the answer is: I think it depends on your local setup. [13:06] smoser, I've tried many recipes and use multiple disks(I said wrong, partman can only handle one DISK), none of this worked for me :/ I dont know why... my solution was using guided lvm installation with 15% of disk space. It's working fine, but I want to partitionate the other 3 disks. [13:06] smoser, I'll try to use this early command [13:07] guimaluf, well this is n't really maas specific. [13:07] and as i said, i've never really done this. [13:08] but i do believe it shoudl be possible [13:20] smoser, I know it's not related directly with maas, but it's a customization I want to use with maas. [13:21] understood. [13:50] ok. i have a python quesiton [13:50] nooooo.... [13:50] KernelParametersBase is a named tuple [13:50] but how do values for each key get set? [13:51] construct it with args/kwargs [13:51] at least i see code expecting 'params.purpose' to have some value, but i dont understand where it gets said value. [13:52] ok. got it. [13:53] eg, I see in tftp: `KernelParameters(**data)` [13:54] and also by defined names in maasserver.api [13:54] smoser: a question in return, constraining by arch - [13:55] currently juju/ec2 allows 'i386' and 'amd64' which must match exactly, or '?' to mean either [13:56] as you can stick an i386 image on a amd64 box to satisfy the contraint, what should maas do when told to acquire an i386 machine? [13:56] there's no way of picking images currently, right? [13:56] there is no way of picking images, no. [13:57] well, as what hsould maas do... it should install i386 [13:57] thats easy! [13:57] as to whether or not it can, i dont know. [13:58] was that the question, mgz? [13:58] so, Node has an architecture param right now, and I added a constraint to just match that, [13:58] see [13:59] I should special case accept both 'amd64' and 'i386' there, and add some logic to pick the right image? [13:59] or just accept that this is overly limiting for now, till we have some image fanciness? [14:00] i think near term there are no images. [14:00] so near term, if a node says it's amd64, it really is going to end up 64 bit? [14:01] i think i agree with what you're saying. basically if i386 comes in as a constraint, or it is otherwise told to install i386 that it should just allow it if the node is amd64 [14:01] mgz, this is not un-related to the "multiple release" issue [14:01] we had the same problem there, really. [14:01] there is just a global "release" [14:02] and we're now attachign that as an attribute of the node [14:02] right, that is similar. [14:02] but really we want an "instance" ("deployment" or whatever) table [14:02] and that instance/deployment would say "i386" is the arch [14:02] but we dont have that now. [14:02] and if you change the node's arch for a deploy, then you have to store the *real* arch to avoid downcasting permenantly. [14:03] ie, for release we just said that Node.os_release would just be set back to None on 'release' [14:05] what are the values acceptable for "purpose" of KernelParameters ? [14:05] the only code i see looks for 'commissioning'. so thats the only string i ssee that is seemingly valid. [14:06] probably that's all that's defined as having a meaning right now [14:12] mgz, did you follow what i was saying above? [14:12] its reasonable that you could accept that constraint. [14:12] but if someone asks for i386, you shoud'nt give them amd64 and just pretend you did what they asked. [14:13] the use case for i386 on amd64 is very slim, and honestly i386 in general. but i tihnk maas should install an i386 distro if its asked to do so. [14:13] right, until we can actually stick an appropriate image on the machine, the current constraint is correct [14:13] but to do that you ahve to change the arch of that node [14:13] and then you have to store what it *really* was so you can put it back later. [14:24] smoser: any luck getting the dhcpd apparmor profile into precise and quantal? [14:25] jtv, its in quantal [14:25] it wont be in precise until it works for you in quantal [14:26] ! [14:26] i'm not SRUing anything that isn't known functional [14:26] (that is a SRU requirement) [14:27] that it is fixed in the development release, and i personally dont consider "fixed but not verified as useful" the same thing as "fixed released" [14:27] At least now I can move ahead with the quantal side I guess. [14:28] correct [14:28] oh. hey. one question, jtv [14:28] how do you kick a build of daily ppa ? [14:28] its out of date [14:28] (and uninstallable) [14:31] Isn't a daily PPA supposed to build daily? In which case, the trick would be to find out what's been stopping it from building. [14:32] yeah i would have thought hte same [14:34] but afaiks https://launchpad.net/~maas-maintainers/+archive/dailybuilds?field.series_filter=quantal is revno 987 but https://code.launchpad.net/~maas-maintainers/maas/trunk is at 1000 [14:35] My guess is that pushing a "build again" button probably wouldn't do much good, if the build doesn't come through. [14:36] smoser: Hmm... I see a 20-hour-old package at 994. [14:36] Isn't that the one you want? [14:36] Ah, it's not built [14:37] ok. i'm blind. where do you see this? [14:37] i see 0.1+bzr987+dfsg-0+994+83~ppa0~quantal1 [14:37] gay [14:37] never mind [14:37] :) [14:38] i have no idea what i saw at 987 [14:38] oh. as you said, the newer isnt built [14:38] i'm really confused [14:39] So am I. [14:39] No idea what the 994 stands for. [14:40] I need to run out for a bit. [14:41] 994 is bzr branch [14:41] 987 is the bzr branch on the packaging branch [14:41] and 994 is the branch the daily build is creating [14:41] i mean, [packaging [14:42] Thanks! Problem solved then, I hope. [14:42] roaksoax, ok. can i get a new trunk ? [14:42] a build of new trunk [14:42] i want 0.1+bzr1000 [14:43] smoser: you want one released today? [14:43] smoser: or someone can just fire up a new daily build [14:44] roaksoax, i'm sorry for being confusing. [14:44] i want the daily ppa to have the latest trunk [14:44] (and i think generally i always want that.... no?) [14:45] smoser: so someone needs to fire up a new build then [14:45] smoser: 0.1+bzr987+dfsg-0+1000+83~ppa0~quantal1 [14:45] that's what you want [14:50] so bzr987 is the packaging version? [14:50] but anyway, yes. thats what i want. [14:50] and generally if we can have per-commit, that'd be good too. [14:50] i think [14:50] at least it would seem. [14:52] jtv, what is the correct style for this: http://paste.ubuntu.com/1204901/ [14:52] specifically i'm asking about the line 8 and the replacement of that method (get_ephemeral_name) [14:52] (lines 93-106) [14:59] rvba, ^ ? [15:00] smoser: use patch(), let me give you an example… [15:01] i see it. [15:01] thanks [15:01] smoser: ok, cool. [15:09] rvba, ok. now i ask for review. [15:09] https://code.launchpad.net/~smoser/maas/kernel-cmdline-cleanup/+merge/124226 [15:12] smoser: ok, I'm finishing up a branch and then I'll review it. [15:16] smoser: daily builds builds _daily_ [15:16] buildd resources are scarce :-) [15:18] fjlacoste, can you poke it manually? [15:18] (just curious) [15:20] smoser: yes [15:20] smoser: you can always push a button to build now [15:21] there is probably an api to request it [15:21] (i'm really speculating here) [15:21] so we could automate it (as a post-jenkins action) [15:24] where is the button? [15:24] * smoser sucks with web uis [15:25] fjlacoste, ^ === fjlacoste is now known as flacoste [15:27] smoser: it's not you, it's LP :-) [15:27] smoser: the button is on the recipe page [15:28] which isn't obviously linked from the archive page [15:28] i got to it from the package details [15:28] expand a build [15:28] then click on the recipe build [15:28] very very obvious :-) [15:28] here's the link: [15:28] https://code.launchpad.net/~julian-edwards/+recipe/maas-daily-precise [15:28] there is a Request a build link at the bottom [15:28] which asks for which series to build to [15:28] precise is building now [15:28] i'll ask quantal [15:30] thanks. [15:34] flacoste, would you be upset if i linkd that from the daily build ppa description? [15:34] smoser: not at all, users always find a way ;-) [15:36] done [15:36] thank you. [15:53] BAH [15:53] https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds/+recipebuild/306950 [15:53] strange. seems to have uploaded though anywah [15:55] fudge. still uninstallable [15:55] roaksoax, http://paste.ubuntu.com/1205032/ [15:56] smoser: that's becuase dhcp now needs you to specify IP and it hasn't yet been done [15:56] smoser: rvba just pointed it out to me today so I haven't done that just yet [15:57] if you want you can go ahead and fix it though :) [16:00] smoser: meanwhile, I think we have to shelve this idea of the dhcpd upstart script getting its interfaces list from the maas database. Not the rest, so we still need to run our own dhcpd, but since there's no database locally, we might as well just store this information in /var/lib and have the upstart script read directly from that. [16:00] (Contacting the API at that point in bootstrapping would be difficult) [16:01] Now, where is that directory where I can put my apparmor config snippets for dhcpd? [16:17] jtv, thats fine. [16:18] jtv, the packaging already lays one down [16:18] https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083 [16:19] also see examplecommand line there [16:24] Thanks smoser — I don't see the example command though. I see it's a different approach from the include-a-directory one we discussed… how do we get apparmor to apply our profile to dhcpd? Link the executable? [16:25] smoser: branch approved with a few remarks. [16:27] jtv, well, there could be a bug in the packaging... i'm not exactly sure how it gets updated. but you should not worry about that. [16:28] Okay, I'll try not to. [16:28] jtv, command line example is in comment 0 https://code.launchpad.net/~smoser/maas/packaging.lp1049177/+merge/124083/comments/267072 [16:29] Ah [16:29] Too tired. === matsubara is now known as matsubara-lunch [17:00] roaksoax, https://code.launchpad.net/~smoser/maas/packaging.aa-update/+merge/124478 [17:00] jtv, ^ that has the fix to apply the apparmor profile on maas installation/upgrade [17:12] smoser: approved [17:18] roaksoax, are you working on the ipaddr fix ? [17:20] smoser: nope [17:24] plop [17:24] rvba is gone [17:24] and i just finished the release stuff [17:32] oh. good. [17:32] can i see ? [17:32] smoser: https://code.launchpad.net/~andreserl/maas/add_distro_series_support_lp1013146/+merge/124482 [17:33] smoser: and this is for juju: http://paste.ubuntu.com/1205229/ === matsubara-lunch is now known as matsubara [17:34] why do you use the word series? [17:34] smoser: bigjools requested so [17:35] then maybe change KernelParameters release= [17:35] dont you think its just confusing to insert inconsistency of a string inside the code? [17:36] smoser: yeah I'll do that too after this stuff gets merged because tests will have to get changed, and there's plety of tests to fix with this MP [17:36] smoser: yes it is confusing, but bigjools says it matches LP code when referring to a release. [17:37] line 10 [17:37] you are adding a commissionoing_distro_series to the node, right? [17:38] oh i see. you're not. lever mind then. [17:38] smoser: no [17:38] smoser: that's just saying if there's no node or the node is commissioning, the present the series for commissioning [17:38] that's for the kernel parameters [17:38] right [17:39] i thought you were setting a field on the node but only referencing the global default [17:39] but you're not setting the field on the node. [17:39] so thats fine. [17:39] smoser: yes, we are not, when we set the node is on juju http://paste.ubuntu.com/1205229/ [17:40] roaksoax, how do i build package from daily ppa ? [17:41] smoser: i don't know TBH... julian set that up [17:42] hmm. well 'bzr bd -S' just fails for me. [17:57] smoser: https://code.launchpad.net/~julian-edwards/+recipe/maas-daily-precise/+request-builds [17:58] Daviey, yeah, thats fine. i wanted to build locally [17:58] ok [17:59] its not extracting the upstream tarball at all. [18:11] matsubara, around? [18:14] i tihkn i have it back into place now. [18:15] matsubara, had added a file in the debian branch (tests/integration.py directly) rather than as a debian/patches and debuild complained due to [18:15] DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I --source-option=--abort-on-upstream-changes" [18:23] smoser, hi, yes [18:23] see above. [18:23] https://code.launchpad.net/~smoser/maas/packaging.next-server/+merge/124493 [18:23] its fixed in that merge propposal there. [18:24] smoser, jibel suggested that I should add tests/ at the root of the packaging branch rather than debian/tests/ [18:24] smoser, that's for the autopkgtest work. [18:25] matsubara, hm.. well, i'm not sure. [18:25] smoser, hmm those tests don't modify any upstream files... [18:25] but i dont think its right (and debuild complained to me) to lay down that file from the debian overlay. [18:26] it modifies a file (creates it) outside of debian/ [18:26] which its not supposed to do [18:26] ah, I see [18:26] i honestly dont know about autopkgtest though [18:26] I'll ask jibel about it then. the thing about leaving it as a patch is that I think autopkgtest might ignore it [18:26] i'm sure somehow those 2 things have been resolved if others are doing this. [18:26] nah. [18:27] i woudl doubt it [18:27] the first thing that dpkg does is apply patches when it extracts source. [18:27] so unlikely that the autopkgtest would operate before that [18:28] roaksoax, does something magically pull the approved branchesinto packaging branch ? [18:28] or do i have to do that manually? [18:28] smoser: the lander does it [18:28] smoser: did you add the commit message? [18:28] yeah [18:28] just di [18:28] d [18:28] smoser, cool. your mp should be fine then. I'll talk to jibel on monday and see if there's a standard [18:29] and then do any modificaton that's needed [18:29] matsubara, thanks. [18:29] and roaksoax it seems like it just got landed [18:29] roaksoax, https://code.launchpad.net/~smoser/maas/packaging.next-server/+merge/124493 [18:29] now review that please [18:29] :) [18:29] we're almost installable! [18:29] wweeeee! [18:31] smoser: why is there a patch for add-maas-ingration.py [18:31] see above. [18:31] you're not supposed to write files outside of debian/ [18:31] dpkg --source-option=--abort-on-upstream-changes complains about that. [18:32] oh i see [18:34] so once the lander lands that i'll push the "build" button and i think we might have it installable [19:03] \o/ [19:04] arrgh I have one more test to fix in juju and we should be deploying series with juju too [19:16] shoot [19:16] https://launchpadlibrarian.net/115990138/buildlog.txt.gz [19:17] anyone have ideas on that? [19:19] nope [19:19] :/ [19:24] i kind of hope it is as simple as my stupid patch name [19:24] (ended in .py) [19:24] but i'm trying to build the recipe now and see if i can make it fail here and then succeed [19:29] roaksoax, I'm trying to build a package from the precise branch: https://code.launchpad.net/~matsubara/+archive/maas/+packages but it doesn't build python-django-maas. Is there anything special I need to do in the recipe? [19:30] matsubara: nope, the like above hasn't yet built precise though [19:32] roaksoax, ah, it takes a while to build all the packages? just the maas is published first? [19:33] matsubara: when you upload to PPA it is all related to the score [19:33] matsubara: so it has to build the mpackage and then it will publish the biinaries [19:33] matsubara: look at build status [19:33] https://code.launchpad.net/~matsubara/+archive/maas/+build/3787754 [19:34] I see [19:34] thanks [19:34] no prob :)_ [20:26] roaksoax, https://code.launchpad.net/~smoser/maas/rename-patch/+merge/124506 [20:26] please. [20:26] matsubara, it seems i screwed up [20:26] please review the above [20:27] it sucks. we can try to find a better fix later, per jelmer its a bug in the builder [20:28] smoser, looks good, isn't going to fail to build because of the file in outside the debian dir? or is it just a warning? [20:28] that was only reproducable locally [20:28] but the other way was only reproducible on the server [20:28] :-( [20:28] at least i tihnk. but it could have been user error. [20:29] anyway, it *did* build the way you had it. so i hope it will again. [20:29] :-) [20:29] push 'approve' ? [20:32] * roaksoax lunch [20:32] ok. one more time i abuse the builder [20:32] hopefully this time it works. [20:32] https://code.launchpad.net/~maas-maintainers/+archive/dailybuilds/+recipebuild/307137 [20:36] ok. so it built. YEAH! [20:36] https://launchpadlibrarian.net/115995593/buildlog.txt.gz [21:02] k. matsubara roaksoax the daily ppa is installable and built [21:02] but it doesn't seem to register boot files [21:02] i see a message about 'No boot images have been registered yet" [21:02] its possible i have to wait 5 minutes (it says i might) but if thats the case, that is broken [21:03] (broken as in, test is going to need to say "how about you do that NOW and block until its done") [21:04] jtv, if you see the above, i think that was code you recently committed. [21:13] awesome [21:13] smoser: thanks for making it build [21:20] smoser, I'll give it a try later on. I need to step off to eat === matsubara is now known as matsubara-afk [21:32] yeah, so still see the "no boot images" message [21:32] after 32 minutes. [21:34] http://paste.ubuntu.com/1205716/ is celery.log [21:34] lp:~smoser/maas/maas-pkg-test/ is what i have done [21:34] to get this far