maemo.org - Talk - Want more apps? Vote for this bug

maemo.org - Talk (https://talk.maemo.org/index.php)

- Applications (https://talk.maemo.org/forumdisplay.php?f=41)

- - Want more apps? Vote for this bug (https://talk.maemo.org/showthread.php?t=36229)

Re: Want more apps? Vote for this bug

Quote:

Originally Posted by javispedro (Post 416874)

Isn't it sbox+sbdmock? It will use qemu-arm-user _only_ for build tools that are not in any devkit/toolchain. That doesn't include C/C++ compilers, but of course may include Erlang compilers.

I was basing it simply on this:

Quote:

homeasvs: X-Fade, are the build machines using qemu-arm ?
X-Fade: yes

http://mg.pov.lt/maemo-irclog/%23mae...12-08.log.html

Also, fwiw, he's building erlang itself, not building something with erlang.

Re: Want more apps? Vote for this bug

Note that his answer and mine are compatible :)

Re: Want more apps? Vote for this bug

Update: that erlang build i mentioned...is still running...

Re: Want more apps? Vote for this bug

While I agree that there are serious issues with the build system (especially since Fremantle came online... and it's basically trashing everything because it's being overwhelmed), I've heard that Nokia is also providing several new servers along with a completely overhauled/fixed build setup so that things will be faster. My understanding of it right now is that EVERYTHING (Maemo.org stuff, autobuilder for Chinook, Diablo, Fremantle, Garage, etc) are running off of a single server. That poor little server!

However in the mean time the argument to say "the autobuilder is preventing more applications" is in my mind not accurate at all. Okay, so let's say worst case scenario your app takes 2 days to build in autobuilder... If that's your product release/app release, then 2 extra days for people to wait doesn't exactly mean "there are less apps available because of it". Sure things get backed up a bit, but you're still talking about final releases here. I think the bigger problem is that many people are using autobuilder as their "testing compiler" instead of compiling locally.

For example, when I build a new version of one of my apps, I'll compile locally, test it on my device to make sure it installs/uninstalls properly.. then I'll upload the compiled .deb to the project Garage page, and post links for others to "test install" with. Once they say it's good to go and there are no major problems/changes to be made, THEN I submit to autobuilder... sure it takes a little bit for autobuilder to process and things to show up in extras, but after you finish writing a commerical application it takes a LOT MORE time to get that application published and out to store shelves...

So should things be faster... yea definitely... is the fact that things are slower than ideal holding back the whole community and development process? No way...

Re: Want more apps? Vote for this bug

Quote:

Originally Posted by jolouis (Post 418969)

However in the mean time the argument to say "the autobuilder is preventing more applications" is in my mind not accurate at all. Okay, so let's say worst case scenario your app takes 2 days to build in autobuilder... If that's your product release/app release, then 2 extra days for people to wait doesn't exactly mean "there are less apps available because of it". Sure things get backed up a bit, but you're still talking about final releases here. I think the bigger problem is that many people are using autobuilder as their "testing compiler" instead of compiling locally.

Well mine compiled locally fine in the /scratchbox (I was building asterisk, fwiw) but didn't build in the autobuilder. There are always subtleties and the autobuilder is not identical to the scratchbox. Take a look here and you can see how many FAILS or other errors there are:

https://garage.maemo.org/pipermail/e...er/thread.html

I bet you *all* of those devs built their packages locally, to be honest.

It also does hold things up for more than just two days because you lose momentum. If it took 15 minutes to find out your build failed, you continue on with the project; if it takes you a couple days, well, you've lost all that mindspace and by then 50 other things have come flying at you to work on. It's not just two days wait, it disturbs a clean workflow. I've decided to not bother packaging on there until things get sorted out because it's agonizing to wait, heh.

That and the fact that you can't see any live build logs (like fedora does, for example), so there's no real way to know what state your package is in either.

Anyway, more boxes is obviously going to help. Hopefully they're huge.

-Jeff

Re: Want more apps? Vote for this bug

Oh, and by the way, erlang is STILL building.

Re: Want more apps? Vote for this bug

Erlang finished! It only took two days, 18 hours:

Code:

[2009-12-07 19:55:04] Processing package erlang 13.b.2.1-dfsg-2. Uploader: thomasvs, builder: builder1

[2009-12-07 19:55:13] Building erlang 13.b.2.1-dfsg-2 for target 'maemo-fremantle-armel-extras-devel'

[2009-12-10 10:44:35] OK

[2009-12-10 10:44:53] Building erlang 13.b.2.1-dfsg-2 for target 'maemo-fremantle-i386-extras-devel'

[2009-12-10 13:22:11] OK

[2009-12-10 13:22:23] Signing build results

[2009-12-10 13:22:24] erlang 1:13.b.2.1-dfsg-2 has been queued for loading into fremantle extras-devel repository

Re: Want more apps? Vote for this bug

Quote:

The biggest difference I find between scratchbox and autobuilder is that in scratchbox you're not necessarily building a package "from nothing", where as on the autobuilder you are. For example, the first few times I built a package it would compile locally, but when uploading to autobuilder it failed because my source package didn't have "depends" setup properly (it wasn't an issue locally because I already had the packages installed locally; autobuilder doesn't do that though).

What I ended up doing (and found to be the most helpful for troubleshooting/test building) was to get a clean SDK virtual image, and use that as my "local autobuilder"; never install anything on it, never use it for actual devel, but only for testing my source packages to see if they would build on a clean platform. Definitely helped me resolve my packaging problems... should we have to do this? Heck no... I think it's more an issue with the SDK not including that type of "clean build" functionality for testing than anything else though...

Anyways, still looking forward to faster build times on Maemo servers, as I agree completely, delays do tend to take a bit of "the wind out from under you".

Thanks!

-Rob

Re: Want more apps? Vote for this bug

Ya, like Fedora has mock so you can simply do a `mock --clean` to get a clean build environment. With scratchbox you pretty much have to blow it out and start over.

I'm investigating sbdmock now.

-Jeff

Re: Want more apps? Vote for this bug

If you want more apps you can give a hand in Extras-testing: http://wiki.maemo.org/Extras-testing