check out bug #29889 for a reference Additionally, try emerging media-sound/bpmdj-2.0.1 I believe these bugs are relevant as well #37997, #39572 You closed #39572 stating that the sandbox problem was fixed, but I don't see a new version of qt, anc the ChangeLog doesn't note the fix. Did you forget to commit? Setting blocker as this version of qt breaks portage QA.
I don't know of anyway to reconfigure the uic to not exhibit this behavior. The only fix is putting addwrites in the ebuilds affected, unless you have another idea?
uic's source should be modified to use a safe location such as /var/tmp/ I think it is unreasonable to expect addwrites in evert qt-dependant ebuild that didn't require them before this version. I would say it would be reasonable for new packages, but this breaks QA with currently existing packages... Another option could be to throw /usr/qt/*/etc/settings into the default read/write/predict in ebuild.sh.
The problem appears to be in QSettings::sync()... I'm debugging this now, and hopefully I'll get you a patch later tonight: QSettings::sync: failed to open '/usr/qt/3/etc/settings/qt_plugins_3.3rc.tmp' for writing
ok... this isn't a great fix, but it'll have to do for now... at line 936 of src/tools/qsettings.cpp: if (! d->modified) // fake success return TRUE; change it to: if ((! d->modified) || (strcmp(getenv("SANDBOX_ON"), "1") == 0)) // fake success return TRUE; You need #include <stdlib.h> at the top, too... The real fix should be in finding out why d->modified gets set to true when all uic calls is: QSettings config; config.insertSearchPath( QSettings::Windows, "/Trolltech" ); QStringList pluginPaths = config.readListEntry( keybase + "PluginPaths" ); Sorry I don't have any more time to look into this in more detail...
I believe it's also possible to override QSettings using the SYSCONF variable, but don't hold me to that.
the problem is that will override the settings directory everywhere... whereas we just don't want to write to it here...
emerge dev-db/tora-1.3.12 failes with the following messages: -----------ACCESS VIOLATION------------- open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock ... open_wr: /usr/qt/3/etc/settings/.qt_plugins_3.3rc.lock may this be caused by this bug?
Actually, the conditional should be: if ((! d->modified) || (getenv("SANDBOX_ON") && (strcmp(getenv("SANDBOX_ON"), "1") == 0)))
as a followup comment, ebuilds that use the "need-qt" function should get the addwrite set for them automatically.
alright... I believe that is sufficient... I'm going to close this, since I'm the reporter... but if someone has a better solution than that, please feel free to reopen...
