On 31/07/07 13:11 +0300, Lauri Leukkunen wrote:
On 31/07/07 11:56 +0300, ext Marius Vollmer wrote:
That way, all binaries can be replaced that are used a lot during
compilation and are too slow to be emulated: /bin/sh, m4, awk, make,
perl, gcc, binutils, but not much more. Packages like
Lauri Leukkunen [EMAIL PROTECTED] writes:
On 31/07/07 11:56 +0300, ext Marius Vollmer wrote:
Also, both sbox1 and sbox2 redirect whole packages, not just binaries
(if I understand sbox2 correctly). E.g., when redirecting the perl
command, the redirected-to perl will take its modules from the
ext Lauri Leukkunen [EMAIL PROTECTED] writes:
Continuing on the topic of build dependencies, SB2 has an open
design issue regarding them. [...]
I played a bit with sbox2 and I failed in the end, probably because I
didn't use the right toolchain, but while doing that, a picture slowly
formed in
On 31/07/07 11:56 +0300, ext Marius Vollmer wrote:
Also, both sbox1 and sbox2 redirect whole packages, not just binaries
(if I understand sbox2 correctly). E.g., when redirecting the perl
command, the redirected-to perl will take its modules from the
redirected-to prefix, not from the
On Tue, Jul 31, 2007 at 11:56:12AM +0300, ext Marius Vollmer wrote:
Then there would be a way for the user to select whether or not to
make /usr/bin/perl be the armel or i386 version.
I know this sounds like a trite reply, but I have actually read your
entire mail. However:
Sounds like you
On Tue, 2007-07-31 at 13:11 +0300, ext Lauri Leukkunen wrote:
You could take the current emulate mode as a template and start adding
to that your exceptions.
Maybe it's a matter of sb developer's vs sb user's point of view, but I
would rather consider sb to be the exception ...
--
Cheers,
On 31/07/07 13:52 +0300, Igor Stoppa wrote:
On Tue, 2007-07-31 at 13:11 +0300, ext Lauri Leukkunen wrote:
You could take the current emulate mode as a template and start adding
to that your exceptions.
Maybe it's a matter of sb developer's vs sb user's point of view, but I
would rather
Daniel Stone [EMAIL PROTECTED] writes:
Sounds like you want multiarch.
Yes, I know I want multiarch. :) Is it ready?
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
components should be pushed to debian and ubuntu and get those bigger
communities involved in their development. One day we will anyway be
Indeed. When it comes to Hildon that is certainly starting to happen
now.
This should be the default mode for most of the stuff we do. Arguing
ext Andrew J. Barr wrote:
On 7/31/07, Carlos Guerreiro [EMAIL PROTECTED] wrote:
What happens on top of the Maemo platform is a different discussion
altogether.
FWIW, I think that there is a distinction between maemo the platform
and the ITOS firmware that not everyone has grasped.
Lauri, I can see you've been away for too long and missed
some of the action ;-)
That's probably true, but I'm not afraid to raise old issues that may
or may not have been 100% addressed. Worst thing that can happen is
that things are actually not as bad as I thought. I'm just one voice
On Thu, Jul 26, 2007, Xan wrote:
The issue here is: the pc file for hildon-1 hardcodes MAEMO_CHANGES to
1, so anything you build on top of it will get that define. This wan
fine by the time we did it (if you use hildon you surely want all the
stuff and certainly you are using our gtk version),
On Thu, Jul 26, 2007 at 06:59:06PM +0300, ext Xan wrote:
On 7/26/07, Loïc Minier [EMAIL PROTECTED] wrote:
On Thu, Jul 26, 2007, Loïc Minier wrote:
Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE
etc. :)
Updating my own question: this function is within #ifdef
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lauri Leukkunen schreef:
Also note that SB2 is totally not interested in doing x86-x86 development,
like what many people are doing today with SB1. People need to wake up, smell
the coffee, integrate with debian proper and get with the program.
I
Marius Vollmer wrote:
There are two kinds of borders: one kind isolates OSs from each other;
this could be done with some virtualization tool like xen, uml, or
maybe chroot. The other kind isolates different architectures within
the same distribution; this is what SB2 does.
There has been
On 7/26/07, Marius Vollmer [EMAIL PROTECTED] wrote:
From my point of view, the host and target distributions should be as
independent as possible. The host could be Debian, or Redhat, or
Nokia's internal Linux, or OSX, or even Windows.
There are many, many ways to solve this, starting from
On 7/26/07, Loïc Minier [EMAIL PROTECTED] wrote:
On Thu, Jul 26, 2007, Loïc Minier wrote:
Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE
etc. :)
Updating my own question: this function is within #ifdef
MAEMO_CHANGES; does that mean that if we start pulling some
On Thu, Jul 26, 2007, Loïc Minier wrote:
Would be nice if someone could add a #ifdef GDK_CLOSE_ALL_AVAILABLE
etc. :)
Updating my own question: this function is within #ifdef
MAEMO_CHANGES; does that mean that if we start pulling some maemo
changes into Gtk to build hildon (such as the
On 7/26/07, Carlos Guerreiro [EMAIL PROTECTED] wrote:
As long as Nokia works in the current, essentially forked, mode,
nothing will happen. Nokia needs to look at the way it interacts with
upstream projects and change. Sure it can be painful, but hiding
behind a smoke-screen of product
Koen Kooi wrote:
The big problem is that hildon depends on an old, forked version of gtk+ that
nobody in
their right mind wants on their x86 systems. The nokia people at guadec were
unable to
give me an ETA on when that will be fixed :(
Guadec of what year? :P
ext Lauri Leukkunen [EMAIL PROTECTED] writes:
At least it should be possible to build a package for both host and
target distros like this:
cd my_package
dpkg-buildpackage -rfakeroot
sb2 dpkg-buildpackage -rfakeroot
Hmm, I am still quite fuzzy about what SB2 is all about. Maybe you
can
As long as Nokia works in the current, essentially forked, mode,
nothing will happen. Nokia needs to look at the way it interacts with
upstream projects and change. Sure it can be painful, but hiding
behind a smoke-screen of product program priorities is just not
helping to solve the real
On Thu, 2007-07-26 at 10:04 +0200, ext Koen Kooi wrote:
The big problem is that hildon depends on an old, forked version of gtk+ that
nobody in
their right mind wants on their x86 systems. The nokia people at guadec were
unable to
give me an ETA on when that will be fixed :(
Currently the
Hi,
Scratchbox2 can now be found in debian, unstable and testing carry frequently
updated releases of it. I've been going over a number of packages trying
to test it. I think it's pretty good considering the limited amount
of people using it, and the fact that the public maemo rootstraps are an
24 matches
Mail list logo
