XPost: linux.debian.maint.boot

Hi/やあ,

It took me much longer than planned before getting back to the buggy
Japanese support we've been having in the graphical installer. Long
story short, Unicode is definitely *not* helping in this particular
area[1], and we end up having weird characters[2] when the Japanese
language is picked up.

1. https://en.wikipedia.org/wiki/Han_unification
2. https://heistak.github.io/your-code-displays-japanese-wrong/

Kentaro-san worked on this a lot, teaching us about the issue, proposing solutions, even exploring ways to keep the size increase to a minimum.
You'll find a number of discussions in the bug report and on the main
merge requests (a number of others have been opened while exploring
ideas):

https://bugs.debian.org/1037256
https://salsa.debian.org/installer-team/rootskel-gtk/-/merge_requests/5

I've come back to this topic lately and it looks like sticking to the MotoyaLCedar font is the best compromise (not as nicely-looking as BIZ UDPGothic, but much smaller!).

At the moment, I'm using a trick on the debian-installer side to get
this font embedded without the usual “font ships a udeb, d-i lists it,
and boom”:

https://salsa.debian.org/installer-team/debian-installer/-/commit/ee21b57e30138b044245fe2f7394a942dfec6945
https://salsa.debian.org/installer-team/debian-installer/-/commit/7aedbaf6cee3abb3333fe146536febea624f21ec

If the addition of a fonts-motoya-l-cedar-udeb would be acceptable, this
would be much slicker:

https://salsa.debian.org/installer-team/debian-installer/-/commit/c3773974bbd99935f3ed7a9c0f8cb6eb05e2184a

Kentaro-san adjusted the proposed udeb addition following some remarks
of mine, and I've confirmed that the clean approach would work as well
as the dirty one (runtime-wise); as a nice bonus, we get the package
registered in Built-Using just like other font udebs.

If Hideki-san agrees, this could look like this:

https://salsa.debian.org/fonts-team/fonts-motoya-l-cedar/-/merge_requests/1

The package was last uploaded in 2019, has been in sync between
unstable and testing ever since, and a udeb addition shouldn't
interfere with anything else (that I can think of).


Release team, do you prefer enforcing the no new package rule (which
has been active for many weeks already), and our sticking to the dirty approach? Or would you be open to having the udeb addition reach trixie
so that things are a little cleaner?

In hindsight, we could have requested an extra udeb for each candidate
font, but I usually prefer coming up with a plan instead of brute
forcing my way through…

I'd totally understand either answer, I know we're way past due
already… I'd just hate not asking after all the time spend on
preliminary work and testing.

Thanks for your time.


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgyYRgACgkQ/5FK8MKz VSDAlQ//UIV26EusGJTkgkHkXmZZfBGLl+v/FIm3SAdNMCm/Pjuhco1/g384NPzv krur5i2ggLdV2ieeg4lcTY7zAyqGDCO1vPs/JGGKl1ErrESARX6YTd88gpp4IB0v KqGCqFYpD8Sv7XPAXR1RBwNOngIeT9X+J6EBAZ1iC0ZOe/Ek+ebdZgGydqubq6D2 DC3z79CypApb5jGYmWqFBnS/0JQ/uXog53mzTbqbKkC3W5gQKnmFI27MduVL6PlE 1xr2wZz3zzAEWRhAGnlA8KnxIsN9TUAAbXUm1ipJKoslgPASCjKUV23F78+UYABB 6FNPVNNH08LJap4jqByAQWJYCfJ0pYdqLE2H+C4NOCh0b4w5W6/SnBZXyUnHn4wk D1BBuMmL0AjTej+ZCGtJC2aVnr/cfmIRD4vYzi+ctyo5HS2+l8sHP5wLfuMqZ10i /EGs65LYsLYKvBiOdXLeYYbsRgKf0R3olHbSxoI5WY43nfobvi92LJDj7w58v3aD DNE2ab+MprtbZqxJuxHhK2MFaToDmPknl/CFglxD4Tpj8+SN0OL92PDRAwlVwq/8 0vq46ZewgSgYlVXosUUhgpgvjQU2Izlj5QOzm+YRoi1tDHJWy3zJ9gRdlh2+Fucq 6w/6fuU/nQPoFl065ec4U/ST2XgnuTAi97vXo0suVvmH3XEZCd4=
=GTeM
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*

XPost: linux.debian.maint.boot
To: [email protected]
To: [email protected]
Copy: [email protected] (Hideki Yamane)
Copy: [email protected] (Kentaro HAYASHI)
Copy: [email protected]

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0PMXh0XbPPZPsEzCSecxgVW1
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

SGkgQ3lyaWwsDQoNCk9uIDI1LTA1LTIwMjUgMDI6MTUsIEN5cmlsIEJydWxlYm9pcyB3cm90 ZToNCj4gUmVsZWFzZSB0ZWFtLCBkbyB5b3UgcHJlZmVyIGVuZm9yY2luZyB0aGUgbm8gbmV3 IHBhY2thZ2UgcnVsZSAod2hpY2gNCj4gaGFzIGJlZW4gYWN0aXZlIGZvciBtYW55IHdlZWtz IGFscmVhZHkpLCBhbmQgb3VyIHN0aWNraW5nIHRvIHRoZSBkaXJ0eQ0KPiBhcHByb2FjaD8g T3Igd291bGQgeW91IGJlIG9wZW4gdG8gaGF2aW5nIHRoZSB1ZGViIGFkZGl0aW9uIHJlYWNo IHRyaXhpZQ0KPiBzbyB0aGF0IHRoaW5ncyBhcmUgYSBsaXR0bGUgY2xlYW5lcj8NCg0KDQpT dWNoIGFuIGFkZGl0aW9uYWwgYmluYXJ5IHBhY2thZ2Ugc291bmRzIGxpa2UgYSBnb29kIGNh bmRpZGF0ZSBmb3IgYW4gDQpleGNlcHRpb24uDQoNClBhdWwNCg0K

--------------0PMXh0XbPPZPsEzCSecxgVW1--

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

wsC7BAABCABvBYJoMz+UCRCcXJnrBb11CkcUAAAAAAAeACBzYWx0QG5vdGF0aW9u cy5zZXF1b2lhLXBncC5vcmceVZVvPf5yjuK5lS41ayFKBS8lb8NdX6Y1Qdd6gr4W EBYhBFi2bUhza+k7BS3mcpxcmesFvXUKAACIpAf/d+/0vzEAuY3emGfl3gG5qzcg zIwnSq2TJnFgLSX4DEg6uWcM8Fl5VVXcRcAWANzDQkZynocf8dyHFTRtLIJTtmFj qLQ6ZAmkt8KKdc1gX/c18r7V0axCnqt3Dnf3Vg1lX8w4c7RONR/znFKVd7kTX6jO X6pE/ZZvHIbX7dnNnRG6JOhYbDWLl1aLEW1RuKmL1ZmY5Yf95gsGHXkKyiCDYlbY HC2PfsxL+IOZkcXrcvDBbZYhKOnaXG9jWKPKs9S5qjW1KutuCm1mk3btYNuvrr9I 3HcbIpR4yjDuOYW2CJcJsVeXFPifMqNhpJQYhNWgEgqnS2/5SaPcweYU2HjlyA==
=594D
-----END PGP SIGNATURE-----

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

XPost: linux.debian.maint.boot

Hi,

Paul Gevers <[email protected]> (2025-05-25):

On 25-05-2025 02:15, Cyril Brulebois wrote:

Release team, do you prefer enforcing the no new package rule (which
has been active for many weeks already), and our sticking to the dirty approach? Or would you be open to having the udeb addition reach trixie
so that things are a little cleaner?

Such an additional binary package sounds like a good candidate for an exception.

Thank you very much, I'll keep track of the upload and follow-up
source-only upload, and come back with a formal unblock request
later on.


Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

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

iQIzBAABCgAdFiEEtg6/KYRFPHDXTPR4/5FK8MKzVSAFAmgzSUEACgkQ/5FK8MKz VSD2aw//eDeDEKcQe5zuqF9pdxceySYXyeaeh2Lfvs2e+0m8Z/jNXq7CB2x8R1TQ EvHcqet2svpp99WsQh8crpX8WzhrMMVTliWvN8mjS2hw7+lFb9LzgxRQjogbaghR mbMhEF9JWybzrJRbjrfeHugQ3y5NsSjit75PebATleiJjtvpIKWWdvPF8E2q0K8f GZHM4KvYVdGh8IxJF1s4vCPWCOCdYxn7s8sSb0mjB68RIUlY9y2zMpxC+BnVeTSR Cs5VU6b1i88K0XSVrBXIcPbH6KUj9+oyQcEJkLMcKYNg8QCEzwWh9tJx9iuc+/Rr hIOKfPhR6XJhsBsFKhDpCi5p2CR8Ob5LIexsX5m1esfbznnwjv9GSp0nFyYIdqez Ezk80HTS3e3TKGJKAsWi6swDwp3QGrWhAW/ZPNFrNO53v/OXJesXcLFasbDLfg0S Iq+mDCXKQLoYnJQOAcjwnfGYvh3+cBbwGl0aqfBU7nJ3HACdRQEizjE2fGl2ayip xn9mxiQtMSaJx1prtvnEr7HI1fvvL4191ePnwylMgAHSkVc4eUsPBZLahuI/ICnx BbSDy16TiiVIzkQseEXw1A0SZHpShSFZUjKGQC97jV0oZq6dwQ44N+PLvk2e+pgf EeYcIasIE7KXNuT8aotCvVYP/5cUpbHqV+IU/MBX9dQQ0BNhfRw=
=Hx5E
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
*