Xilinx-CNS / tcpdirect

AMD TCPDirect ultra low latency kernel bypass TCP and UDP implementation for AMD Solarflare network adapters, to be used with corresponding versions of Onload®️ at https://github.com/Xilinx-CNS/onload. The stable branch is currently `v8_1`.
22 stars 17 forks source link

ON-15664: Produce debian source package #43

Closed tcrawley-xilinx closed 2 months ago

tcrawley-xilinx commented 2 months ago

This PR adds a new script zf_mksrc which creates a tarball that is then used to create the deb package. This tarball can also be archived in the CI pipeline as a record of the source code that isn't either an rpm or deb (though there are current discussions as to whether this is desirable or not).

onload_make_official_deb has been updated to take a tarball created by zf_mksrc and produce a debiansource tarball/package from this.

The deb creation process is quite similar to the onload script.

I had a quick look at changing debian-templ -> debian, but I couldn't think of a nice way to avoid using #VERSION# in the rules file.

There are some potential improvements such as using dch in zf_make_official_deb to generate a changelog with an appropriate version number at package creation time. I want to think build solution that doesn't use zf_mkdist, but I don't think that blocks these changes so I'll raise it as a future PR.

See Xilinx-CNS/onload_internal#1702 for details of onload-dev package.

TODO:


[1/3] ON-15945: Look for installed libraries in debian-ish paths

[2/3] ON-15664: Produce debian source packages

[3/3] ON-16081: Update ReleaseNotes and README with new deb instructions


Testing done

Manually created and installed packages on ubu24.04

TODO:

tcrawley-xilinx commented 2 months ago

Didn't mean to include any changes to ci/ yet. Please ignore for the time being

tcrawley-xilinx commented 2 months ago

jenkins CI updated to now produce a debian source package. Also updated build requirements so it needs onload, onload-dev and build-essential. For some reason we don't provide a nice virtual package from the onload deb, so it uses an OR of all the possible onload and onload-dev variations. It would be nice to improve this, but I don't think it is essential.