Bug 3958 - Build/install tests done with GNU not Busybox
: Build/install tests done with GNU not Busybox
Status: NEW
Product: Development platform
SDK
: 5.0-beta2
: All Windows
: Low normal (vote)
: Harmattan
Assigned To: Mika Luostarinen
: sdk-bugs
:
:
:
: 3938 int-147091
  Show dependency tree
 
Reported: 2008-12-23 23:12 UTC by tz
Modified: 2014-03-08 10:43 UTC (History)
8 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description tz (reporter) 2008-12-23 23:12:22 UTC
SOFTWARE VERSION:
(Control Panel > General > About product)
5.2008.43-7 (perhaps earlier)

STEPS TO REPRODUCE THE PROBLEM:
under scratchbox do:
ls -Q | xargs
on the tablet, do the same

Or just try on the tablet
sh -x /usr/sbin/invokde-rc.d package stop
package can be anything there not being used like supllistenerd or maybe
bluez-utils or metalayer-crawler.

EXPECTED OUTCOME:
same output from ls -Q | xargs
invoke-rc.d stops/starts daemon

ACTUAL OUTCOME:
ls -Q is not valid in busybox.
xargs in busybox does NOT remove quotes as the GNU version does.

invoke-rc.d complains about dangling symlinks for files that exist if you have
added GNU ls and doesn't work.  Using busybox, it misses the symlinks but goes
directly to /etc/init.d instead.

REPRODUCIBILITY:
(always/sometimes/once)
always.

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
The autobuilder and/or whatever Nokia/Maemo uses to check for valid package
install needs to test the installation and removal (the debian
preinst/postinst/prerm/postrm scripts in the main) with the busybox versions of
the tools since those will be what is going to be on the tablet, so things
might fail (perhaps partially and/or silently) which work under the development
environment.

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5)
Gecko/2008120122 Firefox/3.0.5
Comment 1 Eero Tamminen nokia 2008-12-30 15:42:39 UTC
This is not a Busybox bug, but an issue in Maemo Extras (and Nokia internal)
package build checks.  Moving to SDK.

The current SDK doesn't support testing package installation against plain
Busybox, only against the Scratchbox 1 provided GNU tools. Currently Developer
needs to test installation on the device, but if package doesn't work yet
properly, he might actually break it.  Doing this in SDK would be safer.  Also,
the package install checks against Busybox could be easier to automate (in
Extras build queue etc) if SDK would support it.

I think this kind of test setup could be offered by SDK+.
Comment 2 Quim Gil nokia 2009-01-07 17:32:58 UTC
Feedback welcome!

- Does the DP team find this a reasonable report/request?
- If so, can be fixed in Fremantle?
- Is this a Scratchbox1 issue or does it affect also to the Maemo SDK+ based on
SB2?

- And for the bureaucracy, is this a bug or an enhancement request?
Comment 3 Juha Kallioinen nokia 2009-01-07 18:20:31 UTC
(In reply to comment #2)
> Feedback welcome!
> 
> - Does the DP team find this a reasonable report/request?

It's a reasonable request.

With scratchbox1 it would mean creating and maintaining another version of
scratchbox-core, that would be based on busybox and not coreutils. This is a
non-trivial effort.

SDK+ which uses scratchbox2 might be another story and I don't the details of
that.

> - If so, can be fixed in Fremantle?

I don't see this happening for Fremantle since it's still using scratchbox1.

> - Is this a Scratchbox1 issue or does it affect also to the Maemo SDK+ based on
> SB2?

I don't know specifically about sb2. Maybe someone else can enlighten me.

> - And for the bureaucracy, is this a bug or an enhancement request?

It can be seen as either one. Scratchbox is not a perfect duplicate of our
device environment in many other ways either.
Comment 4 Eero Tamminen nokia 2009-01-07 18:30:43 UTC
(In reply to comment #3)
> It's a reasonable request.
> 
> With scratchbox1 it would mean creating and maintaining another version of
> scratchbox-core, that would be based on busybox and not coreutils.

One possibility would be chrooting to the target directory, but then the stuff
bind mounted from elsewhere (dev, home, proc, sys, tmp) would be missing and
mount is an operation that needs to be done as root.

Another possibility could be using System Qemu containing a product release and
testing the installation inside that.  This would require System Qemu working
well enough for this and some way to automatically start it & transfer the
package there.


> SDK+ which uses scratchbox2 might be another story and I don't the details of that.

I think it has a mode that limits path visibility (with exception of /dev &
/proc & /sys I guess) to the target directory, so that could be the easiest
solution.
Comment 5 Andre Klapper maemo.org 2009-03-04 01:31:02 UTC
So Fremantle is planned to still be based on Scratchbox1 I assume...

Juha, are there plans for Harmattan to switch to Scratchbox2 or is this too
early to know?
Comment 6 Quim Gil nokia 2009-03-04 08:19:04 UTC
(In reply to comment #5)
> So Fremantle is planned to still be based on Scratchbox1 I assume...

Yes.

> Juha, are there plans for Harmattan to switch to Scratchbox2 or is this too
> early to know?

There are plans, but not fully committed yet. We will let developers know when
that happens.
Comment 7 Eero Tamminen nokia 2009-03-04 12:59:52 UTC
> So Fremantle is planned to still be based on Scratchbox1 I assume...

Hm. I thought that SDK+ already supports Fremantle, but at least their
documentation for the rootstrap manager doesn't specifically mention Fremantle
alpha rootstraps, so I don't know how well it's tested with Fremantle:
  http://maemo-sdk.garage.maemo.org/maemo-rootstrap.html

(Although SDK+ isn't/wouldn't be official development platform for Fremantle,
nothing should be preventing developers from using SDK+ for that...)
Comment 8 Quim Gil nokia 2009-03-04 13:13:15 UTC
CCing JP, he is involved in the SDK+ project.
Comment 9 Eero Tamminen nokia 2009-03-19 10:04:08 UTC
Ubuntu and Debian are mostly finished in making their scripts (which use
/bin/sh) POSIX compatible.  I think this will help also in making them more
compatible with the Busybox shell, except for bugs in it (which should be just
reported here).

As to somebody writing his own scripts, Debian and Ubuntu offer utility and
instructions on how the make the scripts POSIX compatible (portable), see:
  https://wiki.ubuntu.com/DashAsBinSh

Especially the "checkbashisms" tool from the Debian "devscripts" package could
be useful because it checks the whole script i.e. it's more thorough testing of
the shell syntax than just running a script.  Maybe the Extras build machinery
should start checking the package scripts with "checkbashisms"?

(That still leaves the Busybox command option compatibility to worry about.)
Comment 10 Soumya nokia 2009-04-11 17:08:23 UTC
Re-assigning to Mika, set TM=Harmattan.