Re: RFS: fig2sxd
Hi,
> ... "Debian" changelog, not upstream ...
Hmm. I do not have an upstream changelog, and all previous
debian/changelog entries have the same problem. So what would you
suggest to do:
* Move all debian/changelog entries actually describing upstream changes
to a new upstream-changelog and replace it with "new upstream version"
for all upstream versions (0.1 -- 0.19) in debian/changelog?
* Keep the existing debian/changelog entries and start the upstream
changelog now?
And, as adding a new upstream changelog would mean that the orig.tar.gz
changes:
* Fix it in the next version (0.20) once there are upstream code
changes?
* Fix it now, keep version 0.19 and hide the new upstream changelog
until 0.20-1?
* Add the new upstream changelog via debian's diff.gz? That seems odd.
* Make 0.20 and 0.20-1. What would then be the upstream changelog entry?
> ... currently in freeze... If there is an important problem ...
> ..0.18-1 .. in testing, it is easier to fix it if you can push the fix to
> unstable without pushing additional changes. Otherwise, it would have to
> be uploaded to testing-proposed-updates which causes more work for
> everybody and less possibilities of testing (no "grace" period to ensure
> that a few people test the package).
>
> However, the change is not very large (especially if we ignore
> indentation changes), so in case a fix needs to be pushed, maybe this
> new upstream version would be accepted as well. Therefore, it is up to
> you to upload to unstable (if you think that having a RC bug filed
> against fig2sxd is low probability and even if there is one, the current
> change is likely to be accepted) or to experimental.
Do you want to suggest making the same changes in diff.gz and call it
0.18-2? Probably I do not understand what you actually ask here.
For some people who want to convert huge polylines (the one in the bug
report had > 5500 points) it is certainly helpful -- without, the
program output is correct but unusable. The problem is caused by a bug
in OOo (their bug #95095) which makes OOo read some files generated by
fig2sxd (or whatever other program producing OOo files) incorrectly. The
ideal solution would be to fix the OOo problem and stay with fig2sxd
0.18. Otherwise I think 0.19 should be used in testing, but I do not
expect that this is fast (that's also why I implemented the workaround).
It will continue to work the OOo problem is fixed, and I would not like
to have the program with a known problem in a stable release. As you
say, the actual changes between 0.18 and 0.19 are minor.
I could also make 0.20, where I would fix the changelog problem and add
a few (around 4) lines to print out a warning for the cases without
workaround (i.e. filled polylines/polygons).
Best wishes,
Alexander
Reply to: