RE: autoconf upgrade problem
Kwan Hong Lee wrote:
For some reason, even if I have the new autoconf directory
added to the beginning of the directory, when I call
pulseaudio/autogen.sh it uses the older autoconf, currently
2.59. I can't modify sb_autoconf_wrapper because it's read only.
What can I do?
Please don't reply to individuals. This is a list for a reason.
[EMAIL PROTECTED]:/scratchbox/tools/bin$ echo *2.50*
autoconf2.50 autoheader2.50 autoreconf2.50
[EMAIL PROTECTED]:/scratchbox/tools/bin$ ls -l autoconf2.50
lrwxrwxrwx 1 root root 38 2008-03-31 18:52 autoconf2.50 -
../autotools/autoconf2.59/bin/autoconf
[EMAIL PROTECTED]:/scratchbox/tools/bin$ cd ../autotools/
[EMAIL PROTECTED]:/scratchbox/tools/autotools$ ls
autoconf2.13 autoconf2.59 automake-1.4 automake-1.7 automake-1.8
automake-1.9
[EMAIL PROTECTED]:/scratchbox/tools/autotools$ mkdir ~/ac262
[EMAIL PROTECTED]:/scratchbox/tools/autotools$ pushd ~/ac262/
~/ac262 /scratchbox/tools/autotools
[EMAIL PROTECTED]:~/ac262$ wget
http://ftp.gnu.org/gnu/autoconf/autoconf-2.62.tar.bz2 2 /dev/null
/dev/null
[EMAIL PROTECTED]:~/ac262$ tar jxf autoconf-2.62.tar.bz2
[EMAIL PROTECTED]:~/ac262$ cd autoconf-2.62/
[EMAIL PROTECTED]:~/ac262$ ./configure
--prefix=/scratchbox/tools/autotools/autoconf2.62
[EMAIL PROTECTED]:~/ac262/autoconf-2.62$ make -s
[EMAIL PROTECTED]:~# cd /home/timeless/ac262/autoconf-2.62
[EMAIL PROTECTED]:/home/timeless/ac262/autoconf-2.62# make install 2 /dev/null
/dev/null
[EMAIL PROTECTED]:/home/timeless/ac262/autoconf-2.62# cd /scratchbox/tools/bin
[EMAIL PROTECTED]:/scratchbox/tools/bin# ls -l autoconf2.50
lrwxrwxrwx 1 root root 38 2008-03-31 18:52 autoconf2.50 -
../autotools/autoconf2.59/bin/autoconf
[EMAIL PROTECTED]:/scratchbox/tools/bin# ln -s
../autotools/autoconf2.62/bin/autoconf autoconf2.60
[EMAIL PROTECTED]:/scratchbox/tools/bin# ln -s
../autotools/autoconf2.62/bin/autoheader autoheader2.60
[EMAIL PROTECTED]:/scratchbox/tools/bin# ln -s
../autotools/autoconf2.62/bin/autoreconf autoreconf2.60
[EMAIL PROTECTED]:/scratchbox/tools/bin# patch /dev/stdin
--- sb_autoconf_wrapper 2008-05-05 09:40:45.0 +0300
+++ sb_autoconf_wrapper 2008-05-05 09:42:47.0 +0300
@@ -26,2 +26,4 @@
ac250 ();
+ } elsif ($force eq '2.60' || $force eq '2.62') {
+ ac260 ();
} else {
@@ -158,2 +160,9 @@
-# Default to 2.13.
-ac213 ();
+my $force = $ENV{'SBOX_DEFAULT_AUTOCONF'};
+if ($force eq '2.50' || $force eq '2.59') {
+ac250 ();
+} elsif ($force eq '2.60' || $force eq '2.62') {
+ac260 ();
+} else {
+# Default to 2.13.
+ac213 ();
+}
@@ -222 +223,5 @@
+sub ac260 {
+run_autoconf (/scratchbox/tools/bin/${mode}2.60);
+}
+
sub run_autoconf {
^D
patching file sb_autoconf_wrapper
Hunk #2 succeeded at 161 (offset 1 line).
Hunk #3 succeeded at 224 with fuzz 1 (offset 1 line).
[EMAIL PROTECTED]:~$ scratchbox
[sbox-test-arm: ~] SBOX_DEFAULT_AUTOCONF=2.60
[sbox-test-arm: ~] export SBOX_DEFAULT_AUTOCONF
[sbox-test-arm: ~] autoconf
autoconf2.60: no input file
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
On Sat, 2008-05-03 at 17:22 +, Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius you should try opensource firmwares instead, such as openwrt ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Prelinking and GNU Hashstyle on maemo?
Hi, I notice that back in the maemo 3.x days there was a prelink package for maemo [1]. Was this deprecated in favour of another approach? I have recently ported libferris [3] to maemo chinook. I still have to perform integration into the maemo environment and hildon customization and other perks of a port but the code is deb'ed, installable and console tools run. Libferris benefits greatly by prelinking, on a desktop machine an unprelinked ferrisls on a small directory might spend more than half its runtime in the dynamic linker. So prelinking helps greatly for console use and fork()/exec() patterns in GUI applications. I have tried taking prelink from various versions of debian but am unable to get it and libelf to be happy on my n810. Has anyone played with using the GNU hashstyle [2] with the n810 or other methods to speed up dynamic linking? [1] http://tablets-dev.nokia.com/3.2/content_changes.html [2] http://gentoo-wiki.com/HOWTO_Hashstyle [3] http://witme.sourceforge.net/libferris.web/ signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Diablo, do we need a separate repository?
Hi all, As you probably all know Diablo, the next revision of the IT OS, is coming out sooner or later. Diablo will be binary compatible with chinook, but there will be two additions. There will be a new email framework and a newer version of libssl (0.9.8) because of requirements for the WiMax tablet. Most applications that work on chinook, should run unchanged on diablo. So developers should not have to change anything in their code to run their chinook application on diablo. In the past we added an extras repository with the corresponding codename for all new OS versions. This was needed, because versions weren't binary compatible. We now have come to the point where the next version _is_ binary compatible. My question to the maemo community is this: Do we need a separate extras repository for diablo or should we just add a link to chinook? By linking the two, developers don't have to upload their packages to both repositories. What do you think? Please give us your ideas, pros/cons. - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
Dnia Monday 05 of May 2008, Niels Breet napisał: As you probably all know Diablo, the next revision of the IT OS, is coming out sooner or later. Diablo will be binary compatible with chinook, but there will be two additions. There will be a new email framework and a newer version of libssl (0.9.8) because of requirements for the WiMax tablet. Does someone work on apt-get update;apt-get upgrade from Chinook to Diablo then? Or do we are expected to 'use maemo backup, then rsync whole filesystem, reflash'? -- JID: hrw-jabber.org OpenEmbedded developer/consultant We're here to give you a computer, not a religion. -- Bob Pariseau, at the introduction of the Amiga ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: kernel patches, Re: DSP framebuffer access on N8x0
On Wed, Apr 30, 2008 at 10:17 AM, Frantisek Dufka [EMAIL PROTECTED] wrote: Simon Pickering wrote: This requires two things, a kernel patch, and adding a FRAMEBUFFER section to the /lib/dsp/avs_kernelcfg.cmd file. See https://bugs.maemo.org/show_bug.cgi?id=3123 for the patch. Nice. I've been thinking about garage project named kernel-hacks or something, that would accumulate interesting kernel patches and even have some pre-built kernels with those patches applied. The reason is that there are already quite a few interesting kernel patches and it is hard to keep track of them. Of course it would make sense only if people doing some kernel hacking would actually join such project and submit patches and optionally build kernel images with some subset or all the patches. Opinions? Is it needed? Would you (actively) participate? Any better solutions (git tree)? Or we can still keep them scattered across bugzilla and internet. I like the idea a lot, I think it is needed and I would be running such kernels but I am not sure I would really participate(other then grabbing the source for a mamona kernel). Following the corporate discussion I think this would be a good place to experiment. allowing us to request a kernel module against a certain kernel certainly makes scene (can't this be done using the new autobuilder)? Some of them could be merged to mainline or Nokia kernel but many of them are just quick hacks of debatable value and correctness with little chance of merging to some official tree. Maybe some public GIT tree would be better but I'm not familiar with GIT. And also I don't have 24/7 online server for this anyway. I also thought about starting someting similar directly on http://fanoush.wz.cz/maemo/ but I don't want to hijack other people's stuff and it is free hosting so it is not safe, it can vanish anytime. Also recently I have become a bit slow due to busy real life so having more people for maintenance would be nice :-) Perhaps we can request git support in garage? what else are you missing there? greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
Niels Breet wrote: On Mon, May 5, 2008 13:58, Rafael Proença wrote: Do we need a separate extras repository for diablo or should we just add a link to chinook? My guess is that if you link diablo to chinook what will happen is that all the chinook boxes will be upgraded to diablo, which, I think, is not ideal and even not compatible even though the binaries are compatible, the core system will not be (for example, I heard that the user will not have to reflash the device to upgrade the distribution once they have Diablo installed). I think I need to clarify that I was talking about the extras repository here. This is about community created packages in extras. System packages would be served from a different repository. IMO, the compatibility of binary packages is not the only problem here. But the packages' version and are. For those working with the enhancements, it would obviously be best to keep the Diablo stuff separate, but allow a very easy forward/back-port of packages. In many cases, it's just a changing of a target in the debian changelog - is there someway a web-based backport/forwardport service could be put together to allow the advantages of a separate repository while not inhibiting the ability to share essentially identical packages? -- Ryan Pavlik www.cleardefinition.com #282 + (442) - [X] A programmer started to cuss Because getting to sleep was a fuss As he lay there in bed Looping 'round in his head was: while(!asleep()) sheep++; ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Diablo, do we need a separate repository?
ext Marcin Juszkiewicz [EMAIL PROTECTED] writes: Does someone work on apt-get update;apt-get upgrade from Chinook to Diablo then? No, unfortunately not. We are working to get apt-get upgrade working for releases that come after Diablo. I agree that a smooth upgrade path is needed: without it, we not only need to keep backwards compatibility (packages created with the Chinook SDK run on Diablo), but also fowards compatibility (packages created with the Diablo SDK run on Chinook). If we have a smooth upgrade patch, we can expect people to upgrade to Diablo and stop supporting Chinook devices. Or do we are expected to 'use maemo backup, then rsync whole filesystem, reflash'? For the Chinook to Diablo upgrade, yes. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
My dear friend,software fromhttp://approsoftware.com/is exactly declared as Linux open software product.Unfortunately its offered as a commercial product at high chargeas hardware lock key is installed to make itnot to function without hardware lock key installed.I have already contacted Free Software Foundationasking for kind explanationif it objects or notto have GNU Open Source software to be commercializedby installation of hardware lock key in embedded products.Nokia Internet Tablet is one of such productsand acting that way Nokia can disable some libraries, functions or proprietary/non-proprietary applications, installing hardware lock keymaking GNU open source software disabled without payingextra fee/charge.If this is just the case, GNU open source is no more free open source softwareunder GNU lincense as to run it on embedded device one will have to pay unreasonable extra fee.As any Linux open source project/software is based on community past and present workcommercialization of hardware lock key protected new Linux softwareis exactly making profit and money on community workaccessed for free.Asking community to work for free to let few guys to make real money on commercialized Linux software products.So there is no instead, as the software product offered byApprosoftware.comis exactly described as open source.And demo version is for free, commercial Linux open source version is for fee.Just download and install it to see the problem.DariusJust--- On Mon, 5/5/08, Raphaël Jacquot [EMAIL PROTECTED] wrote:From: Raphaël Jacquot [EMAIL PROTECTED]Subject: Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]To: [EMAIL PROTECTED]Cc: maemo-developers@maemo.org, "Luca Olivetti" [EMAIL PROTECTED]Date: Monday, 5 May, 2008, 9:22 AMOn Sat, 2008-05-03 at 17:22 +, Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius you should try opensource firmwares instead, such as openwrtSend instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Hi Andrew, Andrew Flegg wrote: On the back of my post, maemo.org: what next?[1], it was interesting to read in yesterday's LWN that the community around OpenSolaris feels very much shut out of internal Sun development processes: http://lwn.net/SubscriberLink/280452/8f5b64d861d8f79e/ Indeed - an interesting read. He quoted some very good sources ;-) Reading this, it was very striking the number of similarities with Nokia's situation with maemo and the maemo community. The above is a free link, but I strongly recommend you subscribe to LWN[2] if you haven't already. While I'm still getting to know the maemo community, I think tyhat the difference is in the goals, and in the means that Nokia are putting at the disposition of the community to achieve those goals. Yes, Nokia employees were behind most of the early maemo work. But they also chose to hire small companies with established free software credentials (OpenedHand, Imendio, OpenIsmus, Nemein, Kernel Concepts, the list goes on) to do much of the work. Even though these guys were working in the beginning under NDA, that's a good sign that Nokia wanted to work with upstream projects, rather than create a walled garden. There's also the way that Nokia is now investing in people like myself Niels, and André and Karsten to ensure that weak points of interaction between the community and any Nokia technology are identified and eliminated. I have not been asked to sign any NDAs, and all the work I do will be out in the open, using information available to the community (or I will be asking for that information to be made available). Nokia's goals appear, at least to me, to be clear (but I have no more information on this than anyone else). Their goal is to make a commercially successful tablet product, using as much free software as possible, and providing an open development platform for developers, thereby creating a vibrant ecosystem of application developers targeting the maemo platform. I expect Nokia to keep some control of Hildon and all of the components on which they build their commercial products. But control comes in many forms. Just employing a maintainer doesn't imply control (just ask Josh Berkus or Linus Torvalds) nor does it imply that significant community contributions are unwelcome. Cheers, Dave. -- Dave Neary GNOME Foundation member [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]
Please read the followingfromhttp://approsoftware.com/en/aboutus.htmlopen-source software based on Linux OS is being sold as a commercial producthttp://approsoftware.com/en/howtobuy.html About us Alfanet sp. z o.o. is a Wroclaw-based Polish company, operating since 1996 as an ISP, as well as provider of solutions based on Open-Source Software and Linux operating system. We offer to our customers such services as Web hosting, domain registration and maintenance, design of Web applications and Web pages, network security and wireless Internet access. Alfanet also designs and sells specialized APPro software for Access Points based on ***RTL8186 and Atheros chipsets. This software increases functionality and value of Access Points. APs with the new firmware can replace more expensive Access Points as well as other network devices (bandwidth managers, firewalls, watchdogs). This can bring significant savings related not only to hardware purchases, but also the time needed to work with this extra hardware. Our software also increases network security and its performance. Additionally APPro makes it possible to customize ISP's offer to current demands, which translates to better customer satisfaction. Alfanet, SP. z o.o. ul. Bulwar Ikara 29A/2 54-130 Wrocław Poland Tel. +48 71-79 56 000 Fax +48 71-79 56 500 Last update: Tuesday, 02 October 2007--- On Mon, 5/5/08, Raphaël Jacquot [EMAIL PROTECTED] wrote:From: Raphaël Jacquot [EMAIL PROTECTED]Subject: Re: Opensource locked by hardware key was Re: Corporate ownership of open source projects [LWN]To: [EMAIL PROTECTED]Cc: maemo-developers@maemo.org, "Luca Olivetti" [EMAIL PROTECTED]Date: Monday, 5 May, 2008, 9:22 AMOn Sat, 2008-05-03 at 17:22 +, Darius Jack wrote: ... sorry (cut for clarity) I the meantime I was contacted and learneed that offered software was opensource (no GNU Open Sourrce licence included). Unfortunately software - firmware for Wifi Access Points is offered hardware key locked from the following web page http://approsoftware.com/ I would like to know your opinion if opensource software (GNU Open Source licence (not included) intended for Linux OS, can be hardware key locked to disable its functions. Acting that way, any opensource software for Linux can be hardware key locked and sold for fee as a commercial product restricted access sourcees provided or not. Darius you should try opensource firmwares instead, such as openwrtSend instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Dnia Monday 05 of May 2008, [EMAIL PROTECTED] napisał:
[EMAIL PROTECTED] wrote:
unfortunately the closed part (umac.ko) is full kernel module not
linkable object file so it too depends on kernel version and sadly
even specific kernel configuration
So close, and yet so far away. I would say that umac.ko should
definately be reworked so it is not distributed as a complete kernel
module, but just an object, umac.o, that can be linked to an open
source driver, perhaps even hooked directly to cx3110x.ko.
There is a trick to get umac.ko built for other kernels then default one.
Have a look at [1] and [2]. You need to have umac.ko from device and
remove some sections from it. Then cx3110x 1.x driver can be compiled for
it (I did not tried it with 2.0.15).
cp ${WORKDIR}/umac.ko ${S}/src/binary_umac.o
${OBJCOPY} ${S}/src/binary_umac.o -R __ksymtab
${OBJCOPY} ${S}/src/binary_umac.o -R __ksymtab_strings
${OBJCOPY} ${S}/src/binary_umac.o -R .gnu.linkonce.this_module
${OBJCOPY} ${S}/src/binary_umac.o -R .modinfo
${OBJCOPY} ${S}/src/binary_umac.o -R .init.text
${OBJCOPY} ${S}/src/binary_umac.o -R .exit.text
1.
http://amethyst.openembedded.net/oe/viewmtn/viewmtn.py/OE1/revision/file/d4a97f257158aba4fde91347580030110ef215bf/packages/c3110x/cx3110x_1.1.bb
2.
http://amethyst.openembedded.net/oe/viewmtn/viewmtn.py/OE1/revision/file/d4a97f257158aba4fde91347580030110ef215bf/packages/c3110x/files/umac_binary.patch
Method with open source driver + firmware blob would be better but this
will rather do not happen as 770 and n8x0 are already on market so Nokia
wont spent any extra money on rewriting driver.
--
JID: hrw-jabber.org
OpenEmbedded developer/consultant
Any smoothly functioning technology will have the appearance of magic.
-- Arthur C. Clarke
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
Dnia Saturday 03 of May 2008, Igor Stoppa (Nokia) napisał: Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. The padlock is on many things which got limited just because no one took a moment to discuss things with community (guess). -closed SW: Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. At least ability to *read* battery status without Nokia *closed* binaries should be possible. There is battery class now in kernel... Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. Wlan situation was wrong from beginning - when 770 was released. N8x0 just use newer version of 770 driver. Too bad that no one was working on it to make it work with standard linux wlan components like WPA supplicant. This also blocks Nokia tablets from being usable with non-maemo systems. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. This is not a solution. There are many closed components (some of them were open in older releases) and one person will never get request queue cleaned in acceptable time. I will not mention that many of those closed components looks like closed just because Nokia was able to close it -- other ideas do not came to my brain now. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. I hope that one day (during this year not 2012) few Nokia developers/managers will take a list of maemo components and triple check which one should be closed and which not. Then releasing sources for second ones and reasons of closing for others. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. People are doing lot of low kernel development on misc palmtops with only serial cables (some try even without them). Having measuring tools, special boards is handy but such setups not always are the same as final devices. -- JID: hrw-jabber.org OpenEmbedded developer/consultant It might look like I'm doing nothing, but at the cellular level I'm really quite busy! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Prelinking and GNU Hashstyle on maemo?
maemo has its own precaching system afaik (compiles the programs as libraries and thread them with maemo-invoker, maemo-launcher ,... but this is only for the apps build as libraries which are mostly the ones provided by nokia. I didn't tried prelude or libferris on arm yet. but i found quite interesting the use of the diablo toolkit for optimizing binaries at linkage time. Take a look on the project. Integrating it for scratchbox will be a easy and will benefit both projects. so diablo works for intel and arm (also for mips, ia64 and alpha) http://diablo.elis.ugent.be/ On Mon, 05 May 2008 20:11:38 +1000 Ben Martin [EMAIL PROTECTED] wrote: Hi, I notice that back in the maemo 3.x days there was a prelink package for maemo [1]. Was this deprecated in favour of another approach? I have recently ported libferris [3] to maemo chinook. I still have to perform integration into the maemo environment and hildon customization and other perks of a port but the code is deb'ed, installable and console tools run. Libferris benefits greatly by prelinking, on a desktop machine an unprelinked ferrisls on a small directory might spend more than half its runtime in the dynamic linker. So prelinking helps greatly for console use and fork()/exec() patterns in GUI applications. I have tried taking prelink from various versions of debian but am unable to get it and libelf to be happy on my n810. Has anyone played with using the GNU hashstyle [2] with the n810 or other methods to speed up dynamic linking? [1] http://tablets-dev.nokia.com/3.2/content_changes.html [2] http://gentoo-wiki.com/HOWTO_Hashstyle [3] http://witme.sourceforge.net/libferris.web/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Corporate ownership of open source projects [LWN]
On Mon, 2008-05-05 at 22:30 +0200, ext Marcin Juszkiewicz wrote: Dnia Saturday 03 of May 2008, Igor Stoppa (Nokia) napisał: Sadly the padlock (and i'm not denying that there is one) is around some of the most boring or crufty stuff, not really on the family jewels. The padlock is on many things which got limited just because no one took a moment to discuss things with community (guess). -closed SW: Then comes bme: charging the battery is something that nowadays is described quite well in the application notes of many battery charging chips, so google would be able to provide all the needed information for some primitive charging sw, but again this is a lawsuit waiting to happen. If common sense was more diffuse and companies didn't have to be paranoid, probably more opening could be done, but i'm skeptic about anything happening on that front at the moment. At least ability to *read* battery status without Nokia *closed* binaries should be possible. There is battery class now in kernel... Finally we have the WLAN module and FW, which are again developed under NDA and it's quite unlikely that the manufacturer is willing to release the source. Wlan situation was wrong from beginning - when 770 was released. N8x0 just use newer version of 770 driver. Too bad that no one was working on it to make it work with standard linux wlan components like WPA supplicant. This also blocks Nokia tablets from being usable with non-maemo systems. In the end I think what would be realistically possible - and i'm already completely sure that many won't be satisfied and will complain - is that Nokia provides one person whose sole task is to support the community by mantaining the closed code and providing new binaries that link against recent libraries. The community would still be able to set the direction for the development and ask for updates, so that these closed areas would not hold back work done in the open part. Which is the majority. This is not a solution. There are many closed components (some of them were open in older releases) and one person will never get request queue cleaned in acceptable time. I will not mention that many of those closed components looks like closed just because Nokia was able to close it -- other ideas do not came to my brain now. And I think it would be only fair that, having Nokia enjoyed the benefits of taking these shortcuts (mostly can be summarized in not using better/more open HW), now it will take also the pain of providing continued support for the closed components. I hope that one day (during this year not 2012) few Nokia developers/managers will take a list of maemo components and triple check which one should be closed and which not. Then releasing sources for second ones and reasons of closing for others. Till here you are not really providing much of a proposal for getting things done, just generic complaints that historically are proven to not work. This is my personal opinion - not to be taken as a promise or plan - but as an advice in what the community could do/demand to keep the old devices alive. Can community also demand informations how to make non-maemo systems working on tablets? What if I would like to run XFCE on 770 or Qtopia? Ask Quim, he is the Maemo man. Anyway note that in order to do proper low level kernel development, one needs also measuring tool and special boards that allow for precise measuring of what the sw is doing. Nobody in the community has such setup, so some help from Nokia for validation would still be required. People are doing lot of low kernel development on misc palmtops with only serial cables (some try even without them). Having measuring tools, special boards is handy but such setups not always are the same as final devices. Even our developers have problems at producing proper code without these tools. It's relatively easy to get some functionality to apparently work, but getting it to work right and properly leverage the HW is a different case. And we take care that our hw boards are in sync. -- Cheers, Igor --- Igor Stoppa Next Generation Software Nokia Devices RD - Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Prelinking and GNU Hashstyle on maemo?
On Tue, 2008-05-06 at 03:59 +0200, pancake wrote: I didn't tried prelude or libferris on arm yet. but i found quite interesting the use of the diablo toolkit for optimizing binaries at linkage time. The one show stopper here is, from their home page: Diablo only works on statically linked programs. We are looking into supporting dynamically linked programs, but support for this is not yet completed. Most of the time I try to put functionality into libferris itself keeping the clients fairly small. Static linking a large collection of clients would cause a large amount of bloat in the storage needed. But I'll have a tinker with diablo anyway :) signature.asc Description: This is a digitally signed message part ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
