=== 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 [06:47] nacc, Pharaoh_Atem: did you see https://packages.qa.debian.org/p/pcre3/news/20160227T165039Z.html ? === Guest46749 is now known as Zic [10:53] ginggs: hmm, maybe that'll fix the php segfaults [10:53] ginggs: that's one of the things Fedora patched to fix [10:54] but can someone please tell me why pcre has a soversion of 3 in Debian/Ubuntu but nowhere else? [10:55] Pharaoh_Atem: and pcre2 is the new version [10:55] yeah [10:55] in Fedora it makes sense, because pcre kept the soversion 1 [10:56] so pcre2 is named correctly [10:57] it's the same way in openSUSE, where they actually put the soversion in package names [10:57] it's libpcre1 [10:57] it's a really bizarre ABI change that seems to be exclusive to Debian/Ubuntu [10:58] ginggs: do you have any idea, as the pcre maintainer in Ubuntu? [11:00] 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] i think i recall reading aomething about that [11:01] upstream where bumping the SONAME unecessarily [11:01] *were [11:02] 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:03] oh geez [11:03] I see how it happened [11:04] they patched and bumped the soversion when major versions were introduced [11:04] but that's not irreversible now... unless they don't have a tool that rebuilds all the reverse depends, I guess? [11:12] Pharaoh_Atem: are you able to test if pcre3 2:8.38-2 fixes the php segfaults? [11:13] atm no, I have to rebuild everything :/ [11:13] which... takes hours === 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 [17:10] stefanct: groff> somewhat, depending on what you need === Guest87218 is now known as kirkland === pepee- is now known as pepee === sarnold_ is now known as sarnold [22:32] 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:35] http://dpaste.com/3MX4WYK [22:36] and no, the line break within the .de is not the problem (alone) [22:38] 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:42] 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:55] 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:56] stefanct: so if the .de isn't executed, then you have subsequent lines of input that will just be executed there and then [22:57] 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] stefanct: basically the parser is less smart than you were giving it credit for, but you have arrived at the correct answer :) [22:58] yes, i think you are right [22:59] in any case... lintian should now be happy so i am too :)