Steven Chamberlain 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 still not exp
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
2012/5/5 Christoph Egger :
> 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 and stuff from 8.1
Hi!
Steven Chamberlain 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 configurable set
2012/5/5 Steven Chamberlain :
> 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. This is set by PAM,
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 ul
2012/5/4 Steven Chamberlain :
> 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 settin
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 settin
On 17/04/12 23:02, Robert Millan wrote:
> El 14 de març de 2012 15:46, Christoph Egger 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 suite or run at al
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 ha escrit:
> kern.dfldsiz: 134217728
That's j
Hi!
Steven Chamberlain 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 right now, or
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 aw
Steven Chamberlain 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 failures here.
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:
https://buildd.debian.org/status/logs.php?pkg=cmor&arch=kfreebsd-a
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 writes:
>> It is trying to map a range 0->0x29fa3000 = ~671MiB bytes
Hi!
Steven Chamberlain 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 asdfasdf.deb
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 4.
* Jakub Wilk , 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 heuristics: --param 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
