#1064255 ITP: aemu -- This is an utility library for common functions used in the Android Emulator. External projects (gfxstream, QEMU) may use to perform C++ functions.

#1064255#5
Date:
2024-02-19 04:02:47 UTC
From:
To:
* Package name    : aemu
  Version         : 0.1.2
  Upstream Contact: Google
* URL             : https://android.googlesource.com/platform/hardware/google/aemu/
* License         : Apache-2.0
  Programming Lang: C++
  Description     : This is an utility library for common functions used in the Android Emulator. External projects (gfxstream, QEMU) may use to perform C++ functions.

AEMU development files, used by gfxstream to build against.

This is a blocker of #1059295 as above descriptions.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059295

#1064255#10
Date:
2024-08-30 07:50:47 UTC
From:
To:
Control: tag -1 + pending

Hi!

This ITP has been filed quite some time ago and there were no
recorded activity on it.

I prepared aemu package locally, also packaged gfxstream and
rutabaga, and verified everything works, and everything is
ready for upload to Debian.

Do you have some progress in this area?  I'm going to upload
the whole set (to be used with upcoming qemu 9.1 release),
under qemu umbrella on salsa.

Thanks,

/mjt

#1064255#17
Date:
2024-08-30 08:05:36 UTC
From:
To:
Hi,
Oh, that is great!
I have packaged aemu under my salsa namespace:
https://salsa.debian.org/vimerbf-guest/aemu

But I am stuck in reprotest test failed so this blocks me upload it to upload.

No problem. Please upload them feel free. I would appreciate that you
could add me as one of the uploaders of aemu so that I can maintain it
in the in the future.

Thanks again.

BR,
Bo

#1064255#22
Date:
2024-08-30 08:25:57 UTC
From:
To:
30.08.2024 11:05, Bo YU wrote:

Heh. You did more than me, mine is more like a PoC now than a
real thing.  I guess we can combine the two somehow.  Lemme
take a closer look..

That's not a show-stopper for sure.  But it needs to be checked
one day anyway.

With pleasure.  Now when I briefly seen your version, I think it is
more suitable for the task than mine, and it's better to use it
instead.

The only thing I already noticed which I don't like is - you're importing
just the tarball without upstream git history.  Myself, I prefer that the
upstream git history to be visible too, in particular, so that all upstream
commits in between upstream/N and upstream/M can be seen.  But this can be
done when importing a next upstream version when it will be released.

Certainly I didn't expect you have something already, provided there was
no activity on the ITP bugs since Feb this year.  It's a good surprise!

Thanks,

/mjt

#1064255#27
Date:
2024-08-30 09:18:35 UTC
From:
To:
Hi Michael,
 > https://salsa.debian.org/vimerbf-guest/aemu

Thanks. I would be happy if my previous work could save you time
also.:) Let's push this forward again.
Ack.
Thanks again.
Hmm, could you tell me the workflow which how to import upstream with
full git history? I have faced the same situation which has the same
request likes some go-* packages. I remember they use
`--upstream-vcs-tag` flag when importing initial.

Here I would like to suggest, could you re-import aemu from upstream
with full git history under qemu team salsa directly? Then we can
combine the debian/* into new aemu which is under qemu team. I think
this is a very fast way than others. Maybe it can be uploaded to NEW
after some modifications. Please feel free to change/update anything
on debian/*[0]. Because it blocks gfxstream also so can speed up it.

Talking about gfxstream, it is under my ITP also. So please feel free
to take over it also if you are willing. I would like to maintain it
under qemu team. I have one POC phrased packaging, but I remembered it
can not be built last time.:(

Thanks you, please let me know if any issues.

BR,
Bo

[0]: https://salsa.debian.org/vimerbf-guest/aemu/-/tree/debian/main/debian?ref_type=heads

#1064255#32
Date:
2024-08-30 09:36:24 UTC
From:
To:
30.08.2024 12:18, Bo YU wrote:
..

It's the option, yes.  And in our case with +dfsg suffix (due to the
cuda headers strippage), this has to be specified on every import
(or else it'd be possible to record that in gbp.conf).   You just
fetch upstream git and use --upstream-vcs-tag=whatever-upstream-tag-is
when doing `gbp import-orig`, that's it.  And gbp will use the given
tag as a parent for the upstream/N commit.

I thought about this one, yes.  Lemme do it this way:

  - clone upstream repository
  - create our branches in it (upstream, debian/main, pristine-tar)
  - create sample d/copyright with Files-Excluded: and create gbp.conf
  - run gbp import-orig with the right tags and +dfsg
  - cherry-pick all your commits to debian/
  - fix a few minor things up (like adding Files-Excluded), add
    Uploaders, and add a few my commits.

And publish it on salsa for your review to see what I've done.  And
next we can upload it.

Yes, I did similar packaging for gfxstream too, and I guess we're
on exactly the same position there too ;)  I haven't looked at your
gfxstream packaging yet.  Sure thing I'll take a look there too.

Let's do it together.  Do you do IRC or matrix?  If yes, you can join
me there, - eg, you can find me there on #debian-devel, I'm mjt.

I'm working on the repo, will notify you when done.

Thanks,

/mjt

#1064255#37
Date:
2024-08-30 10:45:03 UTC
From:
To:
30.08.2024 12:36, Michael Tokarev wrote:

Please take a look at https://salsa.debian.org/qemu-team/aemu

Thanks,

/mjt

#1064255#42
Date:
2024-08-30 11:24:17 UTC
From:
To:
Hi,
[...]

Thanks for the above hints, I will absorb them later.

Yeah, I am on IRC too. I known you for a long time on IRC already with
a huge contribution on Debian.:) I will ping you at IRC after building
it on my local pc.
Got it.

Thanks,
BR,
Bo

Al