Re: New package bali-phy
Hi Andreas,
On 03/09/2018 06:20 PM, Andreas Tille wrote:
Hi again,
On Fri, Mar 09, 2018 at 10:42:11PM +0100, Andreas Tille wrote:
I wondered about this. I was unsure if /usr/share/doc/ is a good place for
non-Debian systems, so I did not change the upstream default. But for
Debian it is indeed the natural place for me to look. It seems there are a
few options:
1. Change upstream to install to /usr/share/doc/ everywhere
2. Edit meson.build to put the examples in /usr/share/doc/
3. #2 + make symlink to /usr/share//examples
4. Make a symlink from /usr/share/doc//examples to
/usr/share//examples
I'm not sure #1 works everywhere. #2 has the problem that the path to the
examples would be distribution-dependent. #3 and #4 both seem OK though.
I admit I have no real preference. I can not see any problem in #1 in
general but I'll leave the freedom of decision to you.
That's now the last open question.
I guess you are right. I changed the upstream default to put the
examples in /usr/share/doc.
I also updated README.{html,xhtml,pdf} to mention the new location. I
can tag this as 3.0.2 if that makes life easier, since I'm not sure how
to modify README.pdf with a patch.
how to do it. Do we do this with a quilt patch? Because that would be a
very large patch, and I didn't like the idea of removing the local boost via
a patch that was the same size as boost :-P But it is not really
important. Also, if we strip them out, do they still need to be in the
copyright file? That would shrink the copyright file nicely.
I'll take this as agreement that I'll do what I suggested as an example
and will confirm here once this is done (probably tomorrow).
Done now.
OK, thanks.
In addition, anything from the autotools build system can also be removed.
This includes:
m4/
configure.ac
bootstrap.sh
scripts/git_version.sh
$(find . -name Makefile.am)
I'll do this as well.
Besides these I removed src/dlfcn-win32
Please check and confirm that you are OK with this solution.
That looks good.
-BenRI
Re: New package bali-phy
Hi again, On Fri, Mar 09, 2018 at 10:42:11PM +0100, Andreas Tille wrote: > > I wondered about this. I was unsure if /usr/share/doc/ is a good place for > > non-Debian systems, so I did not change the upstream default. But for > > Debian it is indeed the natural place for me to look. It seems there are a > > few options: > > 1. Change upstream to install to /usr/share/doc/ everywhere > > 2. Edit meson.build to put the examples in /usr/share/doc/ > > 3. #2 + make symlink to /usr/share//examples > > 4. Make a symlink from /usr/share/doc//examples to > > /usr/share//examples > > I'm not sure #1 works everywhere. #2 has the problem that the path to the > > examples would be distribution-dependent. #3 and #4 both seem OK though. > > I admit I have no real preference. I can not see any problem in #1 in > general but I'll leave the freedom of decision to you. That's now the last open question. > > how to do it. Do we do this with a quilt patch? Because that would be a > > very large patch, and I didn't like the idea of removing the local boost via > > a patch that was the same size as boost :-P But it is not really > > important. Also, if we strip them out, do they still need to be in the > > copyright file? That would shrink the copyright file nicely. > > I'll take this as agreement that I'll do what I suggested as an example > and will confirm here once this is done (probably tomorrow). Done now. > > In addition, anything from the autotools build system can also be removed. > > This includes: > > m4/ > > configure.ac > > bootstrap.sh > > scripts/git_version.sh > > $(find . -name Makefile.am) > > I'll do this as well. Besides these I removed src/dlfcn-win32 Please check and confirm that you are OK with this solution. Kind regards Andreas. -- http://fam-tille.de
Re: New package bali-phy
Hi Benjamin, On Fri, Mar 09, 2018 at 10:40:11AM -0500, Benjamin Redelings wrote: > > I've added pristine-tar as per policy[1], removed the redundant > > debian/gbp.conf and changed the formatting of the d/control file > > using `cme fix dpkg-control` to have some consistent formatting > > between other Debian Med packages. > OK, I see, thanks. I had a local pristine-tar branch from gbp but I guess I > did not push it. I will fix up the local branch to point to the remote > branch. I admit that I somehow expected something like this but creating the branch on my own was the faster way to check the packaging. > > I also added a spelling fix as quilt patch. I'm not always that picky > > but since you are upstream you most probably want to fix this in your > > code as well. Hint: If you are runnin lintian with -I option you get > > also those issues. > Ah, it is nice to see an example quilt patch, and thanks for the advice on > lintian -I! Now I can see the error. I fixed the typo upstream, so I guess > we can remove the typo patch in the next release. Yes, for sure it is the intention that it will be fixed upstream. > > Something you might like to consider is the location of the examples > > which is currently in /usr/share/bali-phy/examples. In Debian users are > > used to check /usr/share/doc/PACKAGENAME/examples (no idea how many > > users are *really* trained to look there - but at least this is the > > recommended location). Moreover if we have some autopkgtest which is > > providing some kind of example usage I tend to put this script as well > > in this location and add a README.test that enables users on their local > > machine to reproduce these tests as examples. > I wondered about this. I was unsure if /usr/share/doc/ is a good place for > non-Debian systems, so I did not change the upstream default. But for > Debian it is indeed the natural place for me to look. It seems there are a > few options: > 1. Change upstream to install to /usr/share/doc/ everywhere > 2. Edit meson.build to put the examples in /usr/share/doc/ > 3. #2 + make symlink to /usr/share//examples > 4. Make a symlink from /usr/share/doc//examples to > /usr/share//examples > I'm not sure #1 works everywhere. #2 has the problem that the path to the > examples would be distribution-dependent. #3 and #4 both seem OK though. I admit I have no real preference. I can not see any problem in #1 in general but I'll leave the freedom of decision to you. > Putting the autopkgtest scripts in the doc directory seems like a good idea, > as does adding a README.test . How do you get the test scripts put in the > doc directory, though? May be you have a look into the (totally random!) example mrbayes[1]. This puts all tests into one script run-unit-test. In debian/docs these files are installed into the doc directory. > > If you agree with this approach I can do this for you as a simple > > example since with Files-Excluded in d/copyright this is pretty easy > > to do. In other words: The package is OK in principle and I could > > upload as is. So if you prefer an untouched upstream tarball that > > should be fine. But I personally would strip third party source and > > if you want me to do this for you I can do before uploading. > I very much like the idea of stripping out these things, but I wasn't sure > how to do it. Do we do this with a quilt patch? Because that would be a > very large patch, and I didn't like the idea of removing the local boost via > a patch that was the same size as boost :-P But it is not really > important. Also, if we strip them out, do they still need to be in the > copyright file? That would shrink the copyright file nicely. I'll take this as agreement that I'll do what I suggested as an example and will confirm here once this is done (probably tomorrow). > In addition, anything from the autotools build system can also be removed. > This includes: > m4/ > configure.ac > bootstrap.sh > scripts/git_version.sh > $(find . -name Makefile.am) I'll do this as well. > > Thanks again for your work on this > I'm glad to help. Thanks also for your help in cleaning up the packaging! You are welcome Andreas. [1] https://anonscm.debian.org/git/debian-med/mrbayes.git -- http://fam-tille.de
Re: New package bali-phy
Hi Andreas, On 03/08/2018 11:41 PM, Andreas Tille wrote: Hi Benjamin, thanks for packaging bali-phy which looks quite good. You even added autopkgtest which is excellent work. On Thu, Mar 08, 2018 at 05:44:59PM -0500, Benjamin Redelings wrote: I've created a new project on salsa for the software 'bali-phy'. It builds for me with gbp without any lintian warnings, and the installed packages seem to work. Comments? I've added pristine-tar as per policy[1], removed the redundant debian/gbp.conf and changed the formatting of the d/control file using `cme fix dpkg-control` to have some consistent formatting between other Debian Med packages. OK, I see, thanks. I had a local pristine-tar branch from gbp but I guess I did not push it. I will fix up the local branch to point to the remote branch. I also added a spelling fix as quilt patch. I'm not always that picky but since you are upstream you most probably want to fix this in your code as well. Hint: If you are runnin lintian with -I option you get also those issues. Ah, it is nice to see an example quilt patch, and thanks for the advice on lintian -I! Now I can see the error. I fixed the typo upstream, so I guess we can remove the typo patch in the next release. Something you might like to consider is the location of the examples which is currently in /usr/share/bali-phy/examples. In Debian users are used to check /usr/share/doc/PACKAGENAME/examples (no idea how many users are *really* trained to look there - but at least this is the recommended location). Moreover if we have some autopkgtest which is providing some kind of example usage I tend to put this script as well in this location and add a README.test that enables users on their local machine to reproduce these tests as examples. I wondered about this. I was unsure if /usr/share/doc/ is a good place for non-Debian systems, so I did not change the upstream default. But for Debian it is indeed the natural place for me to look. It seems there are a few options: 1. Change upstream to install to /usr/share/doc/ everywhere 2. Edit meson.build to put the examples in /usr/share/doc/ 3. #2 + make symlink to /usr/share//examples 4. Make a symlink from /usr/share/doc//examples to /usr/share//examples I'm not sure #1 works everywhere. #2 has the problem that the path to the examples would be distribution-dependent. #3 and #4 both seem OK though. Putting the autopkgtest scripts in the doc directory seems like a good idea, as does adding a README.test . How do you get the test scripts put in the doc directory, though? Longer term, there is a more thorough testsuite in master/tests that I use for upstream CI. So far for the cosmetical things. There is one issue left which I would like to discuss: In external/ dir there are code copies of Debian packaged libraries. I noticed that you have added all those libraries as Build-Depends and thus I assume the build is clean and is using the Debian packaged versions. My way to deal with this kind of third party software in upstream sources is to remove them completely from the tarball. This has two advantages: 1. I can be *really* sure that the Debian packaged version is used 2. It saves me work from mentioning the stuff in d/copyright (which can be quite complex some times) If you agree with this approach I can do this for you as a simple example since with Files-Excluded in d/copyright this is pretty easy to do. In other words: The package is OK in principle and I could upload as is. So if you prefer an untouched upstream tarball that should be fine. But I personally would strip third party source and if you want me to do this for you I can do before uploading. I very much like the idea of stripping out these things, but I wasn't sure how to do it. Do we do this with a quilt patch? Because that would be a very large patch, and I didn't like the idea of removing the local boost via a patch that was the same size as boost :-P But it is not really important. Also, if we strip them out, do they still need to be in the copyright file? That would shrink the copyright file nicely. In addition, anything from the autotools build system can also be removed. This includes: m4/ configure.ac bootstrap.sh scripts/git_version.sh $(find . -name Makefile.am) Thanks again for your work on this I'm glad to help. Thanks also for your help in cleaning up the packaging! -BenRI
Re: New package bali-phy
Hi Benjamin, thanks for packaging bali-phy which looks quite good. You even added autopkgtest which is excellent work. On Thu, Mar 08, 2018 at 05:44:59PM -0500, Benjamin Redelings wrote: > I've created a new project on salsa for the software 'bali-phy'. It > builds for me with gbp without any lintian warnings, and the installed > packages seem to work. Comments? I've added pristine-tar as per policy[1], removed the redundant debian/gbp.conf and changed the formatting of the d/control file using `cme fix dpkg-control` to have some consistent formatting between other Debian Med packages. I also added a spelling fix as quilt patch. I'm not always that picky but since you are upstream you most probably want to fix this in your code as well. Hint: If you are runnin lintian with -I option you get also those issues. Something you might like to consider is the location of the examples which is currently in /usr/share/bali-phy/examples. In Debian users are used to check /usr/share/doc/PACKAGENAME/examples (no idea how many users are *really* trained to look there - but at least this is the recommended location). Moreover if we have some autopkgtest which is providing some kind of example usage I tend to put this script as well in this location and add a README.test that enables users on their local machine to reproduce these tests as examples. So far for the cosmetical things. There is one issue left which I would like to discuss: In external/ dir there are code copies of Debian packaged libraries. I noticed that you have added all those libraries as Build-Depends and thus I assume the build is clean and is using the Debian packaged versions. My way to deal with this kind of third party software in upstream sources is to remove them completely from the tarball. This has two advantages: 1. I can be *really* sure that the Debian packaged version is used 2. It saves me work from mentioning the stuff in d/copyright (which can be quite complex some times) If you agree with this approach I can do this for you as a simple example since with Files-Excluded in d/copyright this is pretty easy to do. In other words: The package is OK in principle and I could upload as is. So if you prefer an untouched upstream tarball that should be fine. But I personally would strip third party source and if you want me to do this for you I can do before uploading. Thanks again for your work on this Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html#git-tips -- http://fam-tille.de
New package bali-phy
Hi, I've created a new project on salsa for the software 'bali-phy'. It builds for me with gbp without any lintian warnings, and the installed packages seem to work. Comments? -BenRI
