Hello list, all, On 27/02/2026 18:38, Jeremy Bícha wrote:
On Fri, Feb 27, 2026 at 8:05 AM Roland Clobus <[email protected]> wrote:The reason I hesitate is, that I have some questions in mind: 1) What is the proper location for the fix? 2) Which live images can/should be affected? 3) Who decides what goes in the live images?Debian 13 ======== [snip] I think that we should make select changes with live-tasks stable updates for Debian 13. On the other hand, I don't think we should change tasksel or live-build in Debian 13. ... I don't believe it is a violation of Debian Live philosophy to avoid installing certain recommended packages, especially temporarily.
Agreed. See https://salsa.debian.org/live-team/live-build/-/merge_requests/467 I think that I've added all requested changes for the GNOME image. Please test and gather feedback from the non-english users, especially since fcitx* got replaced by ibus (only for the GNOME image).
I have been bothered by the extra apps included in the Debian Live GNOME images for quite a while, but I didn't realize until yesterday how I could fix it. I'd like to clean up Debian Live GNOME in particular and, if possible, get that done in time for Debian 13.4.
Theoretically any change in rebuild.sh up to the actual moment of release would be applied to the 13.4 point release live images. However, I would rather apply the same freeze as for 'proposed-updates', i.e. one week before the actual release.
I recognize that other desktop maintainers may be bothered by those additional language apps too. I'm hesitant to make changes to Debian 13 for them without getting their input. Some changes are probably fine: I don't believe any desktop wants to have the fortunes .desktop installed (which doesn't even work: I'll submit a merge request for it.). Debian GNOME doesn't currently want fcitx or mozc, although other desktops may be ok with their inclusion. I'd rather not make changes to oldstable live images. There was conversation about oldstable live images last month on this list.
Since there the next point release for oldstable is a bit more into the future, I've not (yet) excluded the modifications to the package list for bookworm. I'll do that in a separate commit/MR.
Yes, I can do live-tasks uploads for you for unstable and stable.
Let's try to use the 'rebuild.sh' strategy first, because that allows for shorter development cycles.
Ideals ===== I was surprised to see that many of the language task recommendations were set a very long time ago, frequently in 2004 by someone who does not use those languages. I suspect that the tasks were simply created by including every package related to a language instead of determining whether those packages should be installed by default for everyone who wants support for that language. Even then, the language tasks are very inconsistent. Just one example: every Debian desktop environment shown for selection in Debian's default net installer installs LibreOffice except for Phosh. Some language tasks install the libreoffice support for that language but many don't.
Phosh is new, so they might have missed it, or decided (given that it is for small screens) to not provide LibreOffice. And there is no live image for Phosh (yet).
Ultimately, it would be ideal if Debian could install the language support for desired languages only for the apps or libraries that are installed. This could be done through either: 1) Something like Ubuntu's language-selector-gnome which I think has that functionality 2) apt could gain a conditional dependencies feature. If French is a desired language, when gimp-help and libreoffice are installed, libreoffice-l10n-fr and gimp-help-fr should be installed. This is useful beyond languages. If the Yaru theme is installed and then a gtk3 app is installed (which installs libgtk-3-0t64), the Yaru GTK3 theme should be installed. But a system that doesn't have GTK3 installed shouldn't have the Yaru GTK3 theme installed. It may take time for someone to implement either of those. I don't think these are new ideas.
At least at boot time it is currently possible to select your locale (by changing the kernel boot command line): `locales=es_AR.UTF-8 keyboard-layouts=latam,es` or `locales=zh_TW.UTF-8` Not very intuitive, but it works :-)
Towards Debian 14 =============== I believe all my current merge proposals are appropriate to land in Unstable, then landed in Debian 13 point releases. After that, it makes sense to work to reform the language tasks to standardize them and match the default install for CLI and the desktops and allow removing workarounds in the live-tasks packages. This will likely need at least some NEW binary packages.
Agreed. Let's finish the experiment based on 'rebuild.sh' and then it makes sense to get the MRs merged.
Who === I think once new Debian Live installs more closely match non-live installs, I don't think there will be much disagreement about the content of the live images. I have done work in tasksel to give the Debian GNOME team more control over what's installed when someone chooses GNOME in the installer. task-gnome-desktop basically just installs 'gnome' (and a small list of additional task-desktop packages). Cinnamon and GNOME Flashback do this too. I think every desktop task should do this so that decision making and bugs can be handled directly with the desktop's metapackage instead of needing to get changes into a tasksel upload.
That's a good concept. I would also like to have a minimal set of override for the live images. In the Minidebconf25 in Hamburg and in the Debconf25 in Brest I proposed (paraphrased): "Let's define a release target: have the desktop environment tested in openQA and make that a criterium for being included in tasksel" So far I've been swamped in other tasks, but at least during the Outreachy project we managed to get increase the amount of desktop environment under test from 2 to 5. My goal would be that all desktop environments (for which we generate live images) would be tested in openQA. With kind regards, Roland Clobus
OpenPGP_signature.asc
Description: OpenPGP digital signature
