Linux beta testers wanted

[rickg22]

Hey guys, we often receive patches to add a feature or solve a bug in Code::Blocks. But we can't apply those patches until we've tested them in both Windows and Linux. Yiannis got Linux, but he's the main developer, and I only got Windows.

We'd appreciate any volunteers who would help test patches on the Linux platform(s). This would speed up the patch applications.

Thanks in advance.

[David Perfors]

As soon as I get my computer organized, I will try to test patches.. I will install slackware, so I could also make a package for it...

[rickg22]

Thanks!

[fiammy]

I'm trying to get it working right under SuSE Linux 9.2 Pro. I'll try to build the CVS as soon as possible, and flood you with bug reports :-)

[rickg22]

Yes, I noticed the flooding already :lol:

[AkiraDev]

Hi!
I'll try it under Fedora Core 3, time permitting.

*Desperately waves his arms, hoping someone will make an RPM package for RH9/FC3*

[DreadNot]

I've got SuSE 9.1.  I'll test under it when I'm up to speed under MSW.

[David Perfors]

I changed my mind, next week I am going to install *BSD beside windows (Hopefully I get the Xwindows to work now)

[Anonymous]

Hi, also posted a bug report,
I dont get Code::Blocks running
I am also using Gentoo 2.6.9 kernel
@Algorithms: Did you get Code::Blocks running?

[RShadow]

Hey guys, we often receive patches to add a feature or solve a bug in Code::Blocks. But we can't apply those patches until we've tested them in both Windows and Linux. Yiannis got Linux, but he's the main developer, and I only got Windows.

We'd appreciate any volunteers who would help test patches on the Linux platform(s). This would speed up the patch applications.

Thanks in advance.

I will help test patches.  On a side note .. if you only have windows your missing out!  If  you don't want (or don't have room) to install Linux on your computer use a LiveCD.  Go get Gentoo and build a custom LiveCD.. plop the cd in.. boot up into Linux and test the patches.

[David Perfors]

Right now I am trying to get codeblocks compiled on VectorLinux. This Linux is based on Slackware. (I couldn't install BSD because of hardware incompatibility...)

[morteoh]

I'll try to build it on my debian sid box when i get home, let's see what happens ;-)

Where should i report bugs?

- Morten

[Funto]

The actual version doesn't compile under Linux as I explain it here

You still can try but if I were you I wouldn't expect too much...

[darklordsatan]

Where should i report bugs?

Here
Its in the main page, at the left, under "Development".

[elvstone]

I'm on a FreeBSD 5.4 machine, and I'll do my best to try to make C::B run fine on FreeBSD before the 1.0 release.

Best regards,
Aron Stansvik

[rickg22]

That's cool! Because I'm done on 50% of the compiler plugin.

Then it's only codecompletion (somebody help please), and we got unicode!

[takeshimiya]

I'll try to see if I can test later C::B in debian in my sister's PC, because my motherboard's chipset doesn't work in any distro.
So my only solutions are VMWare (too slow for me) or coLinux (I tried several times but failed to got it working ok).

Recommendation: Don't buy a motherboard with an ATI chipset if you want to run linux =|
New hardware/less known hardware doesn't go well with linux kernel.

[PerryWerneck]

   Hi,

   I Just started using it on Mandriva Linux 2006. I'm using for a few hours now and the only problem (until now) was a hang when importing a big project.

[thomas]

I Just started using it on Mandriva Linux 2006

Woah... I installed Mandriva last weekend to be able to build binaries for that distro, but gave up on the idea after it told me "We are the Borg, we will assimilate your partition table". :lol:

[rickg22]

Perhaps now that Codeblocks is much more mature, we should apply for the compiler farm at sourceforge, i mean, they sure got a million distros in there... i think... :|

Edit: nevermind. I just looked at their hosts list.

    * x86-linux2: Fedora Linux FC2 running Linux 2.6 kernel
    * x86-openbsd1: OpenBSD 3.4
    * x86-solaris1: Sun Solaris 9
    * x86-linux1: Debian GNU/Linux 3.0 running Linux 2.4 kernel
    * x86-freebsd1: FreeBSD 4.8
    * x86-netbsd1: NetBSD 1.6.1

[takeshimiya]

I opted-in the other day for the compile farm, but I dunno how to SSH correctly (I'm newbie here, when I try to login it says wrong password).
I'm also not sure if you need to figure as a project developer.

[mandrav]

I'm also not sure if you need to figure as a project developer.

That's true, only project developers can opt-in for compile farm usage (at least that's what I read ).

[thomas]

I am against using the compile farm because of the implied security risks.
Of course nothing can prevent any of the Code::Blocks developers to deliberately build some kind of malware into the executable, but hey! I guess we should have that much trust!
On the other hand, you have absolutely no clue what goes on when you use a computer at the SF compile farm. You did not install the machine, you don't own it, and you don't know who has been using it before.
It might be just fine, but you might as well unintentionally bundle a trojan with your executable -- and unless it is a well-known variant, it may as well go unnoticed.

This possiblity is quite an argument against using the compile farm.

SF recommends against it, too:

While we encourage the use of the Compile Farm for porting your software to new platforms, and for testing your software, we discourage the use of the Compile Farm for creating packages for distribution to other users.

[sethjackson]

I am against using the compile farm because of the implied security risks.
Of course nothing can prevent any of the Code::Blocks developers to deliberately build some kind of malware into the executable, but hey! I guess we should have that much trust!
On the other hand, you have absolutely no clue what goes on when you use a computer at the SF compile farm. You did not install the machine, you don't own it, and you don't know who has been using it before.
It might be just fine, but you might as well unintentionally bundle a trojan with your executable -- and unless it is a well-known variant, it may as well go unnoticed.

This possiblity is quite an argument against using the compile farm.

SF recommends against it, too:

While we encourage the use of the Compile Farm for porting your software to new platforms, and for testing your software, we discourage the use of the Compile Farm for creating packages for distribution to other users.

Maybe use it for testing... Then compile the released version on a dev's PC??

[takeshimiya]

thomas: Compile Farm is for testing, for the packages we'll have C::B in official repositories I hope.

BTW, I highly doubt security risks, they are *nix machines and they'd give you a limited account, and users of the Compiler Farm can't install software system-wide.

Trojans in linux? And Sourceforge? Even Compile Farm, which is disabled by default in all accounts? I agree to not make packages from these boxes, but you got a little paranoid, ne?

[takeshimiya]

That's true, only project developers can opt-in for compile farm usage (at least that's what I read ).

I'm not a project developer (in sf cb) and I opted-in, but I'm not sure if I'll have access to the C::B files from there.

[thomas]

Trojans in linux? And Sourceforge? Even Compile Farm, which is disabled by default in all accounts? I agree to not make packages from these boxes, but you got a little paranoid, ne?

I think practical. If I am to spread malware, then whom will I attack? Will I try to break into your PC and try to get my malware sent to the 10 people in your address book?
Or will I attack a computer which is used by 1000 developers who might be foolish enough to build packages which are then downloaded by 500.000 users? Think about it...

So clearly, the SF compile farm servers are a much more intersting target, and the threat is a lot higher. Also, do not be fooled by the fact that they run Unix. There are security holes in Unix too. Fewer than in Windows, sure, but Unix is not unbreakable, either. In particular if you are allowed to execute arbitrary software on the machine.

[takeshimiya]

I challenge you to show me one case of malware in Compile Farm.
If we're going to be paranoid, there's more chance to get Yiannis' Windows infected when creating the win32 package, thanks to the autodownloaded windows worms when you don't have applied the latest security fixes.

Anyways, please stay on topic, no one here talked about creating packages from Compile Farm, we are talking about testing.

[rickg22]

Anyways, please stay on topic, no one here talked about creating packages from Compile Farm

*Walks away from the dogfight, whistling innocently...*

[guppy]

*tag*

Ill help out;

Linux/Gentoo [Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.10-gentoo-r6 i686)]

Build env:

sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.20
x11-libs/wxGTK: 2.6.1

RC2 compiles flawlessly "out of the box"
cvs needs manual addition of src/sdk to include path.

[undofen]

Im trying to use C::B on gentoo for a long time now, so I could help if anyone could tell me the procedure ? I apply the patches and reply if they work ? anything more apart from that and bugreports ?

[me22]

For those of you using Gentoo, you can get my codeblocks-svn ebuild from http://bugs.gentoo.org/show_bug.cgi?id=89533

Set it up in a portage overlay and you can just use "emerge codeblocks-svn" to attempt a compile of the latest svn version.  Also means you get your normal CXXFLAGS applied and can use emerge -C to get rid of it.

[280Z28]

I didn't read the whole thread because I'm so interested in developing on Linux, but are you keeping the Linux makefile up to date? As long as it shouldn't take much time I can test it on Solaris at work, and here on my OSX.

Oh the OSX is my roommate's, I'd be appalled if someone thought I would actually endorse such a product.  :lol:

[Der Meister]

Yes, the makefile is kept up to date. And if not (maybe because it simply was forgotten) then you will notice it as soon as you try to compile a new version. But then you can either complain about that or (probably the better way) provide a patch for it.

[cyberkoa]

I do not able to compile the SVN version on my Ubuntu , it stop at the wxScintilla target and says undefine reference of wxScintilla::FindText(.....)  ..

I try at 2 machines , it gives the same error
anything hints ?

[connyosis]

I've compiled code::blocks succesfully on Gentoo with the ebuild from bugs.gentoo.org.
Just created the portage overlay and emerged codeblocks-svn

[me22]

I've compiled code::blocks succesfully on Gentoo with the ebuild from bugs.gentoo.org.
Just created the portage overlay and emerged codeblocks-svn

Good to see my ebuild is in good use =)

That being said, you should always include the SVN revision number when you talk about anything using that ebuild.

You can use # svn info /usr/portage/distfiles/svn-src/codeblocks/trunk/ to get the revision number ( along with some other interesting information ).

[edit] Speaking of the ebuild, I've version bumped it to 1.0-r1 since I found a bug in the ebuild.

[jlac]

Hello,

I can participate to testing under linux...
and distribute a nighty build if you need ?

So i try to compile but i have the same problem :

I do not able to compile the SVN version on my Ubuntu , it stop at the wxScintilla target and says undefine reference of wxScintilla::FindText(.....)  ..

my configuration:
unbuntu 5.10
gcc 4.0.1
autoconf 2.59a-3
automake 1.9
libtool 2.5.6

[jlac]

The solution to resolve error about wxScintilla::FindText(.....) can be found here : http://forums.codeblocks.org/index.php?topic=1688.0