Patch to create debian packages

[jlaba]

Hello,

please find attached a set of debian files, to create debian packages for the V230_G2 and the EPD.py file. The patches (found in debian/patches) improve the Makefiles to support DESTDIR (installation into a specified folder, which is needed to package) and also create a setup.py file to create the python package. They are applied during the build process automatically.

It would be very nice, if you integrate the files (and apply the patches to your repository) into your repository. You may want to improve the packaging, to build a package per PANEL_VERSION. To do this, you need to support out of source builds and add the relevant packages to the debian/control file.

If you have any questions, feel free to ask me!

Kind regards!

P.s.: I'm not able to upload the zip file, but you find the files at https://trac.falaba.de/gnuboat/browser/externals/epaper-driver

[hxw]

Would it be possible for you to make a fork and issue a pull request for the changes?

[jlaba]

I created a fork and integrated the debian packaging. The packages could be build directly from the git repository. To do that, I splitted the changes up into two parts (see Chapter No upstream tarballs at http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM-GIT for an explanation).

All changes made to the upstream sources, are contained in my pull request from above.

All new code only needed to build the debian packages (all stuff within the debian folder) is located at a new branch called debian/jessie, as I prepared the package for current stable release of debian. If you adapt this structure, the workflow for updating the debian package would be:

• Making changes on your master
• Merge wanted changes into the debian/jessie branch
• checkout the debian/jessie branch
• use gbp to build the packages with

gbp buildpackage --git-pristine-tar --git-pristine-tar-commit --git-upstream-tag='v%(version)s' --git-debian-branch=debian/jessie --git-export-dir=/tmp/build-area -us -uc

• if everything is ready for a release, commit the pristine tarball and tag the release (have a look at the link above for the commands)

If you want to support a new debian version (like old version wheezy or next version stretch) just create a new debian/XXX branch from debian/jessie and make the changes there.

Do you like to use this workflow? Than you may create a new branch called debian/jessie from merged master and I create a new pull request to merge my debian/jessie branch into yours.

Regards!

[hxw]

I created a branch called debian/jessie, is that sufficient for you to send request?

[hxw]

Thanks for the changes. Is the workflow above well known? or would it be useful to put you workflow (and gbp command) from your comment above into a README-Debian.md file?

[shawaj]

this has broken a lot of the documentation FYI and none of it actually works to build on RPi anymore.

What do we need to change to build on RPi?

[jlaba]

Hello,

@hxw: It may be known to people familiar with debian packaging. But it should be documented for all others (who are the majority I think)

@shawaj:
Executing the following steps (replacing the variables with your needed values) in the toplevel directory should work:

Compile:

make PANEL_VERSION=$(PANEL_VERSION) PREFIX=$(PREFIX) DESTDIR=$(DESTDIR) SERVICE=$(SERVICE) rpi-epd_fuse

make PANEL_VERSION=$(PANEL_VERSION) PREFIX=$(PREFIX) DESTDIR=$(DESTDIR) SERVICE=$(SERVICE) rpi-install

The last step might not setup the systemd/init script correctly.

Regards!

[shawaj]

@jlaba - hmm. what is prefix and destdir and service supposed to be to keep it exactly the same as before?

we used to be able to install very simply with:

git clone https://github.com/repaper/gratis.git

cd /tmp/epd/gratis
make rpi PANEL_VERSION=V231_G2
sudo make rpi-install PANEL_VERSION=V231_G2
sudo service epd-fuse start

what is the process now? I am currently getting:

make: *** No rule to make target 'rpi-install'. Stop.

[shawaj]

@jlaba - also, why won't it setup the systemd/init script correctly? And how do we do that?

What was the reason for breaking this?

[jlaba]

Actually I followed exectly your steps:

git clone https://github.com/repaper/gratis.git
cd gratis
make rpi PANEL_VERSION=V231_G2

finished successfully. DESTDIR and PREFIX allows the user to install it in a defined subdirectory or tree (like /usr/local) as proposed by the make guide.

Related to the service install part I need to have a look again. I post my thoughts on wednesday.

Regards!

[shawaj]

Make rpi-install doesn't work though, which is important.

Why wasn't this tested before breaking it?

Thanks for looking into it though

On 5 Sep 2016 6:57 pm, "jlaba" [email protected] wrote:

Actually I followed exectly your steps:

git clone https://github.com/repaper/gratis.git
cd gratis
make rpi PANEL_VERSION=V231_G2

finished successfully. DESTDIR and PREFIX allows the user to install it in
a defined subdirectory or tree (like /usr/local) as proposed by the make
guid.

Related to the service install part I need to have a look again. I post my
thoughts on wednesday.

Regards!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#47 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADNCukCpgX9iPYuL5zX7DiPgKyoWsjEbks5qnFgXgaJpZM4JPx1F
.

[jlaba]

Good Afternoon,

you might have a look at https://github.com/jlaba/gratis.git. I have fixed an error creating the directories during installation. I haven't tested the test target, as I do not have the device installed currently. If you find any other errors, feel free to post them. Otherwise I create a merge request.

The installation does add the daemon to a runlevel. But I think this should be done by the user, if he wants it or at least should be handled in a different target.

Regards!