Notices

I was basing it simply on this:

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

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

Note that his answer and mine are compatible

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

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...

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

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

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

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

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

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