Hi Christoph,
On 05/05/12 15:33, Christoph Egger wrote:
The buildds will only get the new kernel some time after the wheezy
release [...]
Now that this happened, could you please give back cmor for a rebuild on
kfreebsd-amd64? AFAIK it is still not expected to build on kfreebsd-i386.
Thanks,
Steven Chamberlain ste...@pyro.eu.org writes:
Hi Christoph,
On 05/05/12 15:33, Christoph Egger wrote:
The buildds will only get the new kernel some time after the wheezy
release [...]
Now that this happened, could you please give back cmor for a rebuild on
kfreebsd-amd64? AFAIK it is
Hi!
Steven Chamberlain ste...@pyro.eu.org writes:
This issue was worked around with a binNMU. It is fixed in kfreebsd-8
VCS and kfreebsd-9 unstable by raising DFLDSIZ.
I don't know if this has been changed yet on the buildd's, which I think
run a squeeze kernel but DFLDSIZ is a boot-time
2012/5/5 Christoph Egger christ...@debian.org:
The buildds will only get the new kernel some time after the wheezy
release (It *might* be possible to get a backports kernel but only iff
we are really sure the kfreebsd-8 kernel from testing rebuilt in stable
will work well with freebsd-utils
severity 661283 important
thanks
Hi,
This issue was worked around with a binNMU. It is fixed in kfreebsd-8
VCS and kfreebsd-9 unstable by raising DFLDSIZ.
I don't know if this has been changed yet on the buildd's, which I think
run a squeeze kernel but DFLDSIZ is a boot-time configurable
2012/5/4 Steven Chamberlain ste...@pyro.eu.org:
This issue was worked around with a binNMU. It is fixed in kfreebsd-8
VCS and kfreebsd-9 unstable by raising DFLDSIZ.
I don't know if this has been changed yet on the buildd's, which I think
run a squeeze kernel but DFLDSIZ is a boot-time
On 04/05/12 23:10, Robert Millan wrote:
Actually, I think that increasing DFLDSIZ might not be the only
solution. DFLDSIZ only sets the default limit, but for login shells
it is increased automatically.
Upstream does it that way, but I'm not sure if GNU/kFreeBSD does (I see
no mention of
2012/5/5 Steven Chamberlain ste...@pyro.eu.org:
Upstream does it that way, but I'm not sure if GNU/kFreeBSD does (I see
no mention of ulimit in /etc?). But if so, it would explain why this
was reproducible on buildd's and not on the asdfasdf porter box.
ulimit is just the user interface.
clone 661283 -1
retitle -1 increase DFLDSIZ on amd64 to something good enough to build cmor
severity -1 wishlist
clone -1 -2 -3
reassign -1 kfreebsd-8
reassign -2 kfreebsd-9
reassign -3 kfreebsd-10
thanks
El 14 de març de 2012 15:46, Christoph Egger christ...@debian.org ha escrit:
kern.dfldsiz:
On 17/04/12 23:02, Robert Millan wrote:
El 14 de març de 2012 15:46, Christoph Egger christ...@debian.org ha
escrit:
kern.dfldsiz: 134217728
That's just 128 MiB.
Argh I misunderstood this before. Yes 128 MiB is definitely too low for
cmor; it seems to need ~700 MiB to pass the test
Hi Christoph,
Is it worth giving cmor back to the kfreebsd-amd64 buildd's (more than
once, if necessary), as it does succeed about 50% of the time.
The netcdf 4.1.4 transition is held up by this. If it works, we won't
have to worry so much about fixing it right now, or the problem may even
go
Hi!
Steven Chamberlain ste...@pyro.eu.org writes:
Is it worth giving cmor back to the kfreebsd-amd64 buildd's (more than
once, if necessary), as it does succeed about 50% of the time.
The netcdf 4.1.4 transition is held up by this. If it works, we won't
have to worry so much about fixing it
Steven Chamberlain ste...@pyro.eu.org writes:
I'm curious anyway what are the kern.maxdsiz and kern.dfldsiz on the
buildds (I'm guessing 1GiB on amd64) and is it permissible for them to
be raised (to maybe 2GiB) if some package like this one required it?
(I'm also wondering about the openjdk-7
reopen 661283
done
On 03/03/12 14:11, Julien Cristau wrote:
I gave it back and it built, so closing.
Hi,
Doesn't this want fixing more permanently? It got queued for a rebuild
for some reason and has been failing again since:
Hi!
Steven Chamberlain ste...@pyro.eu.org writes:
It is trying to map a range 0-0x29fa3000 = ~671MiB bytes which is why
it fails in my VM which has only 512MiB RAM. The value being requested
as length here appears to be a pointer.
Jakub Wilk wrote:
FWIW, I can't reproduce this failure on
Hi,
Yes, this build has failed consistently on asdfasdf , and built fine on
other systems
(fano, I think). I agree its memory-related.
regards
Alastair
On 2012-03-03 11:09, Christoph Egger wrote:
Hi!
Steven Chamberlain ste...@pyro.eu.org writes:
It is trying to map a range 0-0x29fa3000 =
Hi,
Building cmor 2.8.0-2 fails for me in exactly the same place but with
different error codes. This is kfreebsd-i386 with up-to-date Wheezy,
running in VirtualBox limited to 512MiB RAM and no swap:
GNU C (Debian 4.6.2-12) version 4.6.2 (i486-kfreebsd-gnu)
compiled by GNU C version
* Jakub Wilk jw...@debian.org, 2012-02-25, 23:28:
| GNU C (Debian 4.6.2-12) version 4.6.2 (x86_64-kfreebsd-gnu)
| compiled by GNU C version 4.6.2, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
| warning: GMP header version 5.0.2 differs from library version 5.0.3.
| GGC
Source: cmor
Version: 2.8.0-2
Severity: serious
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: kfreebsd-amd64
cmor failed to build from source on kfreebsd-amd64:
| GNU C (Debian 4.6.2-12) version 4.6.2 (x86_64-kfreebsd-gnu)
| compiled by GNU C version
19 matches
Mail list logo
