Latest upstream release: 4.2
Current version/release in Fedora Rawhide: 4.1-2.fc22
Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy
More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring Soon this service will be implemented by a new system: https://github.com/fedora-infra/anitya/
It will require to manage monitored projects via a new web interface. Please make yourself familiar with the new system to ease the transition.
> Dear package maintainers! We will be releasing RawTherapee-4.2 this Friday, 2014-10-24. Please take a minute to read this announcement.
> Please make your builds use cache and config folders called just "RawTherapee" without any version suffix. This can be done by setting the following cmake option:
> In the past we requested that a clean cache and config folder is created by appending the RawTherapee version. We hope that that move has accomplished its purpose, and now strive to offer a seamless and stable upgrade process to users by re-using these files.
> See issue 2427 for a discussion.
> You may optionally want to make the installer check for the existence of any RawTherapee cache and config folder, and, if one is found, inform the user that they can simply copy over the contents from e.g. ~/.config/RawTherapee-4.1 to ~/.config/RawTherapee
> At the same time it would be good to point them to RawPedia so they can find out how to fix crashes on startup and how to write useful bug reports.
> We will also be shipping a rawtherapee.appdata.xml file. See the freedesktop.org AppData page, and issue 2512. Do with it as you will!
The DCACHE_NAME_SUFFIX request differs slightly from the previous one (see bug #1094722). The optional check for existing cache and config is obviously something that we can't really do (although I guess we could add a startup script).
We should include the appdata file --- see https://fedoraproject.org/wiki/User:Rhughes/DraftAppDataGuidelines (that draft is approved but just not yet in the guidelines)
(It'd be kind of cool to have this make the f21 freeze in two weeks, btw)
So, I noticed that in my own home directory, I have a ~/.config/RawTherapee4.1 (as requested last time around), and also ~/.config/RawTherapee from who knows how long ago. (Well, at least two years.) I bet I'm not unique in this, and this seems like the worst possible outcome -- not only will I not get my 4.1 settings, I *will* jump back to whatever it was two years ago for the ancient version.
I added a comment about this to the upstream discussion at https://code.google.com/p/rawtherapee/issues/detail?id=2427 ... unsure of what the right actual really is here.
In any case, I'm submitting a build in rawhide following the upstream request. We should decide if we want that for F21, or if we want to do something else.
oooh. that doesn't build. if someone with time to debug the build would like to help, that'd be awesome.
Any news about the version 4.2? For Ubuntu it is available, why not for Fedora?
Jan, see above. Did not build, and I didn't have time to diagnose. #helpwanted
See build log here: https://kojipkgs.fedoraproject.org//work/tasks/2545/9182545/build.log
Looks like the issue is related to strict aliasing
Okay, got the problems worked out. Builds coming soon for Rawhide and F22. Because of the config issue (comment #4), I don't think we should update existing releases.
mattdm's rawtherapee-4.2-6.fc23 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=623387
rawtherapee-4.2-6.fc22 has been submitted as an update for Fedora 22.
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rawtherapee-4.2-6.fc22'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
rawtherapee-4.2-6.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.