| 00:29.36 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-jaoyfdsgzixarxta) |
| 01:00.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 02:31.19 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 03:05.46 | *** join/#asterisk-dev drmessano (~nonya@pdpc/supporter/active/drmessano) |
| 05:01.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:19.56 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:30.14 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 05:55.42 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 06:25.04 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 07:44.37 | *** join/#asterisk-dev bulkorok (~Benjamin@85.183.61.47) |
| 07:56.18 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 08:21.11 | *** join/#asterisk-dev datachomper (~russ@nat/digium/x-zvsonxtkvhgcyeyk) |
| 09:01.06 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 09:01.06 | *** join/#asterisk-dev jrose_atDigium (~jrose_atD@nat/digium/x-tticofyygqqrsdhn) |
| 09:01.06 | *** join/#asterisk-dev Corydon76-home (~quassel@c-69-137-93-158.hsd1.tn.comcast.net) |
| 09:01.06 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 09:01.06 | *** mode/#asterisk-dev [+o Corydon76-home] by kornbluth.freenode.net |
| 09:35.09 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 09:51.50 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 10:01.19 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 10:30.42 | *** join/#asterisk-dev tzafrir (~tzafrir@local.xorcom.com) |
| 10:30.43 | *** mode/#asterisk-dev [+o tzafrir] by ChanServ |
| 10:57.51 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 11:57.22 | *** join/#asterisk-dev tm1000 (tm1000@2600:3c01::f03c:91ff:fe70:fce6) |
| 11:58.07 | *** join/#asterisk-dev luckman212 (~luckman21@unaffiliated/luckman212) |
| 12:15.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@91.206.59.129) |
| 12:31.35 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 12:59.20 | *** join/#asterisk-dev opticron (~opticron@pianoben.ch) |
| 12:59.20 | *** mode/#asterisk-dev [+o opticron] by ChanServ |
| 13:01.49 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@216-191-106-163.dedicated.allstream.net) |
| 13:24.02 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:37.52 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 13:53.39 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-edxgseiinlzafcpm) |
| 14:03.41 | *** join/#asterisk-dev roderickm (~roderickm@67.63.143.254) |
| 14:36.46 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-uluckdypdawupwgm) |
| 14:57.51 | *** join/#asterisk-dev newtonr (~newtonr@nat/digium/x-acejtepdptrqpues) |
| 14:57.51 | *** mode/#asterisk-dev [+o newtonr] by ChanServ |
| 14:59.45 | *** join/#asterisk-dev sgriepentrog (~sgriepent@nat/digium/x-llfuxltlrdzjyrzp) |
| 15:03.26 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 15:04.19 | *** join/#asterisk-dev otherwiseguy (~otherwise@99-46-2-71.lightspeed.mssnks.sbcglobal.net) |
| 15:04.50 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 15:04.51 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 15:05.30 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:05.30 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:10.44 | *** join/#asterisk-dev mjordan (~matt@nat/digium/x-bywizkfklqkbdnsr) |
| 15:10.44 | *** mode/#asterisk-dev [+o mjordan] by ChanServ |
| 15:15.13 | *** join/#asterisk-dev kharwell (~kharwell@nat/digium/x-rghtndrjeajpdyll) |
| 15:37.17 | file | kharwell, thanks for the media reviews |
| 15:38.01 | kharwell | file: np |
| 15:40.42 | putnopvut | The bridge atxfer nominal test failure is a bit on the interesting side. lots of error messages about channels being read called with no recorded file descriptor. Plus lots of debug messages about blocking thread issues. |
| 15:41.28 | putnopvut | Seems as though perhaps two threads think they're in charge of the channel. |
| 15:41.40 | file | mjordan, I'm coming up empty with a multihomed test... cause you really do need to have multiple interfaces |
| 15:41.43 | file | putnopvut, eep |
| 15:43.28 | putnopvut | It's on the ast2 box, which is the "Alice" party in the test. And based on what I'm seeing here, it appears she's the one that is attempting to perform the transfer when the errors occur. It happens right when the AMI PlayDTMF command gets to Asterisk. |
| 15:44.03 | *** join/#asterisk-dev gtjoseph (~gtj0@unaffiliated/gtj) |
| 15:46.00 | putnopvut | Hm appears that AMI PlayDTMF just calls ast_senddigit directly. If that does what I think it does, it seems like a good way to interfere with the bridge. |
| 15:47.14 | putnopvut | That is, to quote Harry Truman, "shitty" |
| 15:48.40 | mjordan | putnopvut: hm... that does seem like a 'bad idea'. |
| 15:48.55 | mjordan | file: yeah. I don't like it, but I'm not sure what automated test we could have |
| 15:50.10 | mjordan | ya know. Just throwing this out there, but there's some other open source projects that I would think would have run into similar testing scenarios... |
| 15:50.43 | file | crazy. talk. |
| 15:52.52 | *** join/#asterisk-dev scouture (~scouture@unaffiliated/scouture) |
| 15:53.33 | jsmith | file: No, CrazyTalk is a former MVNO that split up to form BasicTalk, SimpleTalk, and SuperHyperMegaTalk |
| 15:53.44 | wdoekes | putnopvut: did you say "called with no recorded file descriptor"? ASTERISK-23418 |
| 15:54.21 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 15:55.01 | *** join/#asterisk-dev sliske_ (~sliske_@2607:f0b0:1:6044:9c6:c937:f7d:e27f) |
| 15:55.37 | putnopvut | wdoekes: I'll have a look at that. |
| 15:58.46 | putnopvut | wdoekes: wow. Does that happen every time? |
| 15:58.54 | sgriepentrog | file/mjordan: it would be possible to define loopback aliases, i.e. lo.1, lo.2, etc. Should be possible to configure on the fly using /sbin/ip in a platform generic way. |
| 15:59.12 | file | yeah |
| 16:00.38 | wdoekes | putnopvut: 100% reproducible. got those errors when I was testing something with channal origination and passing variables |
| 16:01.15 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 16:19.36 | mjordan | huh. That seems... bad. |
| 16:20.44 | file | opticron, hrm... what process is used to steal the channel out for your bridging glue insanity thing? |
| 16:22.33 | opticron | a masquerade |
| 16:23.16 | file | huh |
| 16:23.30 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-lwnaphamoymmnjao) |
| 16:24.02 | opticron | it hasn't quite been added to the bridge yet |
| 16:24.08 | opticron | so it can't just get removed |
| 16:26.06 | file | yeah just checking in the bridge_native_rtp implementation for a lack of glue isn't the solution - you need to re-evaluate in the bridging framework |
| 16:26.34 | file | methinks |
| 16:31.27 | mjordan | hm |
| 16:31.34 | mjordan | there was already some code in bridge_channel_push to try and do that |
| 16:31.38 | mjordan | I wonder where this is sneaking in |
| 16:31.59 | file | mjordan, you know what I would do if I were trying to hack one of those Gibsons? I'd try the backdoor |
| 16:32.09 | mjordan | cus there's always a backdoor |
| 16:35.20 | sgalarneau | file: but then the plague would be after you, he's creepy |
| 16:35.30 | file | sgalarneau, you mean... Eugene? |
| 16:36.04 | sgalarneau | file: or mr the plague |
| 16:37.15 | sgalarneau | file: he's no zero cool mind you |
| 16:44.10 | hexanol | I've found a small memory leak in manager.c that looks trivial to fix (only missing an ao2_ref(..., -1) at the end of a function) |
| 16:44.30 | hexanol | should I open something on the jira or can I just throw this out here ? |
| 16:45.18 | leifmadsen | hexanol: jira is required just to track the licensing |
| 16:45.25 | leifmadsen | needs to be a patch attached to jira |
| 16:45.38 | leifmadsen | mjordan can overrule me if he wishes :) |
| 16:45.43 | hexanol | ah ok |
| 16:48.37 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.110) |
| 17:00.30 | opticron | file, it's just a really bad situation, because once the masquerade actually starts occurring, the channel has entered the bridge and is preparing to change technologies |
| 17:00.37 | file | ugh |
| 17:02.31 | opticron | but the check to see whether it needs a masquerade to get pulled happens early on when it actually WOULD need a masquerade |
| 17:03.02 | newtonr | hexanol, https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process |
| 17:03.03 | file | MASQUERADES |
| 17:22.17 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 17:22.48 | mjordan | leifmadsen: mjordan does not want to |
| 17:22.52 | mjordan | PROCESS PEOPLE |
| 17:23.15 | mjordan | I spent a long Sunday writing all that stuff up. :-P |
| 17:25.06 | file | process is good for you and me |
| 17:29.06 | pabelanger | Who is running asteriskdev twitter? :) |
| 17:29.15 | pabelanger | And what is this issue about 3rd party libs in pjprojct |
| 17:29.38 | file | I run it. |
| 17:29.43 | mjordan | I run it. |
| 17:30.10 | pabelanger | So, what is the issue of not dropping pjproject repo? |
| 17:31.04 | mjordan | pretty much what Josh said - it has a folder that packagers understandably want removed, at least from the build system |
| 17:31.23 | mjordan | so there's still work to be done. jsmith actually has a patch right now that removes it |
| 17:31.47 | pabelanger | Okay, I understand that. But why do we need to keep the pjproject repo? |
| 17:32.02 | pabelanger | Apposed to just stripping the folder and repacking / hosting the tarball? |
| 17:32.14 | mjordan | you can't remove the folder without changing the build system |
| 17:32.21 | mjordan | which means you need to patch pjproject |
| 17:32.37 | pabelanger | sure you can, untar pjproject, rm -rf folder, tar pjproject |
| 17:32.44 | pabelanger | then host the tarball |
| 17:32.51 | mjordan | uhm. |
| 17:32.54 | file | that would break building pjproject. |
| 17:32.59 | mjordan | pabelanger: go try it out. |
| 17:33.07 | mjordan | file was still correctly however. As of pjproject 2.2, you don't have to use the version on github. |
| 17:33.15 | pabelanger | Right, then you patch project in your debian / rpm build process |
| 17:33.40 | mjordan | pabelanger: I think the goal of the packagers is to have any build system changes pushed up stream |
| 17:33.58 | mjordan | since the Asterisk project is the only project currently that uses pjproject in such a fashion, we'd probably be the ones pushing the change |
| 17:34.22 | pabelanger | I completely agree, I just fail to see why we still want to maintain said repo. Are we using jsmith patch? |
| 17:34.39 | mjordan | not yet, but I would say there's a strong desire to go do that |
| 17:35.04 | mjordan | and, I'm not sure why blowing away the repo - when what is obtained from pjproject is not quite where we want it to be - makes a lot of sense. |
| 17:35.19 | mjordan | the good news is, today, you don't have to use it |
| 17:37.25 | pabelanger | Ya, I just see ways of working around it, and having our fork die. Especially if packagers are maintain their own git repos. tzafrir is doing this in debian when he just filters the folder on import: http://anonscm.debian.org/gitweb/?p=pkg-voip/pjproject.git;a=blob;f=debian/import;h=04765c606b41577274c3ba554d8c3b60469ff791;hb=HEAD |
| 17:37.54 | pabelanger | then generates a new tarball for upload and makers it: non-DFSG-free |
| 17:38.40 | pabelanger | At a minimum we should be pointing people and updating our build scripts in svn to use the external tarball |
| 17:38.48 | mjordan | pabelanger: feel free to convince the rest of the packagers :-) |
| 17:39.08 | pabelanger | I am, I am trying to convince us. |
| 17:40.19 | pabelanger | we don't package pjproject, but still using our fork: http://svnview.digium.com/svn/asterisk/trunk/contrib/scripts/install_prereq?view=markup |
| 17:40.24 | mjordan | pabelanger: In general, I don't make unilateral decisions. If you feel like making up stream changes that make it easier to remove the third_party folder in pjproject is a waste of time or doesn't justify having a working place to stage such changes (and the latter one I disagree with, as having a place to review and work on patches is useful), feel free to propose it on the -dev list. |
| 17:40.27 | pabelanger | this should be using svn upstream now |
| 17:40.30 | mjordan | pabelanger: we do package it. |
| 17:40.36 | Qwell | The Asterisk project doesn't require DFSG. |
| 17:41.08 | pabelanger | Qwell, so, then what is the issue of not using the upstream tarball now? If 3rd party libs are not an issue? |
| 17:42.01 | pabelanger | jsmith, We'll talk this weekend, but when you have time, can you explain why fedora cannot just strip the 3rd party libs and repack the tarball, ala Debian? |
| 17:42.16 | tzafrir | Fedora and Debian care about iLBC support in pjproject. But for Asterisk it really doesn't matter, right? |
| 17:42.21 | Qwell | There isn't one. If you want to use the upstream tarball, then use it. |
| 17:42.26 | tzafrir | Does asterisk use media support from pjproject? |
| 17:42.39 | file | Asterisk does not use pjmedia-codec. |
| 17:42.59 | file | Disclaimer: I can't speak for any other packages further down the road. |
| 17:43.08 | jsmith | pabelanger: That's essentially what I'm trying to do, but the build system requires the ilbc code in the third_party directory for pjmedia-codec |
| 17:43.29 | tzafrir | jmls1, where? |
| 17:43.48 | pabelanger | jsmith, Right, but do you need the fork at https://github.com/asterisk/pjproject to live to do it? |
| 17:43.56 | jsmith | pabelanger: Nope |
| 17:44.00 | pabelanger | mjordan, ^ |
| 17:44.03 | pabelanger | so, it can die |
| 17:44.13 | jsmith | pabelanger: Not at all, unless there are other patches that come up in the future |
| 17:44.26 | tzafrir | ahem. jsmith: where does the build system need it? |
| 17:44.30 | jsmith | pabelanger: But as of this moment, there are no outstanding patches that Asterisk needs that haven't been accepted upstream |
| 17:44.46 | mjordan | I'd prefer to wait before nuking it. |
| 17:44.56 | pabelanger | well, we should be pushing pjproject to mirror their own subversion system |
| 17:45.03 | pabelanger | then we can just deal with it |
| 17:45.18 | jsmith | tzafrir: Specifically, pjmedia-codec links to code in the third_party/ilbc directory, even if you use ./configure --disable-ilbc-codec |
| 17:45.43 | pabelanger | Our fork doesn't even maintain any of the SVN history, and is pretty sad IMO we did it that way. |
| 17:46.12 | jsmith | tzafrir: If I could get that to use the system ilbc library (or not build libilbccodec.so) when that configure flag is set, I'd be happy |
| 17:46.19 | Qwell | We don't need to. The repo on github is a place to temporarily and publicly store any changes, to be submitted upstream. |
| 17:46.23 | mjordan | pabelanger: I'm sure the people who worked on that appreciate your opinion. |
| 17:46.52 | jsmith | tzafrir: That being said, I'm not a build system wizard, and so far my skills have been insufficient to make that work |
| 17:47.31 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-hsrrqihrxwdgsmmb) |
| 17:49.52 | pabelanger | My goal is not to piss off people, just have the fork die a fiery death |
| 17:50.48 | pabelanger | Or come up with a better way to maintain said fork, and preserve the svn history of commits |
| 18:05.23 | tzafrir | http://git.tzafrir.org.il/?p=mirror/pjproject.git . I need to get this running automatically |
| 18:06.55 | tzafrir | Rebase whatever you want on top of that |
| 18:48.18 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-ffvestkqyjaabeeg) |
| 19:01.07 | *** join/#asterisk-dev ivan` (~ivan@unaffiliated/ivan/x-000001) |
| 19:03.41 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 19:11.06 | hexanol | just wondering, someone has already run helgrind on asterisk ? |
| 19:11.31 | mjordan | I have |
| 19:11.33 | mjordan | it ain't pretty |
| 19:12.11 | hexanol | hehe is there anything good to get out of it ? |
| 19:12.27 | mjordan | hexanol: you can find some things with it, but as is often the case, you have to think through what it tells you - and it slows down a system substantially |
| 19:12.27 | hexanol | or is it mostly noise |
| 19:12.43 | mjordan | for example, many of the race conditions are legitimate race conditions, but they aren't ones you would particularly care about |
| 19:13.05 | mjordan | DEBUG_THREADS will make it throw a hissy fit |
| 19:13.20 | mjordan | (of course, DEBUG_THREADS is kind of broken) |
| 19:13.38 | mjordan | I have found a few things in the past with it |
| 19:13.45 | mjordan | but it's been probably a year or two since I ran it |
| 19:13.56 | hexanol | ok |
| 19:14.07 | hexanol | what is mostly race condition problem or lock inversion problem that you found ? |
| 19:14.09 | putnopvut | helgrind also doesn't understand the pattern of using a pthread_cond_t and boolean. |
| 19:14.20 | hexanol | true I've seen that from the doc |
| 19:14.29 | putnopvut | And we use that in quite a few places :) |
| 19:14.51 | mjordan | hexanol: the only one I found that I bothered fixing was some improper destroying of mutexes in chan_iax2 |
| 19:14.58 | leifmadsen | putnopvut: perfect, so step one is to replace all of those with something helgrind understands |
| 19:14.59 | mjordan | IIRC |
| 19:15.30 | putnopvut | helgrind recommends using a semaphore instead. In some cases, we could do that. |
| 19:15.51 | putnopvut | In other cases the "boolean" is actually checking if a list is empty, for instance. A semaphore won't work very well there. |
| 19:15.54 | mjordan | "Helgrind will be less effective when you merely throw an existing threaded program at it and try to make sense of any reported errors." |
| 19:16.55 | mjordan | heh, it also has problems with memory pools |
| 19:26.39 | gtjoseph | If anyone's got free time (ha!) could you look at r3254 and r3283? I'd like to clear those out. |
| 19:28.53 | leifmadsen | r3300 too :) |
| 19:28.58 | mjordan | gtjoseph: I can take a look a bit later this afternoon |
| 19:29.08 | gtjoseph | cool, thanks |
| 19:29.20 | mjordan | leifmadsen: marquis just shipped it... :-P |
| 19:29.37 | mjordan | although... is that sorta like shipping your own code at this point? :-D |
| 19:29.48 | leifmadsen | mjordan: kinda :) |
| 19:29.56 | leifmadsen | we didn't write it though! :) |
| 19:30.05 | leifmadsen | I just want another ship it though to be honest |
| 19:30.06 | mjordan | truth |
| 19:30.19 | mjordan | I hate not knowing how things get into that wonky state |
| 19:30.26 | mjordan | was their a pickup involved? |
| 19:30.29 | mjordan | their/there |
| 19:30.33 | leifmadsen | quite possible |
| 19:30.35 | leifmadsen | we do use that |
| 19:30.43 | leifmadsen | that, or parking |
| 19:30.52 | leifmadsen | let me check who is on this machine and find out if that is a common scenario |
| 19:31.09 | leifmadsen | we're using numbered pickups, vs named pickup groups at this point |
| 19:31.20 | mjordan | I'm just curious if the other channel suddenly turned into a masqueraded channel, in which case, I could see that happening |
| 19:31.21 | leifmadsen | if that makes any difference at all |
| 19:31.37 | mjordan | nah, at the point they go do something with the channel it is still a masquerade |
| 19:31.52 | leifmadsen | makes sense now |
| 19:34.39 | *** join/#asterisk-dev ibercom (58196f7d@gateway/web/freenode/ip.88.25.111.125) |
| 19:35.23 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-mpdufenpgycviqoa) |
| 19:50.53 | leifmadsen | mjordan: I can confirm it is a possibility |
| 19:51.06 | leifmadsen | one of our customers on that server has a pickupgroup defined |
| 19:51.30 | leifmadsen | and since we're using numbers right now, anyone who has one defined for them is likely using it somewhat regularly |
| 20:16.45 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 20:38.14 | *** join/#asterisk-dev danjenkins (~dan@cpc65687-folk2-2-0-cust207.1-2.cable.virginmedia.com) |
| 21:23.46 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-sztpridieuszpyqm) |
| 21:29.50 | mjordan | leifmadsen: In that case, the change is probably the best you can hope for: check to see if the thing is still valid in between when it was last unlocked and when it entered into the loop |
| 21:30.32 | leifmadsen | mjordan: ok cool, just wanted to make sure it wasn't a complete hack :) |
| 21:30.35 | leifmadsen | russellb: <3 |
| 21:30.40 | Marquis42 | lol |
| 21:31.09 | russellb | what'd i do |
| 21:31.15 | leifmadsen | mjordan: maybe you could just comment with that on the review so that anyone internal who might be questioning the ship it will unquestion it |
| 21:31.22 | Marquis42 | russellb: leifmadsen was just trollin' you |
| 21:31.23 | leifmadsen | russellb: r3300 |
| 21:31.27 | leifmadsen | it's a true story |
| 21:31.28 | russellb | oh that |
| 21:31.38 | russellb | i got a ship it? neat |
| 21:31.43 | leifmadsen | heh |
| 21:31.43 | russellb | that means i have 2 things to merge now |
| 21:31.52 | russellb | on a roll |
| 21:32.02 | russellb | not sure what type of roll |
| 21:32.10 | russellb | whole wheat maybe |
| 21:32.16 | Marquis42 | Hopefully like a spider roll, yummy! |
| 21:32.26 | russellb | ah yes, could be |
| 21:36.56 | leifmadsen | now i want sushi |
| 21:41.34 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.110) |
| 21:42.30 | *** join/#asterisk-dev otherwiseguy (~otherwise@172.56.11.110) |
| 21:51.40 | coreyf1513 | sgriepentrog, file, mjordan: earlier you guys were talking about a multihomed test. I don't like the idea of testsuite attempting to reconfigure networking, I'd rather see test_config.py Dependency check that the required interfaces already exist. |
| 21:54.17 | mjordan | coreyf1513: yeah. I'm kind of afraid of that as well. |
| 21:54.34 | mjordan | I'm trying to think of a way of doing this that doesn't involve some special purpose hardware |
| 21:55.06 | pabelanger | dummynet |
| 21:55.17 | pabelanger | or bridge-utils |
| 21:55.30 | pabelanger | you just need to setup for base NIC in bridge mode |
| 21:55.43 | pabelanger | then you can dynamically create / delete interfaces on it |
| 21:59.00 | *** join/#asterisk-dev [TK]D-Fender (~chatzilla@64.235.216.2) |
| 22:03.42 | mjordan | pabelanger: Hm.... not sure if that would pass or fail the idea of the testsuite mucking with the networking, but it's certainly better than having two NICs in a machine |
| 22:04.05 | mjordan | heh. |
| 22:04.10 | mjordan | dummynet was written by rizzo |
| 22:08.28 | pabelanger | mjordan, Ya, I wouldn't have the testsuite do any networking. That is a deployment issue, which could be done with puppet or something. coreyf1513 is right to have a dependency check in place to see if the underlying setup is there, else skip |
| 22:09.27 | coreyf1513 | I think it would be nice if a script to setup the networking was included with testsuite, but it should not be run automatically |
| 22:09.50 | pabelanger | Ya, direction to set it up would be there |
| 22:15.06 | *** join/#asterisk-dev otherwiseguy (~otherwise@2605:a601:43e:3501:2677:3ff:fe8f:2730) |
| 22:19.12 | russellb | so ... mucking with networking (virtual interfaces anyway) for testing seems fine ... but if the tests affect system state (they sure would in that case), it'd be best to move to disposable test hosts |
| 22:19.24 | russellb | new VM for each test run to have a consistent test env |
| 22:19.52 | russellb | may or may not know of a project that provides API driven compute, networking, and storage infrastructure |
| 22:19.55 | putnopvut | Honestly, that's a good model to have in general for automated testing |
| 22:20.01 | russellb | +1 |
| 22:21.26 | pabelanger | russellb, nodepool! |
| 22:21.39 | putnopvut | That's an anagram of "No poodle" |
| 22:21.48 | pabelanger | woah |
| 22:21.50 | pabelanger | mind |
| 22:21.50 | pabelanger | is |
| 22:21.51 | pabelanger | blown |
| 22:22.04 | russellb | pabelanger: heh well ... that may be overkill |
| 22:22.06 | putnopvut | Or "loon dope" |
| 22:22.11 | *** join/#asterisk-dev vlad_starkov (~vlad_star@77.41.82.191) |
| 22:22.13 | putnopvut | That loon is dope |
| 22:22.27 | pabelanger | russellb, maybe, but the concept is right |
| 22:22.43 | russellb | hm |
| 22:22.48 | russellb | bamboo still has the EC2 stuff, but that's it' |
| 22:23.00 | russellb | not sure how easy it would be to trick it into a local EC2 clone |
| 22:23.16 | russellb | doesn't sound great if you're having to trick it |
| 22:23.56 | russellb | anyway, as cool as i think this stuff is, if you really want to invest in infrastructure, i think i'd do git first :-) |
| 22:24.13 | pabelanger | ! |
| 22:24.18 | russellb | returns to lurk mode |
| 22:24.55 | mjordan | russellb: we've actually spec'd that out in the past, it's not bad at all |
| 22:25.02 | russellb | which |
| 22:25.10 | mjordan | making bamboo use openstack |
| 22:25.13 | putnopvut | heh, file and I were lamenting about svn's lack of an equivalent to "git stash" and "git add -p" |
| 22:25.13 | russellb | ah, cool |
| 22:25.31 | putnopvut | just today, I mean |
| 22:25.46 | russellb | or could just use EC2, save you a lot of self-hosting pain |
| 22:26.02 | sgriepentrog | btw mock is a great tool for creating a clean chroot instance to test in - same kernel & modules but clean filesystem installation |
| 22:26.13 | putnopvut | russellb: that would result in a smaller e-peen though. |
| 22:26.47 | pabelanger | sgriepentrog, See my pbuilder code in subversion for chroots and bamboo |
| 22:26.55 | pabelanger | spend a few weeks working on it when I was at digium |
| 22:27.04 | russellb | chroots don't really help you if you're mucking with networking (global host state) |
| 22:27.05 | sgriepentrog | .. as a way to avoid building or rewinding snapshot of vm |
| 22:27.11 | pabelanger | right |
| 22:27.21 | pabelanger | VM would be the best way |
| 22:27.38 | pabelanger | leaves for taco night |
| 22:27.44 | sgriepentrog | If you're mucking with networking then yes. For build dependencies mock works well. |
| 22:27.45 | russellb | or if you want to be hipster, try docker |
| 22:27.54 | russellb | sure, mock rocks for what it's for :) |
| 22:28.47 | russellb | & |
| 22:33.48 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 22:43.16 | coreyf1513 | russellb: I don't agree that mucking with networking is ok for the tests to do. Think of python-twisted or pjsua or asttest, the testsuite doesn't install it if not found. The same should be true of network interfaces/addresses. if the system isn't properly setup to run a test, the test has to be skipped. |
| 22:48.05 | *** join/#asterisk-dev snuff-work (~snuffy@210.8.167.13) |
| 22:48.08 | *** mode/#asterisk-dev [+o snuff-work] by ChanServ |
| 22:51.45 | gtjoseph | anyone else seeing a ton of whitespace in 12's console logging recently? |
| 22:52.06 | putnopvut | gtjoseph: Not I. Can you pastebin an example? |
| 22:54.35 | gtjoseph | Huh, when I cut and paste the output the whitespace isn't there. must be tabs. |
| 22:54.38 | *** join/#asterisk-dev sgalarneau (~Adium@nat/digium/x-qeftmgyytopluhen) |
| 22:57.18 | gtjoseph | Hah! I had changed my terminal background to white last week and now the file and function are invisible because they're bright white. |
| 23:09.46 | putnopvut | wow, good job figuring that out. That'd drive me mad. |
| 23:10.23 | gtjoseph | :) |
| 23:24.35 | newtonr | gtjoseph, haha I did that once with a grey background terminal, drove me to a level of Lovecraftian insanity |
| 23:25.35 | gtjoseph | it shows you how much i look at the messages though. i didn't even miss the file and function. |
| 23:40.37 | *** part/#asterisk-dev mjordan (~matt@nat/digium/x-bywizkfklqkbdnsr) |
| 23:56.14 | *** part/#asterisk-dev kharwell (~kharwell@nat/digium/x-rghtndrjeajpdyll) |