[06:47] <ginggs> nacc, Pharaoh_Atem: did you see https://packages.qa.debian.org/p/pcre3/news/20160227T165039Z.html ?
[10:53] <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:54] <Pharaoh_Atem> but can someone please tell me why pcre has a soversion of 3 in Debian/Ubuntu but nowhere else?
[10:55] <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:56] <Pharaoh_Atem> so pcre2 is named correctly
[10:57] <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:58] <Pharaoh_Atem> ginggs: do you have any idea, as the pcre maintainer in Ubuntu?
[11:00] <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:01] <ginggs> upstream where bumping the SONAME unecessarily
[11:01] <ginggs> *were
[11:02] <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:03] <Pharaoh_Atem> oh geez
[11:03] <Pharaoh_Atem> I see how it happened
[11:04] <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:12] <ginggs> Pharaoh_Atem: are you able to test if pcre3 2:8.38-2 fixes the php segfaults?
[11:13] <Pharaoh_Atem> atm no, I have to rebuild everything :/
[11:13] <Pharaoh_Atem> which... takes hours
[17:10] <cjwatson> stefanct: groff> somewhat, depending on what you need
[22:32] <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:35] <stefanct> http://dpaste.com/3MX4WYK
[22:36] <stefanct> and no, the line break within the .de is not the problem (alone)
[22:38] <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:42] <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:55] <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:56] <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:57] <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:58] <stefanct> yes, i think you are right
[22:59] <stefanct> in any case... lintian should now be happy so i am too :)