Bug 5674 - (int-140665) Autobuilder fails to use opt-ified packages
(int-140665)
: Autobuilder fails to use opt-ified packages
Status: RESOLVED FIXED
Product: System software
Upstart
: 5.0/(3.2010.02-8)
: All Maemo
: Medium blocker (vote)
: 5.0/(10.2010.19-1)
Assigned To: unassigned
: upstart-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2009-10-21 20:11 UTC by nathanael
Modified: 2010-03-15 20:57 UTC (History)
6 users (show)

See Also:


Attachments


Note

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


Description nathanael (reporter) 2009-10-21 20:11:09 UTC
SOFTWARE VERSION:

STEPS TO REPRODUCE THE PROBLEM:
Submit a package that uses an optified package as a dependancy.
Example: https://garage.maemo.org/builder/fremantle/sword_1.6.0a-0maemo1/

EXPECTED OUTCOME:
Builds

ACTUAL OUTCOME:
dpkg: error processing <optified package> (--unpack):
 trying to overwrite `/opt', which is also in package base-files

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

OTHER COMMENTS:
Please note the example package given above actually is missing a couple
dependencies in the control file -- so it will actually fail at a (much) later
point in time.   But the package will show the this reported problem.

I can install and used optified packages fine in the sdk/scratchbox.  


Threads:
http://lists.maemo.org/pipermail/maemo-developers/2009-October/021512.html
http://lists.maemo.org/pipermail/maemo-developers/2009-October/021588.html


User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3)
Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3
Comment 1 Ed Bartosh 2009-10-22 09:43:28 UTC
Fixed. Please find details in this thread:
http://lists.maemo.org/pipermail/maemo-developers/2009-October/021588.html

Niels, I tried to reassign this bug to myself, but bugzilla doesn't allow me to
do that. So, please make it fixed.
Comment 2 Anderson Lizardo 2009-11-26 20:02:13 UTC
I suppose the official SDK rootstraps need to be fixed? Will there be a new
rootstrap release with the fix?
Comment 3 Marcell Lengyel maemo.org 2009-11-30 11:41:19 UTC
(In reply to comment #2)
> I suppose the official SDK rootstraps need to be fixed? Will there be a new
> rootstrap release with the fix?

In the SDK the installer script takes care of fixing the rootstrap and in the
autobuilder it is done manually. Is there anything else that needs fixing?
Comment 4 Anderson Lizardo 2009-11-30 13:04:16 UTC
There are people (not only me, I hope) who use sbdmock (same tool used on
autobuilder) to build packages locally. Given that it resets the target and
unpacks the rootstrap on each build, manual fixes are lost and builds again
fail with the problem reported here.

You should also not forget the developers who follow the manual installation
instructions described on the official SDK documentation.

IMHO the best fix is to either (a) fix the rootstraps or (b) patch scratchbox
to do that at the lowest level.

I think (a) is the cleanest and easiest path, but I use the above patch to
scratchbox for now, so I don't need to remember to fix my rootstraps manually:

#####
--- /scratchbox/tools/lib/python2.3/sb/config.py    2009-08-27
10:53:12.000000000 -0400
+++ /scratchbox/tools/lib/python2.3/sb/config.py    2009-11-30
07:02:21.000000000 -0400
@@ -534,7 +534,7 @@

     bin = join(tools_dir, "tar")
     print "Unpacking rootstrap..."
-    if os.spawnv(os.P_WAIT, bin, [bin, "xfz", path, "-C", root, "--exclude",
"./dev/*"]):
+    if os.spawnv(os.P_WAIT, bin, [bin, "xfz", path, "-C", root, "--exclude",
"./dev/*", "--exclude", "./opt"]):
         raise Error("Failed to extract rootstrap: " + path)

     if url:
#####

But as I said, I think simply removing the opt symlink from the next rootstrap
releases is cleaner.
Comment 5 Marcell Lengyel maemo.org 2009-11-30 15:43:22 UTC
(In reply to comment #4)
> There are people (not only me, I hope) who use sbdmock (same tool used on

I see, I was not aware of that.

> autobuilder) to build packages locally. Given that it resets the target and
> unpacks the rootstrap on each build, manual fixes are lost and builds again

On the autobuilder machine, before moving the rootstraps to the right place,
those are unpacked, /opt removed then repacked. This needs to be done just once
per release.

I agree that the best fix would be to fix the rootstrap and there is a bug
report in the internal bugzilla for that. Andre, shall we reopen this until the
internal one is fixed?
Comment 6 Harald Fernengel nokia 2009-12-01 15:24:04 UTC
*** Bug 6471 has been marked as a duplicate of this bug. ***
Comment 7 Andre Klapper maemo.org 2009-12-10 16:31:16 UTC
(In reply to comment #5)
> shall we reopen this until the internal one is fixed?

Yes...
Comment 8 Andre Klapper maemo.org 2010-02-17 21:14:18 UTC
This has been internally fixed in upstart 0.3.8-59.
Awaiting internal verification before closing this as FIXED.
Comment 9 Andre Klapper maemo.org 2010-02-25 18:09:32 UTC
This has been fixed in package
upstart 0.3.8-59+0m5
which is part of the internal build version
10.2010.08-5
(Note: 2009/2010 is the year, and the number after is the week.)

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Comment 10 Andre Klapper maemo.org 2010-03-15 20:57:12 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).