Can't open file from .cache folder

[budinero]

When printing a file to boomaga, it shows the following error message "I can't open file '/home/user/.cache/boomaga_tmp_xxxxx.pdf'". In the folder .cache there is an empty folder named "boomaga_tmp_xxxxx.pdf" (with the .pdf extension) and a .pdf file called boomaga_in_file_yyy[yy].pdf after the error.

[SokoloffA]

Perhaps I found the problematic line QDir().mkpath(outFileName + "/.."); https://github.com/Boomaga/boomaga/blob/master/gui/pdfmerger/pdfmerger.cpp#L381

To check I need to repeat the problem. Which distribution are you using? How do you install the program, from source or a package?

[budinero]

Hi, I'm using Arch, the package is from AUR repository, installed and compiled from https://github.com/boomaga/boomaga/archive/v0.9.0.tar.gz. Y tried reinstalling again after last qt/kde updates, but the problem persists.

[SokoloffA]

Oh, installing Arch is pain. If you install the program from AUR, you already have all dependencies. Please, comment this line and build program from source. After that replace /usr/lib/boomaga/boomagamerger or /usr/local/lib/boomaga/boomagamerger on new version.

[budinero]

Thanks! I can't reproduce the problem with boomagamerger compiled from source, even without commenting line 381. Could it be related to the AUR package build/make options? The package configuration PKGBUILD is https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=boomaga-qt5

[SokoloffA]

Sorry for long silence.

The only option that can affect is -DUSE_QT5=Yes. Do you compiled for Qt4 or Qt5? For buid Qt5 version, use -DUSE_QT5=Yes option for cmake. Step by step:

$ cd <directory_with_source>
$ mkdir build && cd build
$ cmake -DUSE_QT5=Yes ..
$ make

[budinero]

I thought that Qt5 was the default. I can confirm that the problem appears only with boomaga compiled for Qt5 and that removing line 381 solves the issue.

[SokoloffA]

removing line 381 solves the issue.

It's good. Today I'll make new version.

[SokoloffA]

@budinero Please test the fixed version from git.

[budinero]

I edited the PKGBUILD from the AUR to point to the master git archive and it is working well now. Thanks!

[SokoloffA]

I'll make a new release ASAP.

[SokoloffA]

Done.

[koyudalex]

I have the same issue.

===== /usr/lib/x86_64-linux-gnu/boomaga/boomagamerger: symbol lookup error: /usr/lib/x86_64-linux-gnu/boomaga/boomagamerger: undefined symbol: _ZN6PDFDoc11writeObjectEP6ObjectP9OutStreamP4XRefjPh14CryptAlgorithmiii "I can't read file '/home/akoiuda/.cache/boomaga_tmp_15049-1.pdf' Unknown error" /usr/bin/lpr: No file in print request.

[SokoloffA]

For Ubuntu guys

Hi guys, I made the packages for different versions of Ubuntu and published they on ppa. I forced versions of libpoppler-dev. I hope this will solve our problems. Please leave feedback - is in your distributions the program works or not.

---

For Mint guys

Kick your maintainers, about to upgrade the package and specify depends like:

libpoppler-dev (>= 0.44.0-3ubuntu2.1)

Versions for different libpopplerXX can be found in .dsc files on my ppa

[koyudalex]

It works! Thanks much!

[frohro]

I'm running Ubuntu 17.04, and had the issue with the packaged version. I then built from source with Qt5, and tried, but it was missing some configuration files, so I installed the package version again, and now using the packaged setup and the compiled from source executable in /usr/local/bin it works.

[dajare]

I'm running Ubuntu (Gnome) 17.10, and I'm still getting this problem.

I installed with sudo apt install boomaga and have ended up with Boomaga 0.7.1. I added the ppa:boomaga/ppa repository, and updated, but I'm still not getting the 0.9.1 version that I can see in the ppa.

If I can do anything to help debug, please let me know! (I used Boomaga on a 16.04 LTS machine (no longer available to me) and was very grateful to have the program!)

[SokoloffA]

I built 0.9.1 for Ubuntu 17.10

[dajare]

@SokoloffA Thanks! I got the update this morning -- all good now. :)

[SokoloffA]

I'm glad.

[perezmeyer]

If 0.9.1 has the fix it should be already available in Debian experimental. I'm not currently pushing it to unstable due to the ongoing poppler transition, but I might ask for an exception.

[SokoloffA]

In this topic is discussed 2 problems.

1. Small problem described budinero in the first post. I easily fixed it in June. Release 0.9.1 hasn't this bug.

2. The problem with libpoppler. Boomaga has no errors, the problem is in the libpoppler. My English is ugly, but I'll try to explain the situation.

Until 3 Jul 2017 the libpoppler had a public function with following signature

void PDFDoc::markDictionnary (
    Dict* dict, 
    XRef * xRef, 
    XRef *countRef, 
    Guint numOffset, 
    int oldRefNum, 
    int newRefNum)

3rd July Albert Astals Cid added seventh optional parameter

void PDFDoc::markDictionnary (
    Dict* dict, 
    XRef * xRef, 
    XRef *countRef, 
    Guint numOffset, 
    int oldRefNum, 
    newRefNum int, 
    std::set<Dict*> *alreadyMarkedDicts)

Since the parameter is optional, he doesn't broke the API. But he broke the ABI (Application binary interface) But this is not the main problem, the problem is that this fix as a patch included in libpoppler-0.41.0-0ubuntu1.2 (and perhaps in some other distributives) But the library version was not changed!

So the program built with the old version of the library are incompatible with the new version of the library, and vice versa. But, as the library version hasn't changed, I can't determine in the code what version is used, with six parameters or seven.

Really the fix doesn't require code changes, all we need is rebuild the program with the new library. For ubuntu I do it, and published as boomaga - 0.9.1-2.

As I see Debian don't use poppler 0.41. And I don't found such patch in changes.

• wheezy use 0.18.4
• wheezy-backports - 0.26.5
• jessie - 0.26.5
• stretch - 0.48.0
• buster - 0.57.0
• sid - 0.57.0

P.S. This issues have some else information, that may be useful.

• compatibility with poppler #52
• Boomaga window doesn't display document #53

[perezmeyer]

Strictly speaking PDFDoc::markDictionnary is part of poppler's private headers (part of the libpoppler-private-dev package) so they do not need a SONAME bump but they should have rebuilt whatever uses poppler's private headers, as boomaga does.

[SokoloffA]

I don't make claims. I know that it's included in the private package. But, unfortunately, the public API of the poppler is very limited. It only allows to render a PDF, but I need to change the content of a PDF, and this can only be done through the poppler private functions.

Strictly speaking it is not the fault of the libpoppler developers. They often change the API, but always bump soname.

Compatibility broken by Ubuntu maintainers. But they were in a difficult position, they cannot change the upstriam version, they can only change the release number (I mean number after dash). And they did it, but build system can determine only soname of the library, no the release number.

I wait in fear, when one of the main distributives will remove private headers of libpoppler. So, I plan to remove the use of private poppler functions, and write your own PDF processor from scratch, but it require a time.