Added ebuilds for 1.12 and upcoming 1.13 version.

[jeeger]

As discussed, new ebuilds for 1.12 and upcoming 1.13.

[dannyedel]

Thank you for adding these!

I'd only like to request one change. v1.13 and up will be able to tell their own version number, so no more telling it -DDSPDFVIEWER_VERSION=xxx required (only you want to make it something like v1.13-jeeger1, but unless you have source-changes I don't see the point in that).

This should™ allow you to drop the entire local mycmakeargs making my software compilation perfectly boilerplate.

fyi: The relevant commit making this work is 29837fe4ced130b2d9ddbd5692466860097e9eac

[jeeger]

There we are, this should work. I'm not entirely sure though, so I'll test it when 1.13 is out. Could you leave the PR open until then?

[dannyedel]

Sure, no problem.

As soon as I've merged my debian-cleanup branch, I'll do some more final testing, but I think it's ready to be called v1.13 later today.

[dannyedel]

v1.13 is released now.

[dannyedel]

for your information, I've written an article about reproducing the checksum of the github tarball (just scroll to the end for quick instructions), in case you want to add checksums for the tarball download.

[dannyedel]

Hi, just a heads-up: In the meantime I've had to release v1.13.1 fixing a regression introduced in 1.13. (Good that gentoo hasn't updated yet : )

If you want to test building from tarballs, you can use https://github.com/dannyedel/dspdfviewer/archive/HEAD.tar.gz as a source. This tarball should not contain any dist-specific files since dc76a28 (will be in v1.14), that also means it won't contain the gentoo/ or debian/ subdirectories again, looking like a clean distro-independent upstream tarball.

If you clone from git (like you do on the -9999 build) those directories will be included (and git describe spits out a version), but I think that's allright and expected (I use the debian/ directory from git so I can just call debuild to spit out a binary)

If you build from tarball source, I'd ask you to adjust your cmake step as follows: If you do not add any patches, you can simply call cmake without a version argument, and use the default program verison (Or specify the version again, you choose). In addition, cmake should automatically import any CFLAGS and CXXFLAGS the user has set in his environment, so compiler optimisations should work. If you add any gentoo-specific patches, please use -DDSPDFVIEWER_VERSION=v1.13.1-r1 or something similar, just to clarify its a patched source.

My official Debian packages use the 1.13.1-1 format, so if we can keep it slightly different between the distributions, the version number alone encodes information about the build system : )

[dannyedel]

Hi @jeeger,

since this pull-request was opened, I have released v1.13 (and a few days later, v1.13.1 since it contained a bug). So I won't merge this PR into the codebase, just to overwrite it later.

However, by working on Debian I have since learned a few things about packaging, and it now seems to me like a really bad idea to include dist-specific code into the actual upstream git repo.... Once I figure out how to make jenkins build installable deb's without having a debian/ directory that will be gone aswell.

---

So if we can somehow™ set this up, It'd be nice to have the gentoo ebuilds in some other repository (preferrably one installable via layman).

If you search "gentoo dspdfviewer" in google, gpo.zugaina.org is one of the first results, and it suggests that two overlays in gentoo (andy and betagarden) already contain an (although outdated) ebuild. Maybe contacting their authors might be the better course of action, to reduce duplication of efforts.

It would be cool if dspdfviewer in gentoo could be bumped to v1.13.1 (current stable) in any case. If we manage to move the ebuild out of the source repository into something (like a small git repo on your github acc, or a layman-overlay) where you have full write access without going through me, it would be even better.