maemo.org Bugzilla – Bug 5674
Autobuilder fails to use opt-ified packages
Last modified: 2010-03-15 20:57:12 UTC
You need to log in before you can comment on or make changes to this bug.
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
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.
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 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.
(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?
*** 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? Yes...
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 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/
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).