On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <h...@alyssa.is> wrote: > > Hi Gurchetan, > > > Thanks for the reminder. I did make a request to create the release > > tags, but changes were requested by Fedora packaging effort: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=2242058 > > https://bugzilla.redhat.com/show_bug.cgi?id=2241701 > > > > So the request was canceled, but never re-requested. I'll fire off > > another request, with: > > > > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream: > > manually add debug logic") > > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve licensing") > > > > as the commits. These match the Fedora requests, and the AEMU one has > > been merged into Fedora already it seems. > > These revisions have the problem I mentioned in my previous message: > > >> The gfxstream ref mentioned here isn't compatible with > >> v0.1.2-rutabaga-release, because it no longer provides logging_base.pc, > > rutabaga was not fixed to use the new AEMU package names until after the > v0.1.2-rutabaga-release tag, in commit 5dfd74a06. So will there be a > new Rutabaga release that's compatible with these release versions of > gfxstream and AEMU?
Good catch. One possible workaround is to build gfxstream as a shared library. I think that would avoid rutabaga looking for AEMU package config files. But if another rutabaga release is desired with support for a static library, then we can make that happen too.