Simon, thanks for the extensive reply. > If this isn't implicated in any
user-visible problem, then it's almost > certainly harmless, and definitely not
Severity: important. The main user-visible problem on my computer these days is
that X11 is used instead of Wayland, and the only big action of mine was
upgrading to Debian 12 from Debian 11 (with a few packages from Debian 12).
Before we get to the first Wayland-related message in the log in some
yet-to-be-written bug report, we better deal with all the visible warnings,
errors, and failures, one by one, that happen earlier because an issue
happening at time 𝑡 may potentially be (and sometimes is) a consequence of
failures happening at times < 𝑡. Dealing with issues one by one, starting with
the earliest, is usually the technically most _proper_ way to deal with
software. (Ideally, we'd better start even with the high-level architecture of
the GUI, but it's too far from the specific topic here.) > The gdm display
manager runs gnome-shell in a special mode to provide > its "greeter" (login
prompt) user interface, but there isn't really > any state in that session that
would be useful to save, so the fact that > gdm can't load a saved state is not
doing anyone any harm. If my memory serves me right, at least the state of the
Num Lock was saved in certain older Debian versions. I'm going to double check
on this. > Arguably the fact that it tries to load a saved session file and
logs a > message while in this special mode is a minor bug, but gnome-shell is
a > large, user-facing component with many more users than developers, and > as
a result, a very large number of bug reports that are more serious > than this
one. > > If this offends you, then you could do the research into why this is >
appearing and send a merge request upstream to silence it; but please > bear in
mind that even if you take the time to do that, the time needed > for a
developer to review whether that contribution is correct would be > time that
they cannot spend on something with a higher impact, like for > example
diagnosing and fixing a crash. A crash is sometimes (of course, not always) a
consequence of an accumulation of issues which happened earlier. (What I
personally learned by looking into the documentation of failures of
safety-critical or security-critical applications is that for such
applications, a hard failure can _always_, to the extent of my knowledge, be
contributed to a combination of issues, and that these hidden issues are very
difficult to figure out only from the user-visible symptoms; sometimes the root
causes are never found.) What you said, essentially, means that resources
(here, time) might lack to develop a system the proper way. I fully and
completely understand; no argument here. At the same time, this lack of
resources is more an organizational problem and less a technical one. (The
question of how to organize software development, in particular open-source
software development, in such a way that the technically ideal path will be
followed with little resources available is both extremely important and
difficult. In my view, the sheer multitude of > 80K bugs on www.debian.org/Bugs
is not only due to the size of Debian but also a result of the inability to
find and follow the technically ideal path. This is not specific to Debian;
other software projects suffer similarly. In short, the situation is already
bad, and it will get only worse if the current method of software development
continues. I'm not going to discuss this question here further, as this would
lead us too far away from the topic.) Practically and pragmatically, given the
fact that some folks develop a piece of software (here: Gnome) mainly because
this is what they want to do (and not only because they have to do it, e.g., to
get paid), I hope that I'm providing these folks with feedback. Given that I'm
dealing with tons of issues myself, I'm probably doing already more than the
majority of Gnome users. It's impossible for me to do more now (otherwise I
simply run out of time, sleep, health, and money); even reporting all the
red-colored failures in the journal is highly likely to be out of my reach. I
hope that if at any point a developer decides to look into any particular issue
or a combination of issues, he/she gets the logs he/she needs. In this case,
the corresponding bug report(s) will be of help. I apologize if my bug reports
sound too harsh (I guess, I have felt simply overwhelmed and extremely
helpless; I promise to express myself more professionally). > This is unlikely
to be fixed as a Debian-specific change. Any change has a > risk of causing
regressions, so we have to weigh up that risk against the > benefit of fixing a
bug. If the bug is minor, then the maximum possible > benefit is very small, so
any risk at all would be a problem. I get it. At the same time, in my
understanding, this is what Debian *experimental* and then Debian *sid* are
made for. If eventually a fix is available (say, from the original authors
upstream), I don't see any reason for you to reject it, even if it lands only
in, e.g., Debian 12.5 or in Debian 13. After all, you really don't wish to say
that you wouldn't welcome it if the session-saving-and-restoring functionality
gets either fixed or removed. (If, for whatever reason, a piece of software
can't be fixed, it must be removed, because running useless/faulty pieces of
software is both a risk and a waste by itself. E.g., counting the contribution
of the bugs worldwide to the exhaust of the carbon dioxide into the atmosphere
is a sobering exercise. Again, let me not go off the topic here.) An aside: the
situation might – purely hypothetically, of course – turn out to be even worse,
namely if the offending message “Window manager warning: Failed to parse saved
session file: …” does _not_ reflect what really happens, thus leading us all
astray. Having said this, could I kindly ask you whether it is possible for you
to at least remove the wonfix tag and perhaps raise the severity again, for
example, to normal? Gratefully, AlMa
