Hi Jan, Am Freitag, den 25.06.2010, 00:18 +0200 schrieb Jan Vornberger: > On Sat, Jun 19, 2010 at 10:19:58PM +0200, Joachim Breitner wrote: > > Maybe the bluetile-gnome.desktop file can be modified such that is > > ignored if /usr/bin/gnome-session is not present. I think there is a > > field for that... You could play with "TryExec", see > > http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html > > > > The second question is how to make gnome use bluetile for just this > > session. Possibly by starting bluetile, which then starts gnome-session > > and somehow prevents metacity from starting? But sounds not very clean > > to me. > > I found out that one way is to set the environment variable > WINDOW_MANAGER before invoking gnome-session. > I created a solution based on this approach. A gnome-bluetile desktop > file which invokes a binary called 'gnome-bluetile-session' which sets > the WINDOW_MANAGER variable and execs gnome-session. > I decided to make gnome-bluetile-session a small binary so that I can > compile in the correct path to Bluetile. I already created a man page > for that new binary. The desktop file is in the repository as > misc/gnome-bluetile-session.desktop. Sounds good. I removed the debian/bluetile-session.desktop file and installed your gnome-bluetile-session.desktop as /usr/share/xsessions/gnome-bluetile.desktop. I guess there is no need for a pure bluetile session .desktop file. > I played aroung with TryExec and included it in the gnome-bluetile > desktop file. It sort of seems to work. GDM displays 'GNOME + Bluetile' > when the TryExec binary is found. If it's not found it just shows > 'gnome-bluetile.desktop' instead - the name of the desktop file. So > there is _some_ effect, but obviously it should hide the entry > completely. Should I file a bug against GDM? Yes, that would be good. > I moved your desktop files into the Bluetile repository. I hope you > don't mind? They might be helpful for other distributions as well. I > would think that both the Bluetile standalone as well as the GNOME + > Bluetile option could be included in the package, right? Do you expect that people want to run bluetile without GNOME? Such power users probably want to configure their WM and will use xmonad directly. > So in summary, the following desktop files are now in Bluetile's > repository: > > misc/bluetile.desktop > > misc/bluetile-session.desktop > install as /usr/share/xsessions/bluetile.desktop (as the package > does currently) > > misc/gnome-bluetile-session.desktop > install as /usr/share/xsessions/gnome-bluetile.desktop > > I hope this solution is acceptable for the Debian package. Yes, it’s very good! I also made the bluetile package suggest gnome-core, so that people are hinted that these two go well together. > Learning from bug #586284 I also improved the documentation a little > bit. The repository now contains a README file. Maybe that can go into > /usr/share/doc/bluetile. It will. I took the liberty to adjust it slightly for the Debian package (where no cabal install is needed and bluetile is in the path). > And finally I extended my Cabal hooks to also run if 'cabal copy' is > used and move the binaries to libexec in that case as well. I would be > interested to know if that works for you and makes moving the binaries > manually by the Debian package unnecessary. Looks good, thanks. > Side note: I originally had hoped to be able to just hook into postCopy, > because I figured 'cabal install' is just register + copy (as the > documentation claims). But it turns out that the postCopy hook _only_ > runs when you invoke 'cabal copy' and the postInstall hook _only_ runs > when you invoke 'cabal install'. So to make this work both for people > installing with cabal as well as distributions using 'cabal copy' I had > to create two hooks now. I find this highly confusing. I might file a > bug against Cabal later - at least as a note to others. Yes, I had expected the same behavior. It is probably worth a bug report, although I assume that they won’t break the API before a major release. > All the changes above are available as Bluetile 0.4.2 in this tar file: > http://code.haskell.org/~jav/releases/bluetile-0.4.2.tar.gz Packaged and uploaded. Again, please make sure to upload exactly this package as 0.4.2 to hackage, otherwise our packaging scripts might be upset. > One question here: I created a new version now, but If I do changes like > that which are targeted at making distribution easier, I would like to > run them by you, Joachim, to see if anything else needs changing before > actually creating a new release. So I don't have to run through version > numbers unnessary just for small fixes. How would I do that so that it's > most convenient for you? Create a release candidate tarball? or just let > you know that you can pull from the darcs repository? If anything, I’d prefer a tarball, as the creation of a tarball from a darcs repository can also be the source of errors. But I don’t expect the packaging related stuff to change drastically often and I’d say just release your version without extra round-trips with us. In all but a very few cases, you will not have to upload small fixes. And if there are minor problems, I can just patch them for one version of the Debian package. Greetings and thanks, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata
Attachment:
signature.asc
Description: This is a digitally signed message part