On Fri, Mar 18, 2011 at 14:01, Andreas Tille <[email protected]> wrote: > Cool. :-) I detected the problem when traveling to LinuxTage Chemnitz > event when I spent some time into dicompyler packaging. This problem > is solved now.
Glad to know I wasn't the only one who noticed it. > I have some minor issue: > > W: dicompyler: executable-not-elf-or-script > ./usr/share/dicompyler/resources/*.png > W: dicompyler: macos-ds-store-file-in-package > usr/share/dicompyler/resources/.*DS_Store > > While I could perfectly fix these cosmetical issues in the Debian package > I would like to suggest that you rather fix this in your release tarball > by doing > > chmod a-x resources/* > > Fixing file permissions in your source code repository might be a valid > option as well. Fixed in the repository. I wasn't actively checking permissions before committing, but will start now. I also looked for .DS_Store and did not find it this time. I think I was using the Finder to move some folders around and it got stuck in the tarball. > But there is another bug in the code: > Snipped... > > I guess some code which checks for an existing .dicompyler dir and creates > it if needed. > Thanks for catching this. It is now fixed as I have restored the lines of code that were inadvertently removed in a prior update. A new tarball (again same file name) has been uploaded. This time I have marked the repository revision in the description. Thanks, Adit -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
