Bug#319887: apt-zip 0.13.3 has a brokenly applied patch
On 9/7/05, Giacomo A. Catenazzi [EMAIL PROTECTED] wrote: Eddy Petrişor wrote: Hello Giacomo, I have observed that you have applied a part of my patch to apt-zip 0.13.3. Thanks for that. It seems that you have lost my previous mail ;-) Probably... sorry The problem is that the patch was applied brokenly on apt-zip's code (I guess you took parts of it). The formatting is messed up in the wget method and the generated scripts; the patch I proposed used a trick for formatting and infile code: all the leading tabs are eliminated in the resulting output, but no the same for the spaces. (Probably) your editor replaced the tabs with spaces in some files and in some files didn't. yes. I applied by hand because my tree had already some previous changes. so I guess you accept my correction, as the generated scripts are broken in many ways Also the replacement of the less portable command which (not present on cygwin) with type was recorded in the changelog, but was not added to the code. I forgot it, But I uploaded a new version of apt-zip before I received this mail, so now I deleted the whole check. I think there are enough the check in IP/TCP and in wget (or alternate) programs. Anyway dpkg will further check the package. I am sorry, but I don't see the connection to the initial point. In the generated scripts, which gzip is used to test whether gzip is present; which is less portable than type, so I changed that into type gzip. (which is not present in cygwin, at least in my copy, while type is a built-in command and has a longer history, thus is more portable) I have made a new patch which fixes all the problems and adds suport for relative paths (please add this as I usually invoke apt-zip with a command like apt-zip -s -m . -p codeville, and I am sure many could use it in the same way on a flash stick, as there is no need to make files in the root of the removable media). Ok. now I understand. You mean .. Relative path support was already included (as zip, ../dir). . is a special case, because it mount the filesystem, but I remain in the old .. I propose an alternate (simple?) way: cd . I really would prefer my approach as is more flexible: apt-zip-list -s -m relative_path_should/be/allowed Another important point is that if one uses relative paths, the apt-zip-* scripts would fail (in their curent form) as they expect to find the tar archive in a directory specified as an absolute path. I also fail to see the benefit of doing cd . , probably I am missing something. But, anyway is your package, you can decide if a feature is impotant/useful enough to be included. PS: The changelog is updated and your name is registered for the packahe maintainer ;-) Sorry for impersonating you :o) I don't agree on your changes in copyright files. It is not as intended in policy. Yann is included because we need a name. Really the copyright should go in the 'normal' files and copyright should include the (old) maintainers, main developers (but no need to keep updated). Weird, will keep in mind... I always thought this way of recoding copyright (distributed in files) is prone to problems later if somebody forgets to add that note... anyway -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Bug#319887: apt-zip 0.13.3 has a brokenly applied patch
Eddy Petrişor wrote: On 9/7/05, Giacomo A. Catenazzi [EMAIL PROTECTED] wrote: Eddy Petrişor wrote: The problem is that the patch was applied brokenly on apt-zip's code (I guess you took parts of it). The formatting is messed up in the wget method and the generated scripts; the patch I proposed used a trick for formatting and infile code: all the leading tabs are eliminated in the resulting output, but no the same for the spaces. (Probably) your editor replaced the tabs with spaces in some files and in some files didn't. yes. I applied by hand because my tree had already some previous changes. so I guess you accept my correction, as the generated scripts are broken in many ways yes. Also the replacement of the less portable command which (not present on cygwin) with type was recorded in the changelog, but was not added to the code. I forgot it, But I uploaded a new version of apt-zip before I received this mail, so now I deleted the whole check. I think there are enough the check in IP/TCP and in wget (or alternate) programs. Anyway dpkg will further check the package. I am sorry, but I don't see the connection to the initial point. In the generated scripts, which gzip is used to test whether gzip is present; which is less portable than type, so I changed that into type gzip. (which is not present in cygwin, at least in my copy, while type is a built-in command and has a longer history, thus is more portable) type is more common that which (type is in POSIX), but type has not fix output. Anyway the test seems not important, so I removed the whole check () function. I have made a new patch which fixes all the problems and adds suport for relative paths (please add this as I usually invoke apt-zip with a command like apt-zip -s -m . -p codeville, and I am sure many could use it in the same way on a flash stick, as there is no need to make files in the root of the removable media). Ok. now I understand. You mean .. Relative path support was already included (as zip, ../dir). . is a special case, because it mount the filesystem, but I remain in the old .. I propose an alternate (simple?) way: cd . I really would prefer my approach as is more flexible: apt-zip-list -s -m relative_path_should/be/allowed Another important point is that if one uses relative paths, the apt-zip-* scripts would fail (in their curent form) as they expect to find the tar archive in a directory specified as an absolute path. I should test. On my (non complete) test I can use a relative path. I also fail to see the benefit of doing cd . , probably I am missing something. The trick is after mount the partition to go in the partition. So any 'cd' command (if it go in the right dir) is good. I'm not sure about cwd/PWD in solaris. But, anyway is your package, you can decide if a feature is impotant/useful enough to be included. PS: The changelog is updated and your name is registered for the packahe maintainer ;-) Sorry for impersonating you :o) I don't agree on your changes in copyright files. It is not as intended in policy. Yann is included because we need a name. Really the copyright should go in the 'normal' files and copyright should include the (old) maintainers, main developers (but no need to keep updated). Weird, will keep in mind... I always thought this way of recoding copyright (distributed in files) is prone to problems later if somebody forgets to add that note... anyway Here the problem is that there is no copyright statement on the other file. And it is needed. I think debian/copyright is not the right place (i.e. if the package will be packad for other distributions) ciao cate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#319887: apt-zip 0.13.3 has a brokenly applied patch
Hello Giacomo, I have observed that you have applied a part of my patch to apt-zip 0.13.3. Thanks for that. The problem is that the patch was applied brokenly on apt-zip's code (I guess you took parts of it). The formatting is messed up in the wget method and the generated scripts; the patch I proposed used a trick for formatting and infile code: all the leading tabs are eliminated in the resulting output, but no the same for the spaces. (Probably) your editor replaced the tabs with spaces in some files and in some files didn't. Also the replacement of the less portable command which (not present on cygwin) with type was recorded in the changelog, but was not added to the code. I have made a new patch which fixes all the problems and adds suport for relative paths (please add this as I usually invoke apt-zip with a command like apt-zip -s -m . -p codeville, and I am sure many could use it in the same way on a flash stick, as there is no need to make files in the root of the removable media). I have extended space protection in a place or two. PS: The changelog is updated and your name is registered for the packahe maintainer ;-) Sorry for impersonating you :o) Note that there is no close #319887 registration in the changelog, as the issue still seems open for some places. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein apt-zip-0.13.3-0.13.4.patch Description: Binary data
Bug#319887: apt-zip 0.13.3 has a brokenly applied patch
Eddy Petrişor wrote: Hello Giacomo, I have observed that you have applied a part of my patch to apt-zip 0.13.3. Thanks for that. It seems that you have lost my previous mail ;-) The problem is that the patch was applied brokenly on apt-zip's code (I guess you took parts of it). The formatting is messed up in the wget method and the generated scripts; the patch I proposed used a trick for formatting and infile code: all the leading tabs are eliminated in the resulting output, but no the same for the spaces. (Probably) your editor replaced the tabs with spaces in some files and in some files didn't. yes. I applied by hand because my tree had already some previous changes. Also the replacement of the less portable command which (not present on cygwin) with type was recorded in the changelog, but was not added to the code. I forgot it, But I uploaded a new version of apt-zip before I received this mail, so now I deleted the whole check. I think there are enough the check in IP/TCP and in wget (or alternate) programs. Anyway dpkg will further check the package. I have made a new patch which fixes all the problems and adds suport for relative paths (please add this as I usually invoke apt-zip with a command like apt-zip -s -m . -p codeville, and I am sure many could use it in the same way on a flash stick, as there is no need to make files in the root of the removable media). Ok. now I understand. You mean .. Relative path support was already included (as zip, ../dir). . is a special case, because it mount the filesystem, but I remain in the old .. I propose an alternate (simple?) way: cd . I have extended space protection in a place or two. ok PS: The changelog is updated and your name is registered for the packahe maintainer ;-) Sorry for impersonating you :o) I don't agree on your changes in copyright files. It is not as intended in policy. Yann is included because we need a name. Really the copyright should go in the 'normal' files and copyright should include the (old) maintainers, main developers (but no need to keep updated). Note that there is no close #319887 registration in the changelog, as the issue still seems open for some places. ciao cate
