Ubuntu, Xmonad, and Xinerama

newer
slides for my upcoming xmonad talk...

Chris Sanner

18 Mar 2008 18 Mar '08

11:47 a.m.

So color me a newbie, to xmonad, haskell, programming, etc. I was running the unofficial xmonad package for gutsy, but upgraded to hardy heron and their included versions of xmonad and associated haskell libraries (right term?) because it appeared to be more cleanly set up to modify my xmonad install. Unfortunately, when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces. The digging I've done on google suggested that libghc6-x11 is built without xinerama support, but i found: /usr/lib/X11-1.4.1/ghc-6.8.2/Graphics/X11/Xinerama.hi in the package. There were a lot of scripts and commands suggested to be run, but I need a few more basic pieces to the instruction before I can run those - any help would be appreciated, and I'm willing to run (and probably install) most anything to get it right. I'd *prefer* not to step too far outside the boundaries of the debs, but would be willing to do so to submit patches/bug reports upstream. Thanks in advance. -- __________________________________________________ Christopher Sanner | mailto:hitch@propheteer.org Phone :571-277-0206 | http://propheteer.org/ The universe is like a grapefruit -- it's yellow and dimply, and some people have half of one for breakfast.

Show replies by date

Joachim Breitner

18 Mar 18 Mar

12:16 p.m.

Hi, Am Dienstag, den 18.03.2008, 11:47 -0400 schrieb Chris Sanner:

...

So color me a newbie, to xmonad, haskell, programming, etc. I was running the unofficial xmonad package for gutsy, but upgraded to hardy heron and their included versions of xmonad and associated haskell libraries (right term?) because it appeared to be more cleanly set up to modify my xmonad install. Unfortunately, when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces.

The digging I've done on google suggested that libghc6-x11 is built without xinerama support, but i found: /usr/lib/X11-1.4.1/ghc-6.8.2/Graphics/X11/Xinerama.hi in the package.

There were a lot of scripts and commands suggested to be run, but I need a few more basic pieces to the instruction before I can run those - any help would be appreciated, and I'm willing to run (and probably install) most anything to get it right. I'd *prefer* not to step too far outside the boundaries of the debs, but would be willing to do so to submit patches/bug reports upstream.

Thanks for the report. I guess this problem can be traced back to the Debian package for haskell-x11. I’m not sure if Igloo, haskell-x11’s maintainer, sees a problem in Xinerama support. If not, I’m sure he will fix this in the near future. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469852 You can locally recompile and install (in that order) haskell-x11, xmonad, xmonad-contrib. If you have libxinerama-dev and x11proto-xinerama-dev (not sure which) installed while doing so, you’ll get xinerama support. If you need more detailed instructions, feel free to ask. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Andrew Sackville-West

5:28 p.m.

On Tue, Mar 18, 2008 at 05:16:37PM +0100, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 18.03.2008, 11:47 -0400 schrieb Chris Sanner:

...

...
[...], when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces. ...

...

You can locally recompile and install (in that order) haskell-x11, xmonad, xmonad-contrib. If you have libxinerama-dev and x11proto-xinerama-dev (not sure which) installed while doing so, you’ll get xinerama support. If you need more detailed instructions, feel free to ask.

I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again. A

Andrew Sackville-West

5:59 p.m.

On Tue, Mar 18, 2008 at 02:28:10PM -0700, Andrew Sackville-West wrote:

...

On Tue, Mar 18, 2008 at 05:16:37PM +0100, Joachim Breitner wrote:

...
Hi,

Am Dienstag, den 18.03.2008, 11:47 -0400 schrieb Chris Sanner:

...
...
[...], when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces. ...

...
You can locally recompile and install (in that order) haskell-x11, xmonad, xmonad-contrib. If you have libxinerama-dev and x11proto-xinerama-dev (not sure which) installed while doing so, you’ll get xinerama support. If you need more detailed instructions, feel free to ask.

I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

and just to follow up, there was an upgrade to libxinerama-dev that occured at about the same time as these problems seem to have started... a downgrade of that with a rebuild did not resolve the problem. A

Joachim Breitner

6:58 p.m.

Hi, Am Dienstag, den 18.03.2008, 14:28 -0700 schrieb Andrew Sackville-West:

...

On Tue, Mar 18, 2008 at 05:16:37PM +0100, Joachim Breitner wrote:

...
Hi,

Am Dienstag, den 18.03.2008, 11:47 -0400 schrieb Chris Sanner:

...
...
[...], when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces. ...

...
You can locally recompile and install (in that order) haskell-x11, xmonad, xmonad-contrib. If you have libxinerama-dev and x11proto-xinerama-dev (not sure which) installed while doing so, you’ll get xinerama support. If you need more detailed instructions, feel free to ask.

I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages? Do you have x11proto-xinerama-dev installed? What is the output of the configure step when configuring haskell-x11? For other interested parties: Detailed steps to locally re-build your debian xmonad packages, check http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=469852 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

Andrew Sackville-West

8:15 p.m.

On Tue, Mar 18, 2008 at 11:58:56PM +0100, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 18.03.2008, 14:28 -0700 schrieb Andrew Sackville-West:

...
On Tue, Mar 18, 2008 at 05:16:37PM +0100, Joachim Breitner wrote:

...
Hi,

Am Dienstag, den 18.03.2008, 11:47 -0400 schrieb Chris Sanner:

...
...
[...], when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces. ...

...
You can locally recompile and install (in that order) haskell-x11, xmonad, xmonad-contrib. If you have libxinerama-dev and x11proto-xinerama-dev (not sure which) installed while doing so, you’ll get xinerama support. If you need more detailed instructions, feel free to ask.

I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages?

Do you have x11proto-xinerama-dev installed? What is the output of the configure step when configuring haskell-x11?

this all may be a red-herring... it *appears* that my local xmonad wasn't getting updated because I hadn't changed it or touched it. It's not conclusive as I *had* made some changes to it, but the whole process has gotten so confusing now that I can't confirm either way exactly what happened. Regardless, I am now getting functioning xinerama running the official debian packages. Is it possible that having a custom ~/.xmonad/xmonad.hs that wasn't changed across updates could cause xinerama to fail because ~/.xmonad/xmonad-i386-linux doesn't get rebuilt? A

Joachim Breitner

19 Mar 19 Mar

6:20 a.m.

Hi, Am Dienstag, den 18.03.2008, 17:15 -0700 schrieb Andrew Sackville-West:

...

...
...
I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages?

Do you have x11proto-xinerama-dev installed? What is the output of the configure step when configuring haskell-x11?

this all may be a red-herring... it *appears* that my local xmonad wasn't getting updated because I hadn't changed it or touched it. It's not conclusive as I *had* made some changes to it, but the whole process has gotten so confusing now that I can't confirm either way exactly what happened. Regardless, I am now getting functioning xinerama running the official debian packages.

Sorry to ask for details again: Are you getting xinerama with the unmodified official debian packages or with the debian packages locally re-build?

...

Is it possible that having a custom ~/.xmonad/xmonad.hs that wasn't changed across updates could cause xinerama to fail because ~/.xmonad/xmonad-i386-linux doesn't get rebuilt?

Quite possible, happens to me all the time :-) Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

David Roundy

11:21 a.m.

On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:

...

...
Is it possible that having a custom ~/.xmonad/xmonad.hs that wasn't changed across updates could cause xinerama to fail because ~/.xmonad/xmonad-i386-linux doesn't get rebuilt?

Quite possible, happens to me all the time :-)

Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this. I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed. -- David Roundy Department of Physics Oregon State University

Christopher Sanner

11:24 a.m.

David Roundy wrote:

...

Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

alternatively, could the installation of xmonad or xmonad-contrib could include post-install actions to kick off recompiling?

Roman Cheplyaka

12:02 p.m.

* Christopher Sanner [2008-03-19 11:24:58-0400]

...

David Roundy wrote:

...
Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

alternatively, could the installation of xmonad or xmonad-contrib could include post-install actions to kick off recompiling?

Note that xmonad can be installed system-wide (say, with --prefix=/usr/local) and going to every user's .xmonad does not look sane. -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

David Roundy

12:09 p.m.

On Wed, Mar 19, 2008 at 06:02:14PM +0200, Roman Cheplyaka wrote:

...

* Christopher Sanner [2008-03-19 11:24:58-0400]

...
David Roundy wrote:

...
Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

alternatively, could the installation of xmonad or xmonad-contrib could include post-install actions to kick off recompiling?

Note that xmonad can be installed system-wide (say, with --prefix=/usr/local) and going to every user's .xmonad does not look sane.

As a workaround, however, we could install an empty file as /etc/xmonad, and then we could trigger a recompile whenever this file is newer than xmonad.hs. It might be easier to do this than to figure out where ghc stores its packages to look at their timestamp (which would be the right thing to do). -- David Roundy Department of Physics Oregon State University

Roman Cheplyaka

1:16 p.m.

* David Roundy [2008-03-19 12:09:41-0400]

...

On Wed, Mar 19, 2008 at 06:02:14PM +0200, Roman Cheplyaka wrote:

...
* Christopher Sanner [2008-03-19 11:24:58-0400]

...
David Roundy wrote:

...
Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

alternatively, could the installation of xmonad or xmonad-contrib could include post-install actions to kick off recompiling?

Note that xmonad can be installed system-wide (say, with --prefix=/usr/local) and going to every user's .xmonad does not look sane.

As a workaround, however, we could install an empty file as /etc/xmonad, and then we could trigger a recompile whenever this file is newer than xmonad.hs. It might be easier to do this than to figure out where ghc stores its packages to look at their timestamp (which would be the right thing to do).

1. (Just in case someone will take this approach) Programs (other than editors or package managers) should avoid touching /etc, I believe. So you better use /var. 2. In case of --user install, that file should be placed under ~/.xmonad. It may seem that just touching xmonad.hs is simpler, but... It's not very ethical from my point of view. -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

David Roundy

1:34 p.m.

On Wed, Mar 19, 2008 at 07:16:03PM +0200, Roman Cheplyaka wrote:

...

* David Roundy [2008-03-19 12:09:41-0400]

...
On Wed, Mar 19, 2008 at 06:02:14PM +0200, Roman Cheplyaka wrote:

...
* Christopher Sanner [2008-03-19 11:24:58-0400]

...
David Roundy wrote:

...
Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

alternatively, could the installation of xmonad or xmonad-contrib could include post-install actions to kick off recompiling?

Note that xmonad can be installed system-wide (say, with --prefix=/usr/local) and going to every user's .xmonad does not look sane.

As a workaround, however, we could install an empty file as /etc/xmonad, and then we could trigger a recompile whenever this file is newer than xmonad.hs. It might be easier to do this than to figure out where ghc stores its packages to look at their timestamp (which would be the right thing to do).

1. (Just in case someone will take this approach) Programs (other than editors or package managers) should avoid touching /etc, I believe. So you better use /var. 2. In case of --user install, that file should be placed under ~/.xmonad. It may seem that just touching xmonad.hs is simpler, but... It's not very ethical from my point of view.

Agreed. What do you think of my patch to check the timestamps on the ghc's package files? -- David Roundy Department of Physics Oregon State University

Don Stewart

2:02 p.m.

droundy:

...

On Wed, Mar 19, 2008 at 07:16:03PM +0200, Roman Cheplyaka wrote:

...
* David Roundy [2008-03-19 12:09:41-0400]

...
On Wed, Mar 19, 2008 at 06:02:14PM +0200, Roman Cheplyaka wrote:

...
* Christopher Sanner [2008-03-19 11:24:58-0400]

...
David Roundy wrote:

...
Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

alternatively, could the installation of xmonad or xmonad-contrib could include post-install actions to kick off recompiling?

Note that xmonad can be installed system-wide (say, with --prefix=/usr/local) and going to every user's .xmonad does not look sane.

As a workaround, however, we could install an empty file as /etc/xmonad, and then we could trigger a recompile whenever this file is newer than xmonad.hs. It might be easier to do this than to figure out where ghc stores its packages to look at their timestamp (which would be the right thing to do).

1. (Just in case someone will take this approach) Programs (other than editors or package managers) should avoid touching /etc, I believe. So you better use /var. 2. In case of --user install, that file should be placed under ~/.xmonad. It may seem that just touching xmonad.hs is simpler, but... It's not very ethical from my point of view.

Agreed. What do you think of my patch to check the timestamps on the ghc's package files?

I'm not keen on this. We already decided to restrict the recompilation checking, to not use --make, to only look at xmonad.hs itself. Looking at package.confs is something to consider for ghc --make, but I strongly feel that's not xmonad job. xmonad.recompile isn't a haskell package and build system. Deep recompilation checking would make an interesting extension module, though. And could be used as leverage on the cabal and ghc --make devs. I can point you to the relevant trac tickets for recompilation handling, if you'd like to add more there. -- Don

David Roundy

2:13 p.m.

On Wed, Mar 19, 2008 at 11:02:39AM -0700, Don Stewart wrote:

...

I'm not keen on this. We already decided to restrict the recompilation checking, to not use --make, to only look at xmonad.hs itself.

Looking at package.confs is something to consider for ghc --make, but I strongly feel that's not xmonad job. xmonad.recompile isn't a haskell package and build system.

I'm afraid that xmonad.recompile actually is a haskell build system, whether or not you want it to be one. If we don't want to implement a haskell build system, we shouldn't implement one, rather than implementing a poor build system, and saddling our users with a confusing hard-to-upgrade package. I agree that since the only reason we introduce any timestamp-checking at all is for efficiency we don't want to make it ultra-sophisticated. But it'd be nice if it at least worked in the common case. -- David Roundy Department of Physics Oregon State University

Don Stewart

2 p.m.

droundy:

...

On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:

...
...
Is it possible that having a custom ~/.xmonad/xmonad.hs that wasn't changed across updates could cause xinerama to fail because ~/.xmonad/xmonad-i386-linux doesn't get rebuilt?

Quite possible, happens to me all the time :-)

Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

If in doubt, recompile.

...

I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

that's a long open ticket for cabal, and I'm not keen to duplicate that for xmonad. we have a simple policy: look only at xmonad.hs, and compile if it is out of date. that's the only rule. anything else is duplicating --make and chunks of cabal in an ad hoc way. having smarter recompilation checking is not an issue i feel we have to solve, but we can lean on the cabal and ghc guys to improve things at their end. -- Don

David Roundy

2:08 p.m.

On Wed, Mar 19, 2008 at 11:00:00AM -0700, Don Stewart wrote:

...

droundy:

...
On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:

...
...
Is it possible that having a custom ~/.xmonad/xmonad.hs that wasn't changed across updates could cause xinerama to fail because ~/.xmonad/xmonad-i386-linux doesn't get rebuilt?

Quite possible, happens to me all the time :-)

Someone really should figure out how to build software reliably using ghc packages. This is just embarassing. And then we could tell the cabal folks how to do this.

If in doubt, recompile.

...
I understand that dons is reluctant to load up ghc every time xmonad loads, but perhaps we could figure out some way to track the modification date of the xmonad and/or xmonad-contrib packages and recompile if those have changed.

that's a long open ticket for cabal, and I'm not keen to duplicate that for xmonad.

we have a simple policy: look only at xmonad.hs, and compile if it is out of date. that's the only rule. anything else is duplicating --make and chunks of cabal in an ad hoc way.

I disagree. We wouldn't (currently) be duplicating any code in --make or cabal, since both of those don't handle this situation correctly. Moreover, since we don't intend to use either --make or cabal when rebuilding xmonad.hs, it seems reasonable to use a slightly more sophisticated heuristic to remove a pot-hole that many, many users and developers fall into. It is the very unintuitive that every upgrade of xmonad requires a modification of the configuration file in order to take effect. -- David Roundy Department of Physics Oregon State University

Andrew Sackville-West

12:27 p.m.

On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 18.03.2008, 17:15 -0700 schrieb Andrew Sackville-West:

...
...
...
I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages?

Do you have x11proto-xinerama-dev installed? What is the output of the configure step when configuring haskell-x11?

this all may be a red-herring... it *appears* that my local xmonad wasn't getting updated because I hadn't changed it or touched it. It's not conclusive as I *had* made some changes to it, but the whole process has gotten so confusing now that I can't confirm either way exactly what happened. Regardless, I am now getting functioning xinerama running the official debian packages.

Sorry to ask for details again: Are you getting xinerama with the unmodified official debian packages or with the debian packages locally re-build?

Hi, no problem. I took the time this morning to actually go through this methodically: 1. aptitude remove xmonad (drags many dependencies out with it) 2. rm /var/cache/apt/archives/libghc* 3. mv ~/.xmonad ~/org_xmonad 4. aptitude install xmonad 5. mod-q --- xmonad restarts with obviously default config with *functioning xinerama*!!! 6. mv ~/org_xmonad ~/.xmonad && touch ~/.xmonad/xmonad.hs 7. mod-q --- xmonad rebuilds and restarts with my config and functioning xinerama. So, yes, confirmed, xmonad xinerama works with debian official packages in fully up-to-date sid. :) A

Don Stewart

2:03 p.m.

andrew:

...

On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:

...
Hi,

Am Dienstag, den 18.03.2008, 17:15 -0700 schrieb Andrew Sackville-West:

...
...
...
I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages?

Do you have x11proto-xinerama-dev installed? What is the output of the configure step when configuring haskell-x11?

this all may be a red-herring... it *appears* that my local xmonad wasn't getting updated because I hadn't changed it or touched it. It's not conclusive as I *had* made some changes to it, but the whole process has gotten so confusing now that I can't confirm either way exactly what happened. Regardless, I am now getting functioning xinerama running the official debian packages.

Sorry to ask for details again: Are you getting xinerama with the unmodified official debian packages or with the debian packages locally re-build?

Hi, no problem. I took the time this morning to actually go through this methodically:

1. aptitude remove xmonad (drags many dependencies out with it) 2. rm /var/cache/apt/archives/libghc* 3. mv ~/.xmonad ~/org_xmonad 4. aptitude install xmonad 5. mod-q --- xmonad restarts with obviously default config with *functioning xinerama*!!! 6. mv ~/org_xmonad ~/.xmonad && touch ~/.xmonad/xmonad.hs 7. mod-q --- xmonad rebuilds and restarts with my config and functioning xinerama.

So, yes, confirmed, xmonad xinerama works with debian official packages in fully up-to-date sid. :)

Great! Thanks Joachim and Andrew for teasing out this issue.

Joachim Breitner

3:44 p.m.

Hi, Am Mittwoch, den 19.03.2008, 09:27 -0700 schrieb Andrew Sackville-West:

...

On Wed, Mar 19, 2008 at 11:20:17AM +0100, Joachim Breitner wrote:

...
Hi,

Am Dienstag, den 18.03.2008, 17:15 -0700 schrieb Andrew Sackville-West:

...
...
...
I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages?

Do you have x11proto-xinerama-dev installed? What is the output of the configure step when configuring haskell-x11?

this all may be a red-herring... it *appears* that my local xmonad wasn't getting updated because I hadn't changed it or touched it. It's not conclusive as I *had* made some changes to it, but the whole process has gotten so confusing now that I can't confirm either way exactly what happened. Regardless, I am now getting functioning xinerama running the official debian packages.

Sorry to ask for details again: Are you getting xinerama with the unmodified official debian packages or with the debian packages locally re-build?

Hi, no problem. I took the time this morning to actually go through this methodically:

1. aptitude remove xmonad (drags many dependencies out with it) 2. rm /var/cache/apt/archives/libghc* 3. mv ~/.xmonad ~/org_xmonad 4. aptitude install xmonad 5. mod-q --- xmonad restarts with obviously default config with *functioning xinerama*!!! 6. mv ~/org_xmonad ~/.xmonad && touch ~/.xmonad/xmonad.hs 7. mod-q --- xmonad rebuilds and restarts with my config and functioning xinerama.

So, yes, confirmed, xmonad xinerama works with debian official packages in fully up-to-date sid. :)

Yet another question: Do you run i386 or amd64 (or something else)? It might depend on whether the libghc6-x11-dev packages was created by some autobuilder (without xinerama) or by some developer (with xinerama headers installed) Thanks, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de

Andrew Sackville-West

7:57 p.m.

On Wed, Mar 19, 2008 at 08:44:38PM +0100, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, den 19.03.2008, 09:27 -0700 schrieb Andrew Sackville-West: ...

...
So, yes, confirmed, xmonad xinerama works with debian official packages in fully up-to-date sid. :)

Yet another question: Do you run i386 or amd64 (or something else)? It might depend on whether the libghc6-x11-dev packages was created by some autobuilder (without xinerama) or by some developer (with xinerama headers installed)

Actually running -k7 ATM, but I guess I've got a -686 kernel waiting for reboot (debian's dropped -k7...). Either way, that puts me in i386 land. A

Andrew Sackville-West

18 Mar 18 Mar

8:16 p.m.

On Tue, Mar 18, 2008 at 11:58:56PM +0100, Joachim Breitner wrote:

...

Hi,

Am Dienstag, den 18.03.2008, 14:28 -0700 schrieb Andrew Sackville-West:

...
On Tue, Mar 18, 2008 at 05:16:37PM +0100, Joachim Breitner wrote:

...
Hi,

Am Dienstag, den 18.03.2008, 11:47 -0400 schrieb Chris Sanner:

...
...
[...], when I did this my xinerama/twinview support went away. I've now got one giant expanse of screen instead of two discrete workspaces. ...

...
You can locally recompile and install (in that order) haskell-x11, xmonad, xmonad-contrib. If you have libxinerama-dev and x11proto-xinerama-dev (not sure which) installed while doing so, you’ll get xinerama support. If you need more detailed instructions, feel free to ask.

I tried recompiling all this stuff to no avail. Specifically, I've rebuilt the debian source packages for x11, xmonad and xmonad-contrib and also *removed* those and built the versions from hackage. Everything seems to work just fine except xinerama. I suspect there may be breakage deeper into the system somewhere. libxinerama-dev has also been upgraded, I may have to try downgrading that and rebuilding again.

Just checking back: The problem is also present when building xmonad from cabal, independant from the debian packages?

sorry, I should have more specifically answered your questions. Yes the problem existed building upstream sources. but as in the previous mail, I think the local copy just wasn't getting rebuilt because xmonad.hs hadn't been touched.

...

Do you have x11proto-xinerama-dev installed?

yes

...

What is the output of the configure step when configuring haskell-x11?

it shows xinerama being detected properly. A

6273

Age (days ago)

6274

Last active (days ago)

List overview

Download

21 comments

8 participants

participants (8)

Andrew Sackville-West
Chris Sanner
Christopher Sanner
David Roundy
Don Stewart
Joachim Breitner
Joachim Breitner
Roman Cheplyaka