Re: [sage-devel] Error building sage-5.9.beta5 on Lubuntu 13.04 raring-ringtail (beta)

On Fri, 19 Apr 2013 01:29:14 Kjetil brinchmann Halvorsen wrote: > I think this is the same problem I earlier reported on sage-5.8 (on > Lubuntu 12.10) > > Here is the output from make: > > > --- > Default path = /home/kjetil/sage/sage-5.9.beta5/local

[sage-devel] Error building sage-5.9.beta5 on Lubuntu 13.04 raring-ringtail (beta)

I think this is the same problem I earlier reported on sage-5.8 (on Lubuntu 12.10) Here is the output from make: --- Default path = /home/kjetil/sage/sage-5.9.beta5/local /usr /usr/local --- checking for GMP

Re: [sage-devel] Re: [GSoC 2013] Questions regarding "Sage Android app"

Sir, Thanks for your help. I will go through these links shared on that post and try to work on building a proposal. If I get any other question during this process, I will definitely get back to this list. Regards On Thu, Apr 18, 2013 at 2:08 AM, Volker Braun wrote: > See this post in the sa

Re: [sage-devel] Re: Size limits for optional/experimental spkgs?

On Thu, Apr 18, 2013 at 6:42 AM, leif wrote: > Volker Braun wrote: >> >> The database is already in a manually optimized binary format. The >> default bzip2 compresses it from 11GB to 9GB... > > > ... which suggests you could further improve your encoding / "custom" > compression format. ;-) > > >

[sage-devel] Re: Size limits for optional/experimental spkgs?

P Purkayastha wrote: On 04/18/2013 11:23 PM, Volker Braun wrote: The average user will probably abort the download of obscure databases way before hitting any limits ;-) And I don't think many non-LFS systems are out there (outside of skynet ;-) LFS? Linux From Scratch? Nope, limit-free Sage

[sage-devel] Re: Size limits for optional/experimental spkgs?

Close, but no cigar ;-) http://en.wikipedia.org/wiki/Large_file_support On Thursday, April 18, 2013 5:47:23 PM UTC+1, P Purkayastha wrote: > > LFS? Linux From Scratch? > > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this

[sage-devel] Re: Size limits for optional/experimental spkgs?

Volker Braun wrote: The average user will probably abort the download of obscure databases Sounds like you're calling for a new Sage package category... -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You received this message because you are subscribed to the Google Gro

[sage-devel] Re: Size limits for optional/experimental spkgs?

On 04/18/2013 11:23 PM, Volker Braun wrote: The average user will probably abort the download of obscure databases way before hitting any limits ;-) And I don't think many non-LFS systems are out there (outside of skynet ;-) LFS? Linux From Scratch? -- You received this message because you ar

[sage-devel] Re: Size limits for optional/experimental spkgs?

The average user will probably abort the download of obscure databases way before hitting any limits ;-) And I don't think many non-LFS systems are out there (outside of skynet ;-) On Thursday, April 18, 2013 4:17:22 PM UTC+1, leif wrote: > > Sure. But the average user^TM will presumably not

[sage-devel] Re: Size limits for optional/experimental spkgs?

Volker Braun wrote: In any case, if your computer can't handle large files then just don't install huge databases. Sure. But the average user^TM will presumably notice /after/ having downloaded the first 4 GB... B) -leif -- () The ASCII Ribbon Campaign /\ Help Cure HTML E-Mail -- You r

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

pang wrote: On Thursday, April 18, 2013 4:23:08 PM UTC+2, pang wrote: Not a c expert, I get a: sageadmin@ks3316508 ~> g++ semaphores..c /tmp/cc4ALTKd.o: In function `main': semaphores.c:(.text+0x22): undefined reference to `sem_open' semaphores.c:(.text+0x59)

[sage-devel] Re: Size limits for optional/experimental spkgs?

On Thursday, April 18, 2013 3:47:09 PM UTC+1, leif wrote: > Other than what? (I had the limitations of some filesystems [or even > OSs / libraries] in mind.) > I know (or hope so ;-) but the relevant limit is 2GB there. Anything beyond needs LFS, which might be an issue for legacy systems. Th

[sage-devel] Re: Size limits for optional/experimental spkgs?

Volker Braun wrote: On Thursday, April 18, 2013 2:42:21 PM UTC+1, leif wrote: In case we at all want to put a limit on the file size of (even "huge") spkgs, I'd say 4 GB (for each uncompressed and untarred file as well) would be reasonable. Any other reason for picking a cutoff tha

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

On Thursday, April 18, 2013 4:23:08 PM UTC+2, pang wrote: > > Not a c expert, I get a: > > sageadmin@ks3316508 ~> g++ semaphores.c >> /tmp/cc4ALTKd.o: In function `main': >> semaphores.c:(.text+0x22): undefined reference to `sem_open' >> semaphores.c:(.text+0x59): undefined reference to `sem_close

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

Not a c expert, I get a: sageadmin@ks3316508 ~> g++ semaphores.c > /tmp/cc4ALTKd.o: In function `main': > semaphores.c:(.text+0x22): undefined reference to `sem_open' > semaphores.c:(.text+0x59): undefined reference to `sem_close' > semaphores.c:(.text+0x63): undefined reference to `sem_unlink' >

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

On Apr 18, 2:35 am, pang wrote: > > sudo rm -rf /dev/shm && sudo ln -s /run/shm /dev/shm > > It really looked promising, but unfortunately, it didn't work: is a reboot > necessary? I also used the following little program to check if semaphores got on: #include #include #include #include #in

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

On Thursday, April 18, 2013 3:09:43 PM UTC+2, leif wrote: > > pang wrote: > > sudo rm -rf /dev/shm && sudo ln -s /run/shm /dev/shm > > > > > > It really looked promising, but unfortunately, it didn't work: is a > > reboot necessary? > > I don't think so. > > What does > > $ ls -ld /run/

[sage-devel] Re: Size limits for optional/experimental spkgs?

On Thursday, April 18, 2013 2:42:21 PM UTC+1, leif wrote: > In case we at all want to put a limit on the file size of (even "huge") > spkgs, I'd say 4 GB (for each uncompressed and untarred file as well) > would be reasonable. Any other reason for picking a cutoff that is O(1) below the size o

[sage-devel] Re: Size limits for optional/experimental spkgs?

Volker Braun wrote: The database is already in a manually optimized binary format. The default bzip2 compresses it from 11GB to 9GB... ... which suggests you could further improve your encoding / "custom" compression format. ;-) In case we at all want to put a limit on the file size of (eve

[sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

pang wrote: sudo rm -rf /dev/shm && sudo ln -s /run/shm /dev/shm It really looked promising, but unfortunately, it didn't work: is a reboot necessary? I don't think so. What does $ ls -ld /run/shm give? (I.e., are the permissions correct?) -leif -- () The ASCII Ribbon Campaign /\

Re: [sage-devel] Re: change trac httpd.conf settings

Didn't get added to the http headers: vbraun@boxen:~$ wget -S -O /dev/null http://trac.sagemath.org/sage_trac/raw-attachment/ticket/14319/trac_14319-empty.patch --04:51:40-- http://trac.sagemath.org/sage_trac/raw-

[sage-devel] Re: Size limits for optional/experimental spkgs?

The database is already in a manually optimized binary format. The default bzip2 compresses it from 11GB to 9GB... On Thursday, April 18, 2013 12:43:11 PM UTC+1, P Purkayastha wrote: > > On 04/18/2013 07:19 PM, Volker Braun wrote: > > On Thursday, April 18, 2013 11:42:57 AM UTC+1, P Purkayasth

Re: [sage-devel] Re: change trac httpd.conf settings

On Thu, Apr 18, 2013 at 1:18 PM, Volker Braun wrote: > How exactly am I supposed to test it without actually making the change. well, i just made the change and restarted apache. i'm just not sure where to click and for what headers i have to look for. so, it's either working or it didn't had an

[sage-devel] Re: Size limits for optional/experimental spkgs?

On 04/18/2013 07:19 PM, Volker Braun wrote: On Thursday, April 18, 2013 11:42:57 AM UTC+1, P Purkayastha wrote: How did you compress it? You can try using lrzip to achieve some more compression. See https://github.com/ckolivas/lrzip I doubt that

[sage-devel] Re: Size limits for optional/experimental spkgs?

On Thursday, April 18, 2013 11:42:57 AM UTC+1, P Purkayastha wrote: > How did you compress it? You can try using lrzip to achieve some more > compression. See https://github.com/ckolivas/lrzip > I doubt that this'll turn it into a "small" spkg though ;-) -- You received this message because

[sage-devel] Re: change trac httpd.conf settings

How exactly am I supposed to test it without actually making the change. Since it only changes headers relevant to 3rd party proxies I think it is pretty uncontroversial. In the worst case the downstream proxy stays broken. -- You received this message because you are subscribed to the Google G

[sage-devel] Re: Size limits for optional/experimental spkgs?

On 04/18/2013 05:25 PM, Volker Braun wrote: I made a package containing all reflexive 4-d polytopes. Is a 9 gigabyte file suitable as optional/experimental spkg? $ du -sh polytopes_db_4d-1.0.spkg 8.7Gpolytopes_db_4d-1.0.spkg How did you compress it? You can try using lrzip to achieve some more

[sage-devel] Re: change trac httpd.conf settings

On Thursday, April 18, 2013 12:30:24 PM UTC+2, Volker Braun wrote: > > Since I continue to trip over this issue it would be great if somebody who > controls the apache config files would implement the workaround proposed in > http://trac.sagemath.org/11813. could you test it please? H --

[sage-devel] change trac httpd.conf settings

Since I continue to trip over this issue it would be great if somebody who controls the apache config files would implement the workaround proposed in http://trac.sagemath.org/11813. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Size limits for optional/experimental spkgs?

On 18 April 2013 10:56, Volker Braun wrote: > Oh, excellent. I didn't know that we have a "huge" category. Probably > because there is only one entry ;-) > > > > On Thursday, April 18, 2013 10:30:45 AM UTC+1, François wrote: >> >> On 18/04/13 21:25, Volker Braun wrote: >> > I made a package contai

Re: [sage-devel] Size limits for optional/experimental spkgs?

Oh, excellent. I didn't know that we have a "huge" category. Probably because there is only one entry ;-) On Thursday, April 18, 2013 10:30:45 AM UTC+1, François wrote: > > On 18/04/13 21:25, Volker Braun wrote: > > I made a package containing all reflexive 4-d polytopes. Is a 9 gigabyte > >

Re: [sage-devel] Size limits for optional/experimental spkgs?

On 18/04/13 21:25, Volker Braun wrote: > I made a package containing all reflexive 4-d polytopes. Is a 9 gigabyte > file suitable as optional/experimental spkg? > > $ du -sh polytopes_db_4d-1.0.spkg > 8.7Gpolytopes_db_4d-1.0.spkg > I think that would belong to "huge" http://www.sagemath.org/dow

[sage-devel] Size limits for optional/experimental spkgs?

I made a package containing all reflexive 4-d polytopes. Is a 9 gigabyte file suitable as optional/experimental spkg? $ du -sh polytopes_db_4d-1.0.spkg 8.7G polytopes_db_4d-1.0.spkg -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe

Re: [sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

On Thu, Apr 18, 2013 at 10:35 AM, pang wrote: > sudo rm -rf /dev/shm && sudo **ln -s /run/shm /dev/shm >> > > It really looked promising, but unfortunately, it didn't work: is a reboot > necessary? > Eh, it depends: What went wrong? Cheers, Michael > -- > You received this message because y

Re: [sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

> > sudo rm -rf /dev/shm && sudo ln -s /run/shm /dev/shm > It really looked promising, but unfortunately, it didn't work: is a reboot necessary? -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving

[sage-devel] hawk going in down in 10 mins due to power failure

-- Dr. David Kirkby Ph.D C.Eng MIET -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to

Re: [sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

> >> - I had the same error playing with LXC containers and it was resolved by >> linking/mounting tmpfs in the appropriate place. Unfortunately I don't >> remember precise steps, but it was possible to find them back then ;-) >> >> > Yeah, a LXC based system will potentially give you some t

Re: [sage-devel] Re: This platform lacks a functioning sem_open implementation This platform lacks a functioning sem_ope

On Thu, Apr 18, 2013 at 7:55 AM, Andrey Novoseltsev wrote: > (hate new google groups...) > > I think you may be able to make a link from /dev/shm to /run/shm That seems to be mostly an issue if you use Debian or Debian based distro since they are following the HFS standard - see http://wiki