Active Topics
-
The N900 is now 15 years old! (6)
to Nokia N900 by Macros - 1 day, 3 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 1 day, 15 hrs ago -
n770 youtube video (0)
to General by nmdv - 5 days, 15 hrs ago - more...
shawnjefferson |
2013-11-01
, 01:32
|
|
Posts: 254 |
Thanked: 509 times |
Joined on Nov 2011
@ Canada
|
#1
|
Is it possible to get a thumb repository on maemo.org? Using the autobuilder, promotion, etc..
| The Following 9 Users Say Thank You to shawnjefferson For This Useful Post: | ||
|
|
2014-01-11
, 03:01
|
|
Posts: 254 |
Thanked: 509 times |
Joined on Nov 2011
@ Canada
|
#2
|
Originally Posted by joerg_rw
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.
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.
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.
|
|
2014-01-11
, 10:26
|
|
Posts: 1,163 |
Thanked: 1,873 times |
Joined on Feb 2011
@ The Netherlands
|
#3
|
You get my vote! I wouldn't mind a thumb repo with user applications, I can only applaud this idea 
__________________
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate
N900 loaded with:
CSSU-T (Thumb)
720p recording,
Pierogi, Lanterne, Cooktimer, Frogatto
N9 16GB loaded with:
Kernel-Plus
--
[TCPdump & libpcap | ngrep]
--
donate
 |
|
2014-01-11
, 14:54
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#4
|
Originally Posted by shawnjefferson
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?
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.
 |
|
2014-01-11
, 15:24
|
|
Posts: 5,028 |
Thanked: 8,613 times |
Joined on Mar 2011
|
#5
|
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.
Last edited by Estel; 2014-01-11 at 15:45.
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.
__________________
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
N900's aluminum backcover / body replacement
-
N900's HDMI-Out
-
Camera cover MOD
-
Measure battery's real capacity on-device
-
TrueCrypt 7.1 | ereswap | bnf
-
Hardware's mods research is costly. To support my work, please consider donating. Thank You!
Last edited by Estel; 2014-01-11 at 15:45.
 |
|
2014-01-11
, 17:58
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#6
|
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 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.
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
| The Following 4 Users Say Thank You to joerg_rw For This Useful Post: | ||
|
|
2014-01-11
, 18:01
|
|
Posts: 6,447 |
Thanked: 20,981 times |
Joined on Sep 2012
@ UK
|
#7
|
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.
Last edited by pichlo; 2014-01-11 at 19:13.
*) 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.
Last edited by pichlo; 2014-01-11 at 19:13.
|
|
2014-01-12
, 00:10
|
|
Posts: 254 |
Thanked: 509 times |
Joined on Nov 2011
@ Canada
|
#8
|
Originally Posted by joerg_rw
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.
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 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.
|
|
2014-01-12
, 02:05
|
|
Posts: 2,222 |
Thanked: 12,651 times |
Joined on Mar 2010
@ SOL 3
|
#9
|
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).
Last edited by joerg_rw; 2014-01-12 at 02:34.
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
__________________
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Maemo Community Council member [2012-10, 2013-05, 2013-11, 2014-06 terms]
Hildon Foundation Council inaugural member.
MCe.V. foundation member
EX Hildon Foundation approved Maemo Administration Coordinator (stepped down due to bullying 2014-04-05)
aka "techstaff" - the guys who keep your infra running - Devotion to Duty http://xkcd.com/705/
IRC(freenode): DocScrutinizer*
First USB hostmode fanatic, father of H-E-N
Last edited by joerg_rw; 2014-01-12 at 02:34.
| The Following User Says Thank You to joerg_rw For This Useful Post: | ||
|
|
2014-01-15
, 19:19
|
|
Posts: 3,328 |
Thanked: 4,476 times |
Joined on May 2011
@ Poland
|
#10
|
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.
Last edited by marmistrz; 2015-09-01 at 07:59. Reason: fixed a typo
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.
__________________
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
If you want to support my work, you can donate by PayPal or Flattr
Projects no longer actively developed: here
Last edited by marmistrz; 2015-09-01 at 07:59. Reason: fixed a typo
| The Following User Says Thank You to marmistrz For This Useful Post: | ||