On Tue, Sep 12, 2023 at 1:53 AM Alyssa Ross <
hi@alyssa.is> wrote:
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?
It's harder to get the attention of the Android build team than the Chrome build team. Though, there are a few issues with AEMU/gfxstream packaging we also need to figure out -- see "[PATCH v13 0/9] rutabaga_gfx + gfxstream" for details -- interested in your opinion on the matter!