Re: Squeeze devkit to be installed to autobuilder
Niels can confirm that it is in fact one of my primary directives ;) to allow for all stuff we deploy on the autobuilder to be replicated on local SDK setups (including official and SDK+). In fact my initial post (last paragraph) included instructions for Scratchbox 1 setups (not step by step, though). Marcin Juszkiewicz wrote: 1. Setup 2. FREMANTLE_ARMEL 3. cs2007q3-glibc2.5-arm7 4. debian-squeeze 5. none (as CPU-transparency method) 6. do not extract rootstrap 7. installed default set of files to target You should configure the _ARMEL target this way: Compiler: cs2007q3-glibc2.5-arm7 Devkits: perl doctools git qemu svn debian-squeeze CPU-transparency: /scratchbox/devkits/qemu/bin/qemu-arm-sb (do not extract rootstrap; no need to install files) Also, inside the target, you need to install: maemo-sdk-symbols, dh-make, cdbs, and quilt (if you used them; you most probably did). -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Dnia środa, 14 kwietnia 2010 o 20:52:19 Javier S. Pedro napisał(a): Hello all, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. Will there be step-by-step instructions for developers like me how to do that at home? I hate sbox, it makes me sick each time when I use it but I like to have own packages for things which I use so I have to deal with it (and no, I do not want to use madde or other less official things). Regards, -- JID: h...@jabber.org Website: http://marcin.juszkiewicz.com.pl/ LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Tuesday 27 April 2010 10:08:56 Marcin Juszkiewicz wrote: Dnia środa, 14 kwietnia 2010 o 20:52:19 Javier S. Pedro napisał(a): Hello all, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. Will there be step-by-step instructions for developers like me how to do that at home? I hate sbox, it makes me sick each time when I use it but I like to have own packages for things which I use so I have to deal with it (and no, I do not want to use madde or other less official things). And, where do we find the relevant sbdmock config files and rootstraps? Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Tuesday 27 April 2010 10:08:56 Marcin Juszkiewicz wrote: Will there be step-by-step instructions for developers like me how to do that at home? I hate sbox, it makes me sick each time when I use it but I like to have own packages for things which I use so I have to deal with it (and no, I do not want to use madde or other less official things). First you download the debian-squeeze devkit[1] and install it in your host. Then you change your fremantle targets to use the debian-squeeze devkit instead of debian-etch. You can do that with sb-menu. Then you apt-get install maemo-sdk-symbols from extras-devel and you are done. And, where do we find the relevant sbdmock config files and rootstraps? I changed these lines in our sbdmock config: config_opts['devkits'] = 'perl:debian-squeeze:doctools:svn:git' config_opts['after_rootstrap'] = 'fakeroot apt-get -y -q %s install maemo-optify man-db cdbs dpatch maemo-sdk-symbols' % config_opts['apt-get_options'] No rootstrap changes were needed. Graham - Niels [1] http://scratchbox.org/debian/dists/stable/main/binary-i386/scratchbox-devkit-debian-squeeze_1.0.3_i386.deb ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Dnia wtorek, 27 kwietnia 2010 o 15:52:58 Niels Breet napisał(a):
On Tuesday 27 April 2010 10:08:56 Marcin Juszkiewicz wrote:
Will there be step-by-step instructions for developers like me how to do
that at home? I hate sbox, it makes me sick each time when I use it but
I like to have own packages for things which I use so I have to deal
with it (and no, I do not want to use madde or other less official
things).
Sorry but I am not so familiar with sbox.
First you download the debian-squeeze devkit[1] and install it in your
host.
done
ma...@maemo-desktop:/$ dpkg -l *squeeze*
ii scratchbox-devkit-debian-squ 1.0.3 Debian Squeeze devkit for Scratchbox
ma...@maemo-desktop:/$
Then you change your fremantle targets to use the debian-squeeze devkit
instead of debian-etch. You can do that with sb-menu.
done:
[sbox-FREMANTLE_ARMEL: ~/pkg/my-extras/mdbus2-2.0.0] sb-menu
then:
1. Setup
2. FREMANTLE_ARMEL
3. cs2007q3-glibc2.5-arm7
4. debian-squeeze
5. none (as CPU-transparency method)
6. do not extract rootstrap
7. installed default set of files to target
and landed in:
[sbox-FREMANTLE_ARMEL: ~]
CFLAGS=-Wall -g -O2 -mthumb ./configure --host=arm-linux-gnueabi --
build=arm-linux-gnueabi --prefix=/usr --sysconfdir=/etc --
mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
checking for a BSD-compatible install... /scratchbox/tools/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [configure-stamp] Error 1
Then you apt-get install maemo-sdk-symbols from extras-devel and you are
done.
mdbus2 package fails at configure step
Regards,
--
JID: h...@jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Hi,
ext Marcin Juszkiewicz wrote:
[sbox-FREMANTLE_ARMEL: ~]
CFLAGS=-Wall -g -O2 -mthumb ./configure --host=arm-linux-gnueabi --
build=arm-linux-gnueabi --prefix=/usr --sysconfdir=/etc --
mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
checking for a BSD-compatible install... /scratchbox/tools/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [configure-stamp] Error 1
Then you apt-get install maemo-sdk-symbols from extras-devel and you are
done.
mdbus2 package fails at configure step
What sets the CFLAGS and configure flags?
CFLAGS are broken as N900 OMAP3 revision doesn't reliably support thumb
(see ARM errata).
With Sbox you don't need to set --host or --build options.
- Eero
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Tue, 2010-04-27 at 16:00 +0200, ext Marcin Juszkiewicz wrote:
...
1. Setup
2. FREMANTLE_ARMEL
3. cs2007q3-glibc2.5-arm7
4. debian-squeeze
5. none (as CPU-transparency method)
You need to use qemu as CPU-transparency here...
-Kimmo
6. do not extract rootstrap
7. installed default set of files to target
and landed in:
[sbox-FREMANTLE_ARMEL: ~]
CFLAGS=-Wall -g -O2 -mthumb ./configure --host=arm-linux-gnueabi --
build=arm-linux-gnueabi --prefix=/usr --sysconfdir=/etc --
mandir=\${prefix}/share/man --infodir=\${prefix}/share/info
checking for a BSD-compatible install... /scratchbox/tools/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-linux-gnueabi-gcc... arm-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C
compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.
make: *** [configure-stamp] Error 1
Then you apt-get install maemo-sdk-symbols from extras-devel and you are
done.
mdbus2 package fails at configure step
Regards,
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Squeeze devkit to be installed to autobuilder
-Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers- boun...@maemo.org] On Behalf Of ext Javier S. Pedro Sent: 16 April, 2010 01:40 To: maemo-developers@maemo.org Subject: Re: Squeeze devkit to be installed to autobuilder Graham Cobb wrote: By the way, has the change been well tested? With real packages built with the modified SDK and installed on all existing firmware releases? We don't want to do all this and discover it doesn't fix the problem. We built quite a lot of packages [1], checked sanity of dependencies and I also tested a few on my device (1.1.1). It fixes the problem. Feel free to test some of them :) Have tested a couple on a 1.2 device (but that was to be expected). Works well as far as I can see. Quite an impressive task you guys have done! Tero We expect most of the issues to appear in the building stage, and testing seems to prove this. [1] https://garage.maemo.org/builder/.fremantletest/__packages__/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
i found quite a lot of updates this morning on my PR1.1.1 device. Many of those, however, (like MaePad) throw at me an Update file corrupted error... fMMS update (I think frals is still on SDK for PR 1.2) updated fine... Is this related to this change ? Aniello On 16 April 2010 02:46, tero.k...@nokia.com wrote: -Original Message- From: maemo-developers-boun...@maemo.org [mailto:maemo-developers- boun...@maemo.org] On Behalf Of ext Javier S. Pedro Sent: 16 April, 2010 01:40 To: maemo-developers@maemo.org Subject: Re: Squeeze devkit to be installed to autobuilder Graham Cobb wrote: By the way, has the change been well tested? With real packages built with the modified SDK and installed on all existing firmware releases? We don't want to do all this and discover it doesn't fix the problem. We built quite a lot of packages [1], checked sanity of dependencies and I also tested a few on my device (1.1.1). It fixes the problem. Feel free to test some of them :) Have tested a couple on a 1.2 device (but that was to be expected). Works well as far as I can see. Quite an impressive task you guys have done! Tero We expect most of the issues to appear in the building stage, and testing seems to prove this. [1] https://garage.maemo.org/builder/.fremantletest/__packages__/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
i found quite a lot of updates this morning on my PR1.1.1 device. Many of those, however, (like MaePad) throw at me an Update file corrupted error... fMMS update (I think frals is still on SDK for PR 1.2) updated fine... Is this related to this change ? Yes and no. The same thing happens on a PR1.2 device. It seems the caching network caches the debs for 2 days, so it sees new package data, but gets the old file. We now issued a flush of the cache, will take another hour or so for it to complete. Let's see if that fixes the issue. Aniello - Niels ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On 16 April 2010 10:39, Niels Breet ni...@maemo.org wrote: i found quite a lot of updates this morning on my PR1.1.1 device. Many of those, however, (like MaePad) throw at me an Update file corrupted error... fMMS update (I think frals is still on SDK for PR 1.2) updated fine... Is this related to this change ? Yes and no. The same thing happens on a PR1.2 device. It seems the caching network caches the debs for 2 days, so it sees new package data, but gets the old file. We now issued a flush of the cache, will take another hour or so for it to complete. Let's see if that fixes the issue. Thanks Neils, we'll try later at lunch time (an hour and a half from now) and see what happens. I'm confident that should fix it. -- anidel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On 16 April 2010 10:41, Aniello Del Sorbo ani...@gmail.com wrote: On 16 April 2010 10:39, Niels Breet ni...@maemo.org wrote: i found quite a lot of updates this morning on my PR1.1.1 device. Many of those, however, (like MaePad) throw at me an Update file corrupted error... fMMS update (I think frals is still on SDK for PR 1.2) updated fine... Is this related to this change ? Yes and no. The same thing happens on a PR1.2 device. It seems the caching network caches the debs for 2 days, so it sees new package data, but gets the old file. We now issued a flush of the cache, will take another hour or so for it to complete. Let's see if that fixes the issue. Thanks Neils, we'll try later at lunch time (an hour and a half from now) and see what happens. I'm confident that should fix it. Fix worked. Of all the updated only Mapper is not installable due to hildon1 = 2.2.10 (and libpixman-1-0 = 0.15.16) dependencies... Was it recompiled? Aniello ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Aniello Del Sorbo wrote: Of all the updated only Mapper is not installable due to hildon1 = 2.2.10 (and libpixman-1-0 = 0.15.16) dependencies... Because it seems to be overloaded, I cannot fetch the package from the repository atm; however, the package was built succesfully under the test autobuilder ([1]) with the more accurate libhildon1 (= 2.2.0-1~rc8+0m5) dependency (~PR1.0). I have also rebuilt it in my local machine with same results. So I guess it's a temporary problem... [1] https://garage.maemo.org/builder/.fremantletest/maemo-mapper_3.0+beta4/results/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Wed, Apr 14, 2010 at 20:00, Niels Breet ni...@maemo.org wrote: As part of this task we need to decide with the 'broken' or affected packages which have been built on the PR1.2 SDK and have gotten PR1.2 dependencies. The simple thing would be to resubmit all packages which have been built successfully since the autobuilder SDK change on 2010-03-24[1]. However if that's too complex/too large; alternatively: 1) We identify any package with a known uninstallable dependency (libhildon = 2.2.10 being the best example, but there are a few others); and resubmit them. 2) After that, we email everyone who has uploaded a package in that time which has been built successfully and ask them to check their packages (ideally with links to the specific pages on maemo.org/packages/) and reupload. Would it also be possible to show, on maemo.org/packages/ - based on package version constraints - the minimum release required to install the app? We can automatically import all rebuilt packages into extras-devel or we can decide to let developers re-submit their packages after the builder has been switched to the new setup. I definitely favour the resubmitting approach. It's easiest for developers by far; and so in terms of total effort is the lowest overall. However, will we have issues with version numbers? If we auto resubmit them, should we ensure that each package is resubmitted with a new version number? If so, a suffix of -20100415 would be sufficient? Cheers, Andrew [1] http://lists.maemo.org/pipermail/maemo-developers/2010-March/025512.html -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Wed, Apr 14, 2010 at 20:00, Niels Breet ni...@maemo.org wrote: As part of this task we need to decide with the 'broken' or affected packages which have been built on the PR1.2 SDK and have gotten PR1.2 dependencies. The simple thing would be to resubmit all packages which have been built successfully since the autobuilder SDK change on 2010-03-24[1]. I have already done that rebuild. The resulting packages can be checked here: https://garage.maemo.org/builder/.fremantletest/__packages__/ We can automatically import all rebuilt packages into extras-devel or we can decide to let developers re-submit their packages after the builder has been switched to the new setup. I definitely favour the resubmitting approach. It's easiest for developers by far; and so in terms of total effort is the lowest overall. Well, importing all the rebuilt packages is the easiest approach. However, will we have issues with version numbers? If we auto resubmit them, should we ensure that each package is resubmitted with a new version number? If so, a suffix of -20100415 would be sufficient? I really don't like touching source packages, that just feels wrong. Cheers, Andrew [1] http://lists.maemo.org/pipermail/maemo-developers/2010-March/025512.html -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
However, will we have issues with version numbers? If we auto resubmit them, should we ensure that each package is resubmitted with a new version number? If so, a suffix of -20100415 would be sufficient? Although I am generally against modifying developer's packages, I agree that this is the most pragmatic solution. Anyone who doesn't like it can submit a newer version of the package. By the way, has the change been well tested? With real packages built with the modified SDK and installed on all existing firmware releases? We don't want to do all this and discover it doesn't fix the problem. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
On Thu, Apr 15, 2010 at 15:21, Graham Cobb g+...@cobb.uk.net wrote: However, will we have issues with version numbers? If we auto resubmit them, should we ensure that each package is resubmitted with a new version number? If so, a suffix of -20100415 would be sufficient? Although I am generally against modifying developer's packages, I agree that this is the most pragmatic solution. Anyone who doesn't like it can submit a newer version of the package. The other solution, which Niels has suggested, is just replacing the updated packages. Since most people haven't been able to install them, this is a quick win (no real redefinition of what the version *is*). We could then approach it as: 1) Email all developers you have successfully built packages since 2010-03-24 outlining them of the situation and the actions about to be taken. (Preferably linking to the maemo.org/packages/ pages for the packages they've uploaded) 2) Swap in the rebuilt versions, with the same version number, from the test/experimental/staging area Niels built: https://garage.maemo.org/builder/.fremantletest/__packages__/ 3) Re-index the repo. 4) Resolve https://bugs.maemo.org/show_bug.cgi?id=9752 By the way, has the change been well tested? With real packages built with the modified SDK and installed on all existing firmware releases? We don't want to do all this and discover it doesn't fix the problem. Indeed. I'm not aware of any extensive testing apart from a few packages on my PR1.1.1 device. Javier/Niels? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Graham Cobb wrote: By the way, has the change been well tested? With real packages built with the modified SDK and installed on all existing firmware releases? We don't want to do all this and discover it doesn't fix the problem. We built quite a lot of packages [1], checked sanity of dependencies and I also tested a few on my device (1.1.1). It fixes the problem. Feel free to test some of them :) We expect most of the issues to appear in the building stage, and testing seems to prove this. [1] https://garage.maemo.org/builder/.fremantletest/__packages__/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Squeeze devkit to be installed to autobuilder
Hello all, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. This means that packages built in the PR1.2 SDK using no PR1.2-introduced functions will work on a PR1.1 device and even on a 1.0 device. Unfortunately, this approach doesn't include Qt packages as there are more problems to that, but we hope the Qt API to be more stable in future releases. Of course, upgrading to Squeeze _will_ cause compatibility problems to some packages. We have been rebuilding many of them in a test environment [5, 6] and analyzed the common issues -- in fact, we have talked to a few maintainers about those. If your package doesn't build when we move the autobuilder to Squeeze and you don't know how to fix it, don't hesitate to ask. We find that most of the compatibility problems are caused by stricter checks, and that is always a Good Thing (TM). If you want to swap your local SDK to squeeze, you have to 1. Install the squeeze devkit from [2] 2. Replace debian-etch devkit with debian-squeeze in scratchbox target 3. Inside target, apt-get install maemo-sdk-symbols cdbs man-db dpatch [1] http://wiki.maemo.org/Task:PR1.2_autobuilder [2] http://scratchbox.org/debian/dists/stable/main/binary-i386/scratchbox-devkit-debian-squeeze_1.0.3_i386.deb [3] http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps [4] http://maemo.org/packages/view/maemo-sdk-symbols/ [5] https://garage.maemo.org/builder/.fremantletest/ [6] https://garage.maemo.org/builder/.fremantletest/__packages__/ -- Javier ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
Hello all, Hi, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. This means that packages built in the PR1.2 SDK using no PR1.2-introduced functions will work on a PR1.1 device and even on a 1.0 device. As part of this task we need to decide with the 'broken' or affected packages which have been built on the PR1.2 SDK and have gotten PR1.2 dependencies. We can automatically import all rebuilt packages into extras-devel or we can decide to let developers re-submit their packages after the builder has been switched to the new setup. Thoughts? -- Javier -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Squeeze devkit to be installed to autobuilder
First off, a big thanks for this effort. My package (soon to be two ;-) uses Qt, so I'm not sure how much this will help me personally, it is definitely an important step in the right direction. For those packages that are OK, importing them automatically is fine. However for those that do have problems, the developer should be able to control when it gets moved. I think the major lesson learned here is to try hard not to replace a working package with a broken one. It would be unwise to do the same thing again. Scenarios include abandoned packages, long developer response times, etc ... - ianaré sévi 2010/4/14 Niels Breet ni...@maemo.org: Hello all, Hi, As part of the plan to fix the PR1.2 SDK dependency issues in the autobuilder [1], we plan to upgrade the Debian devkit in the Fremantle autobuilder to the Squeeze version [2] (from the current etch one), and start using improved shlibdeps [3] (a.k.a. .symbols files) to version dependencies on a much more granular basis (minimal required version of libraries will be calculated per symbol instead of per library). We plan to ship .symbols files for most of the SDK libraries [4]. This means that packages built in the PR1.2 SDK using no PR1.2-introduced functions will work on a PR1.1 device and even on a 1.0 device. As part of this task we need to decide with the 'broken' or affected packages which have been built on the PR1.2 SDK and have gotten PR1.2 dependencies. We can automatically import all rebuilt packages into extras-devel or we can decide to let developers re-submit their packages after the builder has been switched to the new setup. Thoughts? -- Javier -- Niels Breet maemo.org webmaster ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
