Re: [PATCH v15 0/9] rutabaga_gfx + gfxstream

[Gurchetan Singh]

On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@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.