Re: Timeouts
On Tue, Mar 9, 2010 at 4:54 PM, dann frazier wrote: > --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > rt_sigreturn() = -819 > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x40002b28) = -513 > --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > rt_sigreturn() = -819 > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x40002b28) = -513 > --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > rt_sigreturn() = -819 > clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x40002b28) = -513 > --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- > rt_sigreturn() = -819 > >> Anyway, this seems to be something that was introduced with 6.12. I >> wonder what we can do about this, besides p-a-s. Error -513 is ERESTARTNOINTR. It appears that the process is executing clone when it gets a SIGVTALRM, after which the kernel restart the clone, but the whole process repeats over and over again? I don't know what's wrong in this case, somebody will have to debug this. Cheers, Carlos. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/119aab441003091410w25d3bb11n410a90a2c6020...@mail.gmail.com
Re: Timeouts
[Adding debian-hppa to the CC, since it may require porter help] On Tue, Mar 09, 2010 at 06:38:23PM +, Iain Lane wrote: > On Tue, Mar 09, 2010 at 10:46:54AM -0700, dann frazier wrote: >> On Mon, Mar 08, 2010 at 10:56:53PM +0100, Joachim Breitner wrote: >>> Hi, >>> >>> Am Montag, den 08.03.2010, 22:42 +0100 schrieb Joachim Breitner: >>> > > This might be a solution, yes, though I would prefer not to do >>> > > this. You've managed to get highlighting-kate's build times down, making >>> > > it build everywhere but on armel (where it got tried on a slw >>> > > buildd, let's see if this gets better on one of the faster boxes). We >>> > > have similar problem with agda, could you have a look at that? >>> > >>> > Maybe Iain Lane can comment on agda. >>> >>> speaking of which: >>> https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw >>> says >>> >>> Building Agda-2.2.6... >>> [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( >>> src/full/Agda/Auto/NarrowingSearch.hs, >>> dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) >>> E: Caught signal 'Terminated': terminating immediately >>> make: *** [build-ghc6-stamp] Terminated >>> Build killed with signal TERM after 1 minutes of inactivity >>> >>> Isn???t this time limit a bit too low? >> >> I put that in to cause agda to fail and stop retrying, adn then bumped >> it back up. >> >> The timeout is normally 300 minutes, but agda would continue to >> generate output even when it had been wedged for over 12 hours. > > I rather suspect that the monotonically increasing memory usage is the > problem here. I don't know of a resolution, and the thread with the GHC > devs didn't seem to offer anything up. Anyone have any ideas? Dann, did > you have a look at the memory usage when the build was going on by any > chance? Well, its stuck again on penalosa, so let me check.. da...@penalosa:~$ free total used free sharedbuffers cached Mem: 411700424024401714564 0 7358401202828 -/+ buffers/cache: 4637723653232 Swap: 2650684 442650640 And it doesn't appear to be increasing. ghc is taking ~90% of the cpu, top suggests its mostly system usage: top - 21:49:22 up 10 days, 3:15, 2 users, load average: 1.42, 1.45, 1.39 Tasks: 62 total, 2 running, 60 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 99.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4117004k total, 2402860k used, 1714144k free, 735840k buffers Swap: 2650684k total, 44k used, 2650640k free, 1202832k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 819 buildd20 0 224m 198m 21m R 92.2 4.9 48:31.18 ghc 31922 dannf 20 0 3804 1908 1536 R 0.3 0.0 0:00.51 top 1 root 20 0 2144 792 652 S 0.0 0.0 0:20.16 init 2 root 20 0 000 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 000 S 0.0 0.0 0:00.13 ksoftirqd/0 strace shows ghc looping here: --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 > Anyway, this seems to be something that was introduced with 6.12. I > wonder what we can do about this, besides p-a-s. > > Iain -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309215414.gb9...@lackof.org
Re: Timeouts
On Tue, Mar 09, 2010 at 10:46:54AM -0700, dann frazier wrote: On Mon, Mar 08, 2010 at 10:56:53PM +0100, Joachim Breitner wrote: Hi, Am Montag, den 08.03.2010, 22:42 +0100 schrieb Joachim Breitner: > > This might be a solution, yes, though I would prefer not to do > > this. You've managed to get highlighting-kate's build times down, making > > it build everywhere but on armel (where it got tried on a slw > > buildd, let's see if this gets better on one of the faster boxes). We > > have similar problem with agda, could you have a look at that? > > Maybe Iain Lane can comment on agda. speaking of which: https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw says Building Agda-2.2.6... [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( src/full/Agda/Auto/NarrowingSearch.hs, dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) E: Caught signal 'Terminated': terminating immediately make: *** [build-ghc6-stamp] Terminated Build killed with signal TERM after 1 minutes of inactivity Isn???t this time limit a bit too low? I put that in to cause agda to fail and stop retrying, adn then bumped it back up. The timeout is normally 300 minutes, but agda would continue to generate output even when it had been wedged for over 12 hours. I rather suspect that the monotonically increasing memory usage is the problem here. I don't know of a resolution, and the thread with the GHC devs didn't seem to offer anything up. Anyone have any ideas? Dann, did you have a look at the memory usage when the build was going on by any chance? Anyway, this seems to be something that was introduced with 6.12. I wonder what we can do about this, besides p-a-s. Iain signature.asc Description: Digital signature
Re: Timeouts
On Tue, Mar 09, 2010 at 10:50:31AM -0700, dann frazier wrote: > On Mon, Mar 08, 2010 at 11:02:19PM +0100, Marc 'HE' Brockschmidt wrote: > > Joachim Breitner writes: > > > speaking of which: > > > https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw > > > says > > > > > > Building Agda-2.2.6... > > > [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( > > > src/full/Agda/Auto/NarrowingSearch.hs, > > > dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) > > > E: Caught signal 'Terminated': terminating immediately > > > make: *** [build-ghc6-stamp] Terminated > > > Build killed with signal TERM after 1 minutes of inactivity > > > > > > Isn?t this time limit a bit too low? > > > > Seems so, no idea what the reason for that was. penalosa has been > > reconfigured to a normal timeout in the meantime. Given back on hppa, > > now. > > Which explains why peri hasn't done anything useful for about 17 hours > :) > > I'm quite sure it is not going to make any progress: > https://buildd.debian.org/build.cgi?pkg=agda;ver=2.2.6-3;arch=hppa > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572300 > > I'm still fairly new to working w/ sbuild. Other than my > 1-minute-timeout trick, is there a way to kill a build and stop it > from retrying later? sbuild-abort should do that. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309182129.ga7...@roeckx.be
Re: Timeouts
On Mon, Mar 08, 2010 at 11:02:19PM +0100, Marc 'HE' Brockschmidt wrote: > Joachim Breitner writes: > > speaking of which: > > https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw > > says > > > > Building Agda-2.2.6... > > [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( > > src/full/Agda/Auto/NarrowingSearch.hs, > > dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) > > E: Caught signal 'Terminated': terminating immediately > > make: *** [build-ghc6-stamp] Terminated > > Build killed with signal TERM after 1 minutes of inactivity > > > > Isn?t this time limit a bit too low? > > Seems so, no idea what the reason for that was. penalosa has been > reconfigured to a normal timeout in the meantime. Given back on hppa, > now. Which explains why peri hasn't done anything useful for about 17 hours :) I'm quite sure it is not going to make any progress: https://buildd.debian.org/build.cgi?pkg=agda;ver=2.2.6-3;arch=hppa http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572300 I'm still fairly new to working w/ sbuild. Other than my 1-minute-timeout trick, is there a way to kill a build and stop it from retrying later? -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309175031.gc2...@lackof.org
Re: Timeouts
On Mon, Mar 08, 2010 at 10:56:53PM +0100, Joachim Breitner wrote: > Hi, > > Am Montag, den 08.03.2010, 22:42 +0100 schrieb Joachim Breitner: > > > This might be a solution, yes, though I would prefer not to do > > > this. You've managed to get highlighting-kate's build times down, making > > > it build everywhere but on armel (where it got tried on a slw > > > buildd, let's see if this gets better on one of the faster boxes). We > > > have similar problem with agda, could you have a look at that? > > > > Maybe Iain Lane can comment on agda. > > speaking of which: > https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw > says > > Building Agda-2.2.6... > [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( > src/full/Agda/Auto/NarrowingSearch.hs, > dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) > E: Caught signal 'Terminated': terminating immediately > make: *** [build-ghc6-stamp] Terminated > Build killed with signal TERM after 1 minutes of inactivity > > Isn???t this time limit a bit too low? I put that in to cause agda to fail and stop retrying, adn then bumped it back up. The timeout is normally 300 minutes, but agda would continue to generate output even when it had been wedged for over 12 hours. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100309174654.gb2...@lackof.org
Re: Timeouts
Hi again, On Tue, Mar 09, 2010 at 10:01:46AM +, Iain Lane wrote: Heya, [sorry, I've been away for a few days and then had some trip-induced illness to contend with] On Mon, Mar 08, 2010 at 10:42:47PM +0100, Joachim Breitner wrote: Hi, [...] Maybe Iain Lane can comment on agda. I've been watching this a bit. I just asked Marc on IRC to give back on alpha (with increased timeout), s390, sparc to see if we can get moving there. Or if they fail again then we can see how deterministic it is to maybe be able to look at refactoring the affected module(s) in coordination with upstream. I just noticed that a lot of the failures (all except hppa) are in building the profiling modules. Perhaps just dropping those (just for the problematic arches?) is an option. Although you may argue that these arches are just the ones where we need profiling the most. Cheers, Iain signature.asc Description: Digital signature
Re: Timeouts
Heya, [sorry, I've been away for a few days and then had some trip-induced illness to contend with] On Mon, Mar 08, 2010 at 10:42:47PM +0100, Joachim Breitner wrote: Hi, [...] Maybe Iain Lane can comment on agda. I've been watching this a bit. I just asked Marc on IRC to give back on alpha (with increased timeout), s390, sparc to see if we can get moving there. Or if they fail again then we can see how deterministic it is to maybe be able to look at refactoring the affected module(s) in coordination with upstream. Now, thanks to Marco's research: agda 2.2.6-2 2.2.6-3 hppa 04:57:19 60:57:00+ kfreebsd-i386 00:17:10 00:11:39 mips 02:35:19 03:54:06 mipsel 02:34:59 04:04:43 powerpc00:26:37 00:27:16 s390 00:47:49 02:00:55 sparc 03:23:58 08:33:05+ ... I wonder if we have uncovered a bug somewhere. Agda built in the past for hppa mips s390 sparc, yet is having some trouble now. That's assuming that all of the give-backs that we just scheduled fail again. Otherwise I don't want agda to hold back the testing transition, so we should be open to Joachim's previous suggestion of dropping arch support for those binaries, or doing similar to ghc6 and removing the already built binaries from those arches so that future FTBFS do not affect the testing transition. Cheers, Iain signature.asc Description: Digital signature
Re: Timeouts
Hi, Am Montag, den 08.03.2010, 22:56 +0100 schrieb Marc 'HE' Brockschmidt: > Joachim Breitner writes: > > Am Montag, den 08.03.2010, 22:30 +0100 schrieb Marc 'HE' Brockschmidt: > >> This might be a solution, yes, though I would prefer not to do > >> this. You've managed to get highlighting-kate's build times down, making > >> it build everywhere but on armel (where it got tried on a slw > >> buildd, let's see if this gets better on one of the faster boxes). We > >> have similar problem with agda, could you have a look at that? > > We also have the problem with haskell-src-exts (a build dependency of > > hlint), where no such easy solution is available. This might not affect > > the transition, as it is “only” a build dependency and haskell-src-exts > > is not in testing. > > Hum, well, it would be helpful if we could rebuild what is in testing > with packages from testing. We shouldn't abuse britney's bugs too > much. I agree. In principle, I’m all for enforcing build-dependencies at upgrade time... but in practice, sometimes, it helps :-) > Is there an option to get ghc6 to leave out optimizations that eat > up a lot of memory? It just feels wrong to see something not build on > s390 because of missing resources :-) I find an architecture that only allows 2GB of virtual memory for one process (including mmap’ed files and what not) not the ideal of a strong architecture... but of course it is in comparison to armel etc. In the case of agda, I don’t think there is a lot we can do without reimplementing part of the build system. I asked upstream about ghc’s memory consumption, and there are no easy fixes. See thread http://lists.debian.org/debian-haskell/2010/03/msg00055.html for more details. Note that leaving out optimizations could make the resulting binary close to unusable (in the worst case), so I’m not sure if we make our users a service by providing lower qualities packages just to look good on the arch coverage graph. Before we do that, I’d be in favor for dropping the support for these arches. > > There is the unreproducible bug > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554174 which needs to > > be closed or tagged squeeze-ignore (which you can probably do). Other > > than that, it looks good! > > I've downgraded it to important. The semantics of *-ignore is a bit > different, indicating that the bug fix is needed, but can be done at a > later point. That's not the issue here, where we don't even know if > there's an actual bug in the package. good, thanks for the clarification. BTW, on the page http://release.debian.org/migration/testing.pl?package=ghc6 haskell-mtl is listed, although it has built on all arches. Is it just that testing.pl does not handle synchronous transitions very well or what needs to be done to reduce the list on that page? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Timeouts
Joachim Breitner writes: > speaking of which: > https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw > says > > Building Agda-2.2.6... > [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( > src/full/Agda/Auto/NarrowingSearch.hs, > dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) > E: Caught signal 'Terminated': terminating immediately > make: *** [build-ghc6-stamp] Terminated > Build killed with signal TERM after 1 minutes of inactivity > > Isn’t this time limit a bit too low? Seems so, no idea what the reason for that was. penalosa has been reconfigured to a normal timeout in the meantime. Given back on hppa, now. Marc -- Fachbegriffe der Informatik - Einfach erklärt 139: AOL-CD Das wichtigste Werkzeug des gemeinen Spammers oder Trolls in Deutschland. (Marc Haber) pgpDi7BMJIjW4.pgp Description: PGP signature
Re: Timeouts
Hi, Am Montag, den 08.03.2010, 22:42 +0100 schrieb Joachim Breitner: > > This might be a solution, yes, though I would prefer not to do > > this. You've managed to get highlighting-kate's build times down, making > > it build everywhere but on armel (where it got tried on a slw > > buildd, let's see if this gets better on one of the faster boxes). We > > have similar problem with agda, could you have a look at that? > > Maybe Iain Lane can comment on agda. speaking of which: https://buildd.debian.org/fetch.cgi?pkg=agda&arch=hppa&ver=2.2.6-3&stamp=1267580450&file=log&as=raw says Building Agda-2.2.6... [ 1 of 191] Compiling Agda.Auto.NarrowingSearch ( src/full/Agda/Auto/NarrowingSearch.hs, dist-ghc6/build/Agda/Auto/NarrowingSearch.o ) E: Caught signal 'Terminated': terminating immediately make: *** [build-ghc6-stamp] Terminated Build killed with signal TERM after 1 minutes of inactivity Isn’t this time limit a bit too low? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part
Re: Timeouts
Joachim Breitner writes: > Am Montag, den 08.03.2010, 22:30 +0100 schrieb Marc 'HE' Brockschmidt: >> This might be a solution, yes, though I would prefer not to do >> this. You've managed to get highlighting-kate's build times down, making >> it build everywhere but on armel (where it got tried on a slw >> buildd, let's see if this gets better on one of the faster boxes). We >> have similar problem with agda, could you have a look at that? > We also have the problem with haskell-src-exts (a build dependency of > hlint), where no such easy solution is available. This might not affect > the transition, as it is “only” a build dependency and haskell-src-exts > is not in testing. Hum, well, it would be helpful if we could rebuild what is in testing with packages from testing. We shouldn't abuse britney's bugs too much. Is there an option to get ghc6 to leave out optimizations that eat up a lot of memory? It just feels wrong to see something not build on s390 because of missing resources :-) > Maybe Iain Lane can comment on agda. That would be great. >> As far as I can see, agda and the armel issues are the last bits missing >> before we can get the new ghc6 into testing :-) > > There is the unreproducible bug > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554174 which needs to > be closed or tagged squeeze-ignore (which you can probably do). Other > than that, it looks good! I've downgraded it to important. The semantics of *-ignore is a bit different, indicating that the bug fix is needed, but can be done at a later point. That's not the issue here, where we don't even know if there's an actual bug in the package. Marc -- BOFH #433: error: one bad user found in front of screen pgpytPCIORWVe.pgp Description: PGP signature
Re: Timeouts
Hi,
Am Montag, den 08.03.2010, 22:30 +0100 schrieb Marc 'HE' Brockschmidt:
> Joachim Breitner writes:
> > If the package requires too much resources for such an architecture to
> > build, maybe it’s an indication that these architectures are also a too
> > weak to use the package, and therefore there would be no loss to drop
> > support for these packages on the affected arches (i.e. remove any
> > existing old builds and add the files to N-F-U)? At least until a user
> > on these arches complains?
>
> This might be a solution, yes, though I would prefer not to do
> this. You've managed to get highlighting-kate's build times down, making
> it build everywhere but on armel (where it got tried on a slw
> buildd, let's see if this gets better on one of the faster boxes). We
> have similar problem with agda, could you have a look at that?
We also have the problem with haskell-src-exts (a build dependency of
hlint), where no such easy solution is available. This might not affect
the transition, as it is “only” a build dependency and haskell-src-exts
is not in testing.
Maybe Iain Lane can comment on agda.
> In other news, armel failed to build hdbc-{odbc,postgresl,sqlite3}. I
> guess they need a give-back + dep-wait on some new binNMUs, but I fear I
> have no idea what I need to binNMU. Could you give me a hint there?
I was just doing this this very moment. This should fix it, and I
regularly check http://tinyurl.com/ydqdkdd so I’ll watch this.
> As far as I can see, agda and the armel issues are the last bits missing
> before we can get the new ghc6 into testing :-)
There is the unreproducible bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=554174 which needs to
be closed or tagged squeeze-ignore (which you can probably do). Other
than that, it looks good!
Greetings,
Joachim
--
Joachim "nomeata" Breitner
Debian Developer
nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
Re: Timeouts
Joachim Breitner writes:
> If the package requires too much resources for such an architecture to
> build, maybe it’s an indication that these architectures are also a too
> weak to use the package, and therefore there would be no loss to drop
> support for these packages on the affected arches (i.e. remove any
> existing old builds and add the files to N-F-U)? At least until a user
> on these arches complains?
This might be a solution, yes, though I would prefer not to do
this. You've managed to get highlighting-kate's build times down, making
it build everywhere but on armel (where it got tried on a slw
buildd, let's see if this gets better on one of the faster boxes). We
have similar problem with agda, could you have a look at that?
In other news, armel failed to build hdbc-{odbc,postgresl,sqlite3}. I
guess they need a give-back + dep-wait on some new binNMUs, but I fear I
have no idea what I need to binNMU. Could you give me a hint there?
As far as I can see, agda and the armel issues are the last bits missing
before we can get the new ghc6 into testing :-)
Marc
--
BOFH #165:
Backbone Scoliosis
pgpc3Srp5jbf0.pgp
Description: PGP signature
Re: Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Marco Túlio Gontijo e Silva writes: > Excerpts from Marc 'HE' Brockschmidt's message of Sáb Mar 06 06:26:43 -0300 > 2010: >> This seems a bit more problematic than I originally assumed. >> >> Consider for example agda on sparc: >> https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 >> sparc is not a fast architecture, but also not the slowest one supported >> by Debian. In this case, it failed to build the package because a single >> file needed more than 500 minutes to compile. If this is indeed not due >> to a bug, but expected behaviour, it seems not supportable anymore. > It seems that the build time of agda for some arches grew very much with > ghc6-6.12.1, specially hppa and sparc: > > agda 2.2.6-2 2.2.6-3 > > hppa 04:57:19 60:57:00+ > kfreebsd-i386 00:17:10 00:11:39 > mips 02:35:19 03:54:06 > mipsel 02:34:59 04:04:43 > powerpc00:26:37 00:27:16 > s390 00:47:49 02:00:55 highlight-kate was rebuilt again today on s390, leading to this: [26 of 61] Compiling Text.Highlighting.Kate.Syntax.Java ( Text/Highlighting/Kate/Syntax/Java.hs, dist-ghc6/build/Text/Highlighting/Kate/Syntax/Java.p_o ) virtual memory exhausted: Cannot allocate memory I can't believe that this is not a bug. Marc -- BOFH #302: microelectronic Riemannian curved-space fault in write-only file system pgpwUT8fAjKkV.pgp Description: PGP signature
Re: Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Hi Marc. Excerpts from Marc 'HE' Brockschmidt's message of Sáb Mar 06 06:26:43 -0300 2010: > Joachim Breitner writes: > > Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: > >> Joachim Breitner writes: > >> > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 > >> > . -m "rebuild against changed pcre-light ABI" > >> Done. Got lost in the cracks somehow. Do you know why its hitting > >> timeouts on other archs? Is this something we could fix? > > Probably just because it needs a lot of memory and CPU power, and the > > other arches have difficulties compiling the package in time. > > This seems a bit more problematic than I originally assumed. > > Consider for example agda on sparc: > https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 > sparc is not a fast architecture, but also not the slowest one supported > by Debian. In this case, it failed to build the package because a single > file needed more than 500 minutes to compile. If this is indeed not due > to a bug, but expected behaviour, it seems not supportable anymore. It seems that the build time of agda for some arches grew very much with ghc6-6.12.1, specially hppa and sparc: agda 2.2.6-2 2.2.6-3 hppa 04:57:19 60:57:00+ kfreebsd-i386 00:17:10 00:11:39 mips 02:35:19 03:54:06 mipsel 02:34:59 04:04:43 powerpc00:26:37 00:27:16 s390 00:47:49 02:00:55 sparc 03:23:58 08:33:05+ For ghc6 this didn't happened; when the time grew, it grew not very much: ghc6 6.10.4-1 6.12.1-12 alpha 13:05:04 14:40:30 amd64 01:24:19 01:31:30 armel 100:47:35 127:04:23 hppa 12:25:45 16:08:58 kfreebsd-i386 01:21:37 02:14:17 mips 20:03:36 15:31:51 mipsel 20:03:22 16:25:52 powerpc04:59:03 03:25:32 s390 07:20:55 03:24:32 sparc 50:23:08 07:22:11 Maybe this is related to something in the agda's code interaction with the new version of ghc6 in hppa and sparc; possibly a bug somewhere. > How should slower archs (like mips*, armel) handle such packages? Is > splitting this up in smaller files an option? Splitting in smaller files is not very different from what I proposed in debian-haskell of using a verbose build. The good option in this case would be adding --ghc-options=-v2 to Setup configure. I think that, if these packages are not going to be dropped for these arches, this is a good enough workaround. At least it seems to me to be better than what's being used now: watcher.sh (#571824). Greetings. (...) -- marcot http://wiki.debian.org/MarcoSilva -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1267876809-sup-8...@zezinho
Re: Timeouts
Hi, Am Samstag, den 06.03.2010, 10:26 +0100 schrieb Marc 'HE' Brockschmidt: > Joachim Breitner writes: > > Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: > >> Joachim Breitner writes: > >> > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 > >> > . -m "rebuild against changed pcre-light ABI" > >> Done. Got lost in the cracks somehow. Do you know why its hitting > >> timeouts on other archs? Is this something we could fix? > > Probably just because it needs a lot of memory and CPU power, and the > > other arches have difficulties compiling the package in time. > > This seems a bit more problematic than I originally assumed. > > Consider for example agda on sparc: > https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 > sparc is not a fast architecture, but also not the slowest one supported > by Debian. In this case, it failed to build the package because a single > file needed more than 500 minutes to compile. If this is indeed not due > to a bug, but expected behaviour, it seems not supportable anymore. How > should slower archs (like mips*, armel) handle such packages? Is > splitting this up in smaller files an option? Even if possible, I’m not sure if that would help: Having more smaller files will give more output on the build log, but still take the very long time it takes. If the package requires too much resources for such an architecture to build, maybe it’s an indication that these architectures are also a too weak to use the package, and therefore there would be no loss to drop support for these packages on the affected arches (i.e. remove any existing old builds and add the files to N-F-U)? At least until a user on these arches complains? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Joachim Breitner writes: > Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: >> Joachim Breitner writes: >> > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 . >> > -m "rebuild against changed pcre-light ABI" >> Done. Got lost in the cracks somehow. Do you know why its hitting >> timeouts on other archs? Is this something we could fix? > Probably just because it needs a lot of memory and CPU power, and the > other arches have difficulties compiling the package in time. This seems a bit more problematic than I originally assumed. Consider for example agda on sparc: https://buildd.debian.org/fetch.cgi?pkg=agda;ver=2.2.6-3;arch=sparc;stamp=1267334936 sparc is not a fast architecture, but also not the slowest one supported by Debian. In this case, it failed to build the package because a single file needed more than 500 minutes to compile. If this is indeed not due to a bug, but expected behaviour, it seems not supportable anymore. How should slower archs (like mips*, armel) handle such packages? Is splitting this up in smaller files an option? Marc -- BOFH #89: Electromagnetic energy loss pgptN3nqOvnIz.pgp Description: PGP signature
Timeouts, Was: Bug#571745: nmu: highlighting-kate_0.2.5-4
Hi, Am Freitag, den 05.03.2010, 14:53 +0100 schrieb Marc 'HE' Brockschmidt: > Joachim Breitner writes: > > nmu highlighting-kate_0.2.5-4 . i386 kfreebsd-i386 amd64 kfreebsd-amd64 . > > -m "rebuild against changed pcre-light ABI" > > Done. Got lost in the cracks somehow. Do you know why its hitting > timeouts on other archs? Is this something we could fix? Probably just because it needs a lot of memory and CPU power, and the other arches have difficulties compiling the package in time. There are more haskell-packages affected: https://buildd.debian.org/status/package.php?suite=unstable&p=haskell-haskell-src+xmonad-contrib+haxml+haskell-edison-core+highlighting-kate+haskelldb+haskell-regex-tdfa+haskell-src-exts+agda I already contacted the armel porters (the packages used to build a month ago, with the same compiler, it seems that they have reduced the timeout since then), but I’m wondering if there is a general solution to this? Maybe a flag in debian/control specifying that a package is known to take a very long time to build? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
