maemo.org Bugzilla – Bug 5674
Autobuilder fails to use opt-ified packages
Last modified: 2010-03-15 20:57:12 UTC
You need to
before you can comment on or make changes to this bug.
STEPS TO REPRODUCE THE PROBLEM:
Submit a package that uses an optified package as a dependancy.
dpkg: error processing <optified package> (--unpack):
trying to overwrite `/opt', which is also in package base-files
EXTRA SOFTWARE INSTALLED:
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.
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168)
Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729) FirePHP/0.3
Fixed. Please find details in this thread:
Niels, I tried to reassign this bug to myself, but bugzilla doesn't allow me to
do that. So, please make it fixed.
I suppose the official SDK rootstraps need to be fixed? Will there be a new
rootstrap release with the fix?
(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?
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
+++ /scratchbox/tools/lib/python2.3/sb/config.py 2009-11-30
@@ -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",
+ if os.spawnv(os.P_WAIT, bin, [bin, "xfz", path, "-C", root, "--exclude",
"./dev/*", "--exclude", "./opt"]):
raise Error("Failed to extract rootstrap: " + path)
But as I said, I think simply removing the opt symlink from the next rootstrap
releases is cleaner.
(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
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?
*** Bug 6471 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> shall we reopen this until the internal one is fixed?
This has been internally fixed in upstart 0.3.8-59.
Awaiting internal verification before closing this as FIXED.
This has been fixed in package
which is part of the internal build version
(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
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
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).