Even though we fork the upstream development version, we should think about how we can get PIKA into the hands of actual users (even thought things are janky, it still works as my daily driver).
Generally speaking, it'd probably be best to automate .deb, appimage, flatpak, and Windows builds (maybe mac if someone can be bothered to help us and has the mac development stack, not automated I guess).
Higher Priority:
We'll need to fix the way Versioning works so we can actual cut releases, this is probably some changes to heckimp.
We need to fix the about dialog shenanigans by figuring out why heckimp breaks the xsltproc and/or patching it out of the about dialog so the heckimp user has more control over it.
Lower priority:
Maybe some patch-shipping support for heckimp. Granted upstream's 3.0 stuff is a very moving target but we could freeze our release branch at a specific version of it.
Maybe we can fix python and vala scripts
Even though we fork the upstream development version, we should think about how we can get PIKA into the hands of actual users (even thought things are janky, it still works as my daily driver).
Generally speaking, it'd probably be best to automate .deb, appimage, flatpak, and Windows builds (maybe mac if someone can be bothered to help us and has the mac development stack, not automated I guess).
Higher Priority:
- We'll need to fix the way Versioning works so we can actual cut releases, this is probably some changes to heckimp.
- We need to fix the about dialog shenanigans by figuring out why heckimp breaks the xsltproc and/or patching it out of the about dialog so the heckimp user has more control over it.
Lower priority:
- Maybe some patch-shipping support for heckimp. Granted upstream's 3.0 stuff is a very moving target but we could freeze our release branch at a specific version of it.
- Maybe we can fix python and vala scripts
I have written a shell script that lets us build inside of a docker image for debian-based builds. This could probably be mutated into a .deb packager (with deps), but for now produces tarballs of /usr/local and expects the user to install the deps after untarring it. It's pretty easy to discover the deps we can probably automate it by deploying it into a clean docker, and then picking out the 'not found' on ldd outputs.
I have written a shell script that lets us build inside of a docker image for debian-based builds. This could probably be mutated into a .deb packager (with deps), but for now produces tarballs of /usr/local and expects the user to install the deps after untarring it. It's pretty easy to discover the deps we can probably automate it by deploying it into a clean docker, and then picking out the 'not found' on ldd outputs.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Even though we fork the upstream development version, we should think about how we can get PIKA into the hands of actual users (even thought things are janky, it still works as my daily driver).
Generally speaking, it'd probably be best to automate .deb, appimage, flatpak, and Windows builds (maybe mac if someone can be bothered to help us and has the mac development stack, not automated I guess).
Higher Priority:
Lower priority:
I have written a shell script that lets us build inside of a docker image for debian-based builds. This could probably be mutated into a .deb packager (with deps), but for now produces tarballs of /usr/local and expects the user to install the deps after untarring it. It's pretty easy to discover the deps we can probably automate it by deploying it into a clean docker, and then picking out the 'not found' on ldd outputs.
After fixing the URL thing in heckimp we can put releases up.
probably need to figure out .debs antd maybe some sort of /opt/ install script that does LD_PATH shenanigans so it can be a clean install with tar.