Move debian package generation to a dispatch only workflow #2543
Conversation
|
@Rot127 Thanks for addressing the questions, I figure we can keep the issue open about official Debian packaging for later then. But while I wait for this to merge, could I request that the current workflow still be part of the release? Essentially my hope is, to emulate what PANDA has, yes this Debian package is not ready for general release, but someone can get it from the official source (in my example, the panda repository) and use the Debian package, e.g. see below https://github.com/panda-re/panda/releases/tag/v1.8.54 |
|
If you want to knock these out, the control file should be Architecture: amd64 The file I got from Apt is like 'libcapstone-dev_4.0.2-5_amd64.deb'. So I suspect we can tweak the filename to just include the version and _amd64.deb But I saw the comment about using CPack, so maybe, we can just stick with libcapstone-dev name, we can use this as a current stop gap, since from my understanding, the Debian package does work correctly, but it is just not ready for Debian/Ubuntu packaging |
Yes! Absolutely. It is still on the todo list.
We want to do a v6-Alpha2 patch release after this one. For the v5 branch, I have to ask you to create a PR. I spent already a lot of time on it and have to take care of other things. But shouldn't be too much work.
It works somewhat. But with all the things missing I don't want to have it part of a release. I tried hard to raise the quality of Capstone project in the last years (more tests, fixing clang-tidy issues, documentation, better issue management etc.). So adding such an incomplete package goes against the quality enhancements. If it would be not quite ready for the official repos, but good enough it would be fine. But the list of missing information is so long, that there are likely other issues which I didn't find. |
|
OK, so my question is, what is needed for the Debian Package, to be at the level to be ready to be on release? I can definitely take on testing the whole confirming it works if tag is like 6.0.1-Alpha2, etc. I can look into hashing, but not sure what else, it seems you took care of a lot of the issues like moving it to the right folder, and using --prefix correctly. Once that is done, I figure I can raise a PR for v5 branch. |
It should be all documented in the Debian docs. Unfortunately, I currently don't have the time to read myself into this and answering all these questions. This is also why I asked you here to
This way we know everything is in a good shape. |
* Update changelog for V6.0.0-Alpha1 (#2493) * update version to v6-alpha1 * update bindings const values * Update changelog for V6.0.0-Alpha1 * Remove irrelevant changes. (#2495) * Fixing UB santizer, `LITBASE` and assert errors. (#2499) * Update labeler with Xtensa and v6 files. (#2500) * Add hard asserts to all SStream functions and memset MCInst. (#2501) * Only trigger on released action. (#2497) * Fix cstest build with Ninja (#2506) * Tricore EA calculation (#2504) * Update libcyaml dependency in cstest to 1.4.2 (#2508) * AArch64: Replace vararg add_cs_detail by multiple concrete functions Fixes UB caused by various mismatches on how these arguments are passed and read. This became visible when running on PowerPC hosts with e.g. `cstool -d aarch64 204862f8`. Apart from the UB fix, this is meant to be a pure refactor. Partially addresses #2458 * xtensa: Fix Branch Target (#2516) * xtensa: Fix Branch Target * auto-sync: fix byte pattern * xtensa: add branch insn tests * Revert "auto-sync: fix byte pattern" This reverts commit cf8e870. * Fix #2509. (#2510) Compatibility headers should always include the header in the same dir. * Fix stringop-truncation warning some compilers raise. (#2522) * Add CC and VAS compatibility macros (#2525) * Fix endianess issue during assignment. (#2528) * This time actually fix big endian issue. (#2530) * tricore: fixes #2474 (#2523) * tricore: fix auto-sync tricore * tricore: fixes TriCoreGenCSMappingInsnName.inc * tricore: fixes * tricore: try fix ld.a SC * tricore: fixes all * Add TriCore to .github/workflows/auto-sync.yaml * Add TriCore details tests(a15, d15, a10|sp) * Change CI to create Debian Package to Release (#2521) * Updating CI to create Debian package and version is assigned by tag version. Also updating release CI to not use end-of-life workflows * Clear up usage of static libraries. - Python bindings only use the dynamic lib. But built and copied the static ones sometimes nonetheless. - Add toggles to build only static, static/dyn or only dynamic. --------- Co-authored-by: Rot127 <unisono@quyllur.org> * Rename build arguments: (#2534) - BUILD_SHARED_LIBS -> CAPSTONE_BUILD_SHARED_LIBS - BUILD_STATIC_LIBS -> CAPSTONE_BUILD_STATIC_LIBS - BUILD_STATIC_LIBS -> CAPSTONE_BUILD_STATIC_MSVC_RUNTIME * xtensa: update to espressif/llvm-project (#2533) * fix coverity (#2546) - cid 514642 - cid 514643 - cid 514644 - cid 514645 * Move debian package generation to a dispatch only workflow (#2543) * Move deb package gen files int package/deb * Fix basename check * Make debian package generation dispatch only * Python package building rework (#2538) * - Refactored setup.py to remove hacks regarding packaging of wheels for different platforms, improve and cleanup the code - Updated README.txt - Removed old Makefile and build_wheel.sh scripts - Created a new workflow that takes care of building and testing python packages for different platforms/architectures/python versions * Added SPDX headers to the setup.py * - cstest_py: Fixed positional argument since it doesn't accept a `required` flag. It turns to have a mandatory tests folder path - integration_tests.py: Use pathlib to determine the required path - GitHub action: Simplified the tests execution command * GitHub Actions: Run python 3.8 (lowest) and 3.13 (current highest) for native runners only during testings and the rest during tag release * GitHub Action: - Fixed the cibw_build matrix element - Added a step to prepare artifact name * GitHub Action: Added run_tests.py script to run all tests during CI workflow * - Added SPDX headers to the run_tests.py script and to the build-wheels-publish.yml workflow file - Minor fixes to the workflow as pointed out in the PR review - Updated MANIFEST.in to reflect the actual libraries built during python wheel creation process - Use subprocess.run in place of os.system in run_tests.py script * GitHub Action: - Run qemu step only if non-native Linux runner - Added arch:universal2 matrix element for macos-latest runner * Python bindings: Refreshed the list of files needed to be copied for sdist archive * GitHub Action: Commented out arch:x86 matrix elements * GitHub Action: Run qemu step only if non-native Linux runner * GitHub Action: Minor fixes * Python bindings: Added missing .in pattern when collecting src files for sdist archive * Auto-Sync reproducability + ARM update (#2532) * fix xtensa DecodeMR23RegisterClass and add tests for MAC16 instru… (#2551) * fix xtensa `DecodeMR23RegisterClass` and add tests for `MAC16` instructions * revert * Prepare for update (#2552) * Bindings(chore): Fix DeprecationWarning * Version(upgrade): update bindings const * Fix(chore): Fix ARMCC_Invalid is not defined * Update Changelog Version to 6.0.0-Alpha2 (#2553) * Bindings(chore): Fix DeprecationWarning * Version(upgrade): update bindings const * Fix(chore): Fix ARMCC_Invalid is not defined * Changelog: Update to version 6.0.0-Alpha2 --------- Co-authored-by: Rot127 <45763064+Rot127@users.noreply.github.com> Co-authored-by: Florian Märkl <info@florianmaerkl.de> Co-authored-by: billow <billow.fun@gmail.com> Co-authored-by: Andrew <afq2101@columbia.edu> Co-authored-by: Rot127 <unisono@quyllur.org> Co-authored-by: @Antelox <anteloxrce@gmail.com>
Your checklist for this pull request
Detailed description
Disables the
debpackage build during a release, due to incompleteness.Test plan
Release source archive: https://github.com/Rot127/capstone/releases/tag/v99.99.124
Dispatch workflow: https://github.com/Rot127/capstone/actions/runs/11766843325
Closing issues
...