Thumb repo on RMO

[shawnjefferson]

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

[shawnjefferson]

honestly I'd love to discuss this stuff with you, point you at the already existing infra like

http://maemo.org/packages/view/bash/
Repository Latest version
Diablo Extras-devel free armel bash 3.2-0maemo4
Diablo Extras-devel free i386 bash 3.2-0maemo4
Diablo SDK free armel bash 2.05b-26osso4
Diablo SDK free i386 bash 2.05b-26osso4
Fremantle nokia-applications explicit armel bash 2.05b-26osso7+0m5
Fremantle SDK free armel bash 2.05b-26osso8+0m5
Fremantle SDK free i386 bash 2.05b-26osso8+0m5
Maemo 5 device SSU repository (>= PR1.2) bash 2.05b-26osso8+0m5
bash 2.05b-26osso8+0m5 Fremantle SDK free i386 Package imported System 2010-03-24 15:28 UTC
bash 2.05b-26osso8+0m5 Fremantle SDK free armel Package imported System 2010-03-24 15:28 UTC

and all.
If only this were not a thread about funding which is totally off topic and will not create a proper discussion of the whole theme anyway. The approach to first ask if we need funds to do whatever needs or doesn't need to get done is ... strange, and distractive to the actual topic, at best.

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.

[mr_pingu]

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

[pichlo]

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.

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?

[Estel]

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.

[joerg_rw]

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.

[pichlo]

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.

[shawnjefferson]

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.

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.

[joerg_rw]

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

http://maemo.org/packages/repository/list/fremantle_sdk_free_armel/
http://maemo.org/packages/repository/list/fremantle_sdk_free_i386/
http://maemo.org/packages/package_instance/view/fremantle_sdk_free_armel/bash/2.05b-26osso8+0m5/
http://maemo.org/packages/package_instance/view/fremantle_sdk_free_i386/bash/2.05b-26osso8+0m5/

http://repository.maemo.org/pool/maemo5.0/free/b/bash/bash_2.05b-26osso8+0m5_armel.deb
http://repository.maemo.org/pool/maemo5.0/free/b/bash/bash_2.05b-26osso8+0m5_i386.deb

[marmistrz]

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.