seladb
Providing DEB
Added a new build-deb job to build a Debian package (.deb) for PcapPlusPlus on ubuntu-latest.
The job:
- Checks out the source code.
- Installs required dependencies (cmake, make, g++, libpcap-dev).
- Builds and installs the project into a staged directory.
- Creates a proper DEB control file using the release tag as version.
- Builds the .deb package.
Issue: #1498
Codecov Report
:white_check_mark: All modified and coverable lines are covered by tests.
:white_check_mark: Project coverage is 83.46%. Comparing base (8b1a9a5) to head (27ebe4d).
:warning: Report is 4 commits behind head on dev.
Additional details and impacted files
@@ Coverage Diff @@
## dev #1831 +/- ##
==========================================
- Coverage 83.46% 83.46% -0.01%
==========================================
Files 311 311
Lines 54568 54559 -9
Branches 11808 11507 -301
==========================================
- Hits 45545 45535 -10
+ Misses 8313 7827 -486
- Partials 710 1197 +487
| Flag | Coverage Δ | |
|---|---|---|
| alpine320 | 75.89% <ø> (-0.01%) |
:arrow_down: |
| fedora42 | 75.46% <ø> (+<0.01%) |
:arrow_up: |
| macos-14 | 81.58% <ø> (ø) |
|
| macos-15 | 81.57% <ø> (-0.02%) |
:arrow_down: |
| mingw32 | 70.00% <ø> (ø) |
|
| mingw64 | 69.98% <ø> (+0.11%) |
:arrow_up: |
| npcap | ? |
|
| rhel94 | 75.47% <ø> (-0.01%) |
:arrow_down: |
| ubuntu2004 | 59.48% <ø> (+0.01%) |
:arrow_up: |
| ubuntu2004-zstd | 59.59% <ø> (+0.01%) |
:arrow_up: |
| ubuntu2204 | 75.41% <ø> (-0.01%) |
:arrow_down: |
| ubuntu2204-icpx | 57.85% <ø> (ø) |
|
| ubuntu2404 | 75.51% <ø> (+0.01%) |
:arrow_up: |
| ubuntu2404-arm64 | 75.54% <ø> (-0.01%) |
:arrow_down: |
| unittest | 83.46% <ø> (-0.01%) |
:arrow_down: |
| windows-2022 | 85.41% <ø> (+0.16%) |
:arrow_up: |
| windows-2025 | 85.44% <ø> (+0.11%) |
:arrow_up: |
| winpcap | 85.44% <ø> (-0.09%) |
:arrow_down: |
| xdp | 52.99% <ø> (ø) |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
@seladb @Dimi1010 Extremely sorry. Looks like my code has flaws in it. As I am a beginner in open source, I am making many mistakes. I will, for sure resolve the issues and also work on your suggestions.
@bhaskarbhar No worries about the flaws. That is why the reviews are for. Ty for the effort. :)
@bhaskarbhar why did you close the PR? 🤔
As there were many flaws I thought to go through the package.yml and correct it rather than commiting everytime. Wanted to do a fresh PR with no flaws
@Dimi1010 Removed Test, corrected indentation. The build-deb check in Package and Release are passed.
@clementperon @egecetin @tigercosmos I'm not an expert in this domain, maybe you can also take a look? @Dimi1010 already approved
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
Looking into it.
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
I found this in CmakeLists.txt:
if("${DISTRO_ID}" STREQUAL "ubuntu")
# set(CPACK_GENERATOR ${CPACK_GENERATOR};DEB)
endif()
According to you suggestion, I will remove the comment from CmakeLists and rebuild the build-deb job.
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
I found this in CmakeLists.txt:
if("${DISTRO_ID}" STREQUAL "ubuntu") # set(CPACK_GENERATOR ${CPACK_GENERATOR};DEB) endif()According to you suggestion, I will remove the comment from CmakeLists and rebuild the build-deb job.
Exactly then maybe the actual package pipeline need some rework but not much I think.
Also there should be two deb generated. One for the dev package and one for the runtime.
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
I found this in CmakeLists.txt:
if("${DISTRO_ID}" STREQUAL "ubuntu") # set(CPACK_GENERATOR ${CPACK_GENERATOR};DEB) endif()According to you suggestion, I will remove the comment from CmakeLists and rebuild the build-deb job.
Exactly then maybe the actual package pipeline need some rework but not much I think.
Also there should be two deb generated. One for the dev package and one for the runtime.
Dev and runtime??? Two deb?? I need clarification in this. I have only updated the CmakeLists and package.yml for now. Please guide me as I am unable to understand what are the requirements now.
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
I found this in CmakeLists.txt:
if("${DISTRO_ID}" STREQUAL "ubuntu") # set(CPACK_GENERATOR ${CPACK_GENERATOR};DEB) endif()According to you suggestion, I will remove the comment from CmakeLists and rebuild the build-deb job.
Exactly then maybe the actual package pipeline need some rework but not much I think. Also there should be two deb generated. One for the dev package and one for the runtime.
Dev and runtime??? Two deb?? I need clarification in this. I have only updated the CmakeLists and package.yml for now. Please guide me as I am unable to understand what are the requirements now.
I think that's why I didn't enable it yet. A library have multiple usualy two components the "release" and the "dev". E.g: when you do "sudo apt install libpcap" != "sudo apt install libpcap-dev" This should be similar with deb.
- One "libpcapplusplus" for final user with only ".so"
- and one "libpcapplusplus-dev" for dev user with "Cmake files and .h"
- we could also have one "libpcapplusplus-staticdev" for dev that want static libraries ".a"
@seladb @Dimi1010 at the moment only uncomment the # CPACK_DEB will generate also bin, cmake and .h. i think we should clean a bit this before activating the Deb generator. Also IMO final user except shared libraries no ?
You can find .deb example here: https://github.com/clementperon/PcapPlusPlus/releases/tag/25.06
tree
.
├── bin
│ ├── Arping
│ ├── ArpSpoofing
│ ├── BenchmarkExample
│ ├── BenchmarkExampleGoogle
│ ├── DNSResolver
│ ├── DnsSpoofing
│ ├── HttpAnalyzer
│ ├── IcmpFileTransfer-catcher
│ ├── IcmpFileTransfer-pitcher
│ ├── IPDefragUtil
│ ├── IPFragUtil
│ ├── PcapPrinter
│ ├── PcapSearch
│ ├── PcapSplitter
│ ├── SSLAnalyzer
│ ├── TcpReassembly
│ └── TLSFingerprinting
├── include
│ └── pcapplusplus
│ ├── ArpLayer.h
│ ├── Asn1Codec.h
│ ├── BgpLayer.h
│ ├── CiscoHdlcLayer.h
│ ├── CotpLayer.h
│ ├── DeprecationUtils.h
│ ├── Device.h
│ ├── DeviceListBase.h
│ ├── DhcpLayer.h
│ ├── DhcpV6Layer.h
│ ├── DnsLayerEnums.h
│ ├── DnsLayer.h
│ ├── DnsResourceData.h
│ ├── DnsResource.h
│ ├── EthDot3Layer.h
│ ├── EthLayer.h
│ ├── FtpLayer.h
│ ├── GeneralUtils.h
│ ├── GreLayer.h
│ ├── GtpLayer.h
│ ├── HttpLayer.h
│ ├── IcmpLayer.h
│ ├── IcmpV6Layer.h
│ ├── IgmpLayer.h
│ ├── IpAddress.h
│ ├── IpAddressUtils.h
│ ├── IPLayer.h
│ ├── IPReassembly.h
│ ├── IPSecLayer.h
│ ├── IpUtils.h
│ ├── IPv4Layer.h
│ ├── IPv6Extensions.h
│ ├── IPv6Layer.h
│ ├── Layer.h
│ ├── LdapLayer.h
│ ├── LinuxNicInformationSocket.h
│ ├── LLCLayer.h
│ ├── Logger.h
│ ├── LRUList.h
│ ├── MacAddress.h
│ ├── MplsLayer.h
│ ├── NdpLayer.h
│ ├── NetworkUtils.h
│ ├── NflogLayer.h
│ ├── NtpLayer.h
│ ├── NullLoopbackLayer.h
│ ├── ObjectPool.h
│ ├── OUILookup.h
│ ├── Packet.h
│ ├── PacketTrailerLayer.h
│ ├── PacketUtils.h
│ ├── PayloadLayer.h
│ ├── PcapDevice.h
│ ├── PcapFileDevice.h
│ ├── PcapFilter.h
│ ├── PcapLiveDevice.h
│ ├── PcapLiveDeviceList.h
│ ├── PcapPlusPlusVersion.h
│ ├── PointerVector.h
│ ├── PPPoELayer.h
│ ├── ProtocolType.h
│ ├── RadiusLayer.h
│ ├── RawPacket.h
│ ├── RawSocketDevice.h
│ ├── S7CommLayer.h
│ ├── SdpLayer.h
│ ├── SingleCommandTextProtocol.h
│ ├── SipLayer.h
│ ├── Sll2Layer.h
│ ├── SllLayer.h
│ ├── SmtpLayer.h
│ ├── SomeIpLayer.h
│ ├── SomeIpSdLayer.h
│ ├── SSHLayer.h
│ ├── SSLCommon.h
│ ├── SSLHandshake.h
│ ├── SSLLayer.h
│ ├── StpLayer.h
│ ├── SystemUtils.h
│ ├── TablePrinter.h
│ ├── TcpLayer.h
│ ├── TcpReassembly.h
│ ├── TelnetLayer.h
│ ├── TextBasedProtocol.h
│ ├── TimespecTimeval.h
│ ├── TLVData.h
│ ├── TpktLayer.h
│ ├── UdpLayer.h
│ ├── VlanLayer.h
│ ├── VrrpLayer.h
│ ├── VxlanLayer.h
│ ├── WakeOnLanLayer.h
│ └── WireGuardLayer.h
└── lib
├── cmake
│ └── pcapplusplus
│ ├── FindPCAP.cmake
│ ├── PcapPlusPlusConfig.cmake
│ ├── PcapPlusPlusConfigVersion.cmake
│ ├── PcapPlusPlusTargets.cmake
│ └── PcapPlusPlusTargets-release.cmake
├── libCommon++.a
├── libPacket++.a
├── libPcap++.a
└── pkgconfig
└── PcapPlusPlus.pc
@seladb Cmake can handle deb generation. I think this MR is a bit complicated and could be simplified using cmake deb packaging no ? See https://cmake.org/cmake/help/latest/cpack_gen/deb.html
I found this in CmakeLists.txt:
if("${DISTRO_ID}" STREQUAL "ubuntu") # set(CPACK_GENERATOR ${CPACK_GENERATOR};DEB) endif()According to you suggestion, I will remove the comment from CmakeLists and rebuild the build-deb job.
Exactly then maybe the actual package pipeline need some rework but not much I think. Also there should be two deb generated. One for the dev package and one for the runtime.
Dev and runtime??? Two deb?? I need clarification in this. I have only updated the CmakeLists and package.yml for now. Please guide me as I am unable to understand what are the requirements now.
I think that's why I didn't enable it yet. A library have multiple usualy two components the "release" and the "dev". E.g: when you do "sudo apt install libpcap" != "sudo apt install libpcap-dev" This should be similar with deb.
- One "libpcapplusplus" for final user with only ".so"
- and one "libpcapplusplus-dev" for dev user with "Cmake files and .h"
- we could also have one "libpcapplusplus-staticdev" for dev that want static libraries ".a"
@seladb @Dimi1010 at the moment only uncomment the # CPACK_DEB will generate also bin, cmake and .h. i think we should clean a bit this before activating the Deb generator. Also IMO final user except shared libraries no ?
You can find .deb example here: https://github.com/clementperon/PcapPlusPlus/releases/tag/25.06
tree . ├── bin │ ├── Arping │ ├── ArpSpoofing │ ├── BenchmarkExample │ ├── BenchmarkExampleGoogle │ ├── DNSResolver │ ├── DnsSpoofing │ ├── HttpAnalyzer │ ├── IcmpFileTransfer-catcher │ ├── IcmpFileTransfer-pitcher │ ├── IPDefragUtil │ ├── IPFragUtil │ ├── PcapPrinter │ ├── PcapSearch │ ├── PcapSplitter │ ├── SSLAnalyzer │ ├── TcpReassembly │ └── TLSFingerprinting ├── include │ └── pcapplusplus │ ├── ArpLayer.h │ ├── Asn1Codec.h │ ├── BgpLayer.h │ ├── CiscoHdlcLayer.h │ ├── CotpLayer.h │ ├── DeprecationUtils.h │ ├── Device.h │ ├── DeviceListBase.h │ ├── DhcpLayer.h │ ├── DhcpV6Layer.h │ ├── DnsLayerEnums.h │ ├── DnsLayer.h │ ├── DnsResourceData.h │ ├── DnsResource.h │ ├── EthDot3Layer.h │ ├── EthLayer.h │ ├── FtpLayer.h │ ├── GeneralUtils.h │ ├── GreLayer.h │ ├── GtpLayer.h │ ├── HttpLayer.h │ ├── IcmpLayer.h │ ├── IcmpV6Layer.h │ ├── IgmpLayer.h │ ├── IpAddress.h │ ├── IpAddressUtils.h │ ├── IPLayer.h │ ├── IPReassembly.h │ ├── IPSecLayer.h │ ├── IpUtils.h │ ├── IPv4Layer.h │ ├── IPv6Extensions.h │ ├── IPv6Layer.h │ ├── Layer.h │ ├── LdapLayer.h │ ├── LinuxNicInformationSocket.h │ ├── LLCLayer.h │ ├── Logger.h │ ├── LRUList.h │ ├── MacAddress.h │ ├── MplsLayer.h │ ├── NdpLayer.h │ ├── NetworkUtils.h │ ├── NflogLayer.h │ ├── NtpLayer.h │ ├── NullLoopbackLayer.h │ ├── ObjectPool.h │ ├── OUILookup.h │ ├── Packet.h │ ├── PacketTrailerLayer.h │ ├── PacketUtils.h │ ├── PayloadLayer.h │ ├── PcapDevice.h │ ├── PcapFileDevice.h │ ├── PcapFilter.h │ ├── PcapLiveDevice.h │ ├── PcapLiveDeviceList.h │ ├── PcapPlusPlusVersion.h │ ├── PointerVector.h │ ├── PPPoELayer.h │ ├── ProtocolType.h │ ├── RadiusLayer.h │ ├── RawPacket.h │ ├── RawSocketDevice.h │ ├── S7CommLayer.h │ ├── SdpLayer.h │ ├── SingleCommandTextProtocol.h │ ├── SipLayer.h │ ├── Sll2Layer.h │ ├── SllLayer.h │ ├── SmtpLayer.h │ ├── SomeIpLayer.h │ ├── SomeIpSdLayer.h │ ├── SSHLayer.h │ ├── SSLCommon.h │ ├── SSLHandshake.h │ ├── SSLLayer.h │ ├── StpLayer.h │ ├── SystemUtils.h │ ├── TablePrinter.h │ ├── TcpLayer.h │ ├── TcpReassembly.h │ ├── TelnetLayer.h │ ├── TextBasedProtocol.h │ ├── TimespecTimeval.h │ ├── TLVData.h │ ├── TpktLayer.h │ ├── UdpLayer.h │ ├── VlanLayer.h │ ├── VrrpLayer.h │ ├── VxlanLayer.h │ ├── WakeOnLanLayer.h │ └── WireGuardLayer.h └── lib ├── cmake │ └── pcapplusplus │ ├── FindPCAP.cmake │ ├── PcapPlusPlusConfig.cmake │ ├── PcapPlusPlusConfigVersion.cmake │ ├── PcapPlusPlusTargets.cmake │ └── PcapPlusPlusTargets-release.cmake ├── libCommon++.a ├── libPacket++.a ├── libPcap++.a └── pkgconfig └── PcapPlusPlus.pc
@clementperon Will the original issue change now (Issue: #1498)? As both dev and runtime are required. I created this https://github.com/bhaskarbhar/PcapPlusPlus/releases/download/v25.05-deb/pcapplusplus_25.05_amd64.deb at the very beginning. I created this using the previous methods before you suggested usig cmake -G. I guess its now more complex for me as I am just a beginner in open source :(( , but I will try meeting the requirements. For now can you review the latest build-deb job in package.yml.
@bhaskarbhar I have pushed on my repo an example but don't have time to properly test everything right now. https://github.com/clementperon/PcapPlusPlus/commits/master/
Understood. Also the build-deb passed the Package and Release workflow and its making this:
CPack: - package: /__w/PcapPlusPlus/PcapPlusPlus/Dist/pcapplusplus-25.05+-ubuntu-24.04-gcc-13.3.0-x86_64.deb generated.
@bhaskarbhar I have pushed on my repo an example but don't have time to properly test everything right now. https://github.com/clementperon/PcapPlusPlus/commits/master/
@clementperon @Dimi1010 @egecetin @tigercosmos I don't know much about Debian packages. Can one of you test it? @Dimi1010 already reviewed, but maybe someone else can review also?
@clementperon how many changes do we need to make to have 2 separate DEB packages (one for runtime, one for dev)?
From what I understand the runtime should only contain the .so files, and the dev should contain headers, static library, cmake, etc. So if it's a lot of work to create the runtime, maybe we can start with the dev package which is more or less what we already have?
Also - in which package should the example binaries be? 🤔
@seladb you can see the commit here https://github.com/clementperon/PcapPlusPlus/commit/bcf75779188692d016edba6c325bdd7350e04f65
IMO example binaries should be shipped separatly or in the "-dev" But ss a dev do you expect to "sudo apt install libopencv-dev" to install some /usr/bin/opencv-examples ?
@seladb you can see the commit here clementperon@bcf7577
IMO example binaries should be shipped separatly or in the "-dev" But ss a dev do you expect to "sudo apt install libopencv-dev" to install some /usr/bin/opencv-examples ?
Yes @clementperon I think you're right. We should probably build 3 DEB packages:
- Runtime -
libpcapplusplus- only the shared libraries - Developer -
libpcapplusplus-dev- static files, headers, cmake, pkg-config, maybe the example source files? libpcapplusplus-tools/libpcapplusplus-examples- the executable binaries of the examples
How far away from it are we? Will this require many changes in the current build system?
@seladb you can see the commit here clementperon@bcf7577 IMO example binaries should be shipped separatly or in the "-dev" But ss a dev do you expect to "sudo apt install libopencv-dev" to install some /usr/bin/opencv-examples ?
Yes @clementperon I think you're right. We should probably build 3 DEB packages:
- Runtime -
libpcapplusplus- only the shared libraries- Developer -
libpcapplusplus-dev- static files, headers, cmake, pkg-config, maybe the example source files?libpcapplusplus-tools/libpcapplusplus-examples- the executable binaries of the examplesHow far away from it are we? Will this require many changes in the current build system?
Done you can see the latest tag here: https://github.com/clementperon/PcapPlusPlus/releases/tag/1.2.6 I didn't check the output at the moment
Thanks @clementperon ! Which I guess it's running in your fork, no? Should we open a separate PR for it and close this PR?
Thanks @clementperon ! Which I guess it's running in your fork, no? Should we open a separate PR for it and close this PR?
Yes it's in my fork. I don't have a lot of time and would be glad to review if someone want to test and open the PR