Consider creating deb as part of releases

[wltjr]

If possible it would be nice to have a deb available as part of releases. I was using some newer features of check, and had problems on Travis due to old version of check. I went looking for newer package, and seems one does not exist. Or at least I could not find one.

For some projects of mine I create deb and rpm as part of deployment from Travis. I was wondering if this project could be willing to consider doing the same. I can submit a PR with the initial changes for such.

The idea is to have a package usable for Travis. Since it does not seem an updated deb of check 0.12.0, or even 0.11.0, exist anywhere. If building under Travis it should be usable just the same under Travis. It is not so much for general usage, but that may work just the same.

Thank you for your consideration.

[brarcher]

If I understand correctly, you have a project running on Travis and you would like to test that project using Check. However, as the images used on Travis do not have an up-to-date packages available for Check, you cannot use newer Check features. If a deb archive existed you could install that during your Travis builds. Is my summary correct?

Is the issue here that downstream Linux distros are not updating their packages of Check, and as such there is no deb archive? Is providing a deb file from Check useful because it would available in a known location, such as the releases page on GitHub?

[wltjr]

Yes your summary is 100% correct. This project failed on travis using newer features. I plan to use check with other projects. That was more a test, and first feature I used was added in 0.12.0.

Yes the issue is downstreams distros, ubuntu and debian do not have updated packages of check. I could not find any third party packages either. Yes it would be useful to be in a known location as a result.

[brarcher]

I'm not sure I want to take on maintaining deb packages for releases, sorry. That, and I'm don't think it resolves the root problem. I'm not sure why downstream has not updated the repos in a long time. Perhaps they are still watching Sourceforge and did not start tracking on GitHub. The Check webpage on Sourceforge clearly says to go to GitHub and provides a link. It may be worthwhile to send a note to Ubuntu or Debian and inquire about updating the Check package. Maybe they have a reason for not doing so, though I've not heard anything.

[wltjr]

There is not really any effort in maintaining deb packages. You can use cpack in cmake pretty easily to generate deb and rpm if you like. I do that in a few projects now, ecrire, jem and soon asspr, and use travis, ecrire/jem, to auto-deploy them under releases on github, ecrire/jem, anytime I do a tag. I also use the deb myself for direct installation and usage for testing of those packages.

Those distros tend to lag on versions in general. Though usually there are updated packages in third party repositories. Which I use third party repositories for many things like efl in ecrire, e19 ppa. For some things I have to get via other means, like say Meson via python pip.

I could see about contacting those distros, travis, etc but who knows how long that would take. I could make my own, and host it on my servers or else where. Though not sure how that solves it for others if they run into it.

I think if you provided a deb that worked in travis, etc. Which most tend to have similar environments, like shippable. It could be usable on many. Sure ideally upstreams update, but that they have not in a long time. Nor any 3rd party repositories. That seems to suggestion something, either people do not care, do not use it, etc.

I can contribute via a PR necessary changes to CMakeFiles.txt and travis.yml, less deployment key. Which after that, there should not really be anything to maintain per se. I almost never have to revisit that stuff in my projects once setup. Either way, no worries, thanks for your consideration.

[wltjr]

I just added deployment to my asspr project. Its pretty nifty, few lines in CMakeLists.txt, plus that commit, and on tag I have deb and rpm. I can probably lose packaging sources, or keep and create and upload a hash. Happy to make such modifications for libcheck can submit a PR if interested.

Once again thank you for consideration!

[wltjr]

Any movement on this? libcheck in both ubuntu and debian are still at 1.10, not even 1.11 much less current 1.12. I think it would benefit anyone using CI to have a newer binary available for use. Thanks!

[brarcher]

I think if you might propose a PR which could add the artifacts when a release is made, I can accept the change. My main development machine is a mac, so if Travis-CI could produce the dep and rpm files and post them, rather than my building it locally, it will make releases simpler for me. I see the .travis.yml files for asspr seems to do just that, right? Is this something you could help me with?

[wltjr]

Yes, all you do is push a tag to github. It builds on Travis and uploads the resulting deb, rpm, and tar.gz to github under releases. In addition to the default source tarballs created with any tag. Its really nifty and quite convenient. Plus you know it will run for others in Travis being built there.

I am happy to help. I would have sent over a PR to begin with just wanted to make sure it was of interest before expending the time. I will create a PR with the modifications for CMake and Travis. You will just need to generate a key for release via modifying PR as you merge/test. That is the only thing I cannot do without access. It will want to update the travis.yaml. I tend to just toss those changes to retain what ever format and grab the key. Beyond that may want to tweak the author or other parts of the CMake CPack section I create. But that should be pretty minor.

I will create a PR ASAP and we can go from there. Thanks!

[wltjr]

PR submitted, feel free to modify as needed. Let me know if there is anything else I can do to help out with the auto release deployment. Thanks!