| 01:30.13 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 01:39.25 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 03:42.18 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 03:51.38 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 05:54.21 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:03.32 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 07:25.50 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:39.16 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 08:06.20 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:10.23 | *** join/#asterisk-dev CELYA_ (~Thunderbi@lstlambert-657-1-90-73.w80-13.abo.wanadoo.fr) |
| 08:13.17 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 08:17.07 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 09:22.37 | pchero_work | Hi, May I get some help? I would like to see which SIP headers are parsed into struct ast_party_id id of the struct ast_sip_session from the INVITE SIP message. Where function should I look at it? |
| 09:22.58 | pchero_work | I'm digging the new_invite() now, but hard to find the parser. |
| 09:23.50 | pchero_work | Because all the caller's info comes from session.id, but want to see which SIP headers are parsed into this structure. :P |
| 09:28.07 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 10:43.43 | file | res_pjsip_caller_id is where it happens? |
| 10:51.03 | pchero_work | file: Thanks, now I can see it. :) static void set_id_from_hdr(pjsip_fromto_hdr *hdr, struct ast_party_id *id) does parse the id from 'from' header. :) |
| 10:51.43 | file | it actually supports From, Remote-Party-ID, and P-Asserted-Identity |
| 10:52.39 | pchero_work | Ooops, which one would be selected then? May I need to check the priority.. -_-;; |
| 10:53.48 | file | PAI, RPID, From in that order |
| 10:54.00 | pchero_work | Ah, caller_id_incoming_request() I can see it. :) |
| 10:54.08 | pchero_work | file: Thanks. :) |
| 11:14.02 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-rsygkecvxqulajrr) |
| 11:14.02 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 11:49.32 | file | coreyfarrell: poke |
| 12:44.43 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:21.23 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:35.43 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 13:37.30 | *** join/#asterisk-dev stevedav_ (~stevedavi@197.155.252.3) |
| 13:46.43 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 14:17.40 | coreyfarrell | file: hello |
| 14:17.54 | file | coreyfarrell: hello! an issue came in of... fun |
| 14:18.20 | file | coreyfarrell: https://issues.asterisk.org/jira/browse/ASTERISK-28319?filter=13157 musl strikes again - but the associated mailing list thread has... interesting thoughts |
| 14:23.19 | coreyfarrell | "looks like they expect resource_being_loaded to be 0 if the dlopen succeeds; assuming the intent is that some constructor in the loaded library sets it to 0, this is only valid for the first open". |
| 14:23.43 | coreyfarrell | sigh |
| 14:30.32 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:30.32 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:35.44 | coreyfarrell | file: I'm not sure how to deal with if `dlclose` doesn't work correctly - I hope/assume this means that __attribute__((destructor)) isn't run either. |
| 14:36.23 | file | knows not |
| 14:56.42 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 15:02.59 | file | coreyfarrell: I think I'll accept the issue, but it'll be community level |
| 15:03.46 | coreyfarrell | file: sounds fair. does asterisk have an official 'libc' support policy? |
| 15:04.07 | file | not officially, from a Sangoma/Digium perspective it's certainly not something we support |
| 15:21.15 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-memglsuhjzcdkwxk) |
| 15:21.15 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 15:26.24 | cresl1n | glibc? |
| 15:26.25 | cresl1n | :-P |
| 15:26.50 | cresl1n | but if someone in the community wants to do musl and it doesn't break glibc, I'd be cool with that |
| 15:28.50 | file | aye |
| 17:10.58 | bford | follow up from yesterday's CHANGES/UPGRADE question - in master, we've got stuff like "from 16.0.0 to 16.1.0" in the CHANGES file. as far as automating this process goes, it would be much easier to have everything in a "from 16 to 17" when releasing a new version, otherwise when we do minor releases we would need to manually make the changes to master's CHANGES file so that it retains the information going into previous |
| 17:10.58 | bford | versions. is anyone opposed to having one section from major version to major version for when making a release from master? |
| 17:14.05 | rmudgett | A reason we would want 16.1 to 16.2 sections in master is to show that those changes were not master only additions. A 16 to 17 section shows what is only in 17. |
| 17:20.41 | kharwell | Do we care though? I mean from a user perspective they just need to know what the changes are. Shouldn't matter if they are new features vs bug fixes |
| 17:22.21 | bford | i understand having 16.1 -> 16.2 is more specific, but if we have that, it does hinder the automation process a little bit, which could defeat the purpose of working this issue since it will add more work to do for releases |
| 17:30.56 | gtjoseph | @tsearle: What database were you running alembic against when you got the issue with the taskprocessor script? |
| 17:32.27 | gtjoseph | and what version of SQLAlchemy? |
| 17:33.08 | gtjoseph | your alembic also looks old... alembic==0.9.3 |
| 18:19.07 | file | seanbright: nice find |
| 18:29.44 | seanbright | what's the idiomatic way in python to check if the first character of a string is a given char? |
| 18:29.57 | seanbright | if str[0] == '/' |
| 18:29.57 | seanbright | ? |
| 18:55.20 | coreyfarrell | kharwell: I think having master changes separated into 16.1, 16.2 / etc changes is useful because most people will not upgrade from 16.0.0 to 17.0.0, they upgrade from 16.5.0. |
| 18:59.43 | coreyfarrell | bford: maybe changes for master could have a special header like `Version: master' to flag changes as 'master only' to filter out the cherry-picks from 16.x? only thing is CHANGES/UPGRADE.txt in master would need to be updated at the same time as 16.x releases. |
| 19:06.35 | bford | coreyfarrell: kharwell and i discussed the header option a little too, the main concern being that cherry picks would be rather annoying since version would change for each cherry pick to master |
| 19:07.13 | coreyfarrell | bford: yes but you just wouldn't put the header in changes that are being cherry-picked. |
| 19:08.52 | bford | ah i see what you're saying now |
| 19:08.56 | coreyfarrell | The only reason for the value in `Version: master` is to follow the header syntax. `Master-Only: True` if that would avoid confusion |
| 19:11.03 | bford | that just leaves the minor to minor version issue, which may not be a big deal since we will have the "new in xxx" taken care of |
| 19:12.35 | coreyfarrell | if you mean 'changes in 16.4.1' I don't think that needs to be in the 'master' changelog. I'd say the master changelog should only reference 'Changes from 16.x.0 to 16.y.0' |
| 19:13.18 | bford | my bad, meant the "16.3.0 to 16.4.0" |
| 19:13.30 | kharwell | coreyfarrell: Even upgrades from something like 16.5->17 would be fine as they would get all changes that went into 17 (some previous to 16.5 would be listed of course). This way too for a major release you could group all changes by modules, or potential future tags like deprecated. |
| 19:16.17 | kharwell | I guess though it really depends on how someone typically reads the file. I suppose if the step was small (like one/two sets of changes) all that history could complicate things |
| 19:31.58 | seanbright | coreyfarrell: i think you knew python? or am i thinking of someone else? |
| 19:32.19 | seanbright | s/think/thought/ |
| 19:32.59 | coreyfarrell | seanbright: I pretended to when I did some sledgehammer work to make stuff py3 compatible. |
| 19:33.05 | seanbright | i see |
| 19:33.33 | seanbright | ok, so who here knows python? |
| 19:34.00 | seanbright | simple question: what is the idiomatic way to check if the first character of a given string is a known value? this should be simple |
| 19:34.13 | seanbright | in C it would be *str == '-' |
| 19:34.19 | rmudgett | How can anyone know a language if the mysterious they keeps changing it. |
| 19:34.28 | seanbright | /ignore rmudgett |
| 19:34.31 | seanbright | shoot, sorry |
| 19:34.48 | seanbright | <3 |
| 19:35.43 | seanbright | PYTHON, MOTHERF**KER! DO YOU SPEAK IT!? |
| 19:36.21 | seanbright | i'm happy with [0] |
| 19:36.24 | seanbright | +1 me |
| 19:36.27 | seanbright | and then +2 me |
| 19:36.29 | seanbright | and then let's move on |
| 19:36.45 | bford | i just use "startswith" |
| 19:37.24 | seanbright | probably safer |
| 19:37.50 | seanbright | normal negation works? ... and !str.startswith('foo') |
| 19:37.50 | seanbright | ? |
| 19:38.29 | bford | should, i usually do "if not str.startswith('foo')" |
| 19:38.43 | seanbright | yes. that's better. |
| 19:38.45 | seanbright | awesome. thanks bford |
| 19:38.59 | bford | no problem! |
| 19:40.01 | file | seanbright: if you want to type less you can leave out #close |
| 19:40.10 | seanbright | i like it. rmudgett likes it. |
| 19:40.21 | file | k |
| 19:40.21 | seanbright | and if rmudgett likes it, it can't be wrong. |
| 19:41.29 | seanbright | there. i'm an expert python programmer now. adding to the résumé. |
| 20:08.15 | *** join/#asterisk-dev infobot (ibot@rikers.org) |
| 20:08.15 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 23:11.43 | *** join/#asterisk-dev jpsharp (~jsharp@linode.fivecats.org) |
| 23:17.20 | jpsharp | So stupid question from jpsharp time: I have a custom cel driver that, when I run it, it makes asterisk leak file descriptors from the alertpipes on the channels. The channel destructors apparently never get called to clean up. I have no idea what is causing this. |
| 23:20.58 | coreyfarrell | jpsharp: sounds like you're leaking references to channels. you probably need to enable REF_DEBUG to troubleshoot the leaked reference. |
| 23:47.27 | jpsharp | Oh foo. I had forgotten about ref_debug. Thanks. |
| 23:58.42 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-memglsuhjzcdkwxk) |