On 28-09-13 11:15, Graham Inggs wrote: >> Could you please tag bug 412811 (new upstream version) as wont-fix if >> you still believe it is not fixable (please check). > > I did check on this with the previous maintainer and I intend to get the > opinion of debian-legal on how to proceed. It may be possible to simply > remove the offending example and release the new version. What I intended you to do is to state the above also in bug 412811, so that it is clear for people looking at that bug report. And when you communicate with debian-legal, make sure the bug is in CC. >> And could you please at least comment on bug 173709 (crashing examples). >> (moreinfo unreproducible are possible tags). Might even belong in dx >> instead of dxsamples. > > I did have a brief look at this and found there is a small number of > samples that require scripts to be run or interactors to be built > first. One of the samples in the bug report, supervise/complexdemo, is > one of these. It may be that the reporter did not follow the > instructions in the Readme. Same as above, please post this information to that bug report. And don't forget that follow ups to bug reports don't automatically go to the submitter. I have often made that mistake before somebody told me. > dxsamples includes two symlinks: > usr/share/dx/samples usr/lib/dx/samples > usr/share/dx/java usr/lib/dx/java These directories don't exist, am I (and lintian) right? So why do you even want these symlinks? Speculating now, but maybe this was something from the past. > I feel it would be better if these were moved to the dx package as dx is > only recommended by dxsamples Does that seem reasonable? If we still need them, yes. Else just drop them. But you forgot to Breaks: dxsamples (<< 4.2.0-2) Replaces: dxsamples (<< 4.2.0-2) in dx. See policy 7.6.1 [1] [1] http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces > For the small number of samples that require interactors to be built, I > feel that dxsamples needs a suggests on libdx4-dev or the virtual > package dx-dev. Does that seem reasonable, and which is preferred? As you provide dx-dev, I prefer that, but I can live with your current choice. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature