On Mon, Jul 28, 2025 at 08:38:41AM +0200, Fab Stz wrote:

Thank you Paul for having attended the talk on Qt for Android at DebConf25.

Thanks for giving it, Fab!

Once you have discussed the chanlenges of this package with the team, would >you please share the outcome on the ITP [1] (which I actually changed back to >RFP)? That way any future maintainer would be up to date with regard to how >the pending chanlenges could be overcome.

I'll reply now -- I've got my notebook open and here are some notes I
had from the session; happy to talk it over further with the team but
here's a 'first pass' anyway.

I think there's nothing inherently wrong with the package's aim. There's nothing, on principle, that would stop this from being included in the
non-free section of the archive.

I did pick up on a few things that I think need to be addressed before uploading it to the archive:

One of the first things that jumped out was the way in which this
package builds. IIRC, the android ndk (due to being out of date in
Debian[1]) was downloaded at build-time. All builds (even nonfree!)
should be building without network. For main and contrib this
would be a hard reject. I think we'd apply the same standard for
non-free. If the NDK can't be updated (or this be changed) due to distributibility issues, that's also something that would need fixing :)

The next was social in nature -- this feels like something that should
be done with, at minimum, the consent of the Qt team. Having two
different Qt packages in the archive is one thing (I'm sure someone will
have heartburn over that), but having them configured differently has a potential for causing some real hard confusion for everyone involved :).
I understand (and am sympathetic!) that the Qt team doesn't want to
maintain this -- I think that just means whoever does maintain this
package ought to jump in to get involved with the Qt team in Debian, and ensure that Qt team norms apply to this package too, even if the android
Qt varient isn't a team package. I'm sure the Security team would have
some thoughts which may be helpful to solicit and consider, but I also
don't think they care too much about non-free; they have their hands
full with main.

Lastly, I think the final big flag was "It needs a maintainer" :) -- I
heard you mention you were finishing this enough to "scratch your itch"
with welle, but to include this in the archive, we'd need a willing and
active maintainer to take on this truely massive maintance burden.

After all, the Qt package, as prepared, has more build components
(including full forked Chromium!) than the version in main, and this
package, plus an ecosystem of dependent packages would fall onto this
one person. We'd likely need to carry most if not all of the Debian Qt
patches against Qt in this package too, after all.

It may be worth trying to do this after there's a team of folks who have experience with the Debian Qt team -- so they understand conventions,
norms, and tools related to Qt packaging, even if, again, this isn't
part of the Qt team.

Thanks for your work, it was an interesting talk!

paultag

[1]: Someone should really file a RoM or RoQA on that package

--
⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte <paultag>
⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/
⢿⡄⠘⠷⠚⠋ Debian, the universal operating system.
⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE8rctyP6kE7DHa+fOytLPCmgIXzIFAmiHixgACgkQytLPCmgI XzLZkQf9HhqMUjV0rvY2XmcaAk1dN4jPuQRm267jCVKupyOoIadcw/0njO4622bG nT/rkCDota2LK1b+gH26HzVFquAapoH6ja72zwlU/jSW4EeW3p6kpuUlS7f/c6lm T4E9dRgEMDdX7iV93dxHpVj5U+DfecShcKbM9cstySPXkzX9r3Ibwi0XYT555jZG t4JvP+4s62aho1qN/l/oFYnEv0I6EJDrqFHZnicah0UPfOunb+LfUJ4PX162KKxg Im1jM83MBb1E36wdfVVuRd7TOtv3+7Fqj8m+SFX1lWgxQOAOTxNaoTJ76IANEH8e X/a9GTd1M1ioGp1kjk8bfQI+ng9oXQ==
=fw+Q
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)