search

VDR4Arch / vdr4arch

VDR PKGBUILDs for Arch Linux
33 stars 22 forks source link

Aftermath of projects.vdr-developer.org shutdown + fixes in oscam, lxdvdrip and projectx. #241

Closed tmn505 closed 1 year ago

tmn505 commented 1 year ago

"treewide: replace vdr-developer.org URLs" is not build or run tested, I only checked download and unpack. Every other commit is only build tested.

M-Reimer commented 1 year ago

Thank you very much.

Have you build tested every PKGBUILD where you bumped the vdr-api? Some plugins are unmaintained and known to no longer work. I don't want to advertise them as working on AUR and don't want to fix them to make them build either. A good hint about what does work is the repo-make.conf file.

I'll probably rework your commits to all link to the github.com/vdr-projects fork for most of them. And then directly commit your fixes where needed.

tmn505 commented 1 year ago

Yes, as stated, the vdr-api bumps are build tested. vdr-burn build log: https://paste.debian.net/plainh/ee6559c1 (only warnings about depreciation) vdr-zaphistory build log: https://paste.debian.net/plainh/4cfb8406 (only warnings about unused results) After installing the and running vdr --help they don't segfault, so should work (TM).

The "treewide: replace vdr-developer.org URLs" commit has only URL changes in $url and $source, no version or release bumps, which won't trigger rebuilds.

tmn505 commented 1 year ago

Forgot to include vdr-scraper2vdr, build log: https://paste.debian.net/plainh/2fa49190 (mostly depreciation warnings). Also running vdr --help does not segfault.

tmn505 commented 1 year ago

Added two unrelated commits, where tvheadend compiles now and minisatip reports now proper version instead of 1.2. or 1.2.~ after update.

M-Reimer commented 1 year ago

I've reworked some of the URLs before pushing your changes. I don't want to point anything to the "projects.vdr-developer.org" read-only archive. The "vdr-projects" GitHub organization was created for being able to create patched versions of unmaintained plugins directly. If someone wants to do smaller contributions, it will be more useful if he finds the (writable) community "fork" instead of the read only copy.

tmn505 commented 1 year ago

That's sensible. Thanks for merging. WRT Travis issues, when I tested GitHub Actions it was possible to have both CI active, since the Actions were activated by placing some .yml in .github/workflows, even when other CI provider was installed. Maybe nothing changed and it's still possible.

M-Reimer commented 1 year ago

I'll try as soon as I find the required time. I would prefer to keep ARM builds somehow possible, but if Travis is no longer trustworthy, maybe they should be shut down after all. Having two services "in business" makes it easier for "bad guys" to corrupt packages in some way. With GitHub Actions no "third party service" is involved. Probably would never happen as the packages aren't used by many people but I prefer to also reduce theoretical security issues. The few packages, needed for a typical Raspberry Pi VDR server, probably can be compiled directly on the Raspberry where they are needed.

tmn505 commented 1 year ago

When it comes to ARM, apparently Oracle offers Ampere aarch64 cores on free tier offering. Even Ampere itself has made blog post about using it on GitHub https://amperecomputing.com/blogs/building-and-testing-aarch64-containers-with-ampere-altra-and-github-actions.html. The downsides are Oracle requires credit card number to register (just as identification, against abuse) and they are picky about what card You use, also the machines are aarch64 so I don't know if armv7 code can be compiled there natively. I myself have been pondering about setting my unused ARM device as local worker for GitHub actions, but have not found time to do that yet. If I'll get around to set it up, I'll drop You a note how it went.