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

[Alyssa Ross]

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Alyssa Ross <hi@alyssa.is> writes:
>>
>> > Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >
>> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >>
>> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >>>
>> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >>> >
>> >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >>> >>
>> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi,
>> >>> >> >   gfxstream, aemu-base.  For example, see crrev.com/c/4778941
>> >>> >> >
>> >>> >> > - The release commits can make packaging easier, though once
>> >>> >> >   again all known users will likely just build from sources
>> >>> >> >   anyways
>> >>> >>
>> >>> >> It's a small thing, but could there be actual tags, rather than just
>> >>> >> blessed commits?  It'd just make them easier to find, and save a
>> bit of
>> >>> >> time in review for packages.
>> >>> >>
>> >>> >
>> >>> > I added:
>> >>> >
>> >>> >
>> >>>
>> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging
>> >>> >
>> >>> > Tags are possible, but I want to clarify the use case before
>> packaging.
>> >>> > Where are you thinking of packaging it for (Debian??)? Are you mostly
>> >>> > interested in Wayland passthrough (my guess) or gfxstream too?
>> Depending
>> >>> > your use case, we may be able to minimize the work involved.
>> >>>
>> >>> Packaging for Nixpkgs (where I already maintain what to my knowledge is
>> >>> the only crosvm distro package).  I'm personally mostly interested in
>> >>> Wayland passthroug, but I wouldn't be surprised if others are
>> interested
>> >>> in gfxstream.  The packaging work is already done, I've just been
>> >>> holding off actually pushing the packages waiting for the stable
>> >>> releases.
>> >>>
>> >>> The reason that tags would be useful is that it allows a reviewer of
>> the
>> >>> package to see at a glance that the package is built from a stable
>> >>> release.  If it's just built from a commit hash, they have to go and
>> >>> verify that it's a stable release, which is mildly annoying and
>> >>> unconventional.
>> >>>
>> >>
>> >> Understood.  Request to have gfxstream and AEMU v0.1.2 release tags
>> made.
>> >>
>> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient?
>> >>
>> >> https://crates.io/crates/rutabaga_gfx_ffi
>> >>
>> >> Debian, for example, treats crates.io as the source of truth and builds
>> >> tooling around that.  I wonder if Nixpkgs as similar tooling around
>> >> crates.io.
>> >
>> > We do, and I'll use the crates.io release for the package — good
>> > suggestion, but it's still useful to also have a tag in a git repo.  It
>> > makes it easier if I need to do a bisect, for example.  As a distro
>> > developer, I'm frequently jumping across codebases I am not very
>> > familiar with to try to track down regressions, etc., and it's much
>> > easier when I don't have to learn some special quirk of the package like
>> > not having git tags.
>>
>> Aha, trying to switch my package over to it has revealed that there is
>> actually a reason not to use the crates.io release.  It doesn't include
>> a Cargo.lock, which would mean we'd have to obtain one from elsewhere.
>> Either from the crosvm git repo, at which point we might just get all
>> the sources from there, or by vendoring a Cargo.lock into our own git
>> tree for packages, which we try to avoid because when you have a lot of
>> them, they become quite a large proportion of the overall size of the
>> repo.
>>
>
> Ack.  Request to have a rutabaga release tag in crosvm also made, should be
> complete in a few days.

Thanks!  I've found the rutabaga tag, but I still don't see any relevant
tags for aemu or gfxstream.  Any news there?

signature.asc
Description: PGP signature