On Sun, Oct 19, 2025 at 07:02:45PM +0200, Samuel Thibault wrote: > Samuel Thibault, le dim. 19 oct. 2025 16:02:27 +0200, a ecrit: > > it's azerty-oss which we should indeed be using for berber. > > Actually the story is even more confusing: the azerty-oss variant is > actually the default one, so it's not dz(azerty-oss), but simply dz that > we should be using. This has actually been wrong since its introduction > in debian 11, I guess it was not actually tested. > > > Let me upload 1.240+deb13u2 with this fixed. > > '+' is actually posing problem, because it's used as a file separator by > bdf2psf, and thus when building on buildds: > > /build/reproducible-build/console-setup-1.240+deb13u2/foo+/build/reproducible-build/console-setup-1.240+deb13u2/bar > > is interpreted as /build/reproducible-build/console-setup-1.240, > deb13u2/foo, /build/reproducible-build/console-setup-1.240, and > deb13u2/bar... > > This problem is not new, it already brought concerns for some +nmu > uploads in the past apparently. The simplest way would be to rather use > version 1.241~deb13u1. That's unorthodox, but would be the simplest way > to get the ca(multi) and dz layouts fixed in the installer. Otherwise > we'd have to somehow teach bdf2psf some escape sequence to really mean + > inside the path instead of a file separator, and backport that as well, > what do you think?
Ick. I think in that case you'll need to backport 1.242 as 1.242~deb13u1, and presumably bring the d-i kmaps fix with it. -- Jonathan Wiltshire [email protected] Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 ed25519/0x196418AAEB74C8A1: CA619D65A72A7BADFC96D280196418AAEB74C8A1
