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. > > (This probably differs from Debian, etc., because in Nixpkgs, we don't > package each crate dependency separately. We only have packages for > applications (or occasionally, C ABI libraries written in Rust), and > each of those gets to bring in whatever crate dependencies it wants as > part of its build. This means we use the upstream Cargo.lock, and > accept that different Rust packages will use lots of different versions > of dependencies, which I don't believe is the case with other distros > that take a more purist approach to Rust packaging.) >
