×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

No indi-bleeding OBS builds for Fedora 32

  • Posts: 9
  • Thank you received: 0
Hi there,

Does someone here maintain the OBS builds for indi-bleeding? No builds exist for Fedora 32, and due to a glibc update Fedora 31 builds are not install-able.

software.opensuse.org/download.html?proj...upinix-indi-bleeding
3 years 8 months ago #56958

Please Log in or Create an account to join the conversation.

  • Posts: 171
  • Thank you received: 41
The OBS builds are unmaintained currently :( I created the repository some years ago, but due to lack of time the updates stopped when a bigger change in build scripts were neccessary… We should remove rhe repo from the downloads page until I managed to update everything.
The following user(s) said Thank You: Jasem Mutlaq, Ian
3 years 8 months ago #56959

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 0
That's unfortunate but I understand, thanks for everything you do! Just wanted to make sure it wasn't forgotten about, I should be able to just build the drivers I need manually for now.

Maybe just add a note to the page that Fedora 32+ are not currently supported instead of removing completely?
3 years 8 months ago #56979

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
@lupinix, glad to see you back!

In your absence, I posted a pull request against your repo in the Suse build engine stuff, but did not like the process to build there much, so went down a path of many forks (pun intended), including getting a working AppImage based on git master versions. I was not happy with all the hoops that were needed to build the AppImage either though, and finally landed on Fedora Copr, where I now have an active working Repo with Fedora, SUSE, RHEL, and CentOS builds for both kstars git and indi git. I am currently working on the indi 3rd party section. It is a little more difficult as we probably want to build each driver independently. There are also a few license issues, but most of them should be able to be built. I am working on indi-eqmod currently.

If anyone is running Fedora, CentOS, SUSE, or RHEL and wants to try things out, please do, and report back. The Copr is here: copr.fedorainfracloud.org/coprs/xsnrg/

Use the "bleeding" configs for the latest builds from git. My intention with the others is to mirror release code available in Rawhide, but make it available for stable OS distributions.

The kstars repo is a fork from the official repo, located here: invent.kde.org/xsnrg/kstars/
The indi and indi-3rdparty is forked from github, and located here: github.com/xsnrg/indi and here, respectively: github.com/xsnrg/indi-3rdparty

Feedback desired.

Jim
3 years 8 months ago #57071

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 0
@xsnrg that's awesome, thank you for doing this. I was considering creating Copr builds for it as well but hadn't gotten around to it yet.

If I could make a suggestion: is there a reason you're forking the repositories instead of setting up a remote for the spec (e.g. github.com/xsnrg/indi-rpm) and pulling in the repo or tar as Source0? This way you build from upstream untouched, and don't need to maintain a fork.

As an example, one of my old Copr packages: github.com/ianhattendorf/gli-rpm
3 years 8 months ago #57193

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
@ihattendorf No reason, first stab at it, and still learning. I like what you are suggesting, and will check it out.

I thought about doing a PR against upstream for the .spec file even, once it is stabilized, but don't want that to interfere with the official packager builds. Setting up a remote to bring the .spec in to the undisturbed upstream and a few other build changes that I have in my fork, and then triggering off master on the upstream for a new build should be fabulous.

Thanks for the suggestion

Jim
3 years 8 months ago #57213

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
Finding time is proving to be difficult. In the meantime, I updated the current copr of kstars to 3.5.0git
3 years 8 months ago #57374

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
I was able to get kstars to build as @ihattendorf suggested, so now it is current, and building straight from education/kstars master. I still want to make a couple changes on it, and that would be to have the packages have the short git hash as part of the package name, and to have the build trigger set to education/kstars master branch instead of my repo. As it is right now, I still need to update the spec file manually for the next version. With the spec file using the upstream git hash, and triggering off education/kstars, it should be possible to automate new package creation based on merges to kstars master.

It is probably more important to spend time converting indi over to build this way though, and then indi-3rdparty, so those will be next before tackling full automation.

PRs are always welcome :) You can find the source here: invent.kde.org/xsnrg/kstars-spec and upstream here: invent.kde.org/education/kstars

Jim
3 years 8 months ago #57377

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
indilib is now building from upstream github master as well. The repo for the spec is here: github.com/xsnrg/indi-spec

Now to get the 3rd-party drivers sorted out...
Last edit: 3 years 8 months ago by Jim.
3 years 8 months ago #57400

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
More conversation with myself :)

Making more progress. I was able to come up with a repo of spec files basically, for some of the indi-3rdparty repo driver packages. indi-gpsd, indi-eqmod, and currently working on indi-asi with libasi.

The copr is here: copr.fedorainfracloud.org/coprs/xsnrg/indi-3rdparty-bleeding/
The repo is here: github.com/xsnrg/indi-3rdparty-spec

I am hoping to establish one pattern for the drivers, and a second pattern for drivers that require libraries. I almost think it would be better to either build all the drivers into a single driver package, or to re-structure the repo so that each driver is its own sub-project and can be pulled and built independently of the rest of the drivers and libraries.

Jim
3 years 8 months ago #57415

Please Log in or Create an account to join the conversation.

  • Posts: 9
  • Thank you received: 0
Hah, I was just typing up a reply actually.

I think ideally you would have each driver built as its own RPM package with a dependency on libraries if necessary.

The setup you have now looks great, are you running into any specific issues?
3 years 8 months ago #57416

Please Log in or Create an account to join the conversation.

  • Posts: 535
  • Thank you received: 109
No issues really, just time to learn everything while I look outside longingly at clear skies. Still having some config problems with libasi, but I think I about have it.

Edit: I take that back. libasi is being a royal pain. It includes binaries and those binaries are determined to be Required by the packager's auto Required script. Even though the RPM being built provides those files, trying to install the RPM fails saying those binary libraries are not found.
Last edit: 3 years 8 months ago by Jim.
3 years 8 months ago #57417

Please Log in or Create an account to join the conversation.

Time to create page: 0.958 seconds