Hello installer team,
I've noticed that (currently as draft) preparations [1] are ongoing
to add Lomiri as task-lomiri-desktop into task-desktop.
Is it intended to have Lomiri available in the installer and to have
live images?
If so, it would need some coordination to have it all set up. (I'm
thinking of d-i, regular builds, openQA, Jenkins, live-build, ...)
With kind regards,
Roland Clobs
[1] https://salsa.debian.org/installer-team/tasksel/-/merge_requests/30/
The plan is indeed to propose Lomiri as possible selection for a
desktop environment in D-I.
Unfortunately, I don't know what steps are required to get Lomiri in.
Neither do I know who has a say in this, where it gets decided what
gets included as installer option in D-I and what not.
The Lomiri Operating Environment packaging for Debian is currently seeing quite a boot because we have found a sponsor that finance the related work.^^^^
Mike Gabriel <[email protected]> (2024-05-22):
The Lomiri Operating Environment packaging for Debian is currently seeing^^^^
quite a boot because we have found a sponsor that finance the related work.
Good one!
In d-i, pkgsel starts tasksel, so if that's available in tasksel…
Hi,
Cyril Brulebois <[email protected]> (2024-05-22):
In d-i, pkgsel starts tasksel, so if that's available in tasksel…
so we're one year later, there was quite some traffic on the MR, but
nobody seems to have requested merging this as it is, confirming it's
in a suitable enough state to get published to the masses:
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/30
Similar story on the Phosh thing, which was never even mentioned on this list:
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/29
If we were much earlier in the release cycle, we could consider “work
in progress” quality tasks, but we're near the end, we would add to introduce new binary packages (which per freeze policy was already
forbidden since the previous step), so I'm tempted to call all of this
too late.
Unless someone strongly feels differently, and convinces me to rethink
this, I'll drop both entries from the wishlist for Trixie.
Similar story on the Phosh thing, which was never even mentioned on this list:
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/29
If we were much earlier in the release cycle, we could consider “work
in progress” quality tasks, but we're near the end, we would add to introduce new binary packages (which per freeze policy was already forbidden since the previous step), so I'm tempted to call all of this
too late.
Don't know anything about Phosh status, but it would probably be good to Cc: @agx on this. (Done for this mail).
Unless someone strongly feels differently, and convinces me to rethink this, I'll drop both entries from the wishlist for Trixie.
I raise my hand here, because I strongly feel different regarding the Lomiri part of this mail. Thanks for sending this mail, so there still is some chance to turn the wheel (hopefully!).
cheers,
Mike
--
mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31
mail: [email protected], http://sunweavers.net
Hi,
If we were much earlier in the release cycle, we could consider “work
in progress” quality tasks, but we're near the end, we would add to >introduce new binary packages (which per freeze policy was already
forbidden since the previous step), so I'm tempted to call all of this
too late.
Unless someone strongly feels differently, and convinces me to rethink
this, I'll drop both entries from the wishlist for Trixie.
I have sort of asked for Lomiri inclusion in tasksel and installer
here three weeks ago: https://salsa.debian.org/installer-team/tasksel/-/merge_requests/30#note_609616
(and below).
The missing bit mentioned there has been fixed by Guido directly after my request, so the MR is good to go from the Lomiri packagers' perspective.
In Lomiri & co themselves, we still have various work items on the list (improving session stability, usability and Debian branding), but this is unrelated to this MR.
I also plan to ask the release team for a Debian Edu exception regarding inclusion of an extra bin:pkg education-desktop-lomiri the coming week (unrelated here, just as a side note). The decision regarding Lomiri in tasksel sort of depends on the nature of that education-desktop-lomiri bin:pkg (normally we depend on/recommend the tasksel package and add edu things on top). If there will be no Lomiri tasksel bin:pkg, we will pull in Lomiri packages directly via the education-desktop-lomiri bin:pkg. (Doable, but less preferred).
Similar story on the Phosh thing, which was never even mentioned on this list:
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/29
If we were much earlier in the release cycle, we could consider “work
in progress” quality tasks, but we're near the end, we would add to introduce new binary packages (which per freeze policy was already forbidden since the previous step), so I'm tempted to call all of this
too late.
Don't know anything about Phosh status, but it would probably be good
to Cc: @agx on this. (Done for this mail).
Unless someone strongly feels differently, and convinces me to
rethink this, I'll drop both entries from the wishlist for Trixie.
I raise my hand here, because I strongly feel different regarding the
Lomiri part of this mail. Thanks for sending this mail, so there still
is some chance to turn the wheel (hopefully!).
thanks for adding me in the loop.
As noted in the above merge request I wasn't aware there's a necessity
to raise it on the list. I would have hoped that opening an issue in
gitlab is sufficient as the repository looked active.
Same here. I understand that it's late in the cycle but then the
recent feedback in the MR asking for addition to the Trixie TODO list
made me believe there's nothing else to do for the moment.
Hi,
Guido G�nther <[email protected]> (2025-05-25):
thanks for adding me in the loop.
(Sorry for getting confused by the multiple Guido, would have done on my
own otherwise.)
As noted in the above merge request I wasn't aware there's a necessity
to raise it on the list. I would have hoped that opening an issue in
gitlab is sufficient as the repository looked active.
(Understood, see my other reply.)
Same here. I understand that it's late in the cycle but then the
recent feedback in the MR asking for addition to the Trixie TODO list
made me believe there's nothing else to do for the moment.
Just to confirm, you consider the current state of the MR to be
production ready, and don't anticipate having to tweaks things up
afterwards, be it in tasksel or in the set of packages that's getting
pulled by the prospective task?
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Hallo Mike,
Mike Gabriel <[email protected]> (2025-05-25):
I have sort of asked for Lomiri inclusion in tasksel and installer
here three weeks ago:
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/30#note_609616
(and below).
3 weeks ago was already too late to ask for new binary packages per
freeze policy.
I also plan to ask the release team for a Debian Edu exception regarding
inclusion of an extra bin:pkg education-desktop-lomiri the coming week
(unrelated here, just as a side note). The decision regarding Lomiri in
tasksel sort of depends on the nature of that education-desktop-lomiri
bin:pkg (normally we depend on/recommend the tasksel package and add edu
things on top). If there will be no Lomiri tasksel bin:pkg, we will pull in >> Lomiri packages directly via the education-desktop-lomiri bin:pkg. (Doable, >> but less preferred).
OK.
I might get in touch with the release team regarding the prospective
addition of 1 to 2 tasks in tasksel, to get some feedback on their side.
If they're willing to accept it, we can do that. If they aren't, I'm not going to fight the decision.
Combining this and the Phosh MR[1] ends up looking like this (1024x768):
https://openqa.debian.net/tests/399843#step/choose_software/1
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we
decided to only offer one of those via tasksel.
At the moment, even if it's been growing as of late, the list doesn't
strike me as being “too long” (no, I don't have a precise definition for it). Even with two extra desktop entries, the whole list of choices
would still appear on a single screen, and would be visible without any scrolling. (This is with the graphical installer, on a laptop that's
sticking to 800×600.)
[ cc += Guido Günther ]
Philip Hands <[email protected]> (2025-05-26):
Combining this and the Phosh MR[1] ends up looking like this (1024x768):
https://openqa.debian.net/tests/399843#step/choose_software/1
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we
decided to only offer one of those via tasksel.
Thanks. I think I'd like to have a single entry to start with, maybe the desktop variant?
I haven't looked at either MRs at the moment, but I think I'd like to
have the newest additions at the bottom of the desktop (kinda-sub)list,
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we decided to only offer one of those via tasksel.
Thanks. I think I'd like to have a single entry to start with, maybe the desktop variant? I can understand how hard targeting this or that bit of hardware can be, but I would really expect a desktop environment to have components to figure that out at runtime, instead of having two different sets of packages.
(Thinking out loud, maybe it'd be feasible to skip one of them from d-i,
but offer it when tasksel runs interactively — not from pkgsel —, so that users can switch from say task-lomiri-desktop to task-lomiri-tablet by running tasksel after the install? But if that's mainly about requiring
fewer packages, as opposed to different core components, I'd think that reinforces my initial assessment: propose Lomiri for desktop, leaving it
up to tablet users to either skip desktop entirely, then installing the -tablet task afterwards, or to buy the whole desktop and call it a day?)
I haven't looked at either MRs at the moment, but I think I'd like to
have the newest additions at the bottom of the desktop (kinda-sub)list, instead of having them pop up at some (seemingly) random locations in the existing, non-sorted list. I'd think that's only a matter of adjusting
some priority/score/relevance integer that I vaguely remember, though, so that should be on the easy side of things.
- What happens, if both are installed at the same time? Any harm expected?
- Is Debian an OS common for touch devices (= tablets)? I personally
would go with the desktop variant only, if installing both is not good.
- If we do not install both in parallel (with one entry), I would change to
something like
- Lomiri for desktop
- Lomiri for tablet
to make clear to the user, what they have to expect.
I think placing such new entries between "LXQt" and "web server"
(at the bottom of the DE list) would be good and easy to realize.
- What happens, if both are installed at the same time? Any harm expected? >> - Is Debian an OS common for touch devices (= tablets)? I personally
would go with the desktop variant only, if installing both is not good.
All good questions.
Seeing how adding Phosh would close #593105, it seems we would already
be gaining support for smartphone/tablet-like hardware, in a different
way…
- If we do not install both in parallel (with one entry), I would change to >> something like
- Lomiri for desktop
- Lomiri for tablet
to make clear to the user, what they have to expect.
(Clear descriptions might make sense in any case?)
[ cc += Guido Günther ]
Philip Hands <[email protected]> (2025-05-26):
Combining this and the Phosh MR[1] ends up looking like this (1024x768):
https://openqa.debian.net/tests/399843#step/choose_software/1
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we decided to only offer one of those via tasksel.
Thanks. I think I'd like to have a single entry to start with, maybe the desktop variant? I can understand how hard targeting this or that bit of hardware can be, but I would really expect a desktop environment to have components to figure that out at runtime, instead of having two different sets of packages.
(Thinking out loud, maybe it'd be feasible to skip one of them from d-i,
but offer it when tasksel runs interactively — not from pkgsel —, so that users can switch from say task-lomiri-desktop to task-lomiri-tablet by running tasksel after the install? But if that's mainly about requiring
fewer packages, as opposed to different core components, I'd think that reinforces my initial assessment: propose Lomiri for desktop, leaving it
up to tablet users to either skip desktop entirely, then installing the -tablet task afterwards, or to buy the whole desktop and call it a day?)
I haven't looked at either MRs at the moment, but I think I'd like to
have the newest additions at the bottom of the desktop (kinda-sub)list, instead of having them pop up at some (seemingly) random locations in the existing, non-sorted list. I'd think that's only a matter of adjusting
some priority/score/relevance integer that I vaguely remember, though, so that should be on the easy side of things.
Thoughts on both topics? (The first one might be a hard one, the second
one should be mostly cosmetics?)
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
Hi,
Am 27. Mai 2025 01:47:15 MESZ schrieb Cyril Brulebois <[email protected]>: >Holger Wansing <[email protected]> (2025-05-26):
- What happens, if both are installed at the same time? Any harm expected? >> - Is Debian an OS common for touch devices (= tablets)? I personally
would go with the desktop variant only, if installing both is not good.
All good questions.
However I expect answers not only by you but by lomiri people...
Seeing how adding Phosh would close #593105, it seems we would already
be gaining support for smartphone/tablet-like hardware, in a different >way…
- If we do not install both in parallel (with one entry), I would change to
something like
- Lomiri for desktop
- Lomiri for tablet
to make clear to the user, what they have to expect.
(Clear descriptions might make sense in any case?)
Since Phosh is a "special case desktop", maybe say " Phosh (for
smartphones) ?
Holger
--
Sent from /e/ OS on Fairphone3
Cyril Brulebois <[email protected]> writes:
[ cc += Guido Günther ]
Philip Hands <[email protected]> (2025-05-26):
Combining this and the Phosh MR[1] ends up looking like this (1024x768): >>>
https://openqa.debian.net/tests/399843#step/choose_software/1
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we
decided to only offer one of those via tasksel.
Thanks. I think I'd like to have a single entry to start with, maybe the
desktop variant?
Makes sense to me -- How well does using D-I on a tablet actually work anyway? (There's not much point having the option if it's the case that people generally prefer to create an image to flash, or some such)
I haven't looked at either MRs at the moment, but I think I'd like to
have the newest additions at the bottom of the desktop (kinda-sub)list,
That would have the (somewhat trivial) benefit of avoiding the need to
fiddle with the openQA tests for existing desktops.
They currently include the menu options as a list, and use that to work
out how often to press `down` to get to the option we want. Having to
have multiple versions of that table, and then try to work out which
ordering we're looking at this time, is going to be a little tiresome.
Of course, if there's a good reason to reorder the existing options,
then that will need to be done, but if not, let's not :-)
[ cc += Guido Günther ]
Philip Hands <[email protected]> (2025-05-26):
Combining this and the Phosh MR[1] ends up looking like this (1024x768):
https://openqa.debian.net/tests/399843#step/choose_software/1
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we
decided to only offer one of those via tasksel.
Thanks. I think I'd like to have a single entry to start with, maybe the desktop variant?
I can understand how hard targeting this or that bit of
hardware can be, but I would really expect a desktop environment to have components to figure that out at runtime, instead of having two different sets of packages.
(Thinking out loud, maybe it'd be feasible to skip one of them from d-i,
but offer it when tasksel runs interactively — not from pkgsel —, so that users can switch from say task-lomiri-desktop to task-lomiri-tablet by running tasksel after the install? But if that's mainly about requiring
fewer packages, as opposed to different core components, I'd think that reinforces my initial assessment: propose Lomiri for desktop, leaving it
up to tablet users to either skip desktop entirely, then installing the -tablet task afterwards, or to buy the whole desktop and call it a day?)
I haven't looked at either MRs at the moment, but I think I'd like to
have the newest additions at the bottom of the desktop (kinda-sub)list, instead of having them pop up at some (seemingly) random locations in the existing, non-sorted list. I'd think that's only a matter of adjusting
some priority/score/relevance integer that I vaguely remember, though, so that should be on the easy side of things.
Thoughts on both topics? (The first one might be a hard one, the second
one should be mostly cosmetics?)
Hi,
Cyril Brulebois <[email protected]> wrote (Mon, 26 May 2025 22:52:22 +0200):
Lomiri currently appears twice, so that is 3 new entries with Phosh.
BTW The descriptions for the 2 Lomiri tasks need to be fixed, in order
to distinguish between the `desktop` and `tablet` variants, unless we
decided to only offer one of those via tasksel.
- What happens, if both are installed at the same time? Any harm expected?
- Is Debian an OS common for touch devices (= tablets)? I personally
would go with the desktop variant only, if installing both is not good.
- If we do not install both in parallel (with one entry), I would change to
something like
- Lomiri for desktop
- Lomiri for tablet
to make clear to the user, what they have to expect.
Thanks. I think I'd like to have a single entry to start with, maybe the
desktop variant? I can understand how hard targeting this or that bit of
hardware can be, but I would really expect a desktop environment to have
components to figure that out at runtime, instead of having two different
sets of packages.
(Thinking out loud, maybe it'd be feasible to skip one of them from d-i,
but offer it when tasksel runs interactively — not from pkgsel —, so that
users can switch from say task-lomiri-desktop to task-lomiri-tablet by
running tasksel after the install? But if that's mainly about requiring
fewer packages, as opposed to different core components, I'd think that
reinforces my initial assessment: propose Lomiri for desktop, leaving it
up to tablet users to either skip desktop entirely, then installing the
-tablet task afterwards, or to buy the whole desktop and call it a day?)
I haven't looked at either MRs at the moment, but I think I'd like to
have the newest additions at the bottom of the desktop (kinda-sub)list,
instead of having them pop up at some (seemingly) random locations in the
existing, non-sorted list. I'd think that's only a matter of adjusting
some priority/score/relevance integer that I vaguely remember, though, so
that should be on the easy side of things.
I think placing such new entries between "LXQt" and "web server"
(at the bottom of the DE list) would be good and easy to realize.
Holger Wansing <[email protected]> (2025-05-26):
- What happens, if both are installed at the same time? Any harm expected? >> - Is Debian an OS common for touch devices (= tablets)? I personally
would go with the desktop variant only, if installing both is not good.
All good questions.
Seeing how adding Phosh would close #593105, it seems we would already
be gaining support for smartphone/tablet-like hardware, in a different
way…
- If we do not install both in parallel (with one entry), I would change to >> something like
- Lomiri for desktop
- Lomiri for tablet
to make clear to the user, what they have to expect.
(Clear descriptions might make sense in any case?)
… and depending on your goals on the Lomiri side, maybe we could do the opposite of what I was suggesting earlier: propose something small from
the installer, and let desktop users “upgrade” their systems by pulling task-lomiri-desktop afterwards if they so chose?
I think placing such new entries between "LXQt" and "web server"
(at the bottom of the DE list) would be good and easy to realize.
Right, that's what I had in mind, thanks for expressing it in a much
clearer way.
Having now looked, desktops are defined with:
Parent: desktop
then sorted by the Relevance field, possibly then alphabetically. For example, both LXDE and LXQt have:
Relevance: 9
and are sorted in this order, at the bottom of the desktop list.
So I'd expect the following to be sufficient to sort things as desired
(by at least Holger, Philip, and me):
- For Lomiri (for the single task we would pick):
-Relevance: 2
+Relevance: 10
- For Phosh:
-Relevance: 8
+Relevance: 11
… except I wasn't sure about allowed values and README has:
If a task is important enough that it should go near the top,
give it a relevance of 1. If a task is not likely to be
used, give it a relevance of 9. Default is 5. Relevance can only be a
single digit.
so if that's indeed a hard limitation (and we don't want to touch it),
we might need to renumber things a little.
- GNOME: 1
- Xfce: 2
- GNOME Flashback: 7
- KDE Plasma: 7
- Cinnamon: 8
- MATE: 8
- LXDE: 9
- LXQt: 9
A very quick search suggests supporting 10+ values has been left as a
todo item:
# XXX TODO: support correct sorting when
# Relevance is 10 or more (e.g. package
# education-tasks).
so in case that's confirmed to be problematic, moving everyone up (by
how many units is left as an exercise to the reader) from 7-9 to make
room at position 9 for both Lomiri and Phosh should work.
We still need to hear back from the RT in any case.
Cyril Brulebois <[email protected]> (2025-05-27):
… and depending on your goals on the Lomiri side, maybe we could do the
opposite of what I was suggesting earlier: propose something small from
the installer, and let desktop users “upgrade” their systems by pulling >> task-lomiri-desktop afterwards if they so chose?
For now, I've decided to go with Lomiri = the real desktop.
so if that's indeed a hard limitation (and we don't want to touch it),
we might need to renumber things a little.
- GNOME: 1
- Xfce: 2
- GNOME Flashback: 7
- KDE Plasma: 7
- Cinnamon: 8
- MATE: 8
- LXDE: 9
- LXQt: 9
A very quick search suggests supporting 10+ values has been left as a
todo item:
# XXX TODO: support correct sorting when
# Relevance is 10 or more (e.g. package
# education-tasks).
so in case that's confirmed to be problematic, moving everyone up (by
how many units is left as an exercise to the reader) from 7-9 to make
room at position 9 for both Lomiri and Phosh should work.
I've prepared a desktop-integration branch:
- adjusting the description for the tablet one only:
https://salsa.debian.org/installer-team/tasksel/-/commit/c45ed5a55553da4b8eaeade606ff6182844854cb
- introducing a test stub to hide the tablet from within the
installer (only): https://salsa.debian.org/installer-team/tasksel/-/commit/4f2f6c350701f9630e646afdae60a946645f7c74
- making sure existing desktops stay in the same order while making
room for new ones: https://salsa.debian.org/installer-team/tasksel/-/commit/eaa7aa4f174d5cda48f6ef951efff432d5b8841d
- ensuring Lomiri and Phosh are at the bottom: https://salsa.debian.org/installer-team/tasksel/-/commit/a966e23d3e140bec3b607f8588a4fd385408599c
- documenting what I did:
https://salsa.debian.org/installer-team/tasksel/-/commit/e0a0bc36375281061956fce59c7d9a35764894f9
This seems to behave as I intended it, see attached screenshots during (grayscaled) and after installation. (Note that I unmarked all tasks
that had been initially marked for installation, so the empty
selection in the second screenshot is entirely normal.)
Would that make sense for Lomiri people? Or would you prefer another
approach regarding the full vs. tablet Lomiri tasks?
We still need to hear back from the RT in any case.
Still true.
This looks awesome! In your screenshot (text mode) you still have Lomiri + Lomiri on tablet. I think we should just have Lomiri (on desktop), as proposed above for now. Having Lomiri more than once feels over-spacetaking...
Would that make sense for Lomiri people? Or would you prefer another approach regarding the full vs. tablet Lomiri tasks?
No, this looks really good. Go ahead + BIG THANKS!!!!
We still need to hear back from the RT in any case.
Still true.
Hope they agree on having this. It would be a pain with all the work
that went into your (and Guido Berhörster's work). Thanks once more,
this is much appreciated!!!
Hi,
Mike Gabriel <[email protected]> (2025-05-27):
This looks awesome! In your screenshot (text mode) you still have Lomiri + >> Lomiri on tablet. I think we should just have Lomiri (on desktop), as
proposed above for now. Having Lomiri more than once feels
over-spacetaking...
Sorry if that wasn't clear: that's not the installer in text mode (which would present the same choices as the graphical one), that's tasksel run manually after logging into the installed system. Basically covering the second part of one of your first replies:
Thanks for the loud thinking. How can D-I be tweaked to only show
the lomiri desktop task, but not the tablet task. (I don't know the
internal wiring between tasksel and D-I).
→ new-tasksel-during.png (tasksel started by pkgsel, in d-i)
It would be nice to leave the lomiri tablet task in the tasksel
package while omitting it from D-I. Is that possible?
→ new-tasksel-after.png (tasksel started manually, outside d-i)
If you prefer omitting it from tasksel entirely, requiring prospective
users to `apt-get install` the task, that's entirely possible… that's
just not what I was proposing, and not was I understood you were asking
for. :)
We still need to hear back from the RT in any case.
Still true.
Hope they agree on having this. It would be a pain with all the work
that went into your (and Guido Berhörster's work). Thanks once more,
this is much appreciated!!!
The work will still be there for sid and forky in any case, so nothing
would be lost. :)
On Di 27 Mai 2025 15:43:32 CEST, Cyril Brulebois wrote:
The work will still be there for sid and forky in any case, so
nothing would be lost. :)
Would be nice to see this land in trixie, though. Keeping fingers crossed!
Hi,
Mike Gabriel <[email protected]> (2025-05-27):
On Di 27 Mai 2025 15:43:32 CEST, Cyril Brulebois wrote:
The work will still be there for sid and forky in any case, so
nothing would be lost. :)
Would be nice to see this land in trixie, though. Keeping fingers crossed!
Unfortunately, that wasn't sufficient.
Besides the timing, and assuming I got the picture right, considering
those additions would require:
(1) extending the set of key packages, which the release team is
(quite rightfully I think) reluctant to consider at this late
stage of the release cycle.
or:
(2) adjusting the logic that computes that set automatically, to
special case the new packages, which wouldn't feel much better…
You can find more details in the small thread on the debian-release@
list (6 mails total as of right now):
https://lists.debian.org/debian-release/2025/05/msg01153.html
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 714 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 142:09:03 |
| Calls: | 12,088 |
| Calls today: | 1 |
| Files: | 14,998 |
| Messages: | 6,517,451 |