Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, An old message is inlined below. 2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. What do you mean by not preferring the bootstrap script? I have included the script in upstream's tarball, so that devs can re-generate build scripts, man page and friends. Besides, according to http://manpages.debian.org/cgi-bin/man.cgi?query=dh-autoreconfapropos=0sektion=7manpath=Debian+unstable+sidformat=htmllocale=en, dh_autoreconf cannot run mutiple commands, so I put all commands in the bootstrap script. What is your idea? PS: I think I can remove the +dfsg suffice now since the new tarball is now DFSG-Free. Cheers, Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Alex, What do you mean by not preferring the bootstrap script? I have included the script in upstream's tarball, so that devs can re-generate build scripts, man page and friends. Besides, according to http://manpages.debian.org/cgi-bin/man.cgi?query=dh-autoreconfapropos=0sektion=7manpath=Debian+unstable+sidformat=htmllocale=en, dh_autoreconf cannot run mutiple commands, so I put all commands in the bootstrap script. What is your idea? My idea might be to have the manpage built at dh_build stage and installed at dh_installmanpages stage. So this might be achieved by calling override_dh_auto_build: dh_auto_build yourmanpage generation and a debian/manpages file I can't retrieve the source anymore, so I don't know what was wrong or I didn't like, but I might be fine with the upstream bootstrap script if it makes packaging easier for you :D PS: I think I can remove the +dfsg suffice now since the new tarballis now DFSG-Free. that is nice! cheers, G.
Bug#795704: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Alex, I contacted Ernst (upstream dev) and he agreed to integrate the build system into his dev branch. Wonderful! Good news are good :) I think the above should solve the version string problem as well. Or if it doesn't we can use the old method based on date string. I think it should work find beacuse the date is monotonic increasing. For example, the current release is 12.11.2014. Let's assume the next release is 09.01.2015. We can use some regex replacement to tranform them into 20141211 and 20150901 respectively and this should works. I still don't follow that, you need to change the watch file to see a new release or not? I mean, it might be ok to change it to download the new release, but uscan is used to *detect* new tarballs on the remote, and in that way... I'm not sure it works... Maybe some other DDs can help us in achieving something similar (I guess some uversionmangle syntax might help there) So do I :P I always think I used too much I think and the... The original conversation is forwarded for your reference. thanks!!! Gianfranco
Bug#795704: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, so can't you ask upstream to integrate the build system and sync with them? it isn't a Debian specific feature, and should be upstreamed IMHO. I contacted Ernst (upstream dev) and he agreed to integrate the build system into his dev branch. the problem is that you don't get notified on new releases, and moreover the versioning that upstream does is simply wrong... can't you ask them to follow the always an higher number versioning? I think the above should solve the version string problem as well. Or if it doesn't we can use the old method based on date string. I think it should work find beacuse the date is monotonic increasing. For example, the current release is 12.11.2014. Let's assume the next release is 09.01.2015. We can use some regex replacement to tranform them into 20141211 and 20150901 respectively and this should works. sorry for that, I'm not a native english speaker :) So do I :P I always think I used too much I think and the... The original conversation is forwarded for your reference. Cheers, Alex -- Forwarded message -- From: E. Mayer ewma...@aol.com Date: Fri, 21 Aug 2015 23:41:21 -0700 Subject: Re: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number To: Alex Vong alexvong1...@gmail.com Hi, Alex: I am fine with option [1], integrating the build system into my main-dev. Just need a bit of clarification - what files does the 'build system' encompass, and where should these reside in the source tree relative to the .h and .c files? Also, by 'upstream' is Ginafranco referring to main-dev (i.e. to me), or something else? Thanks, -E On Aug 21, 2015, at 7:19 PM, Alex Vong wrote: Hi Ernst, I have added the suggested paragraph into the man page and introduction. I have remixed it a bit or the introduction would be too long. Regarding the merging, feel free to merge anything that you find useful! Good news! We now have another Debian Developer to review the package. Below is the forwarded message. One of the points he has made is that he thinks the build system should be integrated inside the mlucas tarball. I can think of 2 ways. 1. I will send the with build system tarball to you and the tarball will be hosted in the http://www.hogranch.com/mayer/src/C/ directory. 2. I will host the source in gitlab and the source will be fetchable from it directly. How do you think about it? Thanks, Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp d/rules: wl-asneeded is good if enable, does it introduce some problems? are both autotools-dev and autoreconf needed? usually the latter should superceed the former d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. d/patches/*: they seem to come from a git export-patch, are them already upstream? so why don't just ask to release a new tarball? carrying 30 patches might be a maintenance problem. debian/repack seems not policy compliant (didn't check) maybe get-orig-source.sh is better as a name also source_package_build.bash but I guess this might be a nitpick, since they are called by uscan so the user/developer never need to call them directly. d/watch what is the timestamp there? oh well, seems that upstream in that way doesn't increase the version number when releasing bad numbering is bad :) let me know, (I didn't try to build the package, and didn't check the copyrights) cheers, G. d/copyright: expat seems commented (even if not a problem) same for gpl Il Venerdì 21 Agosto 2015 14:20, Alex Vong alexvong1...@gmail.com ha scritto: Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package mlucas, I have uploaded a new version of the package to fix issues pointed out by Jakub Wilk, please see previous message in the bug report to see what issues are fixed I will now elaborate more on why this package is suitable for Debian, feel free to skip it __BEGIN_ELABORATION__ Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available software to search for Mersenne prime numbers (quote from Wikipedia). The most popular client `mprime' was available in Debian Potato as the package `prime-net' as shown in this post http://www.mersenneforum.org/showthread.php?t=7181. However, it appears the maintainer had lost interest in it because it was classified as `non-free'. `mlucas' has been developed as an alternative since 1996. While it is not as efficient as `mprime', it is licensed under GPL-2+ and thus suitable to be included in `main'. It has been used in the verification of various Mersenne primes, including the 45th (found in 2008), 46th (found in 2009) and 48th (found in 2013) found Mersenne prime. Therefore, the underlying algorithm is believed to be reliable, thus suitable to be included in Debian. __END_ELABORATION__ * Package name: mlucas Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1+dfsg-1.dsc Changes since the last upload: mlucas (14.1+dfsg-1) UNRELEASED; urgency=low * Initial release (Closes: #786656) -- Alex Vong alexvong1...@gmail.com Sun, 02 Aug 2015 03:13:37 +0800 Cheers, Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, Thanks for the quick reply, I have just finished dinner. 2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp Okay. d/rules: wl-asneeded is good if enable, does it introduce some problems? Okay I will add it. are both autotools-dev and autoreconf needed? usually the latter should superceed the former Okay I will remove autotools-dev. d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. d/patches/*: they seem to come from a git export-patch, are them already upstream? so why don't just ask to release a new tarball? carrying 30 patches might be a maintenance problem. Okay. I think this needs further explaination. Upstream does not include a build system, not even a Makefile. Building is done by invoking gcc directly using different flags for different platform. This is however cumbersome, so I add autotools to ease building. I use git for development https://gitlab.com/mlucas-ll/mlucas. The 29 patches can be divided into 3 groups. 0001 - 0012, 0027 are patches related to the source, forwarded upstream to be included in the next version. The rest are patches to add the build system and script to generate man page, NEWS, ChangeLog... Any advice on this? debian/repack seems not policy compliant (didn't check) maybe get-orig-source.sh is better as a name Okay changed. also source_package_build.bash but I guess this might be a nitpick, since they are called by uscan so the user/developer never need to call them directly. I do not understand. What should I do with `source_package_build.bash' ? d/watch what is the timestamp there? oh well, seems that upstream in that way doesn't increase the version number when releasing bad numbering is bad :) Upstream uses Mlucas_MM.DD..tbz2 instead of mlucas_14.1.tar.bz2 for backward capability, so we need to update debian/watch version string for every new release... let me know, (I didn't try to build the package, and didn't check the copyrights) cheers, G. d/copyright: expat seems commented (even if not a problem) same for gpl I do it beacuse lintian will complain about empty license if add `License:' in the header paragraph. While lintian will complain about unused license if I seperate the Expat-licnesed files in a seperate file paragraph. What is your recommendation? This email is probably too long... Cheers, Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, 2015-08-21 22:15 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: so basically the tarball found with uscan has nothing in common with the actual Debian packaging? you grab the tarball, you add a build system and you pack again, right? Actually no. I think this needs clarification. The upstream tarball contains .c .h files and some (non-dfsg-compliant) temporary files. The repack script removes the (non-dfsg-compliant) temporary files and move all the .c .h files into a directory called src/. The build system and friends are added by patches (among those 29 patches). nothing, if it is internal used, and not meant to be called by an user it is fine Exactly, it is called internally by debian/watch. actually the pourpose of the watch file is to notify at each new upstream release, but in that way... not sure if we can make it work I think it is okay, just remember to update the version string before every upload since we cannot *compute* the date string (12.11.2014) from the version string (14.1). The version string actually means 1st release in 2014... maybe I didn't explain myself well lines such as # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # “Software”), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # shouldn't (in my opinion) have the starting # I see! I will remove those `#' then. not a problem for me :) Great! This time is much shorter though. Cheers Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package mlucas, I have uploaded a new version of the package to fix issues pointed out by Jakub Wilk, please see previous message in the bug report to see what issues are fixed I will now elaborate more on why this package is suitable for Debian, feel free to skip it __BEGIN_ELABORATION__ Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available software to search for Mersenne prime numbers (quote from Wikipedia). The most popular client `mprime' was available in Debian Potato as the package `prime-net' as shown in this post http://www.mersenneforum.org/showthread.php?t=7181. However, it appears the maintainer had lost interest in it because it was classified as `non-free'. `mlucas' has been developed as an alternative since 1996. While it is not as efficient as `mprime', it is licensed under GPL-2+ and thus suitable to be included in `main'. It has been used in the verification of various Mersenne primes, including the 45th (found in 2008), 46th (found in 2009) and 48th (found in 2013) found Mersenne prime. Therefore, the underlying algorithm is believed to be reliable, thus suitable to be included in Debian. __END_ELABORATION__ * Package name: mlucas Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1+dfsg-1.dsc Changes since the last upload: mlucas (14.1+dfsg-1) UNRELEASED; urgency=low * Initial release (Closes: #786656) -- Alex Vong alexvong1...@gmail.com Sun, 02 Aug 2015 03:13:37 +0800 Cheers, Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi, Actually no. I think this needs clarification. The upstream tarball contains .c .h files and some (non-dfsg-compliant) temporary files. The repack script removes the (non-dfsg-compliant) temporary files and move all the .c .h files into a directory called src/. The build system and friends are added by patches (among those 29 patches). so can't you ask upstream to integrate the build system and sync with them? it isn't a Debian specific feature, and should be upstreamed IMHO. Exactly, it is called internally by debian/watch. fine I think it is okay, just remember to update the version string before every upload since we cannot *compute* the date string (12.11.2014) from the version string (14.1). The version string actually means 1st release in 2014... the problem is that you don't get notified on new releases, and moreover the versioning that upstream does is simply wrong... can't you ask them to follow the always an higher number versioning? I see! I will remove those `#' then. sorry for that, I'm not a native english speaker :) cheers, G.
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Okay. I think this needs further explaination. Upstream does not include a build system, not even a Makefile. Building is done by invoking gcc directly using different flags for different platform. This is however cumbersome, so I add autotools to ease building. I use git for development https://gitlab.com/mlucas-ll/mlucas. The 29 patches can be divided into 3 groups. 0001 - 0012, 0027 are patches related to the source, forwarded upstream to be included in the next version. The rest are patches to add the build system and script to generate man page, NEWS, ChangeLog... Any advice on this? so basically the tarball found with uscan has nothing in common with the actual Debian packaging? you grab the tarball, you add a build system and you pack again, right? I do not understand. What should I do with `source_package_build.bash' ? nothing, if it is internal used, and not meant to be called by an user it is fine Upstream uses Mlucas_MM.DD..tbz2 instead of mlucas_14.1.tar.bz2 for backward capability, so we need to update debian/watch version string for every new release... actually the pourpose of the watch file is to notify at each new upstream release, but in that way... not sure if we can make it work I do it beacuse lintian will complain about empty license if add `License:' in the header paragraph. While lintian will complain about unused license if I seperate the Expat-licnesed files in a seperate file paragraph. What is your recommendation? maybe I didn't explain myself well lines such as # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # “Software”), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # shouldn't (in my opinion) have the starting # This email is probably too long... not a problem for me :) cheers! G.
