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,
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
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
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
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
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...
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
-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
...@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
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 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
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
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
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
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
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
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
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
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
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
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
21 matches
Mail list logo
