On Tue, Sep 12, 2023 at 1:53 AM Alyssa Ross <h...@alyssa.is> wrote:
> Gurchetan Singh <gurchetansi...@chromium.org> writes: > > > On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <h...@alyssa.is> wrote: > > > >> Alyssa Ross <h...@alyssa.is> writes: > >> > >> > Gurchetan Singh <gurchetansi...@chromium.org> writes: > >> > > >> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <h...@alyssa.is> wrote: > >> >> > >> >>> Gurchetan Singh <gurchetansi...@chromium.org> writes: > >> >>> > >> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <h...@alyssa.is> wrote: > >> >>> > > >> >>> >> Gurchetan Singh <gurchetansi...@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!
