[02:14] <jtv> bigjools: looks like "make lint" is broken in a really weird way...  tries to run "tail" on lp:~maas-maintainers/maas/packaging/debian/changelog (not even head, which would seem to make more sense)
[02:16] <bigjools> jtv: whut
[02:17] <bigjools> jtv: oh ARGH
[02:17] <bigjools> my change has a boo boo
[02:17]  * bigjools fixes
[02:23] <jtv> Ah, it's all "make" attempts that get this — it's just that the message is sometimes drowned out by other output.
[02:24] <bigjools> jtv: yes, I was convinced by Gavin to use the lp branch but forgot it needs checking out somewhere ...
[02:24] <bigjools> so I've gone back to the old way for now until I figure out a sensible approach
[02:35] <bigjools> jtv: just got a random test failure
[02:36] <bigjools> ERROR: maasserver.models.tests.test_node.NodeManagerTest.test_node_can_be_multiple_networks
[02:36] <bigjools> ValidationError: {'vlan_tag': [u'Network with this Vlan tag already exists.']}
[02:36] <jtv> lemme look
[02:37] <jtv> Aigh.
[02:37] <jtv> Nastiness.
[02:38] <jtv> Not much we can do about that one I suspect.
[02:38] <jtv> Unless...
[02:38] <jtv> We could start writing "plural" factory methods.
[02:38] <jtv> "Make me <n> networks."
[02:38] <jtv> Which would then be responsible for preventing these clashes.
[02:48] <bigjools> jtv: do you know how to conditionally set a variable in Makefile? It evaluates everything on startup, even stuff inside a target
[02:48] <bigjools> I tried some shell but the value gets thrown away after...
[02:48] <jtv> No, haven't had time to mess with that stuff for years...  Gavin's the one to ask.
[02:49]  * jtv used to be knee-deep in GNU Make.
[02:49] <bigjools> me too
[02:49] <bigjools> not done one from scratch for 8 yuears
[02:50] <jtv> The friend and former colleague who showed me how to set up all the really hard stuff isn't even alive any more...
[02:51] <jtv> Didn't quite get to see his 20th anniversary with Debian.  :(
[02:52] <jtv> I don't suppose we care if our Makefile is GNU-specific.
[03:18] <bigjools> victory is mine
[03:19] <jtv> No!  I saw it first!
[03:19] <jtv> Er, what?
[03:31] <bigjools> makefile victory
[03:31] <bigjools> it's looking nice now
[03:31] <bigjools> branch forthcoming
[03:31] <jtv> But does it work?
[03:31] <bigjools> yes!
[03:31] <jtv> Review also forthcoming.
[03:31] <jtv> Once you let me know the MP is ready, of course.
[03:39] <bigjools> jtv: https://code.launchpad.net/~julian-edwards/maas/makefile-packaging-target/+merge/207348
[03:40] <jtv> Coming right up.
[03:43] <bigjools> the only thing I know will fail is if you have no-trees on by default (like me) when branching
[03:43] <bigjools> but there's no option that's the opposite of --no-tree on branch :(
[06:10] <bigjools> jtv: what is that migration actually changing in PG?
[06:10] <bigjools> I can't see any change
[06:10] <bigjools> other than the django field name
[06:11] <jtv> It might change it from a fixed-length varchar to a regular varchar.
[06:11] <jtv> But yes, this is more of a UI change.  Did anyone mention lately that the layers get a little muddled in Django?
[06:12] <bigjools> jtv: django does not do varchar
[06:13] <bigjools> everything is fixed
[06:13] <jtv> Well... it creates varchar fields.
[06:13] <jtv> But of fixed lenghts.
[06:13] <bigjools> look at the migration, nothing changed!
[06:13] <jtv> It's called "varchar" because nul-terminating strings was a novel thing at the time.
[06:13] <bigjools> heh
[06:13] <jtv> Space-padding used to be quite normal and socially acceptable.
[06:13] <jtv> Now, I hesitate to mention it in public.
[06:14] <jtv> Argh!  Yup, it's still 255 characters wide.  Damn.
[06:15] <bigjools> I think the field is only used as a hint for the UI
[06:15] <jtv> The difference in field width is, yes.
[06:15] <jtv> I mean
[06:15] <jtv> sorry
[06:16] <jtv> The difference in field _type_.
[06:16] <bigjools> yes
[06:16] <jtv> Want me to bump up the inanely fixed maximum size?
[06:17] <jtv> Oh wait, it looks like you _can_ remove that size on a TextField, and get a proper varchar!
[06:27] <bigjools> !
[06:33] <jtv> Unstoppable progress.  Plunging head-first into the 1990s.
[06:40] <bigjools> Django - unchained
[06:56] <jtv> bigjools: I updated my multiline-network-description branch with the unlimited description size.  Could you give it another go?
[06:57] <bigjools> jtv: done
[06:57] <jtv> Thanks.
[06:57] <bigjools> jtv: make sure input is sanitised before display
[06:57] <bigjools> don't want another xss
[06:58] <jtv> That's what I added that test for.
[06:58] <jtv> Don't know why that wasn't tested in the original Vlan class, but the <pre> doesn't really change anything there.
[07:01] <bigjools> ok
[07:09] <jtv> rvba: better get landing.  :)
[07:11] <rvba> jtv: landing my branches now.
[07:11] <jtv> \o/
[07:11] <rvba> jtv: I've got another one up for review: https://code.launchpad.net/~rvb/maas/network-mac-link-net-page/+merge/207210
[07:11] <jtv> On it.
[07:12] <bigjools> hey rvba
[07:12] <rvba> Thanks.
[07:12] <rvba> \o bigjools
[07:56] <rvba> jtv: rarg, you landed a migration.  It's conflicting with my branch… I'm fixing my branch now…
[07:57] <jtv> Oh!  Yes...  I didn't realise we'd be clashing for a migration number.  Very sorry.
[07:58] <jtv> bigjools: any chance you could look at this MP?  https://code.launchpad.net/~jtv/maas/enlist-restore-avahi-code/+merge/207362
[08:11] <bigjools> jtv: sorry dinner time, later if nobody beat me to it
[08:11] <bigjools> and I was OTP before
[08:11] <rvba> jtv: I'll have a look in just a sec.
[08:11] <rvba> Fixing the migration first.
[08:11] <rvba> (Was OTP before too)
[10:18] <rvba> jtv: conflict in https://code.launchpad.net/~jtv/maas/api-connect_macs/+merge/207374
[10:23] <bigjools>     from maasserver import messages
[10:23] <bigjools> ImportError: cannot import name messages
[10:23] <bigjools> loads of that when I run tests on trusty
[10:25] <jtv> Grrr
[10:25] <jtv> bigjools: got the packaged apiclient installed?
[10:25] <jtv> Need to remove that.
[10:26] <bigjools> oh problaby.... meh
[10:26] <jtv> Sometimes I think we need not just a file with requirements but one with antirequirements as well.
[10:26] <jtv> "If you have any of these installed, things will break."
[10:27] <bigjools> I wonder if we can fix this one day
[10:27] <bigjools> it's useful to have packages installed as well
[10:28] <jtv> Yes...  I wonder why the branch versions don't simply take precedence over installed packages.
[10:33] <rvba> jtv: I guess a cleanup branch is in order to use the new make_networks() factory method in all the code I just landed.
[10:33] <jtv> rvba: always nice!
[10:35] <jtv> rvba: want me to do it?
[10:36] <rvba> jtv: if you don't mind.  I'd like to work on the "Disallow single MAC on multiple non-VLAN networks" task.
[10:37] <rvba> It's not trivial.  Requires the introducing of form-level validation where we don't even use forms.
[10:40] <jtv> :-/
[14:21] <arges> hi. is there some docs on xinstall_preseed with curtin? i'd like to be able to use the fastpath installer and then install an hwe kernel on a maas node. Thanks
[14:35] <arges> http://astokes.org/customizing-fastpath-curtin-installations/ answers it
[19:01] <evilnickveitch> hello. does the tftp server for images live on the cluster controller or the region controller?
[19:02] <roadmr> evilnickveitch: methinks it lives on the cluster controller, but I'm just speculating
[19:03] <evilnickveitch> the docs tend to suggest it does, but if i configure rgion controller to a different address, the tftp server seems to disappear too
[19:03] <evilnickveitch> but thanks for your speculation roadmr  :)
[19:04] <roadmr> oops :( that I have no idea, I have both on the same hardware
[19:22] <ccope> does anyone know if Canonical sells support for MAAS?
[19:46] <ccope> nvm found it in a pdf, the answer is yes
[23:49] <bigjools> evilnickveitch: yes the images all live on the cluster
[23:50] <bigjools> but the cluster needs to talk to the region to ascertain the kernel params and whatnot