Hi,
On Friday, 10 July 2015 at 09:35, Germano Massullo wrote:
Hi, I am Caterpillar, yesterday we were speaking about Darktable and Rawspeed on Freenode. I have a question: if Darktable's Rawspeed fork will be accepted to be included in Fedora's repos, would it be possible to call it "darktable-rawspeed" to distinguish and divide it from upstream Rawspeed?
Well, ideally there should be just one canonical version of Rawspeed and it should come from the canonical upstream. Using a fork is allowed if original upstream is dead or unresponsive to bug reports, if it's compatible and if other projects have switched to it as well.
I have provided some comments in your issue report on rawspeed's github: https://github.com/klauspost/rawspeed/issues/109
Could you please do the same in your report on darktable's redmine? I don't have an account there. http://redmine.darktable.org/issues/10582
Regards, Dominik
Hi, On Sex, 2015-07-10 at 12:48 +0200, Dominik 'Rathann' Mierzejewski wrote:
Hi,
On Friday, 10 July 2015 at 09:35, Germano Massullo wrote:
Hi, I am Caterpillar, yesterday we were speaking about Darktable and Rawspeed on Freenode. I have a question: if Darktable's Rawspeed fork will be accepted to be included in Fedora's repos, would it be possible to call it "darktable-rawspeed" to distinguish and divide it from upstream Rawspeed?
Well, ideally there should be just one canonical version of Rawspeed and it should come from the canonical upstream. Using a fork is allowed if original upstream is dead or unresponsive to bug reports, if it's compatible and if other projects have switched to it as well.
FYI rawstudio bundles rawspeed , because rawspeed isn't available on Fedora , but upstream of rawspeed is not dead [1] One of my goals was update rawspeed [2] on rawstudio , maybe the best was packaging rawspeed or a fork I don't know . I can help on a package review ...
[1] https://github.com/klauspost/rawspeed [2] https://github.com/rawstudio/rawstudio/issues/5
I have provided some comments in your issue report on rawspeed's github: https://github.com/klauspost/rawspeed/issues/109
Could you please do the same in your report on darktable's redmine? I don't have an account there. http://redmine.darktable.org/issues/10582
Regards, Dominik
Thanks,
Hi,
On Friday, 10 July 2015 at 17:56, Sérgio Basto wrote:
On Sex, 2015-07-10 at 12:48 +0200, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 10 July 2015 at 09:35, Germano Massullo wrote:
Hi, I am Caterpillar, yesterday we were speaking about Darktable and Rawspeed on Freenode. I have a question: if Darktable's Rawspeed fork will be accepted to be included in Fedora's repos, would it be possible to call it "darktable-rawspeed" to distinguish and divide it from upstream Rawspeed?
Well, ideally there should be just one canonical version of Rawspeed and it should come from the canonical upstream. Using a fork is allowed if original upstream is dead or unresponsive to bug reports, if it's compatible and if other projects have switched to it as well.
FYI rawstudio bundles rawspeed , because rawspeed isn't available on Fedora , but upstream of rawspeed is not dead [1] One of my goals was update rawspeed [2] on rawstudio , maybe the best was packaging rawspeed or a fork I don't know . I can help on a package review ...
[1] https://github.com/klauspost/rawspeed [2] https://github.com/rawstudio/rawstudio/issues/5
So, we have two consumers of rawspeed: rawstudio and darktable. It's pretty clear that rawspeed must be unbundled, then, and from both. Rawspeed upstream says that darktable's fork contributes back regularly and the only change is disabling support for certain cameras not supported by darktable. I wonder why this is a problem for darktable.
Germano, could you ask darktable developers what the changes are between their fork and canonical rawspeed upstream? Please also produce a diff and post it somewhere.
I have provided some comments in your issue report on rawspeed's github: https://github.com/klauspost/rawspeed/issues/109
Judging by last comment, upstream is receptive to the idea of at least adding an option to build rawspeed as a library (i.e. patches welcome).
Could you please do the same in your report on darktable's redmine? I don't have an account there. http://redmine.darktable.org/issues/10582
If darktable's rawspeed fork is ahead of rawspeed proper then one option would be to refrain from updating until their patches are accepted by rawspeed upstream.
Regards, Dominik
Il 10/07/2015 18:24, Dominik 'Rathann' Mierzejewski ha scritto:
Could you please do the same in your report on darktable's redmine? I don't have an account there. http://redmine.darktable.org/issues/10582
Done
If darktable's rawspeed fork is ahead of rawspeed proper then one option would be to refrain from updating until their patches are accepted by rawspeed upstream.
Regards, Dominik
A little piece of #darktable Freenode channel chat of yesterday, concerning the proposal of Fedora shipping Rawspeed as static library
================
[20:59] <houz> Germano: there are 2 cases that can go wrong: [20:59] <houz> 1) fedora ships a copy of rawspeed that is older than what we expect. the result is missing camera support compared to our release notes [20:59] <pmjdebruijn> which is bound to happen, since upstream rawspeed usually lags significant behind compared to ours [21:00] <houz> 2) fedora ships a newer version of rawspeed than what we expect. in that case rawspeed will allow loading raw formats that dt doesn't expect and misses support for [21:00] <pmjdebruijn> leading to potentially broken history stacks [21:00] <pmjdebruijn> which will impact user data essentially [21:00] <houz> and yes, there is 3) our copy of rawspeed is more a fork that gets synced back and forth than just a copy. actual work is done in our copy [21:22] <Germano> I am sure somebody will say: "uh can't they just submit their Rawspeed changes to upstream and then wait for an upstream version being released and use it?" [21:23] <houz> yes, we could. and stop releasing every 2 months or so ================
Il 10/07/2015 21:49, Sérgio Basto ha scritto:
On Sex, 2015-07-10 at 21:43 +0200, Germano Massullo wrote:
as static library
why static ?
From: https://fedorahosted.org/fpc/ticket/550#comment:3
* ACTION: Rawspeed is way too big/active to be a copylib. Make a static library. (geppetto, 16:32:45) * ACTION: Also rawspeed needs to unbundle pugixml (geppetto, 16:33:01)
On 07/10/2015 02:05 PM, Germano Massullo wrote:
Il 10/07/2015 21:49, Sérgio Basto ha scritto:
On Sex, 2015-07-10 at 21:43 +0200, Germano Massullo wrote:
as static library
why static ?
From: https://fedorahosted.org/fpc/ticket/550#comment:3
- ACTION: Rawspeed is way too big/active to be a copylib. Make a static library. (geppetto, 16:32:45)
- ACTION: Also rawspeed needs to unbundle pugixml (geppetto, 16:33:01)
The second action will require rawspeed to be shared unless a static pugixml is made.
On Fri, Jul 10, 2015 at 09:43:42PM +0200, Germano Massullo wrote:
[21:22] <Germano> I am sure somebody will say: "uh can't they just submit their Rawspeed changes to upstream and then wait for an upstream version being released and use it?" [21:23] <houz> yes, we could. and stop releasing every 2 months or so
This seems very typical of a lot of good, popular open source software these days, and it also seems like a reasonable argument. Unlike the worst scenarios, here at least both versions are actively updated. I think we need to figure out how to be more flexible here (both in this case and in general).
Il 10/07/2015 18:24, Dominik 'Rathann' Mierzejewski ha scritto:
Please also produce a diff and post it somewhere.
diff of subfolders - Rawspeed - data from - https://github.com/darktable-org/darktable/tree/master/src/external/rawspeed - https://github.com/klauspost/rawspeed
here -> http://pastebin.com/1mGaaNGc
Reply from Pascal, one of the Darktable upstream developers http://redmine.darktable.org/issues/10582#note-5
On Saturday, 11 July 2015 at 18:25, Germano Massullo wrote:
Reply from Pascal, one of the Darktable upstream developers http://redmine.darktable.org/issues/10582#note-5
Thanks. What I don't understand is why they're so opposed to the shared library idea. Why is camera support application-specific?
Regards, Dominik
Il 12/07/2015 01:20, Dominik 'Rathann' Mierzejewski ha scritto:
On Saturday, 11 July 2015 at 18:25, Germano Massullo wrote:
Reply from Pascal, one of the Darktable upstream developers http://redmine.darktable.org/issues/10582#note-5
Thanks. What I don't understand is why they're so opposed to the shared library idea. Why is camera support application-specific?
For all other readers: answer has been posted here just a few hours ago https://github.com/klauspost/rawspeed/issues/109#issuecomment-120668893
Dominik, your statement in github comment: <<a temporary (let's say 2 Fedora releases ~= 1 year) bundling exception could get a majority vote in favour. The issue would be revisited in 1 year and we would see where the three projects stand.>>
does it mean: - Fedora Packaging Committee will consider again the question next year and meanwhile the main mantainer and I have to stop releasing further Darktable updates; or - did you simply wanted to tell Darktable and Rawspeed developers that every year the Fedora Packaging Committee has to verify again if there are the conditions for an exception
?
I am posting a new diff made by Pedro (Darktable one of developers) because he said that the diff I posted does not reflect the actual Darktable&Rawspeed development https://gist.github.com/pedrocr/887cdd089bc262a3b2f0
Hi, Germano.
On Sunday, 12 July 2015 at 10:42, Germano Massullo wrote:
Il 12/07/2015 01:20, Dominik 'Rathann' Mierzejewski ha scritto:
On Saturday, 11 July 2015 at 18:25, Germano Massullo wrote:
Reply from Pascal, one of the Darktable upstream developers http://redmine.darktable.org/issues/10582#note-5
Thanks. What I don't understand is why they're so opposed to the shared library idea. Why is camera support application-specific?
For all other readers: answer has been posted here just a few hours ago https://github.com/klauspost/rawspeed/issues/109#issuecomment-120668893
Dominik, your statement in github comment: <<a temporary (let's say 2 Fedora releases ~= 1 year) bundling exception could get a majority vote in favour. The issue would be revisited in 1 year and we would see where the three projects stand.>>
does it mean:
- Fedora Packaging Committee will consider again the question next year
and meanwhile the main mantainer and I have to stop releasing further Darktable updates; or
- did you simply wanted to tell Darktable and Rawspeed developers that
every year the Fedora Packaging Committee has to verify again if there are the conditions for an exception
?
Neither. It means that I'll bring up the issue during the next meeting and ask the other FPC members to reconsider the bundling exception, given that two out of three upstreams are receptive to the idea of making rawspeed a shared library. I'll recommend a two-release temporary exception.
Could somebody contact rawstudio upstream about this as well?
Regards, Dominik
(FAS) Giallu asked me to contact Rawstudio upstream developer. https://github.com/rawstudio/rawstudio/issues/6
On Seg, 2015-07-13 at 18:17 +0200, Germano Massullo wrote:
(FAS) Giallu asked me to contact Rawstudio upstream developer. https://github.com/rawstudio/rawstudio/issues/6
Hi, where is rawspeed package ? we need package it first no ?
I look at rawspeed seems to me that almost all data ... Rawstudio upstream developer ( abrander ) is a little unresponsive , I'm the packager of rawstudio in Fedora so maybe I can help
Thanks,
Il 13/07/2015 18:41, Sérgio Basto ha scritto:
On Seg, 2015-07-13 at 18:17 +0200, Germano Massullo wrote:
(FAS) Giallu asked me to contact Rawstudio upstream developer. https://github.com/rawstudio/rawstudio/issues/6
Hi, where is rawspeed package ? we need package it first no ?
The answer is hereunder
Il 13/07/2015 00:06, Dominik 'Rathann' Mierzejewski ha scritto:
[*cut*] Neither. It means that I'll bring up the issue during the next meeting and ask the other FPC members to reconsider the bundling exception, given that two out of three upstreams are receptive to the idea of making rawspeed a shared library. I'll recommend a two-release temporary exception.
Could somebody contact rawstudio upstream about this as well?
On Seg, 2015-07-13 at 19:08 +0200, Germano Massullo wrote:
Il 13/07/2015 18:41, Sérgio Basto ha scritto:
On Seg, 2015-07-13 at 18:17 +0200, Germano Massullo wrote:
(FAS) Giallu asked me to contact Rawstudio upstream developer. https://github.com/rawstudio/rawstudio/issues/6
Hi, where is rawspeed package ? we need package it first no ?
The answer is hereunder
Hi, Sorry for my bad English , I already ask that in upstream https://github.com/rawstudio/rawstudio/issues/5
But what I'm trying to point out is to use rawspeed as external lib , we need pack rawspeed first , so let do that first . Where is rawspeed package ?
Il 13/07/2015 00:06, Dominik 'Rathann' Mierzejewski ha scritto:
[*cut*] Neither. It means that I'll bring up the issue during the next meeting and ask the other FPC members to reconsider the bundling exception, given that two out of three upstreams are receptive to the idea of making rawspeed a shared library. I'll recommend a two-release temporary exception.
Could somebody contact rawstudio upstream about this as well?
-- packaging mailing list packaging@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/packaging
On Seg, 2015-07-13 at 18:32 +0100, Sérgio Basto wrote:
On Seg, 2015-07-13 at 19:08 +0200, Germano Massullo wrote:
Il 13/07/2015 18:41, Sérgio Basto ha scritto:
On Seg, 2015-07-13 at 18:17 +0200, Germano Massullo wrote:
(FAS) Giallu asked me to contact Rawstudio upstream developer. https://github.com/rawstudio/rawstudio/issues/6
Hi, where is rawspeed package ? we need package it first no ?
The answer is hereunder
Hi, Sorry for my bad English , I already ask that in upstream https://github.com/rawstudio/rawstudio/issues/5
But what I'm trying to point out is to use rawspeed as external lib , we need pack rawspeed first , so let do that first . Where is rawspeed package ?
https://github.com/rawstudio/rawstudio/blob/master/plugins/load-rawspeed/Mak... https://github.com/klauspost/rawspeed#getting-source-code https://github.com/darktable-org/darktable/blob/master/src/external/rawspeed...
Are any one working on packaging rawspeed ? it is not in my priorities (packaging rawspeed) right now ...
Il 13/07/2015 00:06, Dominik 'Rathann' Mierzejewski ha scritto:
[*cut*] Neither. It means that I'll bring up the issue during the next meeting and ask the other FPC members to reconsider the bundling exception, given that two out of three upstreams are receptive to the idea of making rawspeed a shared library. I'll recommend a two-release temporary exception.
Could somebody contact rawstudio upstream about this as well?
Best regards,
Hi,
On Monday, 13 July 2015 at 20:17, Sérgio Basto wrote:
On Seg, 2015-07-13 at 18:32 +0100, Sérgio Basto wrote:
On Seg, 2015-07-13 at 19:08 +0200, Germano Massullo wrote:
Il 13/07/2015 18:41, Sérgio Basto ha scritto:
On Seg, 2015-07-13 at 18:17 +0200, Germano Massullo wrote:
(FAS) Giallu asked me to contact Rawstudio upstream developer. https://github.com/rawstudio/rawstudio/issues/6
Hi, where is rawspeed package ? we need package it first no ?
The answer is hereunder
Hi, Sorry for my bad English , I already ask that in upstream https://github.com/rawstudio/rawstudio/issues/5
But what I'm trying to point out is to use rawspeed as external lib , we need pack rawspeed first , so let do that first . Where is rawspeed package ?
https://github.com/rawstudio/rawstudio/blob/master/plugins/load-rawspeed/Mak... https://github.com/klauspost/rawspeed#getting-source-code https://github.com/darktable-org/darktable/blob/master/src/external/rawspeed...
Are any one working on packaging rawspeed ? it is not in my priorities (packaging rawspeed) right now ...
darktable upstream says [1] it makes no sense, because new/fixed camera support needs changes in both the rawspeed library and any application that uses it. They do see value in abstracting all that logic into a shared library, but that's not a priority for them at the moment. Since rawstudio is using a different version of rawspeed, you'd have to package two different parallel installable versions. That seems like a waste of time and effort, which would be better spent helping both upstreams move the required code into rawspeed library.
[1] https://github.com/klauspost/rawspeed/issues/109#issuecomment-120669126
Regards, Dominik
A few news: Darktable is going to be removed from Fedora official repositories after Fedora Packaging Committee decision: https://fedorahosted.org/fpc/ticket/550#comment:6
You can still use Darktable by enabling my personal Copr repository: # dnf copr enable germano/darktable # dnf install darktable Fedora should update your existing Darktable without any problem. You can find the two commands also here http://www.darktable.org/install/#fedora
packaging@lists.fedoraproject.org
-
Dominik 'Rathann' Mierzejewski -
Germano Massullo -
Matthew Miller -
Orion Poplawski -
Sérgio Basto