| === pepee- is now known as pepee | ||
| === coreycb` is now known as coreycb | ||
| === juliank is now known as Guest18923 | ||
| === juliank_ is now known as juliank | ||
| === nelhage_ is now known as nelhage | ||
| ginggs | nacc, Pharaoh_Atem: did you see https://packages.qa.debian.org/p/pcre3/news/20160227T165039Z.html ? | 06:47 |
|---|---|---|
| === Guest46749 is now known as Zic | ||
| Pharaoh_Atem | ginggs: hmm, maybe that'll fix the php segfaults | 10:53 |
| Pharaoh_Atem | ginggs: that's one of the things Fedora patched to fix | 10:53 |
| Pharaoh_Atem | but can someone please tell me why pcre has a soversion of 3 in Debian/Ubuntu but nowhere else? | 10:54 |
| ginggs | Pharaoh_Atem: and pcre2 is the new version | 10:55 |
| Pharaoh_Atem | yeah | 10:55 |
| Pharaoh_Atem | in Fedora it makes sense, because pcre kept the soversion 1 | 10:55 |
| Pharaoh_Atem | so pcre2 is named correctly | 10:56 |
| Pharaoh_Atem | it's the same way in openSUSE, where they actually put the soversion in package names | 10:57 |
| Pharaoh_Atem | it's libpcre1 | 10:57 |
| Pharaoh_Atem | it's a really bizarre ABI change that seems to be exclusive to Debian/Ubuntu | 10:57 |
| Pharaoh_Atem | ginggs: do you have any idea, as the pcre maintainer in Ubuntu? | 10:58 |
| Pharaoh_Atem | ginggs: this is not a patch that makes me very happy... https://sources.debian.net/src/pcre3/2:8.38-2/debian/patches/soname.patch/ | 11:00 |
| ginggs | i think i recall reading aomething about that | 11:00 |
| ginggs | upstream where bumping the SONAME unecessarily | 11:01 |
| ginggs | *were | 11:01 |
| ginggs | you can look back through the changelog http://metadata.ftp-master.debian.org/changelogs/main/p/pcre3/unstable_changelog to see where pcre2 and pcre3 appeared | 11:02 |
| Pharaoh_Atem | oh geez | 11:03 |
| Pharaoh_Atem | I see how it happened | 11:03 |
| Pharaoh_Atem | they patched and bumped the soversion when major versions were introduced | 11:04 |
| Pharaoh_Atem | but that's not irreversible now... unless they don't have a tool that rebuilds all the reverse depends, I guess? | 11:04 |
| ginggs | Pharaoh_Atem: are you able to test if pcre3 2:8.38-2 fixes the php segfaults? | 11:12 |
| Pharaoh_Atem | atm no, I have to rebuild everything :/ | 11:13 |
| Pharaoh_Atem | which... takes hours | 11:13 |
| === Elimin8r is now known as Elimin8er | ||
| === tlyu_ is now known as tlyu | ||
| === yofel_ is now known as yofel | ||
| === gusnan_ is now known as gusnan | ||
| === ahasenac` is now known as ahasenack | ||
| === Mirv__ is now known as Mirv | ||
| === kees_ is now known as kees | ||
| === Elimin8r is now known as Elimin8er | ||
| cjwatson | stefanct: groff> somewhat, depending on what you need | 17:10 |
| === Guest87218 is now known as kirkland | ||
| === pepee- is now known as pepee | ||
| === sarnold_ is now known as sarnold | ||
| stefanct | cjwatson: sorted it out myself. i dont really understand why but adding \{ and \} to a branch containing a macro definition (.de) helped to avoid "warning: macro `.' not defined" at the end of that definition... | 22:32 |
| stefanct | http://dpaste.com/3MX4WYK | 22:35 |
| stefanct | and no, the line break within the .de is not the problem (alone) | 22:36 |
| cjwatson | stefanct: that would make sense. if you don't have the \{ there, then the .el only executes the next request, I'm not very surprised that that would have strange interactions with .de without \{ \} | 22:38 |
| stefanct | well but executing the next request is exactly what it should do... just because that request has multiple lines i would not expect it to fail | 22:42 |
| cjwatson | stefanct: I think technically the single line containing .de is the request, and then that request copies subsequent lines of input into a buffer | 22:55 |
| cjwatson | stefanct: so if the .de isn't executed, then you have subsequent lines of input that will just be executed there and then | 22:56 |
| cjwatson | stefanct: the .. (or whatever the macro closure is) is in fact a separate request after that telling troff to stop the macro definition | 22:57 |
| cjwatson | stefanct: basically the parser is less smart than you were giving it credit for, but you have arrived at the correct answer :) | 22:57 |
| stefanct | yes, i think you are right | 22:58 |
| stefanct | in any case... lintian should now be happy so i am too :) | 22:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!