Re: vtk / m68k
Mathieu Malaterre dixit: > In case you did not notice vtk FTBFS on m68k: > >http://buildd.debian-ports.org/status/fetch.php?pkg=vtk&arch=m68k&ver=5.8.0-14.1&stamp=1385404238 Mh, I didn’t notice myself as it wasn’t my buildd. Now, doesn’t GCC normally retry on segfault and tell us whether it’s reproducible or not? Also, it doesn’t say in which function… this is a new one. I note that vtk has never built before on m68k according to buildd.d-ports.org (after the move to it). Did it ever build when in the main archive? I could probably build it manually, just to see. bye, //mirabilos -- 22:59⎜ glaub ich termkit is kompliziert | glabe nicht das man damit schneller arbeitet | reizüberflutung │ wie windows │ alles evil zuviel bilder │ wie ein spiel | 23:00⎜ die meisten raffen auch nicht mehr von windows | 23:01⎜ bilderbücher sind ja auch nich wirklich verbreitet als erwachsenen literatur ‣ who needs GUIs thus? -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.1312060903350.23...@herc.mirbsd.org
Re: vtk / m68k
On 2013-12-06 10:05, Thorsten Glaser wrote: In case you did not notice vtk FTBFS on m68k: http://buildd.debian-ports.org/status/fetch.php?pkg=vtk&arch=m68k&ver=5.8.0-14.1&stamp=1385404238 We should increase the timeout on all buildds, I think... I note that vtk has never built before on m68k according to buildd.d-ports.org (after the move to it). Did it ever build when in the main archive? When did we move to debian-ports.org? id | packagename | version| dist | arch | begin | endtime | buildd | state +-+--+--+--+++--+-- 149850 | vtk | 5.0.4-1.1| unstable | m68k | 2008-10-10 13:19:04.454418 | 2008-10-12 07:54:05.206218 | poseidon | maybe-successful 127716 | vtk | 5.0.4-1+b1 | unstable | m68k | 2008-06-07 00:09:09.513509 | 2008-06-07 00:24:09.506838 | thing2 | maybe-successful 126355 | vtk | 5.0.4-1+b1 | unstable | m68k | 2008-05-30 18:21:14.190207 | 2008-06-01 19:15:09.180729 | zeus | maybe-successful 113542 | vtk | 5.0.4-1 | unstable | m68k | 2008-03-27 07:13:13.963362 | 2008-03-31 14:14:08.726147 | vault13 | maybe-successful 113321 | vtk | 5.0.3-1.1| unstable | m68k | 2008-03-26 02:54:08.00619 | 2008-03-27 07:14:14.075255 | vivaldi | maybe-successful 112636 | vtk | 5.0.3-1.1| unstable | m68k | 2008-03-22 10:29:33.193592 | 2008-03-26 02:49:06.508348 | vivaldi | maybe-successful 60180 | vtk | 5.0.2.dfsg-1 | unstable | m68k | 2007-03-29 04:14:00.224401 | 2007-04-02 00:53:55.616146 | vivaldi | maybe-successful 71670 | vtk | 5.0.3-1 | unstable | m68k | 2007-06-27 16:28:35.528248 | 2007-07-01 00:29:22.518169 | vault13 | maybe-successful 71622 | vtk | 5.0.3-1 | unstable | m68k | 2007-06-27 04:13:30.825349 | 2007-06-27 04:18:30.29816 | vivaldi | maybe-successful 43171 | vtk | 5.0.2-4 | unstable | m68k | 2006-11-14 18:39:06.331159 | 2006-11-15 17:59:16.955589 | arrakis | maybe-successful 42922 | vtk | 5.0.2-2 | unstable | m68k | 2006-11-13 06:54:26.245727 | 2006-11-13 07:06:54.867305 | kiivi| maybe-successful 42001 | vtk | 5.0.1-4 | unstable | m68k | 2006-11-01 05:54:07.677343 | 2006-11-05 01:44:18.509613 | vivaldi | maybe-successful 39196 | vtk | 5.0.1-4 | unstable | m68k | 2006-09-30 03:29:07.446155 | 2006-10-01 02:44:06.133365 | vivaldi | maybe-successful 38437 | vtk | 5.0.1-4 | unstable | m68k | 2006-09-23 00:10:24.643507 | 2006-09-23 00:39:07.269186 | tanda| maybe-successful 36000 | vtk | 5.0.1-1 | unstable | m68k | 2006-08-24 21:17:26.96882 | 2006-08-28 12:18:18.123903 | vault13 | maybe-successful 7235 | vtk | 4.4.2-10 | unstable | m68k | 2006-01-18 08:58:52.254056 | 2006-01-18 09:53:31.906897 | kiivi| maybe-successful 6998 | vtk | 4.4.2-9 | unstable | m68k | 2006-01-16 20:13:33.165812 | 2006-01-16 21:13:34.449417 | vault13 | maybe-successful 162051 | vtk | 5.2.1-1 | unstable | m68k | 2009-03-06 23:49:03.622448 | 2009-03-09 01:03:55.869712 | zlin2| maybe-successful 163598 | vtk | 5.2.1-2 | unstable | m68k | 2009-03-23 15:03:40.342003 | 2009-03-23 15:08:34.563331 | zlin2| maybe-successful 197068 | vtk | 5.8.0-14.1 | unstable | m68k | 2013-11-18 23:58:15.79325 | 2013-11-25 19:31:06.082174 | kullervo | maybe-successful (20 rows) -- Ciao... //Fon: 0381-2744150 . Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key. -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/48793276d5add622ae36318d6ac1470a@localhost
dpkg RAM use (was Re: Bits from the Release Team (Jessie freeze info))
Dixi quod… > exactly resource-saving. (Even running apt/dpkg isn’t due to the > sheer size of the archive, though Guillem kindly reduced memory > usage in the upcoming dpkg upload.) Indeed. Running dpkg and APT together should now be possible in 40 MiB or less of total RAM instead of 128 MiB from before. (Less if you use swap, ofc.) This is a totally “random sample”, nothing tested. (Both of them.) But I like it, it’s definitely noticeable. bye, //mirabilos -- [16:04:33] bkix: "veni vidi violini" [16:04:45] bkix: "ich kam, sah und vergeigte"... -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/alpine.deb.2.10.1312061040030.19...@tglase.lan.tarent.de
Re: vtk / m68k
On Fri, Dec 06, 2013 at 10:23:00AM +0100, Ingo J?rgensmann wrote: > On 2013-12-06 10:05, Thorsten Glaser wrote: > >> In case you did not notice vtk FTBFS on m68k: > >>http://buildd.debian-ports.org/status/fetch.php?pkg=vtk&arch=m68k&ver=5.8.0-14.1&stamp=1385404238 > > We should increase the timeout on all buildds, I think... kullervo just failed to build kate... while creating the kate-dbg package. All the other debs have already been created. Three days wasted, or should I upload the debs without the dbg package? Can somebody remind me how to increase the timeout on a per package base? Or how to tell the build which packages I do not want him to build? Christian -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131206095920.gd26...@chumley.earth.sol
Re: vtk / m68k
On 2013-12-06 10:59, Christian T. Steigies wrote: We should increase the timeout on all buildds, I think... kullervo just failed to build kate... while creating the kate-dbg package. All the other debs have already been created. Three days wasted, or should I upload the debs without the dbg package? I had already several of those wasted packages on Spice. There I thought it was due to the low memory and all the swapping that is involved when building the *.deb. Funny enough I think all those failed at the *-dbg.deb as well. Can this be caused by xz as compression tool? Can somebody remind me how to increase the timeout on a per package base? Or how to tell the build which packages I do not want him to build? Back then we used a unified list that were downloaded from Stephens webspace and used by some @includes in the config. I don't know whether this @include still works, but when it does we should use that approach again instead of maintaining on each buildd such a list. -- Ciao... //Fon: 0381-2744150 . Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key. -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/d07b294691b1f2894cf5f64b24c65cb3@localhost
Re: vtk / m68k
Ingo Jürgensmann dixit: > On 2013-12-06 10:59, Christian T. Steigies wrote: >>> We should increase the timeout on all buildds, I think... Not that vtk failed due to the timeout, but a segfault. >> kullervo just failed to build kate... while creating the kate-dbg package. >> All the other debs have already been created. Three days wasted, or should I >> upload the debs without the dbg package? Hm, not really. Anyway, I increased my timeout from 600 to 1800, too. The slower ones should maybe use even more. > *.deb. Funny enough I think all those failed at the *-dbg.deb as well. Can > this > be caused by xz as compression tool? xz needs just under 186 MiB of RAM for compressing at the default level but quite some CPU of course. That’s not an indication it’s bad, I think even m68k can work with xz. >> Can somebody remind me how to increase the timeout on a per package base? Meh, just crank it globally. >> Or how to tell the build which packages I do not want him to build? > > Back then we used a unified list that were downloaded from Stephens webspace > and used by some @includes in the config. I don't know whether this @include > still works, but when it does we should use that approach again instead of > maintaining on each buildd such a list. That would certainly be welcome. I’m putting packages into Not-For-Us but then _no_ buildd will pick them up; we have cases where packages can only reasonably be built on ARAnyM (huge, etc.) or cannot be built on ARAnyM at all (that thing with L2 caches recently), so we can still use per-buildd overrides then. bye, //mirabilos -- „Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal nicht…“ -- Natureshadow, per SMS „Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.bsm.4.64l.131206030.24...@herc.mirbsd.org
Re: vtk / m68k
On Fri, Dec 06, 2013 at 11:13:56AM +, Thorsten Glaser wrote: > > >> Can somebody remind me how to increase the timeout on a per package base? > > Meh, just crank it globally. Ok, I set it to 1800 now. But maybe somebody can still tell me how to do it per package nowadays? > >> Or how to tell the build which packages I do not want him to build? Or this? > > Back then we used a unified list that were downloaded from Stephens webspace > > and used by some @includes in the config. I don't know whether this @include > > still works, but when it does we should use that approach again instead of > > maintaining on each buildd such a list. > > That would certainly be welcome. I???m putting packages into Not-For-Us > but then _no_ buildd will pick them up; we have cases where packages > can only reasonably be built on ARAnyM (huge, etc.) or cannot be built > on ARAnyM at all (that thing with L2 caches recently), so we can still > use per-buildd overrides then. I suggest to put kate into not-for-us, and all other (huge) packages that fail due to timeout. If the contents of that list (too-big-for-us) is available, maybe you can pick them on aranym, or all buildds can pick them when all other packages have been built. Or maybe only buildds with >=512MB RAM pick them (the Falcons and aranyms). Which brings me back to my question, how to I exclude packages on one buildd nowadays? Christian -- To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131206113724.ge26...@chumley.earth.sol
Re: vtk / m68k
Christian T. Steigies dixit:
>I suggest to put kate into not-for-us, and all other (huge) packages that
>fail due to timeout.
kate and similar don’t fail on ara5 due to timeout.
>maybe you can pick them on aranym
No, Not-For-Us prevents wanna-build from acting on them.
Please use only an exclusion list for things your buildd
cannot build on your buildd, if others can do that. I’m
not going to build them all manually every time.
>question, how to I exclude packages on one buildd nowadays?
There’s something in one of ~buildd/.{sbuild,buildd}rc IIRC.
bye,
//mirabilos
--
„Also irgendwie hast du IMMER recht. Hier zuckelte gerade ein Triebwagen mit
der Aufschrift "Ostdeutsche Eisenbahn" durch Wuppertal. Ich glaubs machmal
nicht…“ -- Natureshadow, per SMS
„Hilf mir mal grad beim Denken“ -- Natureshadow, IRL, 2x
--
To UNSUBSCRIBE, email to debian-68k-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.bsm.4.64l.1312061523040.2...@herc.mirbsd.org
