All pastes #285816 Raw Edit

Mine

public text v1 · immutable
#285816 ·published 2006-12-20 02:01 UTC
rendered paste body
<groogs> i actually think r3372 and 3373 should go in to 2.2..
<freepbx> Revision 3372 at http://freepbx.org/trac/changeset/3372: drawselects() updated:   - removed usage of goto_indicate an...
<groogs> it fixes a bug that's never been reported, that its possible to have a destination that doesn't select any radiobox (eg, if you remove a module, anything that was using it as a destination will appear blank)
<X-Rob> ivr and queues use goto_indicate
<groogs> yep
<groogs> so we'd have to update those.. but pre-release is the time to do that kind of stuff
<X-Rob> Nah, it's not _terribly_ broken
<X-Rob> and I'm getting antsy to get rc2 out 8)
<X-Rob> (being that my mum turns up here tomorrow)
<groogs> well i can fix those modules pretty quick..
<groogs> s/goto_indicate/goto/
<groogs> :p
<X-Rob> heh
<X-Rob> fuck it, throw it in
<X-Rob> they're only modules 8)
<naftali5> grrogs, in a way you a re breaking it not fixing
<X-Rob> stick a prereq on the modules of RC2?
* freepbx has quit (Excess Flood)
* freepbx (n=freepbxb@65.111.165.203) has joined #freepbx-dev
<groogs> naftali5: ?
<naftali5> the old way, module gets removed and the goto is gone on the next submit.
<naftali5> new way the goto stays in custom, and goes nowhere unless the context is reinserted by hand
<groogs> right, but it's in that state until you try to edit it ... then you can't edit it without doing something
<groogs> which is kind of weird
<naftali5> you're right on that
<naftali5> ok, i guess your way it is there in case you reenable too, that's good
<groogs> or, you can also look at it like this: if the module is disabled, you can still edit the ivr that uses it BEFORE you go and upgrade/enable the module again
* sb_mx has quit ("Leaving")
<naftali5> and i guess the outcome of blank or a non-existant goto is almost the same (depends how each module handles it)
<groogs> well, its not blank.. its the same value
<naftali5> ok. your way wins because it is consistent (before and after edit)
<groogs> the only difference is that when you edited it, it would complian
<naftali5> also, your way you can see what it _was_ even with the module disabled
* naftali5 sees the light and suddenly agrees with groogs
<groogs> yeah, thats also VERY useful :)
<groogs> especially if you have say, two modules disabled, and now your IVR is full of blanks and you have no idea what was what
<naftali5> yes, and removing the requirement for the word custom is great
<groogs> well, it does mean there's the potental for chaos if they name their custom context, say, 'from-trunk' ..
<groogs> but the tip does suggest using "custom-" at the start ;)
<groogs> X-Rob: can i merge across module branches?
<groogs> (as in, is svnmerge setup for that?)
<X-Rob> Yep.. lemme check which way
<X-Rob> svnmerge _in_ 2.2, you get 2.1.. svnmerge _in_ 2.3, you get 2.2
<X-Rob> so patches applied in 2.2 get merged into 2.3
<groogs> cool
<groogs> how do you check that btw? i'm guessing svnmerge sets svn properties or something? svnmerge is black magic to me.. ;)
<X-Rob> svn pl -v .
* Djeli-afk is now known as Djeli
<freepbx> Changeset http://freepbx.org/trac/changeset/3375: Updated for changes in http://freepbx.org/trac/changeset/3372 (Tue, 19 Dec 2006 23:56:54 GMT)
<freepbx> Changeset http://freepbx.org/trac/changeset/3376: Merged revisions 3372-3373 via svnmerge from  ... (Wed, 20 Dec 2006 00:06:06 GMT)
<groogs> X-Rob: just found a bug in publish.pl
<X-Rob> uh?
<groogs> it's searching for <version>(.+)</version> ...
<groogs> but <depends> has a <version> tag....
<groogs> so it finds that, and instead of doing pbdirectory-0.3.1.tgz its making pbdirectory-2.2.tgz
<X-Rob> wups
<naftali5> that's probably the reason for this page http://www.freepbx.org/trac/wiki/ModuleXml
<freepbx> Changeset http://freepbx.org/trac/changeset/3377: Module Publish Script: ivr 2.5.2 (Wed, 20 Dec 2006 00:10:12 GMT)
<freepbx> Changeset http://freepbx.org/trac/changeset/3378: Module Publish Script: queues 2.2.3 (Wed, 20 Dec 2006 00:10:28 GMT)
<groogs> naftali5: probably
<groogs> whats that other kind of validation? the one that doesnt' have syntax thats 100000 lines long
<groogs> RELAX NG
<groogs> well, anyway, that doesnt even really help for this, what we need is an xmlparser to grab the version instead of just a string parser
<X-Rob> change <version> to <modversion>?
<X-Rob> that's going to break online modules though
<groogs> well, quick fix
<X-Rob> would be to ignore <version> if it's inside <depends>
<groogs> if (($vers == "unset") && (/<version>(.+)<\/version>/)) { $vers = $1; }
<groogs> (though i'm not sure if thats valid perl within the while() thing like that?)
<X-Rob> ..and then make sure that version is before <depends>
<groogs> ls
<groogs> oops
<groogs> X-Rob: can you fix it?
<X-Rob> yep, I'm just sitting here waiting for a phone call at the moment
<X-Rob> (day is insanely bad)
<freepbx> Changeset http://freepbx.org/trac/changeset/3379: Misc apps module (Wed, 20 Dec 2006 00:30:28 GMT)
<freepbx> Changeset http://freepbx.org/trac/changeset/3380: Module Publish Script: miscapps 0.1 (Wed, 20 Dec 2006 00:30:53 GMT)
<X-Rob> fucker. I haven't swiched my freepbx-modules and just got a 500
<Djeli> So.. no chance of a hexadecimal Device ID?
* Djeli runs!
<X-Rob> not yet
* Djeli ducks!
* Djeli narrowly misses being decapitated by a flying TDM400P.
<groogs> Djeli: why?
<Djeli> I always seem to suggest features about 10 minutes before Rob releases a new version.
<groogs> a while ago i was actually suggesting we default to alphanumeric device ids (d201) in DEVICEANDUSER mode, just to make the distinction between users and devices a bit clearer..
<naftali5> Djeli, not his time, though, you've been pushing this for _days_
<X-Rob> s/days/months/
<Djeli> Well, pushing is a strong word. :)
<groogs> what is the purpose?
<Djeli> Its just the final piece to my auto-provisioning module
<groogs> provisioning .. ?
<Djeli> If the SIP devices = Mac Address, then http auto-provisioning of Polycoms is easy
<groogs> oh, interesting idea ..
<Djeli> I have all the provisioning stuff done (in modules, so you can snap-on additional device types)
<groogs> though...
<groogs> no, i like mac address a separate field still
<Djeli> It'll only work in device/user mode
<freepbx> Changeset http://freepbx.org/trac/changeset/3381: Module Publish Script: pbdirectory 0.3 (Wed, 20 Dec 2006 00:34:09 GMT)
<freepbx> Changeset http://freepbx.org/trac/changeset/3382: Fix &lt;version&gt; being incorrectly picked up. (Wed, 20 Dec 2006 00:36:22 GMT)
<groogs> because if a phone dies, you can just swap it
<Djeli> You see, I'd create a new device for that, because it is a new device