| 00:00.06 | WIMPy | I already said so. |
| 00:02.06 | rgagnon | lol ok... so we agree |
| 00:02.34 | WIMPy | I don't think so. |
| 00:08.28 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 00:13.31 | philippel_mac | ping any devs around to check if something would be considered a bug? |
| 00:14.03 | tm1000 | file: ^^ |
| 00:15.53 | tm1000 | WIMPy: amusing |
| 00:15.54 | tm1000 | :-) |
| 00:16.14 | tm1000 | I *almost* want to quote the last four lines there |
| 00:16.43 | WIMPy | I guess we all know that IE is bad at guessing file types. |
| 00:16.53 | WIMPy | But a content-type would be good idea. |
| 00:18.51 | WIMPy | found the html bit funny. Maybe he was a web developer. |
| 00:21.47 | tm1000 | oh wow |
| 00:21.55 | tm1000 | he left right after you didnt agreed with him |
| 00:46.18 | file | what? |
| 00:48.47 | philippel_mac | file: question trying to determine if it would be considered a bug or what |
| 00:49.19 | philippel_mac | when you set the CALLERID(all) or (num) for the first time, it sets the CDR(clid) as well as the CDR(src) |
| 00:49.22 | file | if it's CDR related I don't even want to venture a guess, that's a minefield |
| 00:49.49 | philippel_mac | if you change CALLERID(name) or (num) after that, the number part of CDR(clid) or (src) never chnage |
| 00:49.56 | philippel_mac | the cnam part does |
| 00:50.01 | philippel_mac | so inconsistent |
| 00:50.12 | file | CDRs in general are inconsistent and behavior undefined/undocumented |
| 00:50.32 | philippel_mac | if you subsequently set CALLERID(ANI-num) you can get the CDR(clid) chum part to change |
| 00:50.41 | philippel_mac | yeah I am very aware of that |
| 00:51.04 | snuff-work | if u wanted to make a change for urself go ahead :) |
| 00:51.21 | snuff-work | changing cdr handling generally results in angry ppl |
| 00:51.35 | philippel_mac | I guess my point/issue is … it is definitely inconsistent at a minimum and I'd like to get an assessment as to if it would be considered a bug and possibly changed or if there is a concuss that it is going to be left as is because of hisotry |
| 00:51.36 | snuff-work | cause they have coded/forked so many diff cdr's to make a call |
| 00:51.39 | philippel_mac | history |
| 00:52.10 | philippel_mac | since I want to make some decisions for dealing with some stuff in freepbx and don't want it changing in the future when someone finally decides the inconsistency is a bug |
| 00:53.13 | philippel_mac | so the crux is that inconsistency, once you set it the first time, you can't reset it and in fact using CALLERID(all) you change part but not all of it, unless you set ANI-num specifically … along with the fact that it appears CDR(src) is completely redundant since it's a subset of CDR(clid) |
| 00:53.48 | philippel_mac | file: as far as documentation, Malcom did put it up on the wiki so it is somewhat documented :) |
| 00:53.57 | file | put what? |
| 00:54.11 | philippel_mac | put up some documetnation |
| 00:54.12 | WIMPy | What exactely? |
| 00:54.32 | philippel_mac | e.g it says src is Callerid(num) effectively and clid is CallerID |
| 00:55.27 | file | not reallllly documentation but sorta |
| 00:55.29 | philippel_mac | file: what I want to avoid is making the decision at this point that it will remain like this (e.g. once set once it won't change the chum part) and then down the road someone agrees that CDR(clid) should reflect what it is labeled as, clid |
| 00:55.48 | file | CDRs won't change except for the most dire of circumstances unless enough of us agree to go down that road |
| 00:55.49 | philippel_mac | file: I understand, more then we tend to have at FreePBX so I'm no one to complain :) |
| 00:56.32 | philippel_mac | file: well that's why I'd like to bring it up now, to agree to change it, or not to change it so that we don't count on it being 'sticky' the way it is now and then later it 'breaks' |
| 00:56.57 | file | then I'd suggest emailing the -dev list |
| 00:57.12 | file | I fight to keep them as-is |
| 00:57.22 | snuff-work | +1 file |
| 00:57.42 | snuff-work | cdr handling changes make ppl angry :) |
| 00:57.43 | philippel_mac | k … and I do generally agree with that stance for lots of obvious reasons ... |
| 01:36.01 | *** join/#asterisk-dev file (~file@asterisk/developer-and-muffin-lover/file) |
| 01:36.01 | *** mode/#asterisk-dev [+o file] by ChanServ |
| 01:38.23 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 02:47.56 | *** join/#asterisk-dev blitzrage (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 02:47.56 | *** mode/#asterisk-dev [+o blitzrage] by ChanServ |
| 02:52.30 | snuff-work | wedhorn: started on pickup .. went south kinda quick.. needed more work than i can manage atm |
| 02:52.51 | snuff-work | will need to implement another msg though.. for call-info.. |
| 02:53.12 | snuff-work | as it seems to be used in the pickup/steal process |
| 03:37.56 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@212.179.75.202) |
| 03:37.56 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 04:07.13 | *** join/#asterisk-dev marv (~Adium@c-50-130-4-242.hsd1.al.comcast.net) |
| 04:12.48 | snuff-work | wedhorn: new JIRA issues.. #20788 #20789 #20790 |
| 04:14.27 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 04:14.28 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 04:14.48 | WIMPy | I've got one that's probably not linked to the ancient hardware. When I use a context with switches, Asterisk will deadlock whenever I dieal a valid extension. |
| 04:15.29 | WIMPy | -e |
| 04:52.10 | snuff-work | WIMPy: have u tried getting a core show locks / bt ? |
| 05:20.37 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 06:06.31 | wedhorn | snuff-work, damn, 3 of them. Will see what I can do. |
| 06:15.30 | snuff-work | np |
| 06:15.40 | snuff-work | i hope my logic makes sense on em all still |
| 06:28.06 | wedhorn | the codec and debug look fine, will need to look a bit more at vmexten but nothing appears too wrong with it |
| 06:28.21 | *** join/#asterisk-dev bOOinK[DK] (~quassel@m83-185-133-85.cust.tele2.se) |
| 06:28.22 | wedhorn | notice you didn't add the other g722 codecs |
| 06:28.30 | wedhorn | "other" |
| 06:28.46 | wedhorn | any reason? |
| 06:30.09 | snuff-work | nope i could.. i just doubt if the devices really support em |
| 06:38.53 | wedhorn | I would have assumed that if the device is advertising them (fmt 7 and 8) that they would |
| 06:50.04 | snuff-work | i can always add em back |
| 06:50.10 | snuff-work | n update the patch |
| 06:53.04 | wedhorn | have you tried them? if not, I'm happy to do it |
| 06:53.41 | *** join/#asterisk-dev pnlarsson (~niklas@fw1.gml.g.icnet.infracom.se) |
| 07:03.14 | snuff-work | nope haven't tried |
| 07:03.41 | snuff-work | u can.. i can also send u a cap of stuff for the 'pickup'.. |
| 07:04.16 | snuff-work | but it was tad more involved than i hoped.. then i had hassle even picking up from a sip phone.. anyway :) |
| 07:05.54 | wedhorn | I think we've got the code for receiving the pickup, we just don't do anything with it |
| 07:06.22 | snuff-work | i didn't think so when i looked.. |
| 07:07.30 | wedhorn | You're right we don't |
| 07:09.09 | snuff-work | i counted.. about 10 steps in a ccm pickup flow |
| 07:09.44 | wedhorn | I assume all but the first are the same as any call connection |
| 07:11.21 | snuff-work | so it goes.. push 'pickup' -> 'send new 'callinfomsg (14a)' -> send other phone we are stealing from lampoff/clear prompt |
| 07:11.48 | wedhorn | hang on, it's a softkey so the device will only send instance and callref |
| 07:12.19 | snuff-work | yep.. the ccm sends that new 'callinfomsg' part.. |
| 07:12.28 | snuff-work | and tells other phone he lost :) |
| 07:13.29 | wedhorn | yeah, it's the bit between the first and second bits. Basically work out what call to grab, grab it and end call (the rest of the code will handle what to do with the other device) and connect it to the device requesting it |
| 07:14.06 | snuff-work | mm |
| 07:14.52 | wedhorn | the working out what call to grab (internal to asterisk) and actually grabbing the call (again internal to asterisk) are the hard bits |
| 07:15.49 | wedhorn | once you work out what to grab you can just send a hangup to the other end and the channel will handle it (whether skinny sip or whatever) |
| 07:15.56 | snuff-work | the grab internal to * seems easy enough.. just the ast_pickup() |
| 07:16.00 | wedhorn | channel_driver |
| 07:16.11 | snuff-work | but i need to figure out the stuff to go round |
| 07:16.19 | wedhorn | okay, it probably hangs up as well |
| 07:16.44 | snuff-work | i think i have some idea.. will pastebin somethin tomorrow |
| 07:17.58 | wedhorn | I would work on the assumption that ast_pickup will handle all the other call ends so all you would need to do is to get the chan into a (skinny) sub and connect it (set SUBSTATE_CONNECTED) |
| 07:20.40 | snuff-work | ;) |
| 07:31.09 | *** join/#asterisk-dev bulkorok (~bulkorok@85.183.36.36) |
| 08:06.43 | *** join/#asterisk-dev luckman212 (~luckman21@2001:470:8abb:0:211:32ff:fe10:cdc1) |
| 08:33.51 | *** join/#asterisk-dev schmidts (~schmidts@vie-086-059-105-021.dsl.sil.at) |
| 08:33.53 | schmidts | good morning |
| 08:34.18 | bOOinK[DK] | ahh, schmidts, just the man I was looking for |
| 08:35.18 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:35.18 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:54.37 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 09:09.39 | wedhorn | i'm getting 'uuid/uuid.h: No such file or directory' when trying to make trunk, any ideas? |
| 09:13.10 | schmidts | wedhorn ./configure and make menuselect helps |
| 09:18.15 | *** join/#asterisk-dev alsuren__ (~dlaban@80.169.133.251) |
| 09:22.33 | wedhorn | schmidts: did ./configure and remove menuselect.makeopts |
| 09:23.03 | wedhorn | and a make clean just to be sure |
| 09:25.45 | schmidts | hmm ok |
| 09:26.02 | schmidts | i had the same problem lately when trying to make trunk but it was gone after doing configure and make menuselect |
| 09:27.03 | wedhorn | trying a clean, configure and make, see what happens |
| 09:31.13 | schmidts | ok |
| 10:27.39 | wedhorn | had to install uuid-dev (on ubuntu) |
| 10:59.14 | *** join/#asterisk-dev caio1982 (~caio1982@189.125.242.3) |
| 11:57.50 | *** join/#asterisk-dev x1user (~chatzilla@212.36.13.6) |
| 11:57.57 | x1user | Hi, I've configed ODBC correctly, and asterisk loads without any warning about odbc but i dont get users loaded from sipusers |
| 12:05.30 | *** join/#asterisk-dev oron_laptop (~oron_lapt@local.xorcom.com) |
| 13:55.38 | *** join/#asterisk-dev serafie (~erin@nat/digium/x-bwnefdefsmfavbzj) |
| 14:05.39 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 14:05.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 14:24.08 | *** join/#asterisk-dev sezuan (bouncer@irc.scheff32.de) |
| 14:29.14 | *** join/#asterisk-dev bombev (~bombev@PPPoE-Static-40-132.UnicsBG.Net) |
| 14:45.09 | seanbright | so i saw some back and forth on the UUID review between putnopvut and david lee about whether or not the UUID api in asterisk would always generate RFC 4122 compliant UUIDs, or if that might change under the hood at some point |
| 14:45.15 | seanbright | was there ever a decision made on that? |
| 14:50.48 | Marquis42 | seanbright: I can't say for certain without re-reading the e-mails, but I was under the impression that it was decided that 4122-compliant UUIDs were deemed the way to go. |
| 14:53.37 | seanbright | excellent |
| 14:53.45 | seanbright | makes the most sense |
| 14:53.50 | Marquis42 | I agree |
| 14:55.03 | *** join/#asterisk-dev pabelanger (~pabelange@asterisk/contributor-and-bug-marshal/pabelanger) |
| 14:55.03 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 15:23.16 | *** join/#asterisk-dev b3nt_pin (~quassel@142.134.193.186) |
| 15:24.14 | b3nt_pin | With the recent addition of uuid related operations, shouldn't "configure" check for uuid.h? |
| 15:24.41 | opticron | b3nt_pin, I actually just ran into this as well, configure didn't choke, but the build failed due to lack of uuid.h |
| 15:24.41 | file | it already does - it just doesn't cause configure to fail if it isn't there |
| 15:32.21 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 15:32.21 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 15:33.46 | seanbright | putnopvut: asked this while you weren't here but this is the short version: will the UUID API in asterisk always return RFC 4122 compliant UUIDs? |
| 15:34.18 | putnopvut | seanbright: it's designed so it doesn't have to. But I can't really foresee a scenario where we wouldn't have to. |
| 15:34.27 | putnopvut | s/wouldn't have to/wouldn't want to/ |
| 15:34.54 | seanbright | ok. res_calendar_exchange rolls its own UUIDs and i want to change it to use the UUID API |
| 15:35.35 | seanbright | i suppose if we decide to change the UUID API to return something else at some point we would need to re-introduce that code. |
| 15:35.50 | seanbright | NBD... YOLO |
| 15:42.18 | russellb | someone also needs to change the HAVE_URANDOM business |
| 15:42.53 | russellb | since it's an invalid check for cross-compilation or package builds |
| 15:43.08 | putnopvut | russellb: I did before committing |
| 15:43.11 | putnopvut | It's a runtime check now |
| 15:43.16 | russellb | oh you did? awesome! |
| 15:43.19 | putnopvut | yep |
| 15:43.23 | russellb | you rock sir |
| 15:43.28 | russellb | takes that off his todo |
| 15:43.48 | russellb | i mainly watch the -dev list, not commits :-/ |
| 15:44.23 | putnopvut | 'sall good |
| 15:50.01 | russellb | hrm, post-review is failing for me |
| 15:50.36 | putnopvut | lame |
| 15:50.43 | putnopvut | It usually takes like 5 tries for me. |
| 15:50.51 | russellb | heh |
| 15:51.23 | russellb | i like how tempt_fate() is in the traceback... |
| 15:52.52 | putnopvut | lol @ "Bongo Boy" |
| 15:53.31 | pabelanger | Soo, why doesn't app_queue grab the longest waiting call in a queue? |
| 15:53.59 | putnopvut | That's a loaded question if ever there were one. |
| 15:54.09 | putnopvut | Why, pabelanger, it roughly *should* be doing so! |
| 15:54.35 | putnopvut | Autofill can sometimes give the illusion that it's not happening. There could also just be a good ol' bug in app_queue you're experiencing. |
| 15:54.55 | russellb | ha, you were right, 5 tries or so and it worked |
| 15:55.13 | russellb | putnopvut: while we were talking about HAVE_DEV_URANDOM ... https://reviewboard.asterisk.org/r/2245/ |
| 15:55.34 | seanbright | autofill.. .pfft |
| 15:55.40 | seanbright | why is that even an option? |
| 15:55.43 | seanbright | it's 2012 |
| 15:55.44 | Qwell | autofill caused so much confusion when it got added |
| 15:55.56 | Qwell | pretty sure twister was just trolling with that one |
| 15:56.00 | Qwell | twisted* |
| 15:56.19 | pabelanger | Okay, so I should not be using autofill? Basically, my longest waiting calls, contiune to be the longest waiting calls |
| 15:56.21 | seanbright | just enable it by default and remove it from the config |
| 15:56.30 | pabelanger | will positions in front get answered |
| 15:57.07 | seanbright | all that autofill should be done is delivering all calls to all available agents |
| 15:57.10 | seanbright | doing* |
| 15:57.26 | seanbright | well... offering. not delivering. |
| 15:57.38 | seanbright | what you are describing sounds like a bug to me |
| 15:57.56 | pabelanger | Add on top of it, I have mutli agents, in the same queues |
| 15:58.06 | *** join/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:58.21 | *** part/#asterisk-dev rgagnon (~rgagnon@rrcs-71-42-183-54.sw.biz.rr.com) |
| 15:58.30 | seanbright | i love app_queue, but the best thing we ever did was move all of our queueing out of asterisk |
| 15:58.43 | pabelanger | seanbright, to where? |
| 15:58.52 | seanbright | the cloud |
| 15:58.53 | seanbright | heh |
| 15:58.55 | seanbright | a java service |
| 15:59.16 | file | the best queueing system for you is one you write yourself |
| 15:59.24 | seanbright | true story |
| 15:59.26 | putnopvut | Yeah, app_queue is pure balls |
| 15:59.50 | pabelanger | https://issues.asterisk.org/jira/browse/ASTERISK-20623 |
| 15:59.52 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:59.53 | pabelanger | seems related |
| 16:00.24 | putnopvut | Try the patch out. |
| 16:00.30 | pabelanger | plan too |
| 16:02.58 | seanbright | a lot of our clients want skills based routing, which we have hacked around with using penalties |
| 16:03.07 | pabelanger | seanbright, yes |
| 16:03.12 | pabelanger | I was thinking of doing the same thing |
| 16:03.21 | seanbright | but once you reach a certain level of complexity, you need to manage the queue yourself |
| 16:04.21 | seanbright | at my old old old job the owner wanted calls delivered to reps with the highest conversion percentage (sales to handled calls) |
| 16:04.30 | seanbright | the 'rich get richer' scenario |
| 16:04.55 | seanbright | so we had this process that ran every few minutes to calculate the ranks and used AMI to update the penalties |
| 16:04.58 | seanbright | it was awful |
| 16:25.29 | pabelanger | well |
| 16:25.33 | pabelanger | set autofill=no |
| 16:25.37 | pabelanger | seems to have fixed it |
| 16:27.09 | Kobaz | i had a fun deadlock two days ago |
| 16:27.17 | Kobaz | core show locks was showing nothing |
| 16:27.23 | Kobaz | but nothing worked |
| 16:27.34 | Kobaz | i should have killed it with sigabrt to get the core, oh well |
| 16:28.41 | putnopvut | leedm777: the UUID configure script change is good, but we still need to bomb out if the UUID library is not present. |
| 16:28.54 | leedm777 | agreed. |
| 16:28.54 | putnopvut | I think that requires an if check on the result of the AST_EXT_LIB_CHECK |
| 16:29.13 | putnopvut | We can look at the termcap stuff and sqlite3 stuff as an example. |
| 16:29.15 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 16:29.15 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 16:29.19 | file | yup |
| 16:30.15 | leedm777 | I'll take care of that, then. |
| 16:30.24 | putnopvut | configure script stuff is still a big unfamiliar to me. Is an AST_EXT_LIB_SETUP also required? |
| 16:30.29 | putnopvut | s/big/bit/ |
| 16:31.33 | putnopvut | Yeah, I think it is, because that way you can tell the configure script that uuid is located someplace in particular if you want. |
| 16:44.15 | leedm777 | putnopvut: configure fail for missing libuuid committed. |
| 16:46.17 | file | exxxxcellent |
| 16:46.54 | putnopvut | all righty |
| 16:47.02 | putnopvut | thank you muchly |
| 16:47.50 | leedm777 | np |
| 17:16.23 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 17:16.23 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 17:55.57 | pabelanger | Oh, nice |
| 17:55.58 | pabelanger | [2012-12-13 11:54:20.008] WARNING[21604] channel.c: read() failed: Bad file descriptor |
| 18:00.40 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 18:08.18 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 18:08.19 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 18:40.38 | *** join/#asterisk-dev malcolmd (~malcolmd@pdpc/sponsor/digium/malcolmd) |
| 18:40.39 | *** mode/#asterisk-dev [+o malcolmd] by ChanServ |
| 19:26.08 | pabelanger | Any body help what AST_DEVICE_UNAVAILABLE means? |
| 19:26.31 | pabelanger | I know the device is unavailable, but what does that actually mean? |
| 19:28.29 | jsmith | pabelanger: Typically, that a device hasn't registered |
| 19:29.07 | jsmith | pabelanger: (at least, from memory) -- cause code 20? |
| 19:34.10 | pabelanger | jsmith, possible |
| 19:34.20 | pabelanger | maybe asterisk doesn't like the following hint :) |
| 19:34.21 | pabelanger | exten => _3[68]XX,hint,${SIP_DEVICE_${EXTEN}} |
| 19:35.12 | jsmith | Yeah, not sure variable expansion works for hints -- never tried it |
| 19:41.03 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 19:41.03 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 19:41.22 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 19:41.22 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 20:10.25 | *** join/#asterisk-dev moy (~moy@unvlon55-1176057127.sdsl.bell.ca) |
| 20:33.52 | wedhorn | I'm trying to merge a small skinny patch to trunk with merge11trunk and I'm getting an error |
| 20:34.08 | wedhorn | "svnmerge: multiple sources found. Explicit source argument (-S/--source) required." |
| 20:34.51 | wedhorn | it indicates two available sources, one of which is blank, setting the other doesn't seem to carry through to the svnmerge command |
| 20:34.54 | wedhorn | any ideas? |
| 20:40.14 | wedhorn | should I just patch manually and had craft a "merge" message? |
| 20:40.20 | wedhorn | hand |
| 20:41.41 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 20:41.41 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 20:45.18 | *** join/#asterisk-dev moy (~moy@173.239.155.74) |
| 20:46.25 | *** join/#asterisk-dev ivan`_ (~ivan@unaffiliated/ivan/x-000001) |
| 21:03.51 | newtonr | wedhorn: did you specify the revision from your commit to 11 "merge11trunk <revision>" ? |
| 21:06.56 | wedhorn | yep, more digging and I think I've borked my dir-prop-base |
| 21:07.48 | wedhorn | any idea on the easiest way to remake it (is it even possible)? |
| 21:09.52 | leedm777 | wedhorn: I don't think so. I see the same thing if I try merge11trunk 377991 |
| 21:10.20 | elguero | wedhorn: I was about to say same thing as leedm777 |
| 21:10.27 | wedhorn | did I break trunk? |
| 21:10.47 | wedhorn | r377869 |
| 21:10.59 | wedhorn | um r377986 |
| 21:11.08 | leedm777 | wedhorn: you broke the branch-11-merged property |
| 21:11.18 | leedm777 | so, yeah :-P |
| 21:11.24 | wedhorn | bugger |
| 21:12.26 | leedm777 | You committed without resolving the merge conflict. |
| 21:12.32 | wedhorn | okay, I can see it. What do I do now |
| 21:16.30 | leedm777 | wedhorn: I fixed it. Just had to manually edit the property to resolve the merge conflict. |
| 21:17.00 | wedhorn | leedm777: okay thanks, guess I've got to be more careful |
| 21:17.22 | leedm777 | Sure thing. |
| 21:20.20 | elguero | leedm777: since we are talking about the mergetool, something I saw when looking at it, should we change "svn pd branch-10-merged..." and "svn pd branch-10-blocked..." to 1.8 now that we will be merging from 1.8 to 11 instead of 10 to 11 when running merge11trunk? |
| 21:20.29 | leedm777 | wedhorn: Just run svn diff before committing. When it's a merge, you should see the revision your merging being added to the crazy long list in the branch-[whatever]-merged property. |
| 21:20.39 | elguero | lines 32 and 33 http://svnview.digium.com/svn/repotools/mergetool?revision=845&view=markup |
| 21:21.12 | leedm777 | wedhorn: Like you would see if you run svn diff -r 377981:377994 |
| 21:21.50 | elguero | yet, we are still doing merge1011... hmm? |
| 21:22.06 | elguero | I mean it is still in the script |
| 21:22.44 | leedm777 | elguero: We added 811 to the script instead. http://svnview.digium.com/svn/repotools/mergetool?r1=827&r2=845 |
| 21:23.26 | elguero | leedm777: yep, I got that... but I was looking at 11trunk |
| 21:23.52 | elguero | if we are going 1.8 to 11... why do svn pd branch-10-merged |
| 21:24.27 | leedm777 | reparses what elguero said |
| 21:24.38 | elguero | sorry, maybe not too clear |
| 21:24.55 | leedm777 | Or maybe I just read every other word. I do that sometimes :-D |
| 21:25.01 | elguero | hehe :) |
| 21:25.32 | elguero | I was kind of thinking out loud (typing out loud) |
| 21:26.40 | wedhorn | leedm777: thanks for the heads up, will check in future |
| 22:57.37 | *** join/#asterisk-dev moy (~moy@UNVLON55-1176057127.sdsl.bell.ca) |
| 23:34.17 | *** join/#asterisk-dev italorossi (~italoross@187.61.168.117) |
| 23:37.23 | *** join/#asterisk-dev leifmadsen (~lmadsen@asterisk/documenteur-extraordinaire/blitzrage) |
| 23:37.23 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |