Website Re-development Services

2016-12-30 Thread Sanjna 

Hi,

I am a Business Consultant specialising in helping businesses start up and 
grow. We offer highly skilled and experienced developers in fields such as SEO, 
PHP Development, E-Commerce, and Mobile App and Android Development.

We are an 
ISO 9001: 2008 Certified IT Company. We have been partnering with various digital agencies over U.S.A., Canada, Australia U.K. and parts of Europe.


Our Services: -

• Web development- (PHP, Java, .Net Development, Ajax Programming, etc.)

• Web designing- (Logo Design, HTML designing, Corporate Website Design, PSD to 
XHTML/HTML, etc.)

• Open source customization/CMS- (Joomla, Wordpress, etc.)

• Ecommerce website development- (Magento, OS Commerce, Zen Cart integration 
etc.)

• Web Programming Services – (PHP MySQL Development, PHP Frameworks, JavaScript 
Frameworks etc.)

We offer web design and development services at a very affordable cost. If you 
are interested, then please share your requirement and I would be happy to send 
you our pricing and time line.

I’m waiting for reply.

Kinds Regards,

Sanjna

Re: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory

2016-12-30 Thread Mathieu Malaterre 
On Fri, Dec 30, 2016 at 10:06 AM, Emilio Pozuelo Monfort
 wrote:
> On 29/12/16 20:56, Gaudenz Steinlin wrote:
>>
>> Hi Emilio
>>
>> Emilio Pozuelo Monfort  writes:
>>
>>> Source: ceph
>>> Version: 10.2.5-2
>>> Severity: serious
>>>
>>> Your package failed to build on mips/el:
>>>
>>> g++ -DHAVE_CONFIG_H -I.  -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE 
>>> -D__STDC_FORMAT_MACROS -D_GNU_SOURCE 
>>> -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" 
>>> -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" 
>>> -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT-Wdate-time -D_FORTIFY_SOURCE=2 
>>> -I/usr/include/nss -I/usr/include/nspr  -Wall -Wtype-limits 
>>> -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
>>> -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 
>>> -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall 
>>> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
>>> --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong  
>>> -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
>>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>>> tools/rbd/action/Resize.o tools/rbd/action/Resize.cc
>>> virtual memory exhausted: Cannot allocate memory
>>> Makefile:24792: recipe for target
>>> 'test/encoding/ceph_dencoder-ceph_dencoder.o' failed
>>
>> I already noticed this and tried to contact m...@buildd.debian.org and
>> mip...@buildd.debian.org. Unfortunately nobody responded yet, so I don't
>> know if the message was even received or not. AFAIK these are the
>> correct contact points for buildd issues.
>
> This is not a buildd issue but a porting issue. debian-mips@ldo is better for
> this. Added to Cc.
>
>> I don't think there is much I can do about this bug and I'm not
>> convinced this is a issue in ceph. If the buildds are unable to build
>> the package we can either completely remove ceph for mips/mipsel or try
>> to only build the client part and have a reduced set of packages on
>> these architectures.
>
> IIRC there are some flags you can pass to reduce memory usage. Most notably
> ggc-min-expand (which is going to be changed in GCC itself, but afaik it 
> hasn't
> happened yet). So you could try adding
>
> --param ggc-min-expand=10
>
> to CFLAGS/CXXFLAGS.
>
> I'd try that before thinking about removing the package from mips.

Reducing -O2 to -O1 did solve the issue for openvdb on mips* (kudos Jochen)

https://packages.qa.debian.org/o/openvdb/news/20161224T090717Z.html

Re: [Ceph-maintainers] Bug#849657: ceph: FTBFS on mips(el): g++: virtual memory exhausted: Cannot allocate memory

2016-12-30 Thread Emilio Pozuelo Monfort 
On 29/12/16 20:56, Gaudenz Steinlin wrote:
> 
> Hi Emilio
> 
> Emilio Pozuelo Monfort  writes:
> 
>> Source: ceph
>> Version: 10.2.5-2
>> Severity: serious
>>
>> Your package failed to build on mips/el:
>>
>> g++ -DHAVE_CONFIG_H -I.  -D__CEPH__ -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE 
>> -D__STDC_FORMAT_MACROS -D_GNU_SOURCE 
>> -DCEPH_LIBDIR=\"/usr/lib/mipsel-linux-gnu\" 
>> -DCEPH_PKGLIBDIR=\"/usr/lib/mipsel-linux-gnu/ceph\" 
>> -DGTEST_USE_OWN_TR1_TUPLE=0 -D_REENTRANT-Wdate-time -D_FORTIFY_SOURCE=2 
>> -I/usr/include/nss -I/usr/include/nspr  -Wall -Wtype-limits 
>> -Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security 
>> -fno-strict-aliasing -fsigned-char -rdynamic -ftemplate-depth-1024 
>> -Wnon-virtual-dtor -Wno-invalid-offsetof -O2 -g -pipe -Wall 
>> -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
>> --param=ssp-buffer-size=4 -fPIE -fstack-protector-strong  
>> -Wstrict-null-sentinel -g -O2 -fdebug-prefix-map=/«PKGBUILDDIR»=. 
>> -fstack-protector-strong -Wformat -Werror=format-security -c -o 
>> tools/rbd/action/Resize.o tools/rbd/action/Resize.cc
>> virtual memory exhausted: Cannot allocate memory
>> Makefile:24792: recipe for target
>> 'test/encoding/ceph_dencoder-ceph_dencoder.o' failed
> 
> I already noticed this and tried to contact m...@buildd.debian.org and
> mip...@buildd.debian.org. Unfortunately nobody responded yet, so I don't
> know if the message was even received or not. AFAIK these are the
> correct contact points for buildd issues.

This is not a buildd issue but a porting issue. debian-mips@ldo is better for
this. Added to Cc.

> I don't think there is much I can do about this bug and I'm not
> convinced this is a issue in ceph. If the buildds are unable to build
> the package we can either completely remove ceph for mips/mipsel or try
> to only build the client part and have a reduced set of packages on
> these architectures.

IIRC there are some flags you can pass to reduce memory usage. Most notably
ggc-min-expand (which is going to be changed in GCC itself, but afaik it hasn't
happened yet). So you could try adding

--param ggc-min-expand=10

to CFLAGS/CXXFLAGS.

I'd try that before thinking about removing the package from mips.

Cheers,
Emilio

> The second option would have the advantage that no changes to the
> reverse dependencies (notably qemu) are needed.
> 
> Gaudenz
>