Re: RFS: aescrypt
mezgani ali wrote: Benoît, i receive a message from upstream telling that he can not actually modify the source code, he said that if i want to do that for a version i have to branch from the current code, with his complete approval. It sounds like there was a bit of miscommunication; he probably thouht you were asking for access to their source repository and wanted to do some modifications upstream yourself. If they do not mind having this conversation on a public mailing list, maybe you could CC mentors from now on (but no not post any previous private email without permission). Or if you prefer I can try and talk to them directly (I just don't want to sound completely redundant, so if you choose this option, please let me know privately who you've contacted and roughly what you've explained so far). I'm little confused about this, may i branch software ? and host it somewhere ? I don't think you want to do that. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110808074857.ga8...@marvin.lan
Re: RFS: aescrypt
* Benoît Knecht benoit.kne...@fsfe.org [110804 23:03]: Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. I don't get what you mean by there is no need to have a license. Where does this no come from? A software distributed without a license is always presumed to be non-free. I do agree that the license doesn't have to be in the file itself, but then there should at least be a license file in the tarball stating what the license of all the included files is; and if there is a license statement in the file (as it is the case now), it should state all the rights granted to the user. Right now, the header says you're free to distribute these files, and somewhere else one of the copyright holder (in a private email, as far as I can tell) says you can do pretty much whatever you want with those files. I don't think that's an acceptable license grant; it's confusing at best. It's indeed confusing and not ideal. But if all the permissions were properly given then this would be no show-stopper. The problem in this example (apart from debian/copyright being incomplete and apperently getting some number wrong) is that the mail given is not so clear to give this additional permissions and that the author of that mail might not be able to give permissions for all the code (due to there being multiple authors, as you pointed out). There are three contributors (according to debian/copyrigh, not all of them are copyright holders, it's not clear why) listed in aescrypt.c for example, so we'd need a statement from all the copyright holders, preferably somewhere publically accessible. I still think it's way easier to get upstream to fix the license headers. It's easier for everyone involved except the one who has to explain upstream what exactly we want in those files, convince them to add that and then repeat those two steps till it is done... Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110805095511.ga11...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: aescrypt
Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 23:03]: Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. I don't get what you mean by there is no need to have a license. Where does this no come from? From some crazy neuron misfiring in my brain, I guess. Sorry about that :\ A software distributed without a license is always presumed to be non-free. I do agree that the license doesn't have to be in the file itself, but then there should at least be a license file in the tarball stating what the license of all the included files is; and if there is a license statement in the file (as it is the case now), it should state all the rights granted to the user. Right now, the header says you're free to distribute these files, and somewhere else one of the copyright holder (in a private email, as far as I can tell) says you can do pretty much whatever you want with those files. I don't think that's an acceptable license grant; it's confusing at best. It's indeed confusing and not ideal. But if all the permissions were properly given then this would be no show-stopper. The problem in this example (apart from debian/copyright being incomplete and apperently getting some number wrong) is that the mail given is not so clear to give this additional permissions and that the author of that mail might not be able to give permissions for all the code (due to there being multiple authors, as you pointed out). There are three contributors (according to debian/copyrigh, not all of them are copyright holders, it's not clear why) listed in aescrypt.c for example, so we'd need a statement from all the copyright holders, preferably somewhere publically accessible. I still think it's way easier to get upstream to fix the license headers. It's easier for everyone involved except the one who has to explain upstream what exactly we want in those files, convince them to add that and then repeat those two steps till it is done... That's true. Ali, if you don't want to do this, or if you need some help, let me know. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110805100352.gc11...@marvin.lan
Re: RFS: aescrypt
2011/8/5 Benoît Knecht benoit.kne...@fsfe.org Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 23:03]: Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. I don't get what you mean by there is no need to have a license. Where does this no come from? From some crazy neuron misfiring in my brain, I guess. Sorry about that :\ A software distributed without a license is always presumed to be non-free. I do agree that the license doesn't have to be in the file itself, but then there should at least be a license file in the tarball stating what the license of all the included files is; and if there is a license statement in the file (as it is the case now), it should state all the rights granted to the user. Right now, the header says you're free to distribute these files, and somewhere else one of the copyright holder (in a private email, as far as I can tell) says you can do pretty much whatever you want with those files. I don't think that's an acceptable license grant; it's confusing at best. It's indeed confusing and not ideal. But if all the permissions were properly given then this would be no show-stopper. The problem in this example (apart from debian/copyright being incomplete and apperently getting some number wrong) is that the mail given is not so clear to give this additional permissions and that the author of that mail might not be able to give permissions for all the code (due to there being multiple authors, as you pointed out). There are three contributors (according to debian/copyrigh, not all of them are copyright holders, it's not clear why) listed in aescrypt.c for example, so we'd need a statement from all the copyright holders, preferably somewhere publically accessible. I still think it's way easier to get upstream to fix the license headers. It's easier for everyone involved except the one who has to explain upstream what exactly we want in those files, convince them to add that and then repeat those two steps till it is done... That's true. Ali, if you don't want to do this, or if you need some help, let me know. Thank you for clear reply, i sent a mail to upstream and i hope that he will do necessary change to the header files that contain, the incomplete License text. Regards, Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110805100352.gc11...@marvin.lan -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: aescrypt
Benoît, i receive a message from upstream telling that he can not actually modify the source code, he said that if i want to do that for a version i have to branch from the current code, with his complete approval. I'm little confused about this, may i branch software ? and host it somewhere ? Kind regards, 2011/8/5 mezgani ali hand...@gmail.com 2011/8/5 Benoît Knecht benoit.kne...@fsfe.org Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 23:03]: Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. I don't get what you mean by there is no need to have a license. Where does this no come from? From some crazy neuron misfiring in my brain, I guess. Sorry about that :\ A software distributed without a license is always presumed to be non-free. I do agree that the license doesn't have to be in the file itself, but then there should at least be a license file in the tarball stating what the license of all the included files is; and if there is a license statement in the file (as it is the case now), it should state all the rights granted to the user. Right now, the header says you're free to distribute these files, and somewhere else one of the copyright holder (in a private email, as far as I can tell) says you can do pretty much whatever you want with those files. I don't think that's an acceptable license grant; it's confusing at best. It's indeed confusing and not ideal. But if all the permissions were properly given then this would be no show-stopper. The problem in this example (apart from debian/copyright being incomplete and apperently getting some number wrong) is that the mail given is not so clear to give this additional permissions and that the author of that mail might not be able to give permissions for all the code (due to there being multiple authors, as you pointed out). There are three contributors (according to debian/copyrigh, not all of them are copyright holders, it's not clear why) listed in aescrypt.c for example, so we'd need a statement from all the copyright holders, preferably somewhere publically accessible. I still think it's way easier to get upstream to fix the license headers. It's easier for everyone involved except the one who has to explain upstream what exactly we want in those files, convince them to add that and then repeat those two steps till it is done... That's true. Ali, if you don't want to do this, or if you need some help, let me know. Thank you for clear reply, i sent a mail to upstream and i hope that he will do necessary change to the header files that contain, the incomplete License text. Regards, Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110805100352.gc11...@marvin.lan -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/ -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: aescrypt
Please find here the new version of the package: Dear mentors, I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author :Glenn Washburn cr...@berlios.de Paul E. Jones pau...@packetizer.com Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl2 Section : utils It builds these binary packages:aescrypt - Simple tool for encrypt and decrypt files using AES The package appears to be lintian clean. The upload would fix these bugs: 609505 My motivation for maintaining this package is: [fill in]. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aescrypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aescrypt/aescrypt_3.05-1.dsc I would be glad if someone uploaded this package for me. Kind regards Ali MEZGANI On Wed, Aug 3, 2011 at 4:30 PM, Andrey Rahmatullin w...@wrar.name wrote: On Wed, Aug 03, 2011 at 04:16:23PM +, mezgani ali wrote: * License : gpl3 No, it's GPL2+ for aes.c and sha256.c and non-free freeware license (not explicitly allowing modification) for other files. -- WBR, wRAR -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: aescrypt
On Thu, Aug 04, 2011 at 06:13:52AM +, mezgani ali wrote: My motivation for maintaining this package is: [fill in]. Huh? The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aescrypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aescrypt/aescrypt_3.05-1.dsc You don't have a git repo (even though Vcs-* is filled in) so I couldn't find what exactly did you change from the last upload, but looks like you changed only GPL3 to GPL2 in one place of debian/copyright, making it even worse. And it seems you didn't ask the authors about licenses, as I've suggested several times. According to http://forums.packetizer.com/viewtopic.php?f=72t=92 , the non-GPL files are really non-GPL, so you can only ask the upstream to clarify the license, because apparently they wanted to use some permissive one, but failed. Without this, the package cannot enter the Debian archive. -- WBR, wRAR signature.asc Description: Digital signature
Re: RFS: aescrypt
Sorry, the upload of the package failed but, if you check the new sources now, you'll find that the copyright is changed and i've joined the text mail of new license, from upstream author. On Thu, Aug 4, 2011 at 8:49 AM, Andrey Rahmatullin w...@wrar.name wrote: On Thu, Aug 04, 2011 at 06:13:52AM +, mezgani ali wrote: My motivation for maintaining this package is: [fill in]. Huh? The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aescrypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aescrypt/aescrypt_3.05-1.dsc You don't have a git repo (even though Vcs-* is filled in) so I couldn't find what exactly did you change from the last upload, but looks like you changed only GPL3 to GPL2 in one place of debian/copyright, making it even worse. And it seems you didn't ask the authors about licenses, as I've suggested several times. and Vcs repository is created. According to http://forums.packetizer.com/viewtopic.php?f=72t=92 , the non-GPL files are really non-GPL, so you can only ask the upstream to clarify the license, because apparently they wanted to use some permissive one, but failed. Without this, the package cannot enter the Debian archive. -- WBR, wRAR -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: aescrypt
Hi Ali, mezgani ali wrote: Sorry, the upload of the package failed but, if you check the new sources now, you'll find that the copyright is changed and i've joined the text mail of new license, from upstream author. Upstream doesn't seem to understand that their freeware license is not free: it doesn't give you the right to modify the software and to redistribute modified versions of the software. If they want something less restrictive than the GPL, they should use a 3-clause BSD or Expat license. BTW, your debian/copyright file still states either version 3 of the License, or (at your option) any later version. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804121105.gg20...@marvin.lan
Re: RFS: aescrypt
Benoît Knecht wrote: mezgani ali wrote: Sorry, the upload of the package failed but, if you check the new sources now, you'll find that the copyright is changed and i've joined the text mail of new license, from upstream author. Upstream doesn't seem to understand that their freeware license is not free: it doesn't give you the right to modify the software and to redistribute modified versions of the software. If they want something less restrictive than the GPL, they should use a 3-clause BSD or Expat license. Oh and they should also provide a copy of the GPL along with the source code, as required by the GPL itself. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804121832.gh20...@marvin.lan
Re: RFS: aescrypt
Benoît, i've received a message from upstream, telling that the application is totally free, without any restriction for modification or redistribution. in the fact, i insert message text in the copyright file. Please take a look 2011/8/4 Benoît Knecht benoit.kne...@fsfe.org Benoît Knecht wrote: mezgani ali wrote: Sorry, the upload of the package failed but, if you check the new sources now, you'll find that the copyright is changed and i've joined the text mail of new license, from upstream author. Upstream doesn't seem to understand that their freeware license is not free: it doesn't give you the right to modify the software and to redistribute modified versions of the software. If they want something less restrictive than the GPL, they should use a 3-clause BSD or Expat license. Oh and they should also provide a copy of the GPL along with the source code, as required by the GPL itself. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804121832.gh20...@marvin.lan -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: aescrypt
mezgani ali wrote: Benoît, i've received a message from upstream, telling that the application is totally free, without any restriction for modification or redistribution. in the fact, i insert message text in the copyright file. Please take a look I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. It is crucial that they fix this _upstream_, you can't simply add a note in the debian packaging about that. And again, if they want to make sure that the license they're using is free, they should use one of the well known free software licenses such as the 3-clause BSD or the Expat license; if that's still too restrictive for their taste, they could use a public domain license such as CC0. And please, if you're discussing these licensing issues with upstream, don't forget to also remind them about including a copy of the GPL along with the source; it _is_ a license violation not to do so. Thanks. -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804185400.gd3...@marvin.lan
Re: RFS: aescrypt
* Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. (Though it definitely extremly recommendable to have the license clearly stated in every file and the postamble of the GPL recommending this has definitely be counted as one of the best things the FSF ever did). It is crucial that they fix this _upstream_, you can't simply add a note in the debian packaging about that. As long as debian/copyright contains something giving us and the users a license by people authorized to do so everything is fine. And again, if they want to make sure that the license they're using is free, they should use one of the well known free software licenses such as the 3-clause BSD or the Expat license; if that's still too restrictive for their taste, they could use a public domain license such as CC0. While it is definitely recommendable to use something already existing to avoid common pitfalls, that does not mean everything else is impossible. And please, if you're discussing these licensing issues with upstream, don't forget to also remind them about including a copy of the GPL along with the source; it _is_ a license violation not to do so. This is definitely something that is needed. (Or replacing the code with code unter other licenses, at least for sha256 there is less restrictive code flowing around). To get to the real problems: debian/copyright is not giving the license statement from those files. (the message it quotes does refer to something not quoted, I guess the statement found in the files). The original license statement as far as I see mostly misses the explicit permission to modify and distribute modified and to give others the same permission (or it should be clear that it gives those permissions to eveyone). The message quote in debian/copyright starts with describing what this license is supposed to do and then continues with I’ll go further in saying Here it is unfortunately not very clear if this is a addional grant of license or a wrong description about the one found in the files. I think this needs improvement (having that in the upstream files would of course be nice, but as long as you can a explicit permission of the copyright holder that everyone may use, copy and/or modify and state this grant in the file that would be enough). And the files are GPL-2, how do you get to the GPL 3 in seem to be debian/copyright? Bernhard R. Link -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804203700.ga9...@pcpool00.mathematik.uni-freiburg.de
Re: RFS: aescrypt
Bernhard R. Link wrote: * Benoît Knecht benoit.kne...@fsfe.org [110804 20:54]: I've seen that, but they need to make that perfectly clear in the license header of each file in the tarball. An email sent to you and reproduced in the debian/copyright file is not enough. There is nothing special about the source files. There is a need to have a license, there is no need that this license statement must be in the files itself or even in the tarball. I don't get what you mean by there is no need to have a license. A software distributed without a license is always presumed to be non-free. I do agree that the license doesn't have to be in the file itself, but then there should at least be a license file in the tarball stating what the license of all the included files is; and if there is a license statement in the file (as it is the case now), it should state all the rights granted to the user. Right now, the header says you're free to distribute these files, and somewhere else one of the copyright holder (in a private email, as far as I can tell) says you can do pretty much whatever you want with those files. I don't think that's an acceptable license grant; it's confusing at best. (Though it definitely extremly recommendable to have the license clearly stated in every file and the postamble of the GPL recommending this has definitely be counted as one of the best things the FSF ever did). Agreed. It is crucial that they fix this _upstream_, you can't simply add a note in the debian packaging about that. As long as debian/copyright contains something giving us and the users a license by people authorized to do so everything is fine. And again, if they want to make sure that the license they're using is free, they should use one of the well known free software licenses such as the 3-clause BSD or the Expat license; if that's still too restrictive for their taste, they could use a public domain license such as CC0. While it is definitely recommendable to use something already existing to avoid common pitfalls, that does not mean everything else is impossible. Indeed, I was just suggesting using these since they seem to have fallen into one of these common pitfalls already. But if they modify their freeware license in a way that makes it free, that's of course perfectly fine (although I don't see the benefit of coming up with yet another free license). And please, if you're discussing these licensing issues with upstream, don't forget to also remind them about including a copy of the GPL along with the source; it _is_ a license violation not to do so. This is definitely something that is needed. (Or replacing the code with code unter other licenses, at least for sha256 there is less restrictive code flowing around). To get to the real problems: debian/copyright is not giving the license statement from those files. (the message it quotes does refer to something not quoted, I guess the statement found in the files). The original license statement as far as I see mostly misses the explicit permission to modify and distribute modified and to give others the same permission (or it should be clear that it gives those permissions to eveyone). The message quote in debian/copyright starts with describing what this license is supposed to do and then continues with I’ll go further in saying Here it is unfortunately not very clear if this is a addional grant of license or a wrong description about the one found in the files. I think this needs improvement (having that in the upstream files would of course be nice, but as long as you can a explicit permission of the copyright holder that everyone may use, copy and/or modify and state this grant in the file that would be enough). There are three contributors (according to debian/copyrigh, not all of them are copyright holders, it's not clear why) listed in aescrypt.c for example, so we'd need a statement from all the copyright holders, preferably somewhere publically accessible. I still think it's way easier to get upstream to fix the license headers. Cheers, -- Benoît Knecht -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110804210316.ge3...@marvin.lan
RFS: aescrypt
Dear mentors, I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author :Glenn Washburn cr...@berlios.de Paul E. Jones pau...@packetizer.com Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl3 Section : utils It builds these binary packages: aescrypt - Simple tool for encrypt and decrypt files using AES The package appears to be lintian clean. The upload would fix these bugs: 609505 My motivation for maintaining this package is: [fill in]. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aescrypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aescrypt/aescrypt_3.05-1.dsc I would be glad if someone uploaded this package for me. Kind regards Ali MEZGANI -- Ali MEZGANI *N*etwork *E*ngineering/*S*ecurity http://www.nativelabs.org/
Re: RFS: aescrypt
On Wed, Aug 03, 2011 at 04:16:23PM +, mezgani ali wrote: * License : gpl3 No, it's GPL2+ for aes.c and sha256.c and non-free freeware license (not explicitly allowing modification) for other files. -- WBR, wRAR signature.asc Description: Digital signature
RFS: aescrypt
Dear mentors, I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author : Glenn Washburn cr...@berlios.de, Paul E. Jones pau...@packetizer.com, Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl Section : utils It builds these binary packages: aescrypt - Using a powerful 256-bit encryption algorithm, The package appears to be lintian clean. The upload would fix these bugs: 609505 My motivation for maintaining this package is: [fill in]. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/a/aescrypt - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/a/aescrypt/aescrypt_3.05-1.dsc I would be glad if someone uploaded this package for me. Kind regards Ali MEZGANI
Re: RFS: aescrypt
Hi, I'm not in a position to sponsor your package, but I started reviewing it and found several problems: On Sun, Jan 16, 2011 at 09:08:28PM +, mezgani ali wrote: I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author : Glenn Washburn cr...@berlios.de, Paul E. Jones pau...@packetizer.com, Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl Section : utils It builds these binary packages: aescrypt - Using a powerful 256-bit encryption algorithm, This isn't a suitable short description, and the long description gives no indication why I would want to use it. See the developer's reference for short description tips. The package appears to be lintian clean. I doubt this, but I couldn't even build it to check: | make[1]: Entering directory `/tmp/aescrypt-3.05' | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aescrypt.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aes.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c sha256.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c password.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -o aescrypt aescrypt.o aes.o sha256.o password.o | install -o root -g root -m 755 aescrypt /usr/bin | install: cannot create regular file `/usr/bin/aescrypt': Permission denied | make[1]: *** [install] Error 1 That implies that you've been building as root - the autobuild network doesn't, so you need to check for this. You should also use 'dpkg -c *.deb' to check the package contains the files you expect; in this case, it wouldn't have had the binary in. The watch file also fails: |-- Found watchfile in ./debian |-- In debian/watch, processing watchfile line: | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gz | uscan debug: requesting URL http://www.aescrypt.com/cgi-bin/download?file=v3/ snip | uscan warning: In debian/watch, | no matching hrefs for watch line | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gz There's some trailing whitespace in debian/control, and as above you need to improve the short and long descriptions. The source files that have license grants at the top mention GPL2+, not GPL3+ as in your copyright file. The clean target does not remove debian/aescrypt.debhelper.log, so that file got included in your diff. The file debian/files is empty, get rid of it. README.Debian and README.source are also useless. A user looking in /usr/share/doc/aescrypt for those files will see Readme.txt right alongside them, so remove the extra step and leave it at that. debian/rules includes lots of unneccessary calls and some lines are just commented out, so they can be removed to make it easier to read. It looks like it's just been copied from echoping: # Add here commands to install the package into debian/echoping. You can't pass DESTDIR into the upstream make file, because it never uses it - you'll have to persuade upstream to fix the makefile or patch it not to install files to /usr/bin. From the look of your debian/rules, you can probably use the small or tiny form for debhelper, which gets rid of almost all the clutter. After fixing the build system lintian has these pointers: I: aescrypt: extended-description-is-probably-too-short W: aescrypt: binary-without-manpage usr/bin/aescrypt P: aescrypt: no-upstream-changelog E: aescrypt: debian-changelog-file-missing E: aescrypt: unstripped-binary-or-object ./usr/bin/aescrypt The last three are because of missing debhelper calls, they should be easily fixed. That should give you something to be getting on with :) -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 signature.asc Description: Digital signature
Re: RFS: aescrypt
Hi Jonathan, I thank you first for your suggestions, well i fixed most of them and here i have some questions On Mon, Jan 17, 2011 at 12:05 AM, Jonathan Wiltshire j...@debian.org wrote: Hi, I'm not in a position to sponsor your package, but I started reviewing it and found several problems: On Sun, Jan 16, 2011 at 09:08:28PM +, mezgani ali wrote: I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author : Glenn Washburn cr...@berlios.de, Paul E. Jones pau...@packetizer.com, Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl Section : utils It builds these binary packages: aescrypt - Using a powerful 256-bit encryption algorithm, This isn't a suitable short description, and the long description gives no indication why I would want to use it. See the developer's reference for short description tips. The package appears to be lintian clean. I doubt this, but I couldn't even build it to check: | make[1]: Entering directory `/tmp/aescrypt-3.05' | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aescrypt.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aes.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c sha256.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c password.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -o aescrypt aescrypt.o aes.o sha256.o password.o | install -o root -g root -m 755 aescrypt /usr/bin | install: cannot create regular file `/usr/bin/aescrypt': Permission denied | make[1]: *** [install] Error 1 That implies that you've been building as root - the autobuild network doesn't, so you need to check for this. You should also use 'dpkg -c *.deb' to check the package contains the files you expect; in this case, it wouldn't have had the binary in. The watch file also fails: May a package contain obligatory a watch file ? |-- Found watchfile in ./debian |-- In debian/watch, processing watchfile line: | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gzhttp://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt%28.*%29_source%5C.tar%5C.gz | uscan debug: requesting URL http://www.aescrypt.com/cgi-bin/download?file=v3/ snip | uscan warning: In debian/watch, | no matching hrefs for watch line | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gzhttp://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt%28.*%29_source%5C.tar%5C.gz There's some trailing whitespace in debian/control, and as above you need to improve the short and long descriptions. Fixed The source files that have license grants at the top mention GPL2+, not GPL3+ as in your copyright file. Fixed The clean target does not remove debian/aescrypt.debhelper.log, so that file got included in your diff. The file debian/files is empty, get rid of it. Fixed README.Debian and README.source are also useless. A user looking in /usr/share/doc/aescrypt for those files will see Readme.txt right alongside them, so remove the extra step and leave it at that. May i remove them or maybe append the content of Readme.txt file debian/rules includes lots of unneccessary calls and some lines are just commented out, so they can be removed to make it easier to read. It looks like it's just been copied from echoping: Fixed # Add here commands to install the package into debian/echoping. You can't pass DESTDIR into the upstream make file, because it never uses it - you'll have to persuade upstream to fix the makefile or patch it not to install files to /usr/bin. From the look of your debian/rules, you can probably use the small or tiny form for debhelper, which gets rid of almost all the clutter. After fixing the build system lintian has these pointers: I: aescrypt: extended-description-is-probably-too-short W: aescrypt: binary-without-manpage usr/bin/aescrypt P: aescrypt: no-upstream-changelog E: aescrypt: debian-changelog-file-missing E: aescrypt: unstripped-binary-or-object ./usr/bin/aescrypt The last three are because of missing debhelper calls, they should be easily fixed. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmwhttp://people.debian.org/%7Ejmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJNM4fAAAoJEFOUR53TUkxROSUP/1dKuygF0/2r4bZP6quBMElq +q4k8c2KxgmDhFvy99EyO11Go2H+mg5kdnYIUcc+ZnNYmEjCzbxbWeUaFdLoFa0b uHVY1lslbt1Eq6fTAft0TuXc3kmwCNIquRKxC8G+vK3KD4oofgZ/H7RkhCGwJ2gJ A/XW9X8fhcdmnf/dDHXFJcIVGkzz8CgI+N8ghvkRJYX9kbYENQpvyNfutFx5tsH4 QeunRqFv1QCtObZ5HhH4eMcZIjT0qT/HFgXrwjsjQR95UkdkEzUiqNKs3uQGwMJe QtATS82VVUJJMlF6lyhybFQtkkMDx9vIgpks/ACQNVFdMEjNVORYIO/L1QdW2Xds 5jsnEPvkJTONJAvnd/V197lm6O7t4ytAu7fXws8A78aiXbwL/82z6OF4temnaF9n
Re: RFS: aescrypt
Ali, I'm not a mentor, but I believe that your questions can be answered by entire reading this article: http://people.debian.org/~codehelp/ Best regards, @Fernando Mercês http://twitter.com/FernandoMercesLinux Registered User #432779 www.mentebinaria.com.br http://linuxreversing.org http://softwarelivre-rj.org -- Participe do I Hack'n Rio http://hacknrio.org/, dias 8 e 9 de abril na UFRJ! -- On Sun, Jan 16, 2011 at 11:01 PM, mezgani ali hand...@gmail.com wrote: Hi Jonathan, I thank you first for your suggestions, well i fixed most of them and here i have some questions On Mon, Jan 17, 2011 at 12:05 AM, Jonathan Wiltshire j...@debian.orgwrote: Hi, I'm not in a position to sponsor your package, but I started reviewing it and found several problems: On Sun, Jan 16, 2011 at 09:08:28PM +, mezgani ali wrote: I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author : Glenn Washburn cr...@berlios.de, Paul E. Jones pau...@packetizer.com, Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl Section : utils It builds these binary packages: aescrypt - Using a powerful 256-bit encryption algorithm, This isn't a suitable short description, and the long description gives no indication why I would want to use it. See the developer's reference for short description tips. The package appears to be lintian clean. I doubt this, but I couldn't even build it to check: | make[1]: Entering directory `/tmp/aescrypt-3.05' | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aescrypt.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aes.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c sha256.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c password.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -o aescrypt aescrypt.o aes.o sha256.o password.o | install -o root -g root -m 755 aescrypt /usr/bin | install: cannot create regular file `/usr/bin/aescrypt': Permission denied | make[1]: *** [install] Error 1 That implies that you've been building as root - the autobuild network doesn't, so you need to check for this. You should also use 'dpkg -c *.deb' to check the package contains the files you expect; in this case, it wouldn't have had the binary in. The watch file also fails: May a package contain obligatory a watch file ? |-- Found watchfile in ./debian |-- In debian/watch, processing watchfile line: | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gzhttp://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt%28.*%29_source%5C.tar%5C.gz | uscan debug: requesting URL http://www.aescrypt.com/cgi-bin/download?file=v3/ snip | uscan warning: In debian/watch, | no matching hrefs for watch line | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gzhttp://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt%28.*%29_source%5C.tar%5C.gz There's some trailing whitespace in debian/control, and as above you need to improve the short and long descriptions. Fixed The source files that have license grants at the top mention GPL2+, not GPL3+ as in your copyright file. Fixed The clean target does not remove debian/aescrypt.debhelper.log, so that file got included in your diff. The file debian/files is empty, get rid of it. Fixed README.Debian and README.source are also useless. A user looking in /usr/share/doc/aescrypt for those files will see Readme.txt right alongside them, so remove the extra step and leave it at that. May i remove them or maybe append the content of Readme.txt file debian/rules includes lots of unneccessary calls and some lines are just commented out, so they can be removed to make it easier to read. It looks like it's just been copied from echoping: Fixed # Add here commands to install the package into debian/echoping. You can't pass DESTDIR into the upstream make file, because it never uses it - you'll have to persuade upstream to fix the makefile or patch it not to install files to /usr/bin. From the look of your debian/rules, you can probably use the small or tiny form for debhelper, which gets rid of almost all the clutter. After fixing the build system lintian has these pointers: I: aescrypt: extended-description-is-probably-too-short W: aescrypt: binary-without-manpage usr/bin/aescrypt P: aescrypt: no-upstream-changelog E: aescrypt: debian-changelog-file-missing E: aescrypt: unstripped-binary-or-object ./usr/bin/aescrypt The last three are because of missing debhelper calls, they should be easily fixed. -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmwhttp://people.debian.org/%7Ejmw 4096R:
Re: RFS: aescrypt
What about README.Debian and README.source can i keep them empty and in the case when the tools comes with a readme.txt file ? 2011/1/17 Fernando Mercês nand...@gmail.com Ali, I'm not a mentor, but I believe that your questions can be answered by entire reading this article: http://people.debian.org/~codehelp/http://people.debian.org/%7Ecodehelp/ Best regards, @Fernando Mercês http://twitter.com/FernandoMercesLinux Registered User #432779 www.mentebinaria.com.br http://linuxreversing.org http://softwarelivre-rj.org -- Participe do I Hack'n Rio http://hacknrio.org/, dias 8 e 9 de abril na UFRJ! -- On Sun, Jan 16, 2011 at 11:01 PM, mezgani ali hand...@gmail.com wrote: Hi Jonathan, I thank you first for your suggestions, well i fixed most of them and here i have some questions On Mon, Jan 17, 2011 at 12:05 AM, Jonathan Wiltshire j...@debian.orgwrote: Hi, I'm not in a position to sponsor your package, but I started reviewing it and found several problems: On Sun, Jan 16, 2011 at 09:08:28PM +, mezgani ali wrote: I am looking for a sponsor for my package aescrypt. * Package name: aescrypt Version : 3.05-1 Upstream Author : Glenn Washburn cr...@berlios.de, Paul E. Jones pau...@packetizer.com, Mauro Gilardi galva...@gmail.com * URL : http://www.aescrypt.com/ * License : gpl Section : utils It builds these binary packages: aescrypt - Using a powerful 256-bit encryption algorithm, This isn't a suitable short description, and the long description gives no indication why I would want to use it. See the developer's reference for short description tips. The package appears to be lintian clean. I doubt this, but I couldn't even build it to check: | make[1]: Entering directory `/tmp/aescrypt-3.05' | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aescrypt.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c aes.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c sha256.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -c password.c | gcc -Wall -D_FILE_OFFSET_BITS=64 -o aescrypt aescrypt.o aes.o sha256.o password.o | install -o root -g root -m 755 aescrypt /usr/bin | install: cannot create regular file `/usr/bin/aescrypt': Permission denied | make[1]: *** [install] Error 1 That implies that you've been building as root - the autobuild network doesn't, so you need to check for this. You should also use 'dpkg -c *.deb' to check the package contains the files you expect; in this case, it wouldn't have had the binary in. The watch file also fails: May a package contain obligatory a watch file ? |-- Found watchfile in ./debian |-- In debian/watch, processing watchfile line: | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gzhttp://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt%28.*%29_source%5C.tar%5C.gz | uscan debug: requesting URL http://www.aescrypt.com/cgi-bin/download?file=v3/ snip | uscan warning: In debian/watch, | no matching hrefs for watch line | http://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt(.*)_source\.tar\.gzhttp://www.aescrypt.com/cgi-bin/download?file=v3/aescrypt%28.*%29_source%5C.tar%5C.gz There's some trailing whitespace in debian/control, and as above you need to improve the short and long descriptions. Fixed The source files that have license grants at the top mention GPL2+, not GPL3+ as in your copyright file. Fixed The clean target does not remove debian/aescrypt.debhelper.log, so that file got included in your diff. The file debian/files is empty, get rid of it. Fixed README.Debian and README.source are also useless. A user looking in /usr/share/doc/aescrypt for those files will see Readme.txt right alongside them, so remove the extra step and leave it at that. May i remove them or maybe append the content of Readme.txt file debian/rules includes lots of unneccessary calls and some lines are just commented out, so they can be removed to make it easier to read. It looks like it's just been copied from echoping: Fixed # Add here commands to install the package into debian/echoping. You can't pass DESTDIR into the upstream make file, because it never uses it - you'll have to persuade upstream to fix the makefile or patch it not to install files to /usr/bin. From the look of your debian/rules, you can probably use the small or tiny form for debhelper, which gets rid of almost all the clutter. After fixing the build system lintian has these pointers: I: aescrypt: extended-description-is-probably-too-short W: aescrypt: binary-without-manpage usr/bin/aescrypt P: aescrypt: no-upstream-changelog E: aescrypt: debian-changelog-file-missing E: aescrypt: unstripped-binary-or-object ./usr/bin/aescrypt The last three are because of missing debhelper calls,
Re: RFS: aescrypt
2011/1/16 mezgani ali hand...@gmail.com: What about README.Debian and README.source can i keep them empty and in the case when the tools comes with a readme.txt file ? [snip] Please make sure you read this (read it all if you haven't yet): http://www.debian.org/doc/maint-guide/ The things you are asking are documented there. Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTim3hCMKS5f-amkW6r4eh+AXWyUF3qB7Bb6ijs3=@mail.gmail.com
Re: RFS: aescrypt
Please take a look to my new packages ;) It seems to be Ok Regards, On Mon, Jan 17, 2011 at 1:36 AM, Fernando Lemos fernando...@gmail.comwrote: 2011/1/16 mezgani ali hand...@gmail.com: What about README.Debian and README.source can i keep them empty and in the case when the tools comes with a readme.txt file ? [snip] Please make sure you read this (read it all if you haven't yet): http://www.debian.org/doc/maint-guide/ The things you are asking are documented there. Regards, -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTim3hCMKS5f-amkW6r4eh+AXWyUF3qB7Bb6ijs3=@mail.gmail.com -- Ali MEZGANI Network Engineering/Security http://securfox.wordpress.com/
