This package is proposed as a backport as it brings many new features that Darktable users might want, but being a new stable branch it does not fit our updates policy (we have 1.6.x in Core Release/Updates). Here are the release announcements for 2.0 and 2.0.1: - http://www.darktable.org/2015/12/darktable-2-0-released/ - http://www.darktable.org/2016/02/darktable-2-0-1-released/ RPM: (core/backports_testing) ==== darktable-2.0.1-1.mga6 SRPM: (core/backports_testing) ===== darktable-2.0.1-1.mga6
mga5 x86_64 Mate Installed darktable-2.0.1-1.mga6 then checked # urpmi darktable Package darktable-2.0.1-1.mga5.x86_64 is already installed Requires were also installed. - lib64osmgpsmap1.0_0-1.0.2-4.mga5.x86_64 - lib64pugixml1-1.4-5.mga5.x86_64 $ urpmq --whatrequires lib64pugixml1 | sort | uniq lib64OpenImageIO1.2 lib64pugixml1 lib64pugixml-devel lib64OpenImageIO1.2 was not already installed. $ urpmq --conflicts lib64OpenImageIO1.2 $ urpmq --conflicts lib64pugixml1 No conflicts. Showing these without really understanding what the conflicts tag actually means but trying to figure out whether this breaks backports policy or not. I guess not because lib64pugixml1 is current in Core Updates. The maintenance release version of darktable installed earlier pulled in lib64osmgpsmap2. $ cd /usr/lib64 $ ls *osmgp* libosmgpsmap-1.0.so.0 libosmgpsmap.so.2 libosmgpsmap-1.0.so.0.0.0 libosmgpsmap.so.2.0.1 Opened up the interface and found the collection already imported. Moved to the darkroom to try out several of the functions. Everything working properly.
CC: (none) => tarazed25
Keywords: (none) => BackportWhiteboard: (none) => MGA5-64-OK
mga5 i586 in virtualbox Mate Updated the backport candidate and tried it out. It seems to function alright in spite of the dire warnings about using a 32-bit build and in spite of the fact that this test ws executed in a vbox with restricted memory and cpu power.
Whiteboard: MGA5-64-OK => MGA5-64-OK MGA5-32-OK
Moved to backports
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED