Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Dec 25, 2007 11:19 PM, [EMAIL PROTECTED] wrote: I'm using the same HaXML you are, actually. Interesting ... unmerge quits by itself, but with the same error. I am tempted to delete haskell itself, as far as possible, and see if the haxml unmerge would get any further. What if you tried deleting HaXML from /var/lib/portage/world and then remerging it? It would skip the `prerm` action and just overwrite everything. -- _jsn -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Wed, Dec 26, 2007 at 11:40:53AM -0800, Jason Dusek wrote: On Dec 25, 2007 11:19 PM, [EMAIL PROTECTED] wrote: I'm using the same HaXML you are, actually. Interesting ... unmerge quits by itself, but with the same error. I am tempted to delete haskell itself, as far as possible, and see if the haxml unmerge would get any further. What if you tried deleting HaXML from /var/lib/portage/world and then remerging it? It would skip the `prerm` action and just overwrite everything. Nah, no luck. Emerge -p shows it still knows that haxml is a remerge, not a merge from scratch. Whether I try an unmerge or a merge, it still has the prerm phase and it still gobbles memory. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Wed, 26 Dec 2007 13:51:15 -0800, [EMAIL PROTECTED] wrote: What if you tried deleting HaXML from /var/lib/portage/world and then remerging it? It would skip the `prerm` action and just overwrite everything. Nah, no luck. Emerge -p shows it still knows that haxml is a remerge, not a merge from scratch. Whether I try an unmerge or a merge, it still has the prerm phase and it still gobbles memory. You'd need to delete it fro the package database in /var/db/pkg. That would convince portage that it wasn't installed, but I have no idea what side effects this may produce with this package... if any. -- Neil Bothwick Top Oxymorons Number 25: New York culture signature.asc Description: PGP signature
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
[EMAIL PROTECTED] wrote: Jason Dusek wrote: What if you tried deleting HaXML from /var/lib/portage/world and then remerging it? It would skip the `prerm` action and just overwrite everything. Nah, no luck. Emerge -p shows it still knows that haxml is a remerge, not a merge from scratch. Whether I try an unmerge or a merge, it still has the prerm phase and it still gobbles memory. Okay, I figured it out -- remove it from /var/lib/portage/world and remove /var/db/pkg/dev-haskell/haxml-1.13.2 (I moved it to my home directory). Now when you run `emerge haxml --pretend`, it will show it as new. I am on FreeNode as jsnx, by the way. Please feel free to message me. -- _jsn -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Wed, Dec 26, 2007 at 03:35:10PM -0800, Jason Dusek wrote: Okay, I figured it out -- remove it from /var/lib/portage/world and remove /var/db/pkg/dev-haskell/haxml-1.13.2 (I moved it to my home directory). Now when you run `emerge haxml --pretend`, it will show it as new. The merge worked, an unmerge worked, and a second merge worked. The first merge complained about overwriting a bunch of files, all of them looked perfectly reasonable. There were no other fifferences between the twwo merge log. The resulting /var/db/pkg/... dir had some differences, almost all in what looked to be md5sums. I am working over a slow ssh connection right now, I'll look more into it in a few days. I am rerunning ghc-updater again; that's where this whole thing started. I was sort of hoping the unmerge would hang. Not much to debug now, unless I restore /var/db/pkg ... I'll post more when ghc-updater is done. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Wed, Dec 26, 2007 at 06:05:14PM -0800, [EMAIL PROTECTED] wrote: I'll post more when ghc-updater is done. ghc-updater ran fine, or at least didn't hang. There was one error: src/lib/HsShellScript/Commands.chs:21:0: Failed to load interface for `Text.ParserCombinators.Parsec': Perhaps you haven't installed the profiling libraries for package parsec-2.1.0.0? Use -v to see a list of the files searched for. So I manually remerged parsec and repeated ghc-updater, which found only the same dev-haskell/hsshellscript-2.7.0 complaint about parsec. Since haskell is installed only for darcs, and haven't actually used darcs for a bit (major work right now is for people who use, yucch, subversion), I can't say much more than that darcs whatsnew etc seem to work. Don't know what parsec does, whetehr darcs uses it, whether it matters, but I guess for now, unless you think it is worth anything to restore the old /var/db/pkg... dirctory, there isn't much mroe to do on this. I don't like random errors like this, but they can be pretty tought to repeat and track down. Thanks for babysitting :-) -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
[EMAIL PROTECTED] wrote: ghc-updater ran fine, or at least didn't hang. There was one error: src/lib/HsShellScript/Commands.chs:21:0: Failed to load interface for `Text.ParserCombinators.Parsec': Perhaps you haven't installed the profiling libraries for package parsec-2.1.0.0? Use -v to see a list of the files searched for. So I manually remerged parsec and repeated ghc-updater, which found only the same dev-haskell/hsshellscript-2.7.0 complaint about parsec. This is caused by a package trying to load Parsec with profiling, while Parsec has not been built with profiling (`profile` USE flag, which I have enabled globally). Parsec is a parsing library for Haskell. -- _jsn -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Mon, Dec 24, 2007 at 10:57:10PM -0800, Jason Dusek wrote: On Dec 23, 2007 8:23 AM, [EMAIL PROTECTED] wrote: Emerging haxml directly repeats the greedy performance, and when I kill it, it gives me this message: * The 'prerm' phase of the 'dev-haskell/haxml-1.13.2' package has failed * with exit value -1. The problem occurred while executing the ebuild * located at '/var/db/pkg/dev-haskell/haxml-1.13.2/haxml-1.13.2.ebuild'. * If necessary, manually remove the ebuild in order to skip the execution * of removal phases. What the heck is going on here, and how do I manually remove haxml? Does deleting the ebuild (not haxml, just that particular ebuild, as suggested by manually remove the ebuild, make any difference? I took manually remove the ebuild to mean do all the remove steps myself, but I don't have any idea what those steps are. Do you think it means the actual haxml-1.13.2.ebuild file? I'd be willing to try that, but that is the most recent ebuild. It all started with complaints about cabal being out of date and needing to run ghc-updater, which came up with a dozen packages to remerge. I tried remerging cabal itself, which didn't hang up, but ghc-updater still wants to merge haxml. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Dec 25, 2007 6:26 AM, [EMAIL PROTECTED] wrote: On Mon, Dec 24, 2007 at 10:57:10PM -0800, Jason Dusek wrote: On Dec 23, 2007 8:23 AM, [EMAIL PROTECTED] wrote: Emerging haxml directly repeats the greedy performance... Does deleting the ebuild (not haxml, just that particular ebuild, as suggested by manually remove the ebuild, make any difference? I took manually remove the ebuild to mean do all the remove steps myself, but I don't have any idea what those steps are. Do you think it means the actual haxml-1.13.2.ebuild file? I'd be willing to try that, but that is the most recent ebuild. Maybe you're reading it right, but it's not clear -- if you are supposed to remove HaXML by hand, it should have said manually remove the package. When you say Emerging HaXML directly repeats the greedy performance..., do you mean *unmerging* HaXML is not doable? You could try unmerging it and then re-emerging it. If you've already tried that, though, then I'll have to think of something else :) I'm using the same HaXML you are, actually. -- _jsn -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Tue, Dec 25, 2007 at 05:26:31PM -0800, Jason Dusek wrote: On Dec 25, 2007 6:26 AM, [EMAIL PROTECTED] wrote: On Mon, Dec 24, 2007 at 10:57:10PM -0800, Jason Dusek wrote: On Dec 23, 2007 8:23 AM, [EMAIL PROTECTED] wrote: Emerging haxml directly repeats the greedy performance... Does deleting the ebuild (not haxml, just that particular ebuild, as suggested by manually remove the ebuild, make any difference? I took manually remove the ebuild to mean do all the remove steps myself, but I don't have any idea what those steps are. Do you think it means the actual haxml-1.13.2.ebuild file? I'd be willing to try that, but that is the most recent ebuild. Maybe you're reading it right, but it's not clear -- if you are supposed to remove HaXML by hand, it should have said manually remove the package. When you say Emerging HaXML directly repeats the greedy performance..., do you mean *unmerging* HaXML is not doable? You could try unmerging it and then re-emerging it. If you've already tried that, though, then I'll have to think of something else :) I'm using the same HaXML you are, actually. Interesting ... unmerge quits by itself, but with the same error. I am tempted to delete haskell itself, as far as possible, and see if the haxml unmerge would get any further. # emerge -C dev-haskell/haxml dev-haskell/haxml selected: 1.13.2 protected: none omitted: none 'Selected' packages are slated for removal. 'Protected' and 'omitted' packages will not be removed. Waiting 5 seconds before starting... (Control-C to abort)... Unmerging in: 5 4 3 2 1 Unmerging dev-haskell/haxml-1.13.2... Exiting on signal 2 * The 'prerm' phase of the 'dev-haskell/haxml-1.13.2' package has failed * with exit value -1. The problem occurred while executing the ebuild * located at '/var/db/pkg/dev-haskell/haxml-1.13.2/haxml-1.13.2.ebuild'. * If necessary, manually remove the ebuild in order to skip the execution * of removal phases. * Messages for package dev-haskell/haxml-1.13.2: * The 'prerm' phase of the 'dev-haskell/haxml-1.13.2' package has failed * with exit value -1. The problem occurred while executing the ebuild * located at '/var/db/pkg/dev-haskell/haxml-1.13.2/haxml-1.13.2.ebuild'. * If necessary, manually remove the ebuild in order to skip the execution * of removal phases. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
On Dec 23, 2007 8:23 AM, [EMAIL PROTECTED] wrote: Emerging haxml directly repeats the greedy performance, and when I kill it, it gives me this message: * The 'prerm' phase of the 'dev-haskell/haxml-1.13.2' package has failed * with exit value -1. The problem occurred while executing the ebuild * located at '/var/db/pkg/dev-haskell/haxml-1.13.2/haxml-1.13.2.ebuild'. * If necessary, manually remove the ebuild in order to skip the execution * of removal phases. What the heck is going on here, and how do I manually remove haxml? Does deleting the ebuild (not haxml, just that particular ebuild, as suggested by manually remove the ebuild, make any difference? I don't have these problems, but I've got testing flags enabled for all my Haskell stuff and I'm using the Gentoo Haskell overlay. -- _jsn -- [EMAIL PROTECTED] mailing list
[gentoo-user] dev-haskell/{cabal,haxml} -- runaway memory hog
In a routine upgrade, I get the following message from several haskell components: * The package dev-haskell/cabal is not correctly installed for * the currently active version of ghc (6.8.2). Please * run ghc-updater or re-emerge dev-haskell/cabal. So I tried running ghc-updater, and it hangs emerging haxml by gradually absorbing all available CPU time, memory, and swap, eventually the oom killer kills firebird, and eventually I realize something is going on and kill ghc-updater. Emerging haxml directly repeats the greedy performance, and when I kill it, it gives me this message: * The 'prerm' phase of the 'dev-haskell/haxml-1.13.2' package has failed * with exit value -1. The problem occurred while executing the ebuild * located at '/var/db/pkg/dev-haskell/haxml-1.13.2/haxml-1.13.2.ebuild'. * If necessary, manually remove the ebuild in order to skip the execution * of removal phases. What the heck is going on here, and how do I manually remove haxml? I know nothing of haskell; it is merged only because I use darcs. The ebuild mentioned is short and has no prerm anywhere in it. This happens on both a ~x86 machine and a ~amd64 machine. -- ... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._. Felix Finch: scarecrow repairman rocket surgeon / [EMAIL PROTECTED] GPG = E987 4493 C860 246C 3B1E 6477 7838 76E9 182E 8151 ITAR license #4933 I've found a solution to Fermat's Last Theorem but I see I've run out of room o -- [EMAIL PROTECTED] mailing list
