Re: flashcache - call for resolution / seeking for a mentor
Hi Andrey,
>> > What is "This has to be exported to make some magic below work." (before
>> > 'export DH_OPTIONS')?
>> Hmm, apparently a remnants after dh_make
> No, looks like a blind copy-paste.
Fair enough, that could be the case of momentarily blindness of mine. :)
>
>> > If "At the moment this version works only on x86_64 a.k.a. amd64" why
>> > Architecture: linux-any?
>> That is an interesting question.
>> We believe that upstream may eventually fix that.
>>
>> I remember reading discussion on this some time ago, regarding
>> different package with similar problem.
>> It was suggested that limiting package for the only architecture as
>> workaround for upstream bugs is not recommended
>> because package may be ported to a different architecture etc. I had
>> impression that if package meant to be useful on linux-any
>> it should be a target architecture despite know problems with some
>> particular architectures.
>> Please correct me on this - what's the best practice?
> Why it doesn't work on other architectures? Does it build there? Is the
> not working of a "doesn't launch" kind or "works but sometimes crashes"
> kind? Can it corrupt user data because of this?
When I tried on i686 it compiles but then kernel can't load the module
- see https://github.com/facebook/flashcache/issues/5
(third comment)
>> > The patch lacks author information (did you see
>> > http://dep.debian.net/deps/dep3/ ? it suggests adding other useful
>> > information to patch headers).
>> No I did not - thank you very much for the hint.
> I've asked this because you have Description tag in the patch header.
> Usually manually created patches don't have any metadata at all.
This patch is really unnecessary since the patched Makefile is not used at all.
I should have it removed completely. I did patching with quilt without
enough attention to annotation.
Regards,
Dmitry.
Reply to: