On 2023-04-10 14:36, Aurelien Jarno wrote:
> On 2023-03-30 19:59, Wookey wrote:
> > Some enquiries tell me that both these machines types are reliable
> > (although the mustangs are slow) at OBS and Yocto, so they can be OK,
> > but there is certainly much faster kit available now (Ampere Altra).
>
ulously manly one. A bit
of configury on the Aventek site suggests that basic ARM Altra servers
cost about twice as much as AMD ones for similar specs
(cores/RAM/disk), but then the power consumption is less than half. I
don't know how the performance actually compares for buildd purposes
W dniu 10.04.2023 o 14:36, Aurelien Jarno pisze:
On 2023-03-30 19:59, Wookey wrote:
My guess is that all the Conova machine are Mustangs, and the UBC machines
are emags? Is that right?
Unfortunately we don't have a lot of informations about the Conova
machines, that is conova-node01 and cono
with buster on them :(.
>
> OK. That's not good. Can you say which hardware those machines are?
> Our buildd database does not say what actual kit is in use (just the
> manufacturer), and I don't have rights to read the detailed buildd
> admin info on the UBC and conova
rvers hosted at Conova. All of them crash
> regularly (a few times per week in total) and need a powercycle. In
> addition the bullseye kernel does not work on Applied Micro servers, so
> we are currently stuck with buster on them :(.
OK. That's not good. Can you say which hardware t
yes: unstable and ageing hardware
>
> I still think that's referring to the 32-bit machines. I'm a buildd
The 32-bit buildds are running quite stable besides a few disks dying,
given their age.
However they are difficult to manage remotely (they don't start
automatically after powe
about rebooting from cron,
> also the release team arch qualifications have a note about this:
>
> * concerns-dsa: arm64/armhf/armel: yes: unstable and ageing hardware
I still think that's referring to the 32-bit machines. I'm a buildd
admin for those ports and the machines on
Arnd Bergmann dixit:
>Yes, that sounds reasonable in principle.
OK, good. I’ll do that then when I’m caught up with dayjob work.
>I've tried to come up with a minimal test case like
Meh, I’m just going to write a main.s ;-) I like assembly.
Also, less surprises there. GCC is…
bye,
//mirabilos
On Wed, Aug 24, 2022 at 8:03 PM Thorsten Glaser wrote:
> Do you think it would be worth compiling a VERY tiny program from
> execute_before_dh-auto-build that just runs an swp instruction, and
> if that fails, issue a message pointing to your message? I’m doing
> something similar for mksh wrt. th
t I’ve seen it.) Or, at least, I hope they do.
>Most likely, the buildd is running a default debian kernel and has
>the compile-time options enabled, but has it disabled at runtime.
>
>Can you find out if /proc/sys/abi/swp exists on the system, and
Only on the porterbox amdahl; it exi
ome research, is it. This is needed for armel, which
> is v5. Apparently, Linux has SWP emulation for v7/v8 hosts, but at least
> one buildd listed does not have this enabled, breaking the armel ABI.
>
> Please ensure that only hosts with working SWP emulation run armel.
>
> (Can
osts, but at least
one buildd listed does not have this enabled, breaking the armel ABI.
Please ensure that only hosts with working SWP emulation run armel.
(Can I reassign this bugreport to the buildd? Does it have a virtual
package in debbugs?)
Until then, I guess I’ll keep giveback’ing dietlibc on
Hi,
octave segfaults on the buildd (hoibi)
https://buildd.debian.org/status/package.php?p=octave in its testsuite,
but builds fine on a porterbox (harris). Any idea what could be the
issue and (more important) how to debug it?
Thanks
Thomas
--
To UNSUBSCRIBE, email to debian-arm-requ
.@buildd.debian.org?
>
> The build in currently building for the second time with the broken perl
> version. It once again has ended up in an eternal loop in the buggy perl
> installation in the buildd build root. The build has now been running
> for more than 31 hours, and will not succe
Hi!
Is there anyone that receives the mails sent to ar...@buildd.debian.org?
The build in currently building for the second time with the broken perl
version. It once again has ended up in an eternal loop in the buggy perl
installation in the buildd build root. The build has now been running
for
On Thu, Sep 02, 2010, Colin Tuckley wrote:
> >which of the current kernel armel flavours are armhf-ready (which have a CPU
> >that would support armhf): iop32x, ixp4xx, kirkwood, orion5x, (versatile?)
>
> All of the ARM reference platforms (Versatile, Realview and
> Vexpress) can have VFP or Neon
Quoting Konstantinos Margaritis :
As I want to work on armhf support for the linux kernel packages, and I have
to add/remove flavours for armhf accordingly, I'd like to know from people
that know more about this than I do:
which of the current kernel armel flavours are armhf-ready (which have a
ey are too many and too
intrusive, so we will wait for mainlining them into a more recent version.
BTW, the first armhf buildd is running, stats can be viewed here:
http://buildd.debian-ports.org/status/architecture.php?a=armhf&suite=unstable
The buildd is running over nbd on a 100
ist/porters possibly comment upon this
> > > bug? Please could you keep buildd-tools-devel and the bug
> > > in the CC on any reply. Thanks.
> > >
> > > It's not clear to me why this bug has suddenly appeared, and
> > > only on armel. There seem to
tags fixed-upstream pending
thanks
On Sat, May 15, 2010 at 09:57:25PM +0100, Roger Leigh wrote:
> I've attached a patch for schroot which removes the need for
> getting the personality from the kernel. We cache the set
> personality and return that instead. Not as nice as I would
> have liked, b
tags 580136 + patch
thanks
On Fri, May 07, 2010 at 05:04:51PM +0200, Arnaud Patard wrote:
> Roger Leigh writes:
>
> > Could the Debian ARM list/porters possibly comment upon this
> > bug? Please could you keep buildd-tools-devel and the bug
> > in the CC on any reply.
Roger Leigh writes:
Hi,
> Could the Debian ARM list/porters possibly comment upon this
> bug? Please could you keep buildd-tools-devel and the bug
> in the CC on any reply. Thanks.
>
> It's not clear to me why this bug has suddenly appeared, and
> only on armel.
Could the Debian ARM list/porters possibly comment upon this
bug? Please could you keep buildd-tools-devel and the bug
in the CC on any reply. Thanks.
It's not clear to me why this bug has suddenly appeared, and
only on armel. There seem to be a few possibilities:
1) schroot is
Martin Michlmayr wrote:
This also raises the question what to do about arm, i.e. whether we
can remove support for arm from the kernel, installer and other
packages. Riku and Aurelien initially agreed to remove it, but then
Riku pointed out that we may have to keep support around in sid if arm
w
Frans Pop writes:
> On Sunday 15 February 2009, Martin Michlmayr wrote:
>> This also raises the question what to do about arm, i.e. whether we
>> can remove support for arm from the kernel, installer and other
>> packages. Riku and Aurelien initially agreed to remove it, but then
>> Riku pointed
On Sunday 15 February 2009, Martin Michlmayr wrote:
> This also raises the question what to do about arm, i.e. whether we
> can remove support for arm from the kernel, installer and other
> packages. Riku and Aurelien initially agreed to remove it, but then
> Riku pointed out that we may have to k
* Luk Claes [2009-02-15 17:24]:
> Why would we want to add support for new arm hardware if not for new
> installations?
Not new hardware, but a new kernel may have performance enhancements
that may be of interest to existing arm users.
--
Martin Michlmayr
http://www.cyrius.com/
--
To UNSUBSC
Martin Michlmayr wrote:
> This also raises the question what to do about arm, i.e. whether we
> can remove support for arm from the kernel, installer and other
> packages. Riku and Aurelien initially agreed to remove it, but then
> Riku pointed out that we may have to keep support around in sid if
This also raises the question what to do about arm, i.e. whether we
can remove support for arm from the kernel, installer and other
packages. Riku and Aurelien initially agreed to remove it, but then
Riku pointed out that we may have to keep support around in sid if arm
wants to take part in lenny
On Fri, Feb 08, 2008 at 06:48:18PM +0100, Moritz Muehlenhoff wrote:
> Just to give an overview of current security updates blocked by arm:
> (the hppa buildd is currently offline and thus ignored)
-snip-
> Also there are four updates for iceweasel, xulrunner, icedove
> and iceape
Andrew M.A. Cater wrote:
> Anybody come across a "Dual HDD NAS" rebadged from SVP. I'm assuming it
> runs ARM internally?
The web site says "Storlink's Centroid SL3316-G chipset."
So yes, it's ARM, but not one supported by Debian (yet) I suspect.
Colin
--
Colin Tuckley | +44(0)1903 236
On Fri, Feb 08, 2008 at 11:16:09PM +, Steve McIntyre wrote:
> >I don't know which kind of machine is planned for armel.
>
> toffee is an N2100, just the same as hedges AFAIK.
>
Anybody come across a "Dual HDD NAS" rebadged from SVP. I'm assuming it
runs ARM internally?
AndyC - who has just
slowest arch requires ca. 4-5 hours, imposing another
>>> delay.
>>>
>>
>> It takes that long on hedges.billgatliff.com? Wow!
>>
>> Are you saying that _arm_ is lacking high-grunt hardware, or _arme[lb]_?
>
>The current arm buildd building etch and sarge
* Moritz Muehlenhoff <[EMAIL PROTECTED]> [2008-02-08 23:30]:
> toffee, the current security buildd is already a "Thecus N2100" (I
> don't know if there are different models with varying speeds).
There's only one model of the N2100.
--
Martin Michlmayr
http://www.
sing another
>> delay.
>>
>
> It takes that long on hedges.billgatliff.com? Wow!
>
> Are you saying that _arm_ is lacking high-grunt hardware, or _arme[lb]_?
The current arm buildd building etch and sarge is slow.
I don't know which kind of machine is p
On Fri, Feb 08, 2008 at 07:39:50PM +, Martin Guy wrote:
> 2008/2/8, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> > On Fri, Feb 08, 2008 at 06:48:18PM +0100, Moritz Muehlenhoff wrote:
> > > So, these Intel boards are _badly_ needed. Or maybe the buildd
> > > c
Kevin Price wrote:
Hi Martin,
Martin Guy schrieb:
If it's just a question of money I don't mind buying the security team
an N2100, but mine is giving segfaults and bus errors on long builds
so you might like to consider something different.
Are you saying that in general N2100 might b
Hi Martin,
Martin Guy schrieb:
> If it's just a question of money I don't mind buying the security team
> an N2100, but mine is giving segfaults and bus errors on long builds
> so you might like to consider something different.
Are you saying that in general N2100 might be unreliable?
Kevin
--
2008/2/8, Daniel Jacobowitz <[EMAIL PROTECTED]>:
> On Fri, Feb 08, 2008 at 06:48:18PM +0100, Moritz Muehlenhoff wrote:
> > So, these Intel boards are _badly_ needed. Or maybe the buildd
> > can be run in qemu on a fast amd64 machine, I don't know if
> > that would
Moritz Muehlenhoff wrote:
Also there are four updates for iceweasel, xulrunner, icedove
and iceape coming very soon, which take 12-15 hours each, while
the second slowest arch requires ca. 4-5 hours, imposing another
delay.
It takes that long on hedges.billgatliff.com? Wow!
Are you saying
On Fri, Feb 08, 2008 at 06:48:18PM +0100, Moritz Muehlenhoff wrote:
> So, these Intel boards are _badly_ needed. Or maybe the buildd
> can be run in qemu on a fast amd64 machine, I don't know if
> that would work out.
It would probably be slower than the existing buildd.
--
Dan
On Mon, Feb 04, 2008 at 01:05:29PM +0200, Riku Voipio wrote:
> On Sun, Feb 03, 2008 at 11:01:01PM +0100, Moritz Muehlenhoff wrote:
> > I have a question wrt armel qualification for Lenny:
> > What type of machine is planned to be used as the
> > security buildd?
>
> Gen
On Sun, Feb 03, 2008 at 11:01:01PM +0100, Moritz Muehlenhoff wrote:
> I have a question wrt armel qualification for Lenny:
> What type of machine is planned to be used as the
> security buildd?
Generally buildd's are handled by infrastructure team, not by porters.
> Martin Michl
Hi,
I have a question wrt armel qualification for Lenny:
What type of machine is planned to be used as the
security buildd?
The reason I'm asking is because the current arm security
buildd (toffee, a Thecus N2100) has become a bottleneck
for fast security updates (compilations take thric
Hiya folks,
I've moved the buildd on cats over to another Thecus box, just as I
did with toffee a while back. SSH login and mail details should be
identical if you need anything (for those people with accounts);
obviously, shout if you have any problems. We'll keep the old install
aro
Guys:
A couple of weeks ago I set up hedges.billgatliff.com, an ARM machine I
purchased and installed specifically to donate to the Debian Project as
an ARM buildd and/or developer machine. It is installed alongside
leisner.billgatliff.com, which is also tasked solely for Debian ARM
work
Moin,
I am currently investigating why PDL (Perl Data Language) version 1:2.4.3-3
(which fixes a very important FTBFS issue related to mesagl also present in
1:2.4.2-6) has not gone into testing yet. One of the problems is: according
to http://buildd.debian.org/pkg.cgi?pkg=pdl
my package is in the
Guys:
I just set up hedges.billgatliff.com, an ARM machine I purchased and
installed specifically to donate to the Debian Project as an ARM buildd
and/or developer machine. It is installed alongside
leisner.billgatliff.com, which is also tasked solely for Debian ARM work.
Hedges is a
Wookey wrote:
On 2006-11-01 13:51 -0600, Bill Gatliff wrote:
Guys:
Tomorrow morning CST I will be installing a Thecus n2100 at my colo. I
have purchased this machine with the intention of donating it to the
Debian Project to use as a buildd, developer machine, or in whatever
other
On 2006-11-01 13:51 -0600, Bill Gatliff wrote:
> Guys:
>
>
> Tomorrow morning CST I will be installing a Thecus n2100 at my colo. I
> have purchased this machine with the intention of donating it to the
> Debian Project to use as a buildd, developer machine, or in whatever
Jim Buttafuoco wrote:
Bill, where did you get it and for how much?
Newegg. About $500 including memory and disk.
b.g.
--
Bill Gatliff
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bill, where did you get it and for how much?
-Original Message-
From: Bill Gatliff [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 2:51 PM
To: Debian ARM
Subject: New buildd soon to be available
Guys:
Tomorrow morning CST I will be installing a Thecus n2100 at my colo. I
Guys:
Tomorrow morning CST I will be installing a Thecus n2100 at my colo. I
have purchased this machine with the intention of donating it to the
Debian Project to use as a buildd, developer machine, or in whatever
other capacity the Project deems useful. The machine will be installed
Christoph Martin a écrit :
Hi Debian arm build maintainers,
I uploaded a new version of xlbiff on in June, which build without a
problem on all autobuilders except arm. From the log is seams, that
there was a problem with the installation of the X11 builddepends at
that time on the buildd host
Hi Debian arm build maintainers,
I uploaded a new version of xlbiff on in June, which build without a
problem on all autobuilders except arm. From the log is seams, that
there was a problem with the installation of the X11 builddepends at
that time on the buildd host (smackdown ?). I send Ryan
+++ Ari Pollak [05-12-24 15:03 -0500]:
> Martin Pitt wrote:
> > Hi!
> >
> > The PostgreSQL test suite currently fails for arm (specifically on
> > smackdown) because the buildd cannot resolve 'localhost':
> This is breaking the jnettop build completely on
On Sat, Dec 24, 2005 at 03:03:27PM -0500, Ari Pollak wrote:
> This is breaking the jnettop build completely on smackdown, and will
> also break curl if it ever builds on smackdown.
[EMAIL PROTECTED] is the contact address for the buildd
administrator.
> Martin Pitt wrote:
> > H
This is breaking the jnettop build completely on smackdown, and will
also break curl if it ever builds on smackdown.
Martin Pitt wrote:
> Hi!
>
> The PostgreSQL test suite currently fails for arm (specifically on
> smackdown) because the buildd cannot resolve 'localhost'
Hi!
The PostgreSQL test suite currently fails for arm (specifically on
smackdown) because the buildd cannot resolve 'localhost':
LOG: could not resolve "localhost": Name or service not known
LOG: disabling statistics collector for lack of working socket
Full build log is
* Lennart Sorensen <[EMAIL PROTECTED]> [2005-03-08 10:55]:
> On Tue, Mar 08, 2005 at 02:45:55PM +0100, Rafael Laboissiere wrote:
> > Where can you see this?
>
> Go to buildd.debian.org, Click on "examine the build log database",
> select arm, and type octave2.1 as package name, and see list of bu
On Tue, Mar 08, 2005 at 05:45:23PM +0100, Rafael Laboissiere wrote:
> What do you mean by "no one has accepted it"?
As far as I understand the build system, someone has to sign the build
log before the package is accepted into the archives. Until someone
(not sure if that is a buil
On Tue, Mar 08, 2005 at 02:45:55PM +0100, Rafael Laboissiere wrote:
> Where can you see this?
Go to buildd.debian.org, Click on "examine the build log database",
select arm, and type octave2.1 as package name, and see list of build
attemps. Maybe-successful almost always means success. You can c
* Lennart Sorensen <[EMAIL PROTECTED]> [2005-03-07 10:11]:
> Well my arm built 2.1.64 succesfully, but it took a very long time.
It does not surprise me.
> I see in the buildd.debian.org status that arm did build 2.1.65-1,
Where can you see this?
> although I suspect no one has accepted it yet
On Sat, Mar 05, 2005 at 12:09:51AM +0100, Rafael Laboissiere wrote:
> Thanks a lot. A new upstream version of Octave was released today (2.1.67)
> and I already uploaded the corresponding Debian package. It may be that by
> Monday we will also here news from the arm build daemon...
Well my arm b
* Lennart Sorensen <[EMAIL PROTECTED]> [2005-03-04 17:34]:
> I am currently trying a manual build to see if it builds or not on arm.
> So far it has taken about 7 hours, and it's still going (on a 400MHz
> PXA255), so it may simply have timed out on the arm buildd. G++ has a
there a way to know what
> > happened with the arm buildd?
>
> We got no answer from the debian-arm crew to my request above. I think we
> should proceed in the usual way. So, let us go: could someone from the
> debian-admin team please install the build-deps for the octave2.1 pa
* Rafael Laboissiere <[EMAIL PROTECTED]> [2005-02-28 23:31]:
> The latest octave2.1 package reached unstable on 25 Feb 2005 08:32:12 -0500.
> All the arches, besides arm, have catched up. Is there a way to know what
> happened with the arm buildd?
We got no answer from the debian
The latest octave2.1 package reached unstable on 25 Feb 2005 08:32:12 -0500.
All the arches, besides arm, have catched up. Is there a way to know what
happened with the arm buildd?
--
Rafael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Troubl
n tcl8.2
Reading Package Lists...
Building Dependency Tree...
Package tcl8.2 has no available version, but exists in the database.
This was on the buildd 'netwinder'.
The sbuildrc file shouldn't be specifying a version of tcl that no longer
exists in the archive - that's jus
Hello,
For some reason libtool is not being installed on arm. The buildd
seems to be building the package correctly
(http://buildd.debian.org/fetch.php?&pkg=libspf2&ver=1.0.4-3&arch=arm&stamp=1100734655&file=log&as=raw)
but it is still not installed.
Looking at the output
On Wed, 2004-10-27 at 20:07, Adam C Powell IV wrote:
> Also, I ran out of disk space during make install, so I can't upload...
> :-(
Never mind, got creative with debfoster and freed a bit of space. It's
in incoming. Final patch against pristine source is attached.
Zeen,
-Adam P.
GPG fingerpr
reopen 271645
retitle 271645 FTBFS: excessive memory use makes autobuild impossible
tags 271645 +patch
thanks
On Tue, 2004-10-26 at 14:17, Ralph Siemsen wrote:
> Adam C Powell IV wrote:
>
> > Hey, that worked! Now, how to dig in and try to get that one file to
> > compile with -O0 during the bui
Adam C Powell IV wrote:
Hey, that worked! Now, how to dig in and try to get that one file to
compile with -O0 during the build...
Hint: you can override CFLAGS etc in makefiles on a per-target basis.
The info pages describe it under "info make Target-specific" or see
http://www.gnu.org/software/
On Tue, 2004-10-26 at 13:05, Ralph Siemsen wrote:
> Adam C Powell IV wrote:
>
> > There's something wrong here, either a g++ bug or a package bug. I
> > don't see how a 58K .cpp file is taking that much memory to compile,
> > when nothing else in the package seemed to take more than 30-40 MB.
>
hopefully someone there can trigger zinf to
> >> > be rebuilt on an ARM machine with more RAM - see [0] for details. ]
> >> >
> >> > [0]
> >> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271645&repeatmerged=no
> >> >
&g
Adam C Powell IV wrote:
There's something wrong here, either a g++ bug or a package bug. I
don't see how a 58K .cpp file is taking that much memory to compile,
when nothing else in the package seemed to take more than 30-40 MB.
It often depends on the optimisation settings, or the use of templated
RM machine with more RAM - see [0] for details. ]
>> >
>> > [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271645&repeatmerged=no
>> >
>> > As pointed out already, this is not a package bug, but the buildd in
>> > question had too little RAM.
] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271645&repeatmerged=no
> >
> > As pointed out already, this is not a package bug, but the buildd in
> > question had too little RAM.
>
> I've got a Netwinder with a bunch of RAM and will give it a try.
Hmm, 128
In message <[EMAIL PROTECTED]>
Helen Faulkner <[EMAIL PROTECTED]> wrote:
> Does anyone know whether arm uses the same encoding as one of these examples?
> What I am hoping is that arm uses the same floating point encoding as one of
> the
ARM is exactly the same as x86, except that the
Please CC to me - I'm not subscribed to the list.
I am maintaining a new package, labplot, that is failing, at its first upload,
to build on arm (and several other things). I believe the problem is that there
is no floating point encoding being defined for that architecture, which is
leading to
o
>
> As pointed out already, this is not a package bug, but the buildd in
> question had too little RAM.
I've got a Netwinder with a bunch of RAM and will give it a try.
Zeen,
-Adam P.
GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6
Welcome to the best sof
[I'm CCing debian-arm, as hopefully someone there can trigger zinf to
be rebuilt on an ARM machine with more RAM - see [0] for details. ]
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=271645&repeatmerged=no
As pointed out already, this is not a package bug, but the buildd in
Is there any known problems with the buildd on europa?
The build log for gmfsk shows that it couldn't find a whole bunch of
libc functions like malloc, strftime, memcpy etc.. this seems pretty
serious!
http://buildd.debian.org/fetch.php?&pkg=gmfsk&ver=0.6-4&arch=arm&stamp=1
gmfsk has had trouble building on arm lately but the latest version
0.6-3 contains a workaround that should make it build. The arm buildd hasn't
tried it after 6 days though - is this just normal backlog?
thanks
Hamish
--
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Latest build of dossizola failed because of a bug fixed in the version of
libsdl1.2 which is already in testing. The ARM build is the last thing
missing for this version to migrate into sarge - it would be great if
someone could handle the problem.
TIA,
--
Yann Dirson<[EMAIL PROTECTED]> |
+++ Petter Reinholdtsen [04-03-18 11:49 +0100]:
>
> Is this the correct list to reach the arm buildd maintainers? If it
> isn't, could someone please update
> http://www.debian.org/ports/arm/> with the correct list to use?
I believe it is still the right place, but I am n
Is this the correct list to reach the arm buildd maintainers? If it
isn't, could someone please update
http://www.debian.org/ports/arm/> with the correct list to use?
The reason I ask is that I see requests to to the buildd maintainers,
but I almost never see any replies. This make me
imlib2's configure errored on conftest.c, which is created by
ltmain.sh.
Can anyone send that through the buildd again or offer any advice?
Thanks.
On Sun, Feb 01, 2004 at 07:00:28PM -0500, Lukas Geyer wrote:
> Hi,
>
> the ARM buildd failed to build fftw3 due to a timeout, see bug
> #225960. I have successfully built fftw3 on debussy, see
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225960&msg=88
>
>
Hi,
the ARM buildd failed to build fftw3 due to a timeout, see bug
#225960. I have successfully built fftw3 on debussy, see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225960&msg=88
The build log indicates that increasing the timeout to something like
4 hours should be sufficient to b
The last attempt on Nov 1 seemed to have gotten killed:
make: *** wait: No child processesmake[2]: *** [all-recursive]
Terminatedmake[4]: *** wait: No child processesmake[3]: *** wait: No
child processesmake[5]: *** wait: No child processes
thanks,
--
Mike Furr <[EMAIL PROTECTED]>
signature.as
On Sun, 2003-10-19 at 22:48, Petter Reinholdtsen wrote:
> I guess it is a matter of opinion, but I believe g77 is at fault not
> giving a sensible error message. "Internal Compiler Error" instead of
> "Out of memory" is a bug.
>
> But I am not going to do anything to fix it, so if you want to kee
[Philip Blundell]
> Sounds like it's running out of memory. Elara has only 64MB RAM,
> and about 140MB of swap; I think all three of the other autobuilders
> have 128MB ram and more swap space.
>
> I'll add cernlib to no-auto-build on elara and requeue it on one of
> the other machines. I'm clos
On Sun, 2003-10-19 at 05:33, Kevin B. McCarty wrote:
> The last two builds of cernlib on elara.debian.org, an arm buildd, have
> failed with crashes of g77 on the file sszibf.F. (This was with g77-3.3
> versions 1:3.3.2-0pre4 at -O3 and 1:3.3.2-0pre5 at -O2, respectively.)
> Note
The build of ext2resize on arm failed 2003-09-23. See
http://packages.qa.debian.org/e/ext2resize.html> for updated
info.
This is the error message:
/usr/bin/make distclean
make[1]: Entering directory `/build/buildd/ext2resize-1.1.17'
/bin/sh ./config.status --recheck
./confi
On Wed, Aug 20, 2003 at 06:54:35PM -0500, Chris Cheney wrote:
> Both kdebase and kdegames need to be requeued for build, they failed
> about 3 weeks ago due to build-deps being uninstallable at the moment.
They both failed due to what appears to be a not clean chroot on the arm
buildd. Cur
Both kdebase and kdegames need to be requeued for build, they failed
about 3 weeks ago due to build-deps being uninstallable at the moment.
Thanks,
Chris Cheney
Greetings ftp-master,
After trying to track down why one of my packages wasn't getting rebuilt
by the autobuilders, I realized that the openal binary packages have not
moved into the main distribution for arm and sparc, even after they were
successfully autobuilt about a week ago.
I certainly don
On Mon, 2003-04-14 at 08:35, Chris Cheney wrote:
> I noticed that the arm buildd is failing to build kdelibs. It gives an
> error about a multiply defined function. I do not understand why it is
> failing though since it works on all the other buildds. Can someone
> familiar with arm
I noticed that the arm buildd is failing to build kdelibs. It gives an
error about a multiply defined function. I do not understand why it is
failing though since it works on all the other buildds. Can someone
familiar with arm look into it?
Here is the log:
http://buildd.debian.org/fetch.php
1 - 100 of 135 matches
Mail list logo
