GNOME Bugzilla – Bug 677118
No visible info when GdmGreeter is missing
Last modified: 2012-09-15 09:29:40 UTC
A little issue exploited by jhbuild[1], when gdm is missing gnome-shell fails to start with no visibile info, just the following info in ~/.xsession-errors JS ERROR: !!! Exception was: Error: Requiring GdmGreeter, version none: Typelib file for namespace 'GdmGreeter' (any version) not found JS ERROR: !!! lineNumber = '0' JS ERROR: !!! fileName = '"gjs_throw"' JS ERROR: !!! stack = '"("Requiring GdmGreeter, version none: Typelib file for namespace 'GdmGreeter' (any version) not found")@gjs_throw:0 @/opt/gnome3/share/gnome-shell/js/ui/userMenu.js:4 [1] https://mail.gnome.org/archives/release-team/2012-May/msg00029.html
We require libgdmgreeter.
Created attachment 215279 [details] [review] userMenu: Deal with missing GdmGreeter typelib Here's a patch that allows gnome-shell to run without the GdmGreeter typelib, though I honestly don't like to jump through hoops to deal with arbitrarily missing core components (where "arbitrary" means "not included in Ubuntu's default install"). The "non-visible info" when GdmGreeter is missing is exactly the same as with GnomeDesktop, AccountsService, ... So I'd prefer this patch to be dropped (or applied downstream) and GdmGreeter be declared a runtime dependency (note that we don't require gdm to be actually *running*, having libgdmgreeter installed is enough)
(In reply to comment #2) > Here's a patch that allows gnome-shell to run without the GdmGreeter typelib, > though I honestly don't like to jump through hoops to deal with arbitrarily > missing core components (where "arbitrary" means "not included in Ubuntu's > default install"). I think the problem is not "Ubuntu or not Ubuntu?" but simply: if you miss a piece at runtime you have a blank screen -- well, blue striped, to be honest :) -- and no info about what's happened. I suppose the same could occur if, for instance and just as example, gnome-shell (installed with jhbuild) will need gdm 3.x and you have in /usr gdm 3.x-1 We don't have an official GNOME OS build by now, so we have to deal with distros and software currently installed on developers' machines. > So I'd prefer this patch to be dropped (or applied downstream) and GdmGreeter > be declared a runtime dependency (note that we don't require gdm to be actually > *running*, having libgdmgreeter installed is enough) Yes, this could be interesting for downstream and distros (maybe you could link this bug and related info on distributor mailing list), while they can simply make a separated libgdmgreeter, but doesn't solve the issue: no gdm and jhbuild makes gnome-shell fails to launch :) A message at configure time (while it's no more visibile then .xsession-errors)? A error dialog when you start the session? The fail wale page? An explicit dependence of gnome-shell from gdm?
(In reply to comment #3) > > Yes, this could be interesting for downstream and distros (maybe you could link > this bug and related info on distributor mailing list), while they can simply > make a separated libgdmgreeter, but doesn't solve the issue: no gdm and jhbuild > makes gnome-shell fails to launch :) Sorry, I meant: dropping the patch doesn't solve the issue...
Created attachment 215295 [details] [review] userMenu: Deal with missing/incompatible GdmGreeter typelib (In reply to comment #3) > I think the problem is not "Ubuntu or not Ubuntu?" but simply: if you miss a > piece at runtime you have a blank screen -- well, blue striped, to be honest :) > -- and no info about what's happened. Yes, but as mentioned before the same is true for every library we only use via its typelib. Currently those are accountsservice, caribou, gdmgreeter and upower-glib - so far there haven't been any complaints about not handling missing runtime dependencies gracefully, so I do wonder why gdmgreeter is different. > I suppose the same could occur if, for instance and just as example, > gnome-shell (installed with jhbuild) will need gdm 3.x and you have in /usr gdm > 3.x-1 Yes, but then the same may happen for gsd 3.x-1, gnome-session 3.x-1 etc. (unlike gdm, it doesn't suck to build those from jhbuild, but stuff may still go horribly wrong when mixing jhbuild shell with running system gsd/gnome-session). We do have a precedent with NetworkManager though - not accidentally another component that sucks badly with jhbuild :-) So here's a patch version that's less ugly (IMHO), which I'm actually attaching for review: Like NetworkManager, GDM is difficult to build/run from jhbuild, so we pretty much rely on system versions. But while we deal gracefully with a missing or incompatible NetworkManager, we currently fail in case of GdmGreeter - handle this case gracefully as well.
NetworkManager is not (yet?) a sanctioned GNOME dependency. gdm is.
The way Mageia does it: $ rpm -q gnome-shell --requires | grep typelib typelib(AccountsService) typelib(Atk) typelib(Atk) = 1.0 typelib(Caribou) etc so those runtime things should be handled automatically (something parses the javascript IIRC).
(In reply to comment #5) > its typelib. Currently those are accountsservice, caribou, gdmgreeter and > upower-glib - so far there haven't been any complaints about not handling > missing runtime dependencies gracefully, so I do wonder why gdmgreeter is > different. Yeah, I was checking module definitions and it seems an unfortunate and corner case in jhbuild. Currently accountservice, caribou and upower are strict dependencies for gnome-shell, while actually you don't need them at build time (at least configure time); gdm, instead, is placed only in core-os-services metamodule. From a jhbuild point of view we could move modules not needed at build time in <suggests> section of gnome-shell module and add gdm to same section. This way, the only unhandled scenario is when you have missing gdm in /usr and gdm build failure with jhbuild. However the ability to deal with missing system or session services could be a great addition, IMHO.
I don't really think we should support this. While I hate making GNOME harder to build, this is really bad. I wonder if we could split gdmgreeter into its own project? It's already a standalone library, pretty much (and I think Giovanni is porting it to GDBus for the Lock Screen)
(In reply to comment #9) > I don't really think we should support this. I'm not exactly sure what "this" is in this context - I agree that gdmgreeter is a perfectly fine runtime dependency (hey, I've added it in the first place :-), more so as the only method we use here should work perfectly fine when using kdm or lightdm instead of gdm; however it feels really odd to me that we can jhbuild a working shell without having glib/gtk+/clutter installed, but require gdm ... > I wonder if we could split gdmgreeter into its own project? That, or just depend on gdm in the moduleset - it's just hard (or impossible?) to run the built gdm, building it is not at all a problem.
(In reply to comment #10) > That, or just depend on gdm in the moduleset - it's just hard (or impossible?) > to run the built gdm, building it is not at all a problem. Oh, OK. I thought for some reason people were having trouble building it. That's fine by me.
The moduleset has been updated to suggest gdm - not to mention that we now depend on libgdm a lot more, so the patch doesn't fix anything for anyone anymore anyway. So let's WONTFIX this bug and focus on fixing bug 683060 :-)