Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

[Gianfranco Costamagna]

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
>,
>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 tarball>is now 
>DFSG-Free.



that is nice!

cheers,

G.

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

[Alex Vong]

Hi Gianfranco,

An old message is inlined below.

2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna
:
> 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
,
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: Fwd: Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

[Gianfranco Costamagna]

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

[Alex Vong]

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" 
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 

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

[Gianfranco Costamagna]

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

[Alex Vong]

Hi Gianfranco,

2015-08-21 22:15 GMT+08:00, Gianfranco Costamagna
:
> 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

[Gianfranco Costamagna]

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 . 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.

Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number

[Alex Vong]

Hi Gianfranco,

Thanks for the quick reply, I have just finished dinner.

2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna
:
> 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 . 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

[Gianfranco Costamagna]

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  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
. 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 
* 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   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

[Alex Vong]

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
. 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 
* 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   Sun, 02 Aug 2015 03:13:37 +0800

Cheers,
Alex