Thumb repo on RMO
 

Is it possible to get a thumb repository on maemo.org? Using the autobuilder, promotion, etc..

Re: Thumb repo on RMO
 

Perhaps this is a better thread to discuss this then. There is no application repository for thumb-compiled applications on maemo.org that I am aware of... right? You cannot submit source code to an autobuilder and have it built with gcc 4.72 and thumb compiled that I am aware of . Correct me if I'm wrong.

This is what I would like to see, especially now that CSSU-thumb is getting fairly mature and many people are running their devices with thumb compiled CSSU, and many developers are creating thumb versions of their applications. The problem is that these applications are spread all over the place... in the forums, in private repos, in merlin's repo, on webpages, etc... it would be very nice to have a central, official repo for thumb applications, with autobuilder and promotion, etc..., in my opinion anyway.

Re: Thumb repo on RMO
 

You get my vote! I wouldn't mind a thumb repo with user applications, I can only applaud this idea :)

Re: Thumb repo on RMO
 

Sorry if I unintentionally step on someone's toe, but... is there any technical reason for not having everything built with gcc 4.7 and Thumb by default?

Re: Thumb repo on RMO
 

If you call it technical , it would be "because it forces everyone to use cssu-thumb". Which is based on cssu-testing, as opposed to cssu-stable.

That doesn't take into account - of course - that cssu-testing is de facto stable and everyone and their uncle uses it (if using CSSU at all), and cssu-stable is de facto "oldstable bits thrown randomly together", that no one is using (unless is wrongly informed, like, follow CSSU wiki :P).

Same apply for forcing to use custom kernel (kernel-power or cssu one, while the latter perform same function as cssu-stable - only misguided [ ;) ] are using it, for everyone sane it is either KP or no custom kernel at all).

/Estel

// Edit
Whatever the method is, we *need* thumb repo. Chasing binaries from various threads is getting old.

Re: Thumb repo on RMO
 

If it wasn't clear from my prev post quoted above:
I don't see any elementary logical showstoppers to augment autobuilder&repo infra to not only build x86 and armel targets but also a armel-thumb target same time. Most packages are built for armel and x86 targets same time already.
I don't think we would need a new separate 2nd autobuilder and stuff for that, but somebody with better understanding of packaging and repositories has to check this suggestion and find the nasty little problems I failed to see.
If we however find somebody who's willing and has enough time to do this is another question.

Re: Thumb repo on RMO
 

Thanks Estel but I am not convinced that having a random app in extras compiled with a specific version of gcc*) and using a specific instruction set equals forcing me to use a specific version of CSSU, or even any CSSU at all. My own case is a counter-argument: I am using CSSU-Thumb with packages from extras, extras-testing and extras-devel.

*) OK, so maybe a newer version of gcc may require a newer version of libgcc1 and/or libc6 but that's about it as far as I can see. Please correct me if I'm wrong.

EDIT: Jörg, thanks for your input. To be clear, I did not mean adding another build target but upgrading the armel target to gcc4.7+thumb. That should be less work, I assume.

Re: Thumb repo on RMO
 

I see what you mean now... the same autobuilder can be used with just another target added, and the repository would contain a thumb compiled version along with x86 and armel versions.

I wonder though, how does apt-get know to install the thumb version over the normal armel version? We wouldn't want to break the repositories for those people who don't want to run thumb binaries (I suspect), or can't because they aren't running kernel-power. This is why I was thinking a separate repository for thumb-extras, testing and dev would be a possible solution. A user could enable these along with the regular extras repositories and get the thumb versions of applications if they exist (assuming the thumb versions have a higher version, or +thumb0 appended). I don't know enough about how apt-get or repositories work to know if that makes sense or not.

After that, I guess we'd have to look at making changes to the extras-assistant (and midgard?) to support thumb binaries as well. Perhaps that all falls into place by just adding a target to the existing autobuilder processes though.

Hopefully Freemangordon can speak to some of that, since I know he's had recent experience with the autobuilder and extras-assistant, or anyone else who understands repositories/apt.

Re: Thumb repo on RMO
 

I guess you're quite to the point with all you said. Probably the worst logical problem is that an armel-thumb architecture is supposed to also accept armel binaries, but an armel architecture mustn't run armel-thumb binaries. I don't know if that problem can get fixed with a patch to apt or HAM, or by pathnames/URLs in repositories plus symlinks or hardlinks, or whatever. From extras-assistant and midgard I expect the least problems, it should more or less boil down to a duplication of existing cmdlines or dirs or both (given the new 4.7(?) gcc is compatible to the one used now, on the level that it is enangled with the whole autobuilder process).

Re: Thumb repo on RMO
 

So, I have an idea how we could cope with that all (and fix one more problem). My idea:

We can use files in debian/autobuilder

Files there:

sbox - legal values: {hathor, apophis}. Which sbox should be used, as thumb might sometime need apophis (embedlite-components) and sometimes hathor (Qt apps)

devkits - e.g. svn:git:debian-squeeze - it would fix the problem when shlibs:Depends fail to be created with the squeeze devkit. Plus you might disable devkits which complicate stuff. Passed to sb-conf when creating the autobuilder target.

thumb - legal values {thumb, non-thumb, both} - if an app needs newer gcc, or fails with thumb

... Feel free to add more options ...

For now we could enable only for free packages, as it would require absolutely no filtering - everything is built right there right now. And about non-free. A dirty workaround would be to check the libgcc1 version (or libstdc++6)

And what's more: it would finally allow to push CSSU dependant packages to extras-* !

/edit: The thumb option makes sense if the autobuilder automatically added the +thumb suffix. Otherwise, one'd need to enter it manually.