| | <<<Back 1 day (to 2016/11/15) | 20161116 |
| Malav | Hi | 01:27.42 |
| ghostbot | Welcome to #ghostscript, the channel for Ghostscript and MuPDF. 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. | 01:27.42 |
| Malav | What is ghostscript actuallyð
| 01:28.30 |
| tor8 | Robin_Watts: fixes for 697334 and 697335 and a few other commits on tor/master | 11:13.22 |
| Robin_Watts | looking | 11:14.46 |
| | tor8: sebras had some commits he wanted you to look at. | 11:15.04 |
| | (I looked and was happy, but he wanted your OK too, I think) | 11:15.13 |
| tor8 | ugh, openssl! can't we purge it with fire instead? :) | 11:15.58 |
| Robin_Watts | tor8: Still no API comments on these functions. | 11:16.01 |
| tor8 | "Retain only necessary files for curl support." I'd like for the file list to be sorted | 11:16.16 |
| | and I'd like to hear why we should call it libcrypto rather than openssl? just because the library file is libcrypto, but the project name and product is still openssl? | 11:17.05 |
| Robin_Watts | tor8: Your commits lgtm. | 11:18.41 |
| tor8 | Robin_Watts: thanks. | 11:29.12 |
| Robin_Watts | tor8: http://git.ghostscript.com/?p=user/robin/mupdf.git;a=commitdiff;h=96142ee64e9b0101e042c79dd21e8d83b453c844 | 12:18.17 |
| tor8 | Robin_Watts: LGTM | 12:24.25 |
| Robin_Watts | tor8: So, where do we stand on a release | 12:25.23 |
| | ? | 12:25.25 |
| tor8 | I think that fixes the last of the reported issues. | 12:25.52 |
| Robin_Watts | tor8: So rc2 or release ? | 12:26.04 |
| tor8 | sebras has a few commits, but I don't know if he expects to get those in | 12:26.11 |
| Robin_Watts | (just waiting for a cluster run to finish) | 12:26.13 |
| tor8 | what do you think? an rc2 would be safer, but we're late enough as it is... | 12:26.33 |
| Robin_Watts | Updating curl would be nice. | 12:26.39 |
| tor8 | (though the only one who cares is miles) | 12:26.44 |
| | we could cherry pick the crash fixes and put them on a branch for 1.10 | 12:26.57 |
| | to minimize the risk | 12:27.01 |
| Robin_Watts | the VS solution fixes should be taken too. | 12:27.25 |
| tor8 | personally, I'd make an rc2 with what we have on origin/master now | 12:27.46 |
| Robin_Watts | Ah, you pushed "js: Update docs for annotation functions (WIP)." | 12:28.04 |
| tor8 | yeah, the annotation functions are WIP :) | 12:28.17 |
| Robin_Watts | presumably that either shouldn't have gone, or should not have been labelled as WIP ? | 12:28.18 |
| tor8 | but yeah, should've dropped the WIP label | 12:28.27 |
| | but if miles and/or henry are itching for a release, cherry picking the vitals and doing a 1.10 from that and skipping an rc2 is fine by me | 12:28.54 |
| Robin_Watts | I would be tempted to release off a branch, and just cherry pick the 'fixes', yes. | 12:29.05 |
| | tor8: Want me to make a release branch, or do you want to? | 12:32.04 |
| tor8 | Robin_Watts: I've done a bit of cherry-picking on tor/release | 12:34.28 |
| | needed to patch up one or two commits | 12:34.36 |
| | but we did end up with the majority of commits | 12:34.44 |
| | System.loadLibrary(getLibraryName()) ... would it not be simpler to do a chain of try/catch blocks trying to load mupdf_java64, mupdf_java32, mupdf_java in sequence? | 12:36.12 |
| | rather than worry about runtime system name checks, etc | 12:36.28 |
| Robin_Watts | tor8: That was one option I pondered with fred yesterday. | 12:36.34 |
| tor8 | I would prefer that, I think. it'd be more robust for future changes. | 12:36.48 |
| Robin_Watts | You didn't take the page coords/link target stuff. | 12:37.08 |
| tor8 | I did not. if we take that, we might as well take the whole origin/master branch. | 12:37.21 |
| | since there are only about 4-5 commits that we'd leave behind | 12:37.35 |
| | I think it would be good to have the page coord/link target stuff in the release | 12:37.54 |
| Robin_Watts | That's important for epub links to go to the right place, yes? | 12:38.13 |
| tor8 | it's important for links to scroll to the correct spot on the page. nothing we use, but apparently more customers use it than I anticipated. | 12:38.59 |
| | we'd leave behind fred's android viewer improvements, the layer config stuff and some api cleanups you did | 12:39.53 |
| Robin_Watts | The layer stuff was actually customer driven, so there is an argument for getting that in. | 12:46.16 |
| | (and it shouldn't affect any existing users). | 12:46.34 |
| | So maybe best to just do a quick rc2 of what we have? | 12:46.44 |
| tor8 | Robin_Watts: yeah. | 12:48.18 |
| | Robin_Watts: actually, one more quick fix on tor/master | 12:49.01 |
| | something malc brought up, and it would be in keeping with the link target rework | 12:49.22 |
| Robin_Watts | lgtm. | 12:59.32 |
| | So we need to sort sebras' curl fixes, and then we're good to go. | 12:59.54 |
| Robin_Watts | foods. | 12:59.57 |
| malc_ | source/pdf/pdf-page.c:204:1: error: conflicting types for âpdf_lookup_anchorâ | 14:47.18 |
| | pdf_lookup_anchor(fz_context *ctx, pdf_document *doc, const char *name, float *xp, float *yp) | 14:47.18 |
| | ^~~~~~~~~~~~~~~~~ | 14:47.18 |
| | In file included from include/mupdf/pdf.h:17:0, | 14:47.18 |
| | from source/pdf/pdf-page.c:1: | 14:47.21 |
| | include/mupdf/pdf/page.h:14:5: note: previous declaration of âpdf_lookup_anchorâ was here | 14:47.24 |
| | int pdf_lookup_anchor(fz_context *ctx, pdf_document *doc, const char *name, int *xp, int *yp); | 14:47.27 |
| | ^~~~~~~~~~~~~~~~~ | 14:47.30 |
| | | 14:47.34 |
| | diff --git a/include/mupdf/pdf/page.h b/include/mupdf/pdf/page.h | 14:50.39 |
| | index 976b25b..f09e926 100644 | 14:50.39 |
| | --- a/include/mupdf/pdf/page.h | 14:50.39 |
| | +++ b/include/mupdf/pdf/page.h | 14:50.39 |
| | @@ -11,7 +11,7 @@ pdf_obj *pdf_lookup_page_obj(fz_context *ctx, pdf_document *doc, int needle); | 14:50.39 |
| | For use with looking up the destination page of a fragment | 14:50.39 |
| | identifier in hyperlinks: foo.pdf#bar or foo.pdf#page=5. | 14:50.39 |
| | */ | 14:50.39 |
| | -int pdf_lookup_anchor(fz_context *ctx, pdf_document *doc, const char *name, int *xp, int *yp); | 14:50.39 |
| | +int pdf_lookup_anchor(fz_context *ctx, pdf_document *doc, const char *name, float *xp, float *yp); | 14:50.39 |
| | | 14:50.39 |
| | /* | 14:50.39 |
| | pdf_flatten_inheritable_page_items: Make page self sufficient. | 14:50.39 |
| | | 14:50.40 |
| Robin_Watts | malc_: oops. Thanks. tor8 - do you want to handle that? | 14:54.10 |
| tor8 | d'oh! | 15:08.41 |
| | Robin_Watts: shall we force push a fix? | 15:09.11 |
| Robin_Watts | If you want. | 15:09.27 |
| tor8 | okay, force pushed. can you fix the cluster if it gets hickups? | 15:10.15 |
| Robin_Watts | tor8: will do so now. | 15:10.31 |
| tor8 | Robin_Watts: thanks. | 15:10.57 |
| malc_ | nasty... but well, i have only myself to blame | 15:12.58 |
| sebras | tor8: please re-review sebras/master (now sorted file list and the OTHER variable removed) | 17:14.42 |
| Robin_Watts | sebras: Did you see tor8 querying the change of name from openssl to crypto? | 17:15.14 |
| tor8 | Robin_Watts: yes. he replied privately. | 17:15.40 |
| Robin_Watts | ah, right, cool. | 17:15.55 |
| sebras | Robin_Watts: yes, the reason is that the openssl project provides two libraries, libcrypto and libssl. I name the variables after the libraries. | 17:15.55 |
| | for pkcs we only need libcrypto, for https using curl we also need libssl. | 17:16.06 |
| tor8 | sebras: LURATECH_LIBS etc are still not sorted | 17:16.16 |
| sebras | types to much and too slowly. | 17:16.19 |
| | tor8: ah! | 17:16.56 |
| tor8 | other than that, LGTM | 17:17.02 |
| sebras | tor8: resorted. | 17:17.42 |
| tor8 | sebras: speaking of libcrypto etc names | 17:18.28 |
| | sebras: we have JPEG_LIBS and JPEG_CFLAGS, not LIBJPEG_LIBS | 17:19.15 |
| | maybe we should be calling it CRYPTO_LIBS and CRYPTO_CFLAGS? | 17:19.24 |
| | or the other way round | 17:19.48 |
| sebras | CRYPTO_* would work for me. | 17:20.17 |
| | tor8: but still HAVE_LIBCRYPTO? or HAVE_CRYPTO? | 17:21.23 |
| | I'd vote for the first one. | 17:22.18 |
| tor8 | sebras: hm. let's just leave it as is. | 17:22.42 |
| sebras | tor8: LIBCRYPTO_LIBS too? | 17:27.17 |
| tor8 | yeah. your commits as on sebras/master now. | 17:30.56 |
| | are good to push, IMO. | 17:31.06 |
| | and then we can do a quick 1.10-rc2 | 17:31.21 |
| sebras | pushes. | 17:32.45 |
| unexperiencedUse | hello, not sure if anyone is there i'm on my phone and the mobile view of this page is pretty bad (as i expected haha). sorry if i'm not supposed to ask this type of question on here but i'm basically a noob who doesn't know the differences between several apk for the same app, such as MuPDF. Which one should i dl? my device is a galaxy j5 running android 5.1.1 | 17:37.58 |
| sebras | unexperiencedUse: we do publish mupdf on the Google Play store, if you install the mupdf from there it will automagically choose the correct version for you. furthermore you will get updates when we publish them. | 17:40.23 |
| | Robin_Watts: cortex a53 is armv8, but I assume it would be ok with the v7a apk..? | 17:41.07 |
| unexperiencedUse | i wish not to use my google acc on this phone | 17:41.08 |
| Robin_Watts | sebras: I hope so. | 17:41.53 |
| | I would certainly expect it to be fine. | 17:42.05 |
| sebras | unexperiencedUse: aha, in that case try the apk named armeabi-v7a. | 17:42.06 |
| | Robin_Watts: the non-v7 is... v6? | 17:42.40 |
| Robin_Watts | sebras: I'm following googles ABI naming scheme there. | 17:43.29 |
| unexperiencedUse | ok tyvm | 17:43.29 |
| sebras | Robin_Watts: right, so v6. good to know. :) | 17:44.55 |
| | Robin_Watts: apparently there is arm64-v8a too, is that something we should build 1.10 for..? | 17:45.15 |
| Robin_Watts | I *hope* that 64bit phones can still run 32bit apps. | 17:45.53 |
| | Forward 1 day (to 2016/11/17)>>> | |
Log of #ghostscript at irc.freenode.net.