Description of problem: mate-conf doesn't upddate packages with old rpm srciplet style, This affect all packages which have a mateconf scheme in /etc/mateconf/schemas/* of mate-desktop. During updating a package from external Mate-Desktop repo with old scriplet style, mate-conf doesn't write the sheme to user mateconf directory, or yum shows a scriplet error. It is necessary to stop bulding Mate packages for f16/fc17 and removing all packages from bodhi for f16/f17, until this error ist fixed. In general updating the external repo is a bad idea, because i'm shure we will run in other errors, imo. This issue affect 40% of all planned packages of Mate-Desktop. And this is a minimal desktop version. Version-Release number of selected component (if applicable): How reproducible: Install external Mate-Desktop repo and try to update these packages > -- mate-vfs > -- libmate > -- libmatekbd > -- libmateweather > -- mate-file-manager > -- mate-notification-daemon > -- mate-window-manager > -- mate-control-center > -- mate-panel > -- mate-session-manager > > Packages are needed for a working Desktop which aren't in wiki page. > -- mate-screen-saver (for a working lock screen command) > -- mate-system-monitor > -- mate-utils (for sceenshot command)
i would concur with Wolfgang here, that this ought to be considered a blocker before doing any more f16/f17 mate-related updates. Hopefully, it can be sorted out. In the meantime, moving forward with f18+ builds can and should go on unhindered. A compromise could be to put f16/f17 builds for testing/feedback on repos.fedorapeople.org (ie, let folks explicitly test by opting-in), but that also means someone needs to do the work to make that happen. From my discussions with Wolfgang (correct me if I'm wrong), his current focus is f18+ and for f16/f17 on his current 3rd-party repo... which means putting this onto fedorapeople.org isn't a priority for him to do. I could help implement it, if that sounds agreeable.
My proposal: Stop building MATE packages for f16/17. I don't expect to get MATE fully working in the current and previous versions of Fedora. We should concentrate the effort to f18. Once f18 becomes gold in some weeks, f16 becomes deprecated for new packages anyway. This could avoid problems with updates from the external to the official repo (hopefully). In general I'm not a friend of external repos. Have a look at the recent review requests, and you see what I mean. Some years ago I've built packages for Mandriva, for the external repo at mandrivauser.de. There was only one rule: If it works, and some users (or at least one user) can confirm this, then all is fine. Not the best way to get high-quality, conveniently maintainable packages. Nowadays I wouldn't do this anymore. As a workaround, the external repo should contain a hint that direct updates are not recommended. And that means, it will be useless to keep pushing packages for Fedora <f18 because due to less time we won't be able to provide a complete MATE desktop ever.
First error message from user. http://forums.mate-desktop.org/viewtopic.php?f=8&t=594&p=2004#p2004
Build requires should be as follows: mate-common mate-conf-devel mate-vfs libmatecomponent-devel libcanberra-devel GConf2 (unless we are using mateconf here?) ============================================================================== Build/install sections should look like this: %build %configure -disable-static --disable-schemas --disable-esd make %{?_smp_mflags} V=1 =========================================================================== Needs to be here for schemas: %pre %gconf_schema_prepare *.schemas =========================================================================== %install export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 make DESTDIR=%{buildroot} install %find_lang %{name} rm -rf %{buildroot}/%{_libdir}/matecomponent/monikers/*.la =========================================================================== Please own the proper dirs: %{_datadir}/gtk-doc/html/libmate/ %{_includedir}/libmate-2.0/ {_datadir}/mate-background-properties/mate-default.xml sysconfdir should look like this: pretty simple. Please change %config directive to the following: %config(noreplace) %{_sysconfdir}/sound/events/mate.soundlist %config(noreplace) %{_sysconfdir}/sound/events/gtk2-mate-events.soundlist These should be OK in the main package: %{_libdir}/matecomponent/monikers/libmoniker_extra_2.so %{_libdir}/matecomponent/servers/MATE_Moniker_std.server ============================================================================ Please change the following: %{_bindir}/* to: %{_bindir}/mate-open ============================================================================== Belongs in -devel (obviously) %{_libdir}/pkgconfig/libmate-2.0.pc ======================
http://vicodan.fedorapeople.org/matespec/libmate.spec Here's a copy of my spec file, (yeah I know it still needs work, but hope it will help you.)
Also successful koji build on F17 both arches: http://koji.fedoraproject.org/koji/taskinfo?taskID=4408052
Sorry, that should have gone under libmate review bug. Excuse me.
Please do not use GConf2 and use the following macros for mate-conf In your %install section use the following: %install export MATECONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 I also highly suggest using %{buildroot} over $RPM_BUILD_ROOT unless absolutely required. i.e. make DESTDIR=%{buildroot} install %pre: %mateconf_schema_prepare %post: %mateconf_schema_upgrade %postun: %mateconf_schema_remove For example: %pre %mateconf_schema_prepare control-center %mateconf_schema_prepare fontilus %mateconf_schema_prepare mate-control-center %post %mateconf_schema_upgrade control-center %mateconf_schema_upgrade fontilus %mateconf_schema_upgrade mate-control-center %postun %mateconf_schema_remove control-center %mateconf_schema_remove fontilus %mateconf_schema_remove mate-control-center Please also note that 3rd party repos are not supported here. Thanks, Dan
one more comment, I suspect one possible cause of the failure here is faulty scriptlets in the older packages, that don't save state of the older schemas so that they can be properly unregisterred on upgrades.
(In reply to comment #9) > one more comment, I suspect one possible cause of the failure here is faulty > scriptlets in the older packages, that don't save state of the older schemas > so that they can be properly unregisterred on upgrades. One speculation has nothing to do with facts, unfortunately. eg: old mate-filemanager (caja) scriplet part %post /sbin/ldconfig %{_bindir}/update-mime-database %{_datadir}/mime &> /dev/null export MATECONF_CONFIG_SOURCE=`mateconftool-2 --get-default-source` mateconftool-2 --makefile-install-rule %{_sysconfdir}/mateconf/schemas/apps_caja_preferences.schemas > /dev/null || : touch --no-create %{_datadir}/icons/mate >&/dev/null || : %pre if [ "$1" -gt 1 ]; then export MATECONF_CONFIG_SOURCE=`mateconftool-2 --get-default-source` mateconftool-2 --makefile-uninstall-rule %{_sysconfdir}/mateconf/schemas/apps_caja_preferences.schemas > /dev/null || : fi %preun if [ "$1" -eq 0 ]; then export MATECONF_CONFIG_SOURCE=`mateconftool-2 --get-default-source` mateconftool-2 --makefile-uninstall-rule %{_sysconfdir}/mateconf/schemas/apps_caja_preferences.schemas > /dev/null || : fi %postun /sbin/ldconfig if [ $1 -eq 0 ]; then touch --no-create %{_datadir}/icons/mate >&/dev/null || : gtk-update-icon-cache %{_datadir}/icons/mate >&/dev/null || : fi see: https://fedoraproject.org/w/index.php?title=Packaging%3AScriptletSnippets&diff=157059&oldid=125154
Exactly, what you posted essentially validates my claim. Or did I miss something?
OK, so we have some choices: * identify/fix bugs in /etc/rpm/macros.mateconf * don't use macros.mateconf and switch to something else Suggestions?
(In reply to comment #11) > Exactly, what you posted essentially validates my claim. > > Or did I miss something? Sorry. this old scriplet style is correct. If you see an error post it. As i said it in my first post updating from old style to new style is impossible.
You didn't explain that it was impossible, simply that there's some sort of bug. I'll confer with the packaging committee and author of the existing GConf2 scriptlet guidelines for advice.
Update of desktop-file-utils and rebuild of mate-conf package should fix this.
mate-conf-1.4.0-17.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mate-conf-1.4.0-17.fc17
mate-conf-1.4.0-17.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mate-conf-1.4.0-17.fc18
Package mate-conf-1.4.0-17.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing mate-conf-1.4.0-17.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-13407/mate-conf-1.4.0-17.fc17 then log in and leave karma (feedback).
mate-conf-1.4.0-18.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/mate-conf-1.4.0-18.fc18
mate-conf-1.4.0-18.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mate-conf-1.4.0-18.fc17
Correction to last post. It should look like this: http://vicodan.fedorapeople.org/matespec/libmate.spec
mate-conf-1.4.0-19.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mate-conf-1.4.0-19.fc17
mate-conf-1.4.0-20.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/mate-conf-1.4.0-20.fc17