From: Brian L. <br...@lo...> - 2009-08-08 02:09:27
|
I appreciate all the hard work that went into WxHaskell, and the effort going into its continued development. But: $ cabal install wx ... Writing new package config file... ghc-pkg: /usr/lib/ghc-6.10.4/./package.conf: you don't have permission to modify this file Is there some explanation for this hostile behavior? Every other cabalized package I've installed in the past year has been satisified to live in ~/.cabal and not mess with other files behind the back of my distro's package management system. |
From: S. D. S. <do...@sw...> - 2009-08-08 12:00:20
|
Did you recently install something using the sudo command? That may have changed the permissions/ownership of the pacckage.conf. Doaitse On 8 aug 2009, at 03:09, Brian Lewis wrote: > I appreciate all the hard work that went into WxHaskell, and the > effort > going into its continued development. But: > > $ cabal install wx > ... > Writing new package config file... > ghc-pkg: /usr/lib/ghc-6.10.4/./package.conf: > you don't have permission to modify this file > > Is there some explanation for this hostile behavior? Every other > cabalized package I've installed in the past year has been > satisified to > live in ~/.cabal and not mess with other files behind the back of my > distro's package management system. > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > wxhaskell-users mailing list > wxh...@li... > https://lists.sourceforge.net/lists/listinfo/wxhaskell-users |
From: Brian L. <br...@lo...> - 2009-08-08 16:08:21
|
On Saturday, 08.08.09 at 13:41, S. Doaitse Swierstra wrote: > Did you recently install something using the sudo command? That may have > changed the permissions/ownership of the pacckage.conf. I think package.conf's ownership and permissions are as they should be, root:root 644. The wx cabal package seems to assume that the user running 'cabal install' will be able to modify root-owned files in /usr. I don't understand why any installation would be set up that way these days. It also seems wrong because it defies ~/.cabal/config, which says to install stuff under ~/.cabal. > On 8 aug 2009, at 03:09, Brian Lewis wrote: >> I appreciate all the hard work that went into WxHaskell, and the >> effort >> going into its continued development. But: >> >> $ cabal install wx >> ... >> Writing new package config file... >> ghc-pkg: /usr/lib/ghc-6.10.4/./package.conf: >> you don't have permission to modify this file >> >> Is there some explanation for this hostile behavior? Every other >> cabalized package I've installed in the past year has been satisified >> to live in ~/.cabal and not mess with other files behind the back of >> my distro's package management system. |
From: S. D. S. <do...@sw...> - 2009-08-08 18:37:42
|
But this suggests that your Haskell installation is a global one, so you should us: sudo cabal install wx See discussions on the various mailing lists about permissions and install locations for cabal. This has caused quite some confusion, and not only to you. Doaitse On 8 aug 2009, at 18:08, Brian Lewis wrote: > On Saturday, 08.08.09 at 13:41, S. Doaitse Swierstra wrote: >> Did you recently install something using the sudo command? That may >> have >> changed the permissions/ownership of the pacckage.conf. > > I think package.conf's ownership and permissions are as they should > be, > root:root 644. > > The wx cabal package seems to assume that the user running 'cabal > install' will be able to modify root-owned files in /usr. I don't > understand why any installation would be set up that way these days. > > It also seems wrong because it defies ~/.cabal/config, which says to > install stuff under ~/.cabal. > >> On 8 aug 2009, at 03:09, Brian Lewis wrote: >>> I appreciate all the hard work that went into WxHaskell, and the >>> effort >>> going into its continued development. But: >>> >>> $ cabal install wx >>> ... >>> Writing new package config file... >>> ghc-pkg: /usr/lib/ghc-6.10.4/./package.conf: >>> you don't have permission to modify this file >>> >>> Is there some explanation for this hostile behavior? Every other >>> cabalized package I've installed in the past year has been >>> satisified >>> to live in ~/.cabal and not mess with other files behind the back of >>> my distro's package management system. |
From: Brian L. <br...@lo...> - 2009-08-08 19:00:32
|
On Saturday, 08.08.09 at 20:37, S. Doaitse Swierstra wrote: > But this suggests that your Haskell installation is a global one, so > you should us: > > sudo cabal install wx I absolutely should *not* do that. It's not reasonable for the wx cabal package to modify files under the jurisdiction of some different package management system. It's just plain wrong. I configured cabal to install packages in my home directory. This has worked for hundreds of other cabal packages I have installed during my daily development of Haskell for the past year or so. The wx cabal package is different from all the others in that it seems to assume that the user running 'cabal install' will be able to modify root-owned files in /usr. And it actually tries to do so, in defiance of ~/.cabal/config. If there is some technical reason wx cannot be installed as a user package, I'd like to know what it is. If there is a reason, the wx cabal package should be changed to abort early if such an install is attempted. It should not be trying to circumvent cabal's normal procedure for package registration. |
From: Eric Y. K. <eri...@gm...> - 2009-08-08 23:16:20
|
Brian, Does this work better? cabal install wx --configure-opt="--user --enable-split-objs --hcprof" (The key difference is the --configure-opt) On Sat, Aug 08, 2009 at 14:00:49 -0500, Brian Lewis wrote: > If there is some technical reason wx cannot be installed as a user > package, I'd like to know what it is. If there is a reason, the wx cabal > package should be changed to abort early if such an install is > attempted. It should not be trying to circumvent cabal's normal > procedure for package registration. I agree with you. This one stupid little issue makes wxHaskell difficult to install. It drives me absolutely nuts (1) because it's a stupid little issue (2) everybody trips on it and (3) we are ever so tantalisingly close to making wxHaskell easy to install if we could just fix this problem and (4) nobody seems to have the spare cycles to sit down and solve the problem. Things to know: - The wx package itself is fine. The problem is the wxcore package on which it depends. - Part of the issue is that the wxcore package requires a C interface to wxWidgets (which we call wxc, still shipped as part of wxcore). See this diagram of the pieces involved in wxHaskell http://bp2.blogger.com/_c6WmXt2id8U/R8HABBJjdjI/AAAAAAAAAHk/ZT_q6Ts53XY/s1600-h/components.png - Cabalisation is recent. In the past, we only had this hand-written (grr!) configure script plus a makefile. Now we have *that* and the Cabal stuff as a thin layer around this. The Cabal/Setup file is merely a thin wrapper around that and it is not clever enough to understand this '--user' flag (or something isn't being passed through; see http://hackage.haskell.org/trac/hackage/ticket/431 The good news is that we've made some progress: the wx package for example is cleanly Cabalised -- just the simple build method. In the darcs version of wxHaskell, I've also attempted to split wxcore off so that it is cleanly Cabalised (just the Simple build method), but I haven't worked out how to make it point the wxc package that we would have to build separately. Try it and see what I mean. I'm sure it's not a hard problem to solve; we just need somebody that's got 2 hours to stare at the problem, poke it in the right place. Can you help? My vague thinking is that this would somehow be a lot cleaner if we could tell people (i) go install wxWidgets (ii) go install wxC (iii) cabal install wx - There is a separate wxc project on sourceforge that tries to unify our, wxOCaml and wxEiffel's wxc work (all forks off wxEiffel, I think). We're now helping to administer the project, but again... nobody has the time to pay it attention. Argh! So very close to making it all work right! :-( Right now, my problem is that I don't really have the ability to give a clear description of the problem, that say Duncan (CC'ed) could understand and subsequently just give me an answer to. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
From: Brian L. <br...@lo...> - 2009-08-08 23:35:57
|
On Sunday, 09.08.09 at 00:15, Eric Y. Kow wrote: > Does this work better? > cabal install wx --configure-opt="--user --enable-split-objs --hcprof" I'll try. Thanks. > In the darcs version of wxHaskell, I've also attempted to split > wxcore off so that it is cleanly Cabalised (just the Simple build > method), but I haven't worked out how to make it point the wxc > package that we would have to build separately. Could you explain a little more? I don't understand the part after "I haven't worked out how ...". > Try it and see what I mean. I'm sure it's not a hard problem to > solve; we just need somebody that's got 2 hours to stare at the > problem, poke it in the right place. Can you help? I'd be happy to try. I'll take a look and write back. Thanks very much for writing. This is some progress. |
From: Eric Y. K. <eri...@gm...> - 2009-08-08 23:50:14
|
On Sat, Aug 08, 2009 at 18:36:10 -0500, Brian Lewis wrote: > > In the darcs version of wxHaskell, I've also attempted to split > > wxcore off so that it is cleanly Cabalised (just the Simple build > > method), but I haven't worked out how to make it point the wxc > > package that we would have to build separately. > > Could you explain a little more? I don't understand the part after "I > haven't worked out how ...". I'm dimly aware that we build this wxc library that wxcore is dynamically linked against (I think), that we seem to give this library a different name depending on what wxWidgets we build against (for example, on my Mac, I have libwxc-mac2.8.7-0.11.1.3.dylib, whereas on Linux, I have libwxc-gtk2.8.8-0.11.0.so), and that we tend to install this library in the same place that wxWidget's wx-config program lives (eg /usr/local/wxhaskell/lib on my Mac because I've symlinked wx-config into the /usr/local/wxhaskell/bin directory for convenience, but /usr/lib on my Ubuntu box (yuck!) because I forgot to do the same). I also know that somehow on my Mac the wxcore package has this information: library-dirs: /usr/local/wxhaskell/lib hs-libraries: wxcore wxcore0 wxcore1 wxcore2 extra-libraries: wxc-mac2.8.7-0.11.1.2 And I vaguely recall that this is due to some ghc-pkg specific file that we generate from our Makefile. I don't remember what these wxcore wxcore0 wxcore1 wxcore2 libraries are, unfortunately. > > Try it and see what I mean. I'm sure it's not a hard problem to > > solve; we just need somebody that's got 2 hours to stare at the > > problem, poke it in the right place. Can you help? > > I'd be happy to try. I'll take a look and write back. Are you starting to see what I'm getting at? I'm sorry if I'm being unclear; it's because I just don't have a good grasp on what all the pieces are and how they all fit together. I'll bet we can do things to make this simpler though. One hope was to be able to dissociate wxc from wxcore, but I don't even know if this is actually a good idea or potentially foolish. If we do this, then we're going to have to find some way for pick up this wxc library for linking whenever we build a wxHaskell program. Surely this sort of thing has been solved before by other Haskell libraries that wrap around some C library! -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
From: Eric Y. K. <eri...@gm...> - 2009-08-08 23:55:45
|
On Sun, Aug 09, 2009 at 00:50:00 +0100, Eric Y. Kow wrote: > > Could you explain a little more? I don't understand the part after "I > > haven't worked out how ...". > > I'm dimly aware that we build this wxc library that wxcore is > dynamically linked against (I think) I'll also add that a past me tried to look into this around April, but lost steam (and now I've forgotten most of the stuff the past me worked out), so maybe this thread on the mailing list will help http://sourceforge.net/mailarchive/forum.php?thread_name=op.ur3r8oe4g8rhh0%40shelarcywin&forum_name=wxhaskell-devel I also recall the past me thinking that pkg-config would be really handy here, but then later finding out that actually it's not quite what we need. I thought it was something we discussed on list too :-/ -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |
From: Brian L. <br...@lo...> - 2009-08-08 22:33:38
|
On Saturday, 08.08.09 at 23:24, S. Doaitse Swierstra wrote: > http://noordering.wordpress.com/2009/04/21/cabals-default-install-location/ I don't think that's relevant, firstly, because my ~/.cabal/config says explicitly to install packages in ~/.cabal, and secondly, because the wx cabal package seems written to install itself globally no matter what ~/.cabal/config says. 'cabal install wx' dies shortly after trying to register itself by running cat config/wxcore.pkg | sed -e "s|\${wxhlibdir}|/home/brian/.cabal/lib|" | ghc-pkg update - ghc-pkg is hardcoded to use the global package configuration: $ cat $(which ghc-pkg) #!/bin/sh PKGCONF=/usr/lib/ghc-6.10.4/./package.conf exec /usr/lib/ghc-6.10.4/ghc-pkg --global-conf $PKGCONF ${1+"$@"} I don't know how to make it any more clear that this behavior is really wrong. |
From: Lennart K. <kol...@ge...> - 2009-08-09 16:35:34
|
Eric Y. Kow wrote: > On Sat, Aug 08, 2009 at 14:00:49 -0500, Brian Lewis wrote: >> [snip] It should not be trying to circumvent cabal's normal >> procedure for package registration. > > I agree with you. This one stupid little issue makes wxHaskell > difficult to install. It drives me absolutely nuts (1) because > it's a stupid little issue (2) everybody trips on it and (3) > we are ever so tantalisingly close to making wxHaskell easy to > install if we could just fix this problem and (4) nobody seems > to have the spare cycles to sit down and solve the problem. I recently tried to make Gentoo Linux ebuilds for wxHaskell. We've had support in the past, for the 0.9.x series, and would like to support the new 0.11.x too. I spent a few hours just to make it install, and I'm still not satisfied with the result :) The ebuild itself is located at: http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/wxcore/wxcore-0.11.1.2.ebuild and documents itself. You can find the patches at: http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/wxcore/files/ and they have also been documented. What I had to change was: - cabal assumes the ./configure script understands the --with-hc-pkg flag [1], so now it does. - GHC docs are installed into a different path on gentoo. - The code to fix the trailing / in DESTDIR seems to be broken, it gave an error when I ran it. - Not only does Gentoo first install into a separate directory (called ${D} in the ebuild, put into variable DESTDIR), the registration is also done separately. * No files must be attempted to be changed during the install phase, other than in the directory ${D}. Thus, we can't register the package with 'make install', and changed the wxcore.pkg to not require sed magic. Cabal states [1] it assumes the package is not registered during this phase. * Package registration is done in a post install phase, and is handled with other code than what wxHaskell provides (same for all packages). Usually we use ./setup register --gen-pkg-config="${T}/${P}.conf" to get a config file to register later. And what's still not working properly: - The ebuild installs wxhaskell directly into /usr/lib{,64}. I'm not sure I've set all the variables right, though. The wxcore.pkg's import-dir and and library-dirs looks wrong. I'd like to install into /usr/lib{,64}/ghc-<ver>/wx-<ver> as with other packages. > Things to know: > - The wx package itself is fine. The problem is the wxcore package on > which it depends. Making an ebuild for the wx package takes less than 2 minutes, prefect :) Many distros can automatically generate description files for their package systems from correctly packaged cabal applications/libraries. Naturally we want to make it easy for the poor distro maintainers, right? ;) > - Cabalisation is recent. In the past, we only had this > hand-written (grr!) configure script plus a makefile. > Now we have *that* and the Cabal stuff as a thin layer > around this. It's sure some work that has gone into making it use cabal though, even if it isn't perfect. What do we need to make it easier, to use more of cabal? Any features in those ./configure and makefiles cabal doesn't have? I haven't really digged into wxhaskell's build system in many years, but I remember it builds and uses an application (wxdirect?) to generate the bindings to the underlying C library. Maybe we could use a field "installable" similar to existing "buildable" to be able to build in in the wxcore.cabal file? What else? Cheers, Lennart Kolmodin -- wearing the Gentoo developer hat [1]http://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/Distribution-Make.html |
From: Eric Y. K. <eri...@gm...> - 2009-08-09 18:54:05
|
OK, I think I'm starting to remember more bits and pieces... On Sun, Aug 09, 2009 at 18:18:09 +0200, Lennart Kolmodin wrote: > I recently tried to make Gentoo Linux ebuilds for wxHaskell. We've had > support in the past, for the 0.9.x series, and would like to support the > new 0.11.x too. I spent a few hours just to make it install, and I'm > still not satisfied with the result :) So let's see if we can make this easier at last! > The ebuild itself is located at: > http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/wxcore/wxcore-0.11.1.2.ebuild > and documents itself. > You can find the patches at: > http://code.haskell.org/gentoo/gentoo-haskell/dev-haskell/wxcore/files/ > and they have also been documented. One thing to watch out for is the work-in-progress in the Darcs wxHaskell. We've started by moving away from the Make build method in wxcore and just using Simple instead (for now, maybe Custom later). This means that installation would proceed in three phases, one focused on wxc, and then two simple Haskell ones for wxcore and wxc respectively. If we pull this off, we may have a more straightforward route to making ebuilds for wxHaskell. The big gotcha here is that the work was never finished so I think if you try and cabal install wxcore from the Darcs wxHaskell you won't be able to build any apps with it because of a linker error (it's not finding wxc). Re-reading http://sourceforge.net/mailarchive/forum.php?thread_name=op.ur3r8oe4g8rhh0%40shelarcywin&forum_name=wxhaskell-devel it sounds like "all" we need to do is to throw in an extra-libraries and extra-lib-dirs pointing to wxc and where wxc lives respectively. But here's the question: how do we know what wxc is called? and how do we know where it lives? Reading http://sourceforge.net/mailarchive/message.php?msg_name=op.ur50y0kmg8rhh0%40shelarcywin I see that use of pkg-config was my proposed solution, but Shelarcy pointed out that Windows users may not have pkg-config. I wonder how other packages deal with in practice? > Making an ebuild for the wx package takes less than 2 minutes, prefect :) > Many distros can automatically generate description files for their > package systems from correctly packaged cabal applications/libraries. > Naturally we want to make it easy for the poor distro maintainers, right? ;) Yeah! So in my ideal world, we would go a really radical route, and stop trying to make the configure script and makefile smarter. Instead, I think we should remove anything Haskell-related and outsource that to Cabal. > It's sure some work that has gone into making it use cabal though, even > if it isn't perfect. That's exactly right. Shelarcy and the wxHaskell crew have put in a lot of effort into extending the configure script and the makefile to fit in with Cabal and the cabal build system. To be clear, although I gripe rather frequently about this [without producing much in the way of actual code], I am very grateful for the work that has already gone into making it even possible to install this with "sudo cabal install wxcore" in the first place. For the longest time, we've been just two centimeters away from delivering that finishing blow, to making it all "just work". > What do we need to make it easier, to use more of cabal? Any features in > those ./configure and makefiles cabal doesn't have? OK, this isn't quite what you're asking for, but for some things apparently needed in Cabal/cabal-install, here are some of Shelarcy's comments: from http://www.haskell.org/haskellwiki/WxHaskell/Building | Cabal doesn't works well currently. This is Cabal and cabal (install)'s | problem (e.g. 394, 431). And current cabal 0.6.0's dependency solver has | problem. | | So, you should build and install wxHaskell by hand (at least wxcore package). | | If you want to build and install wxHaskell by cabal command, you must use following command. | | > cabal install wx --configure-opt="--user --enable-split-objs --hcprof" | | or | | > sudo cabal install wxcore --global | > cabal install wx http://hackage.haskell.org/trac/hackage/ticket/394 (fixed in Cabal 1.8) http://hackage.haskell.org/trac/hackage/ticket/431 > I haven't really digged into wxhaskell's build system in many years, but > I remember it builds and uses an application (wxdirect?) to generate the > bindings to the underlying C library. Maybe we could use a field > "installable" similar to existing "buildable" to be able to build in in > the wxcore.cabal file? This reminds me. I bet that at this stage, we would not be able to upload wxcore onto hackage because with our incomplete wxc/wxcore split, we would only be able to cabal install wxcore after having done 'make' to compile and run wxdirect :-( So the challenge is may be to extend the Setup file for wxcore with some sort of build pre-hook to run wxdirect on the C header files and Eiffel constants. I really hope there's no dependency on wxc for any of this and that we can just ship these header files. Another problem is getting wxdirect in the first place. We now have a simple wxdirect cabal package which we could dump on Hackage (it's only purpose in life will be to help build wxHaskell and that's OK). I don't know how to express a build dependency on wxdirect because it's an executable, but maybe one workaround would be for wxdirect to expose a sort of null "library"? > What else? Here is a what I think we still need to do: 1. Tell the wxcore package where the wxc library lives using an extra-libraries and extra-lib-dirs field This may require extending the makefile so that we give wxc some sort of standard name. Or maybe this could involve using pkg-config and finding some sort of workaround for Windows users. 2. Add some sort of pre-hook so that wxcore runs wxdirect in such a way that we can compile the source that's generated as part of wxcore. I'll bet this shouldn't be too horrible; people use Happy and Alex after all, right? 3. Depend on wxdirect and release it on Hackage. 4. Figure out how to still have good binary installers for wxHaskell. Maybe only have installers for wxc itself? Thoughts? -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> PGP Key ID: 08AC04F9 |