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, tho
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
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... /
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 h
>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
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
> > a
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
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 16 April 2010 10:41, Aniello Del Sorbo wrote:
> On 16 April 2010 10:39, Niels Breet 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 s
On 16 April 2010 10:39, Niels Breet 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 r
> 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 thi
il 2010 02:46, 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 d
> -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 depen
On Thu, Apr 15, 2010 at 15:21, Graham Cobb 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 aga
> 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
> On Wed, Apr 14, 2010 at 20:00, Niels Breet 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 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
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 pr
> 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
20 matches
Mail list logo
