Re: Looking sponsor for my package - Osmose Emulator
>Was the Debian 0.9.96 source modified directly instead of being
>patched during packaging? I'd have to double check, but I believe
>strycore committed the pristine upstream version as first commit in
>the lutris fork - I would have assumed the Debian version would be the
>same (modulo line endings fixing maybe) with own patches in
my bad, yes they have its own patches
(when you do apt-get source patches are applied automatically)
so you might want to see patches directly
>At any rate, though it's more cumbersome, it's still interesting to
>see what changes were made in Debian directly to the 0.9.96 and see if
>some are still relevant to merge on top of 0.9.97. But I reiterate
>that using proper patches for each change (e.g. unbundling unzip)
>would have been better practice for the changes history (though I
>guess I might find those as commits in the Debian git repo if there's
>one, I'll have a look).
I think patches are the only way...
>Note that as mentioned, the 0.9.96 version is the unmodified version
>from the original author. For the sake of history and making clear
>what changes were made by different author and new maintainers, I
>believe it's always best to start from the original source, and apply
>changes as patches/commits.
they were indeeed
>I did fix the line endings in the whole repo back in January:>https://github.com/lutris/osmose/commit/079de6321645a2a23c3ef3fda1af9dbfd6b4bd02
>But of course that only applies to the later commits, including
>version 0.9.97, and not to the original version 0.9.96.
>This is definitely helpful, I'll have a closer look at your patches
>when I'm home. As for the workflow, since Carlos' fork sadly lacks
>history, I think I'll just copy his 1.0 files on top of the master
>branch of the lutris fork (which is the same commit as our 0.9.97) and
>see from there what would be the extent of the changes that need to be
>merged. Once identified, it would probably be best for the sake of
>authorship that Carlos (if he agrees) makes a pull request with
>distinct commits for each relevant change.
this would be the best way indeed
>Then we can release a new version after some QA testing has been done.
thanks, as versioning we can use 1.0.whatever
or bump epoch and start again from a lower version.
your choice :)
(BTW the current 1.0 is not building on armhf and armel machines)
maybe while cherry-picking you might take in consideration such failures?
thanks a lot,