Welcome!
Important information
-- Spectre and Meltdown vulnerabilities
-- Change in MX sources

News
-- MX Linux on social media: here
-- Mepis support still here

Current releases
-- MX-17.1 Final release info here
-- antiX-17 release info here

New users
-- Please read this first, and don't forget to add system and hardware information to posts!
-- Here are the Forum Rules

MX 15/16 Repository: The YACReader Thread

Message
Author
selmf
Forum Novice
Forum  Novice
Posts: 15
Joined: Sun Oct 08, 2017 4:22 am

Re: MX 15/16 Repository: The YACReader Thread

#11 Post by selmf » Sat Feb 17, 2018 5:49 am

The problem is that pdfium is tightly integrated into Chromium's development process, which is not very packaging friendly. The source code as a whole is spread over multiple git repositories which are managed by a tool suite called "depot tools". An official source checkout can go into the gigabytes, repo history and bundled dependencies (and their history). The tight integration also leads to other problems:

- Pdfium doesn't do releases. The closest thing to a stable version are the branches used in Chromium releases - so you need to cherry-pick them
- Same build system as Chromium (gn/ninja), but the build tool (gn) isn't bundled as it is with Chromium - that means you have to build the build tool too, which also is tightly integrated into Chromium's development process and has a tendency for broken bootstrap scripts
- Limited build options for third party users. You have to patch the source code and build system to create a shared library.
- No install routines

As you can see, packaging this is challenging and requires more than a few overrides in debian/rules.

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16937
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 15/16 Repository: The YACReader Thread

#12 Post by Stevo » Sat Feb 17, 2018 3:38 pm

Thanks for the update. It does look like a real headache. THANKS, GOOGLE. :confused:

selmf
Forum Novice
Forum  Novice
Posts: 15
Joined: Sun Oct 08, 2017 4:22 am

Re: MX 15/16 Repository: The YACReader Thread

#13 Post by selmf » Sat Feb 17, 2018 4:50 pm

Yeah, there is a reason why projects like LibreOffice just embed the source code and call it a day :) For YACReader having Pdfium as a rendering engine mostly means that we can get rid of ancient Poppler on Windows and unsteady Pdfkit on OS X. Packaging is not an issue there as we bundle all libraries anyways. Poppler support is still needed because it is widely available on Linux and forcing Pdfium would be a major show stopper for independent packagers.

Creating packages for .deb and .rpm based packages is on my todo list but it probably won't be happening before 9.0 is released.

selmf
Forum Novice
Forum  Novice
Posts: 15
Joined: Sun Oct 08, 2017 4:22 am

Re: MX 15/16 Repository: The YACReader Thread

#14 Post by selmf » Sun Feb 18, 2018 11:19 am

Version 9.0.0 is out. The official tarball still has some minor issues that will prevent building on Debian, but if you grab the tarball from my OBS account everything should work fine. Grab libunarr 1.0.1 too while you're there ;)

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16937
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 15/16 Repository: The YACReader Thread

#15 Post by Stevo » Sun Feb 18, 2018 6:34 pm

OK, thanks! I see you have the Debian testing and Debian Stretch armhf repos enabled now. ;)

Oh, the testing version didn't build because of a quirk in the OBS for testing. You can fix that by specifically listing libcomerr2 as a build-depend so it does not get hung up with a choice.

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16937
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 15/16 Repository: The YACReader Thread

#16 Post by Stevo » Sun Feb 18, 2018 7:35 pm

Hmmm...why is YACReader in the contrib section, anyway? Does it suggest a non-free package?

selmf
Forum Novice
Forum  Novice
Posts: 15
Joined: Sun Oct 08, 2017 4:22 am

Re: MX 15/16 Repository: The YACReader Thread

#17 Post by selmf » Sun Feb 18, 2018 8:18 pm

Not any more. It used to depend on p7zip as decompression backend, but that made things unnecessarily complicated. You had to download a part of the p7zip sources to build the interface for the shared library. Not very packaging friendly and it finally crumbled on us when 7zip made some bigger api changes.

Lucky for us unarr became available at that time, so we switched the Linux version to that. It's not a 100% replacement, so we still support building with 7zip, but with the release of 9.0.0 we finally made that switch for the other platforms too.

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16937
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 15/16 Repository: The YACReader Thread

#18 Post by Stevo » Sun Feb 18, 2018 8:41 pm

OK, I fixed that in the control file for the MX builds, then. It's good to see that it's totally open. The OBS doesn't pay any attention to those man/contrib/non-free sections, of course.

selmf
Forum Novice
Forum  Novice
Posts: 15
Joined: Sun Oct 08, 2017 4:22 am

Re: MX 15/16 Repository: The YACReader Thread

#19 Post by selmf » Thu Apr 19, 2018 10:18 am

Good news - I managed to create a basic pdfium package for Debian. Not very polished, just the bare necessities to make it build and possibly install.

If you're interested you can take a sneak peak at my yacreader-beta repository (https://build.opensuse.org/project/show ... eader-beta), but don't excpect too much. I haven't tested building YACReader against this yet and there are still lots of gaps to be filled till this package can be considered done. Use at your own risk ;)

User avatar
Stevo
Forum Veteran
Forum Veteran
Posts: 16937
Joined: Fri Dec 15, 2006 8:07 pm

Re: MX 15/16 Repository: The YACReader Thread

#20 Post by Stevo » Thu Apr 19, 2018 1:21 pm

Awesome! I'll check it out, and try to reproduce the build.

I see some "gn" builds failed because of no debhelper 10, but you can get that and dh-autoreconf from jessie-backports and add that for the affected distros, allowing for the fact that the OBS doesn't allow the "+" symbol in a version for some quirky reason...I just edit the version in the changelog to "~bpo8".

I'd also suggest that if pdfium is a shared library, the package names be changed to libpdfium* to be in accord with Debian policy.

Post Reply

Return to “Package Requests/Status - MX-15/16”