On Tue, Jan 30, 2024 at 7:10 PM Gurchetan Singh <[email protected]>
wrote:

>
>
> On Fri, Jan 26, 2024 at 6:23 AM Alyssa Ross <[email protected]> wrote:
>
>> Gurchetan Singh <[email protected]> writes:
>>
>> > On Sat, Jan 20, 2024 at 4:19 AM Alyssa Ross <[email protected]> wrote:
>> >
>> >> Gurchetan Singh <[email protected]> writes:
>> >>
>> >> > On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <[email protected]> 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.
>> >>
>> >> We're exclusively building gfxstream as a shared library.
>> >>
>> >> Looking at rutabaga's build.rs, it appears to me like pkg-config is
>> >> always used for gfxstream unless overridden by GFXSTREAM_PATH.
>> >>
>> >
>> > Hmm, it seems we should be checking pkg-config --static before looking
>> for
>> > AEMU in build.rs -- oh well.
>> >
>> > Would this be a suitable commit for the 0.1.3 release of rutabaga?
>> >
>> >
>> https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
>> >
>> > The gfxstream/AEMU commits would remain unchanged.
>>
>> That combination works for me.
>>
>
> Just FYI, still working on it.  Could take 1-2 more weeks.
>

FYI:

https://android.googlesource.com/platform/hardware/google/gfxstream/+/refs/tags/v0.1.2-gfxstream-release

https://android.googlesource.com/platform/hardware/google/aemu/+/refs/tags/v0.1.2-aemu-release

https://chromium.googlesource.com/crosvm/crosvm/+/refs/tags/v0.1.3-rutabaga-release


>
>
>

Reply via email to