| | <<<Back 1 day (to 2018/03/14) | 20180315 |
| aiena | is it possible to test for PDF/X-1A compliance with gs? | 09:15.44 |
| kens | No, Ghostscript doesn't validate PDF files | 09:16.01 |
| Scripkey | Hi | 10:39.58 |
| ghostbot | Welcome to #ghostscript. If you have a question, please ask it, don't ask to ask it. Do be prepared to wait for a reply as devs will check the logs and reply when they come on line. If you are looking for help or infomation about MuPDF, try the new #mupdf channel. | 10:39.58 |
| Scripkey | I don't know why Google indexed this for me when I was searching for do product of perpendicualr vectors :/ | 10:40.53 |
| | Lol | 10:41.03 |
| | See ya ! | 10:41.07 |
| chrisl | deekej: Howdy! | 15:25.59 |
| kens | chrisl has gone all American.... | 15:26.17 |
| deekej | chrisl: hello :) | 15:26.26 |
| | kens: nah, he'll need more than his talk to go all American I guess... :D | 15:26.49 |
| chrisl | deekej: Did you see the mail on gs-devel from Johannes Meixner ? | 15:27.01 |
| kens | He can practice on staff meetings :-) | 15:27.04 |
| chrisl | Y'all havin' a nice day? | 15:27.24 |
| deekej | chrisl: actually, I'm not subscribed to gs-devel mailing list. I wasn't aware of it. | 15:27.40 |
| kens | :) | 15:27.48 |
| deekej | where can I sub to it? :) | 15:27.57 |
| chrisl | deekej: It's not terribly busy..... | 15:28.04 |
| | https://ghostscript.com/cgi-bin/mailman/listinfo/gs-devel | 15:28.16 |
| | deekej: he's asking for this patch to go in: https://pastebin.com/5xDVifbP | 15:29.15 |
| | His other suggestion was just to remove that line - which I'm not totally keen on | 15:31.02 |
| | deekej: here's the entire mail (for a tiny amount of extra context): https://pastebin.com/NSH0XbsC | 15:32.42 |
| deekej | should be subscribed now :) | 15:34.12 |
| | I'll check the mailing list | 15:34.18 |
| kens | Yeah but you won't ge thte old mail | 15:34.27 |
| | Do we have an archive of that anywhere ? | 15:34.37 |
| | Though just reading Chris' pastebin is quite enough | 15:34.53 |
| chrisl | https://ghostscript.com/pipermail/gs-devel/2018-March/thread.html | 15:35.01 |
| deekej | chrisl: thanks for bringing this up | 15:38.24 |
| | I have actually stumbled upon the same problem in Fedora when I was doing a scratch-build of 9.23-rc1 | 15:38.49 |
| | I didn't have much time to investigate on this, and I thought it was caused by something specific in our build process in Fedora. | 15:39.14 |
| | but now I see that this problem was dragged in with the patch I submitted to you | 15:39.39 |
| | I haven't tested Johannes's patch, I can do it now. But it seems to be sane to me | 15:40.12 |
| | IMHO, this should be fixed before 9.23-final | 15:40.29 |
| | (release) | 15:40.32 |
| chrisl | Okay, thanks. I'll hold off applying until I hear back | 15:40.38 |
| deekej | the scratch-build on Fedora infrastructure is underway, but it doesn't look good so far | 16:01.14 |
| deekej | is investigating | 16:03.04 |
| | so far, the scratch-build has failed on s390x, ppc64 and maybe it will fail on armv7hl as well | 16:07.15 |
| | https://koji.fedoraproject.org/koji/taskinfo?taskID=25728599 | 16:07.23 |
| chrisl | big endian? | 16:07.38 |
| kens | Umm, did you get the LCMS2 art fix ? | 16:07.42 |
| chrisl | http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=124b37fc65fe665d8b4a6133142784c4edb3b3bf | 16:07.50 |
| kens | s309x is big-endian I think | 16:07.53 |
| deekej | the fail is this: | 16:08.13 |
| | ./lcms2art/src/cmsmd5.c: In function 'byteReverse': | 16:08.27 |
| | ./lcms2art/src/cmsmd5.c:36:51: error: 'ContextID' undeclared (first use in this function) | 16:08.27 |
| | cmsUInt32Number t = _cmsAdjustEndianess32(ContextID, *(cmsUInt32Number *) buf); | 16:08.27 |
| | ^~~~~~~~~ | 16:08.27 |
| | ./lcms2art/src/cmsmd5.c:36:51: note: each undeclared identifier is reported only once for each function it appears in | 16:08.27 |
| kens | Yes that's the commit above | 16:08.33 |
| | You need that commit on big-endian platforms | 16:08.46 |
| deekej | ok, but that commit is for lcms2, right? | 16:09.30 |
| kens | No.... | 16:09.36 |
| deekej | we have a separate package for lcms2 | 16:09.39 |
| kens | Our fork of LCMS2 | 16:09.43 |
| deekej | ah, ok | 16:09.48 |
| kens | If its wrong with lcms2 then that's not our problem :) | 16:10.00 |
| deekej | will this commit make it into LCMS2 upstream? | 16:10.13 |
| chrisl | Nope | 16:10.17 |
| | So, LCMS2 is not threadsafe, and has some performance problems. | 16:10.49 |
| deekej | ok, this might be a problem for Fedora :-/ I might not be able to convince LCMS2 maintainer to apply this "downstream" patch | 16:10.51 |
| chrisl | Our patches to solve these problems have been rejected upstream - so we're going to fork LCMS2 | 16:11.19 |
| deekej | is there a chance that patch could break something for other LCMS2 users? | 16:11.25 |
| kens | This bug can't be unique to us. | 16:11.30 |
| chrisl | I suspect it is unique to us | 16:11.47 |
| kens | Chrisl really ? | 16:11.54 |
| chrisl | I suspect it's related to actually being threadsafe | 16:12.06 |
| kens | But surely if CMS_USE_BIG_ENDIAN is true then this always fails | 16:12.13 |
| deekej | if it wasn't unique for you, I don't see a reason why LCMS2 wouldn't accept the patch you have | 16:12.14 |
| kens | The rejected pathces didn't include this | 16:12.36 |
| chrisl | deekej: the lack of threadsafety isn't unique, and that's been rejected, so..... | 16:12.42 |
| | deekej: if you delete the lcms2art directory, it will link to the system lcms2 - and be slower | 16:13.17 |
| kens | Ah, I thought deekej *was* using the system LCMS2 | 16:13.41 |
| chrisl | Well, then that build failure couldn't happen | 16:14.05 |
| kens | doens't know | 16:14.15 |
| chrisl | Unless the build is screwed..... | 16:14.26 |
| kens | I deleted my cms2 folder when we forked | 16:14.26 |
| | SO I can't check the LCMS2 source code | 16:14.39 |
| chrisl | If you use the system lib, we don't build the lcms2 source | 16:15.03 |
| Robin_Watts | deekej is using the lcms2art source. | 16:15.14 |
| chrisl | You link to the binary already on the system | 16:15.18 |
| Robin_Watts | You can see that from the error pasted above. | 16:15.25 |
| kens | Ah yes. | 16:15.32 |
| | So he needs to delete the folder to use the system one | 16:15.42 |
| | Which I assume Fedora will insist on doing | 16:15.55 |
| deekej | kens: yeah, I think so | 16:16.03 |
| chrisl | deekej: So, the plan is that for the *next* release, we will have a full lcms2 fork, which is threadsafe and will have performance improvements. This will get a "proper" release separate from Ghostscript/MuPDF etc | 16:16.24 |
| | Our fork will be called lcms2mt | 16:16.41 |
| deekej | I'm looking at the patch you have for this, and if I understand it correctly, this would change ABI/API compatibility, right? | 16:16.41 |
| kens | We've already changed that | 16:16.52 |
| Robin_Watts | chrisl: Right. So fedora may want to allow lcms2 and lcms2mt to be both installed as system libs. | 16:16.53 |
| chrisl | deekej: It has to for threadsafety | 16:17.05 |
| deekej | Robin_Watts: this is definitely something we would like to have FESCo look into | 16:17.26 |
| chrisl | deekej: We'll maintain backwards compatibility with lcms2 for a while - but not for ever | 16:17.53 |
| deekej | I doubt FESCo would allow to have 2 lcms2 libraries, even though one is fork of another | 16:17.54 |
| Robin_Watts | chrisl: Well, maybe not for that long :) | 16:17.56 |
| | One of the things we want to do is to strip out the "half thread safe" calls. | 16:18.24 |
| deekej | I will bring this to fedora-devel mailing list, to get feedback from other maintainers using lcms2 | 16:18.29 |
| chrisl | deekej: lcms2 is broken, and the current maintainer won't fix it (or accept our fixes for it), so..... we have little choice | 16:18.40 |
| deekej | to see if it would be possible to switch whole Fedora to lcms2mt | 16:18.42 |
| | chrisl: no problem, I totally understand | 16:19.09 |
| Robin_Watts | deekej: That would require changes in all apps that call lcms2 to make them lcms2mt compliant. | 16:19.16 |
| deekej | and I think others will see the reason behind it as well :) | 16:19.21 |
| Robin_Watts | Think of lcms2mt as lcms3 :) | 16:19.25 |
| | so having 2 different versions side by side is probably the simplest solution for greatest adoption. | 16:19.57 |
| deekej | Robin_Watts: yes, and the question what would remain is - how much rewrite would be needed? | 16:19.59 |
| Robin_Watts | Not a huge amount, but some. | 16:20.12 |
| | The calls are basically the same, with some renamed, with an extra param (which can be NULL). | 16:20.31 |
| deekej | would it be for example sufficent to create some macros for transition period which would deal with this? :) I'll have to check it :) | 16:20.44 |
| | ah, from you say it should be possible to create some macros for it | 16:21.06 |
| Robin_Watts | deekej: I wouldn't promise it. | 16:21.21 |
| | suppose we have a function: cmsDoSomething | 16:21.29 |
| | Marti attempted to retrofit threadsafety by adding cmsDoSomethingTHR | 16:21.53 |
| | (which is basically the same, but takes a ContextID * too). | 16:22.32 |
| | Our intent is to remove the cmsDoSomethingTHR calls and just have cmsDoSomething which takes the ContextID *. | 16:22.49 |
| | The bloat on the API is not desirable. | 16:23.14 |
| deekej | ah, okay | 16:30.16 |
| | I think if the Fedora was first to adopt your new LCMS2 fork, it would help significantly | 16:30.44 |
| | in that case calling it lcms3 wouldn't be a bad idea ;) | 16:30.59 |
| | once it would be in Fedora, it would sent a signal to other software out there to at least start considering switching to lcms3 | 16:31.32 |
| chrisl | No, we''re calling it lcms2mt | 16:31.39 |
| deekej | ok :) | 16:31.44 |
| chrisl | deekej: And we'll be keeping up to date with any fixes that go into lcms2 | 16:32.18 |
| deekej | regardless the name, Fedora needs to settle on a way of moving forward. I don't expect people to by trying to hold the change back, when the lcms2 has little to no support | 16:32.36 |
| | This seems like a good system-wide change that could go into Fedora 29. There's still time for it, so I'll try to jump on it next week | 16:33.45 |
| chrisl | deekej: No! It's not there yet | 16:34.02 |
| deekej | ah, yes, sorry | 16:35.05 |
| | but I will still discuss this change with people ASAP | 16:35.30 |
| | let me know once lcms2mt is officially out :) | 16:35.55 |
| chrisl | Our plan is for this happen properly in 6 months - with the next gs/mupdf releases | 16:35.58 |
| deekej | acknowledged :) | 16:36.10 |
| chrisl | We plan to manage the code, and releases on github | 16:36.35 |
| deekej | so for now, the Ghostscript on Fedora will have to built without lcms2art/ directory | 16:37.03 |
| chrisl | No, you can build as you did before - as I said, for at least a while, we're keeping compatible with lcms2 | 16:37.48 |
| | We do want to allow time for the distro wheels to grind | 16:38.17 |
| deekej | but s390x and ppc64 builds are failing for now | 16:38.43 |
| chrisl | Because you're using the lcms2art code | 16:39.01 |
| deekej | and since I won't be able to convince lcms2 maintainer to apply your patch, for those architectures the Ghostscript will have to be build without the lcms2art code, right? | 16:39.28 |
| | otherwise the build process should remain the same | 16:39.54 |
| chrisl | Somewhere you have something that removes the lcms2 directory from the Ghostscript tree - change that to remove the lcms2art directory, and it will work as before | 16:40.26 |
| deekej | ah, I see now | 16:42.45 |
| | so previously (9.22) the tarball contained lcms2/ folder | 16:43.24 |
| chrisl | deekej: Sorry, we only firmed up these plans ~2 weeks ago | 16:43.34 |
| deekej | now (9.23) it contains the lcms2art/ folder | 16:43.35 |
| | no problem :) | 16:43.41 |
| | I'm glad I understand now :) | 16:43.52 |
| | I'm gonna fix it, and try scratch build again :) | 16:44.10 |
| chrisl | So, you may want to tweek your recipe to remove lcms2* from the gs tree | 16:44.38 |
| deekej | I just did :) I'm trying the scratch-build again, lets see if there's something else :) | 16:46.45 |
| | so, the scratch build has passed for now | 17:20.00 |
| | there were some warnings from gcc - would you like to check them, chrisl? :) | 17:20.33 |
| chrisl | Were they new? | 17:20.52 |
| kens | We;'ve never been able to completely eliminate gcc warnings | 17:20.58 |
| deekej | I can't tell if they are new, I have not much to compare them with | 17:21.18 |
| chrisl | There should be many fewer warnings that with previous releases | 17:21.49 |
| deekej | few are harmless warnings about unitialized variables etc. | 17:21.58 |
| kens | Umm uninitialised variables I don't think we shold be seeing | 17:22.13 |
| deekej | if you want to check, you can do it yourself here: | 17:22.30 |
| | https://koji.fedoraproject.org/koji/taskinfo?taskID=25729410 | 17:22.45 |
| chrisl | We have a bunch because the compiler doesn't understand the usage, IIRC | 17:22.46 |
| deekej | you can select which architecture you're interested, and then click on build.log | 17:22.59 |
| | here's the x86_64 log: https://kojipkgs.fedoraproject.org//work/tasks/9411/25729411/build.log | 17:23.21 |
| | the more important warning IMHO are e.g.: | 17:24.00 |
| | ./psi/iutil.c:407:41: warning: array subscript -1 is below array bounds of 'char[256]' [-Warray-bounds] | 17:24.01 |
| | w.ptr = (byte *)buf - 1; | 17:24.01 |
| | ~~~~~~~~~~~~^~~ | 17:24.01 |
| | or | 17:24.05 |
| kens | I'm seeing unused variables, not uninitialised | 17:24.09 |
| deekej | ./devices/gdevxalt.c: In function 'gs_shared_init': | 17:24.16 |
| | ./devices/gdevxalt.c:872:26: warning: passing argument 1 of 'gs_lib_register_device' from incompatible pointer type [-Wincompatible-pointer-types] | 17:24.17 |
| | gs_lib_register_device(&gs_x11_device); | 17:24.17 |
| | kens: ah, sorry, I have possibly expressed myself incorrectly :-/ | 17:24.43 |
| kens | unused variables I would expect | 17:24.54 |
| deekej | I can see this though: | 17:25.19 |
| kens | We hvae some device methods which expect particular parameters, we *have* to pass them to all devices, even though some devices don't use them. | 17:25.19 |
| deekej | ./contrib/lips4/gdevl4v.c: In function 'lips4v_setfillcolor': | 17:25.21 |
| | ./contrib/lips4/gdevl4v.c:1142:13: warning: 'b' may be used uninitialized in this function [-Wmaybe-uninitialized] | 17:25.21 |
| | sput_lips_int(s, b); | 17:25.21 |
| | ^~~~~~~~~~~~~~~~~~~ | 17:25.21 |
| kens | 'may be used' | 17:25.28 |
| | But it isn't | 17:25.34 |
| deekej | yes, that's what I meant, it might not be true :) | 17:25.42 |
| chrisl | FWIW, there's nothing new in there | 17:25.46 |
| kens | Its not | 17:25.47 |
| chrisl | I'll keep that log as a reminder - there are a few things that we never see in our "normal" builds | 17:27.04 |
| deekej | sure, no problem | 17:27.23 |
| chrisl | mostly the x11 ones | 17:27.44 |
| deekej | if the log is gone (it might be deleted because of a scratch build), just let me know and I'll send you a new one | 17:27.46 |
| chrisl | I've saved it locally | 17:28.04 |
| deekej | okay :) | 17:28.09 |
| chrisl | Also, some gtk+ ones I should sort out - although, I don't recall seeing those when I build that stuff | 17:29.03 |
| | "configure: WARNING: unrecognized options: --disable-dependency-tracking" - that isn't our fault ;-) | 17:30.08 |
| deekej | chrisl: yeah, I checked that before :) your configure isn't using the dependency-tracking AFAICT | 17:30.35 |
| | we have that option enabled system-wide for Fedora, to speed up the one-time builds | 17:30.58 |
| | you can silently ignore it if you want, I guess :) | 17:31.20 |
| chrisl | What's the point of configure scripts if they don't check deps? That's pretty much its core purpose | 17:31.33 |
| deekej | but it's not worth the time to change it | 17:31.36 |
| | this dependency tracking is more for C/C++ headers dependencies rather the system/libs dependencies AFAICT | 17:32.19 |
| | it should help generate the Makefile's content automatically | 17:32.55 |
| chrisl | But the makefile contents are based on what dependencies are available | 17:33.28 |
| deekej | https://www.gnu.org/software/automake/manual/html_node/Dependency-Tracking.html | 17:33.37 |
| | this is what I've read about it | 17:33.45 |
| | sorry, I have to go now, I have training waiting :) | 17:34.11 |
| | bye :) | 17:34.20 |
| chrisl | Bye | 17:34.25 |
| | Ah, well, we don't use automake, so..... | 17:35.09 |
| | Forward 1 day (to 2018/03/16)>>> | |
Log of #ghostscript at irc.freenode.net.