Re: [Help] Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]
I should note that the new version now has a dependency on libcereal-dev for serialization. -BenRI On 6/20/24 11:16 PM, Benjamin Redelings wrote: Thanks a lot from me as well! I see the 4.0-beta13 version in experimental now. I noticed that some of the tests for 4.0-beta13 passed, but some timed out.: https://salsa.debian.org/med-team/bali-phy/-/jobs/5786155 I have released a 4.0-beta14 that decreases startup times, so that the tests run more quickly. Hopefully this will prevent timeouts in future packaged versions. -BenRI On 5/30/24 1:31 AM, Andreas Tille wrote: Am Wed, May 29, 2024 at 09:39:01AM +0200 schrieb Étienne Mollier: I'm having a look at BAli-Phy 4.0 beta 13 and after a few adjustments, I see the test suite is passing alright. I pushed my changes on salsa and am preparing an experimental upload. Thanks a lot Andreas.
Re: [Help] Re: [bredelings/BAli-Phy] Test suite error in 4.0-beta7 (Issue #17)]
Thanks a lot from me as well! I see the 4.0-beta13 version in experimental now. I noticed that some of the tests for 4.0-beta13 passed, but some timed out.: https://salsa.debian.org/med-team/bali-phy/-/jobs/5786155 I have released a 4.0-beta14 that decreases startup times, so that the tests run more quickly. Hopefully this will prevent timeouts in future packaged versions. -BenRI On 5/30/24 1:31 AM, Andreas Tille wrote: Am Wed, May 29, 2024 at 09:39:01AM +0200 schrieb Étienne Mollier: I'm having a look at BAli-Phy 4.0 beta 13 and after a few adjustments, I see the test suite is passing alright. I pushed my changes on salsa and am preparing an experimental upload. Thanks a lot Andreas.
Re: New version bali-phy 4.0-beta2
Hi, Thanks for the advice! On 3/29/23 3:04 PM, Andreas Tille wrote: Hi Benjamin, Am Tue, Mar 28, 2023 at 07:04:52AM +0200 schrieb Pierre Gruet: Probably you wouold like to do something as in https://sources.debian.org/src/gedit-plugins/44.1-2/debian/watch/?hl=2#L2 for the gedit-plugins package? This was found by typing "path:debian/watch beta" in the search field of sources.debian.org. There are other packages which you could check there. ACK. I tried a few things, but haven't figured this out yet. I see there is versionmangle, dversionmangle, and uversionmangle. I see that we want the debian version to be 4.0~beta2, not 4.0-beta2 (i.e. with a tilde). I will try again later. Secondly, I suppose that any new version would need to go into experimental, since we are in a hard freeze? I would like to start working on packaging for version 4 now, since some things have changed and I'd like to figure out how to deal with them now. Yes, uploading to experimental is the right thing to do right now :) I'm wondering whether any beta versions should go to experimental in general. The fact that upstream marks it as beta is usually a sign that the code is not for end users production systems. I wrote a couple of watch files that do not even report any alpha/beta versions as new version. I am the upstream :-) I understand the reasoning though. I don't think you should package all betas, but in this case (i.e. for version 4.0-beta2), as the upstream I feel like its the right thing to do. I could relabel this as version 4.0, but I would prefer not to, since there are some features that I want to add before I label this as 4.0. Perhaps this does not matter, since it would be uploaded to experimental anyway. -BenRI Kind regards Andreas.
New version bali-phy 4.0-beta2
Hi, I'd like to upload a new version 4.0-beta2 of bali-phy. It decreases memory usage over the existing 3.6.1 by > 20fold in some cases. The first question I have is about using uscan with the "-beta2" suffix. I hacked the debian/watch file to make uscan recognize the tag name, but now its creating a dfsg source file called `bali-phy_4.0+dfsg.orig.tar.xz`. I suspect this should really be called `bali-phy_4.0-beta2+dfsg.orig.tar.xz`. Any guidance on how to handle -beta versions? I guess normally we may not want these, but in this case I think we do. Secondly, I suppose that any new version would need to go into experimental, since we are in a hard freeze? I would like to start working on packaging for version 4 now, since some things have changed and I'd like to figure out how to deal with them now. -BenRI
Re: New bali-phy version 3.6.0 and some lintian questions
Hi Andreas, Thanks for the feedback! I pushed my changes to salsa, and I think I have incorporated all of your feedback except about the empty directory. I: bali-phy: package-contains-empty-directory usr/share/doc/bali-phy/examples/models/regresssion/ Well, is this really intended to have an empty directory here? WHat is the purpose? So models/regression is a symlink, and it looks like meson doesn't install it. This is an installation bug that I never noticed before. Meson creates the directory that the symlink points to, but does not put anything inside it. Meson will soon stop following symlinks during installation, so fixing this behavior in meson is probably not worth it. In practice, the missing directory doesn't matter. I am probably going to delete the symlink in the next major upstream version. I don't want to make an upstream point release to fix this, since it is not really broken. However, I looked at two things to make the warning message go away: - I tried to remove the symlink with quilt, but quilt won't handle deleting a symlink - The lintian docs suggest adding `find path/to/base/dir -type d -empty -delete` to debian/rules, but its not clear that there is always a hard-coded path/to/base/dir. I could add a lintian override, also. What do you prefer? -BenRI
Re: New bali-phy version 3.6.0 and some lintian questions
Hi Andreas, I pushed a new version to salsa. Could you upload this for me if it seems OK? -BenRI On 2/5/21 7:26 PM, Benjamin Redelings wrote: Hi, I'm getting ready to upload changes for bali-phy version 3.6.0 to the repo on salsa. Building the new version was pretty smooth, but I got some lintian "I" tags in testing that I don't remember seeing before. Here's the lintian output from pbuilder +++ lintian output +++ su: warning: cannot change directory to /nonexistent: No such file or directory I: bali-phy: hardening-no-fortify-functions usr/bin/alignment-cat I: bali-phy: hardening-no-fortify-functions usr/bin/alignment-chop-internal I: bali-phy: hardening-no-fortify-functions usr/bin/alignment-consensus I: bali-phy: hardening-no-fortify-functions ... use --no-tag-display-limit to see all (or pipe to a file/program) I: bali-phy: package-contains-documentation-outside-usr-share-doc usr/lib/bali-phy/help/alphabets.txt I: bali-phy: package-contains-documentation-outside-usr-share-doc usr/lib/bali-phy/help/alphabets/Codons.txt I: bali-phy: package-contains-documentation-outside-usr-share-doc usr/lib/bali-phy/help/alphabets/Doublets.txt I: bali-phy: package-contains-documentation-outside-usr-share-doc ... use --no-tag-display-limit to see all (or pipe to a file/program) I: bali-phy: package-contains-empty-directory usr/share/doc/bali-phy/examples/models/regresssion/ I: bali-phy: unused-override spelling-error-in-binary usr/bin/statreport AfE Safe +++ end of lintian output +++ 1. The package-contains-documentation-outside-usr-share-doc are all wrong -- these files are not documentation. 2. I'm curious about the `hardening-no-fortify-functions` tags. It seems that the -D_FORTIFY_SOURCE=2 is indeed getting passed to the compiler, but it looks like all the executables are still getting flagged as unfortified anyway. Is there a way to look into this further? Thanks! -BenRI On 1/22/19 11:28 AM, Benjamin Redelings wrote: Hi Andreas, I pushed bali-phy version 3.4.1 to the salsa repo. (This version fixes some bugs in version 3.4.0 that are important for usability, but is not a major update.) In any case, can you please upload it for me? Thank you! -BenRI
New bali-phy version 3.6.0 and some lintian questions
Hi, I'm getting ready to upload changes for bali-phy version 3.6.0 to the repo on salsa. Building the new version was pretty smooth, but I got some lintian "I" tags in testing that I don't remember seeing before. Here's the lintian output from pbuilder +++ lintian output +++ su: warning: cannot change directory to /nonexistent: No such file or directory I: bali-phy: hardening-no-fortify-functions usr/bin/alignment-cat I: bali-phy: hardening-no-fortify-functions usr/bin/alignment-chop-internal I: bali-phy: hardening-no-fortify-functions usr/bin/alignment-consensus I: bali-phy: hardening-no-fortify-functions ... use --no-tag-display-limit to see all (or pipe to a file/program) I: bali-phy: package-contains-documentation-outside-usr-share-doc usr/lib/bali-phy/help/alphabets.txt I: bali-phy: package-contains-documentation-outside-usr-share-doc usr/lib/bali-phy/help/alphabets/Codons.txt I: bali-phy: package-contains-documentation-outside-usr-share-doc usr/lib/bali-phy/help/alphabets/Doublets.txt I: bali-phy: package-contains-documentation-outside-usr-share-doc ... use --no-tag-display-limit to see all (or pipe to a file/program) I: bali-phy: package-contains-empty-directory usr/share/doc/bali-phy/examples/models/regresssion/ I: bali-phy: unused-override spelling-error-in-binary usr/bin/statreport AfE Safe +++ end of lintian output +++ 1. The package-contains-documentation-outside-usr-share-doc are all wrong -- these files are not documentation. 2. I'm curious about the `hardening-no-fortify-functions` tags. It seems that the -D_FORTIFY_SOURCE=2 is indeed getting passed to the compiler, but it looks like all the executables are still getting flagged as unfortified anyway. Is there a way to look into this further? Thanks! -BenRI On 1/22/19 11:28 AM, Benjamin Redelings wrote: Hi Andreas, I pushed bali-phy version 3.4.1 to the salsa repo. (This version fixes some bugs in version 3.4.0 that are important for usability, but is not a major update.) In any case, can you please upload it for me? Thank you! -BenRI
bali-phy: version 3.4.1
Hi Andreas, I pushed bali-phy version 3.4.1 to the salsa repo. (This version fixes some bugs in version 3.4.0 that are important for usability, but is not a major update.) In any case, can you please upload it for me? Thank you! -BenRI
Build problems on amd64/armhf
Hi, My software bali-phy is having build failures on amd64 with hardware floating-point (armhf) that don't occur on x86-64, and seemingly do not occur with software floating-point (armel). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=918047 The bug seems to come from NaN's getting generated on arm64/armhf that do not occur on x86-64. Further inspection of the build log shows that the same bug occurs on hppa, but no other architectures. I will investigate further (for example, turning off -ffast-math on x86-64) but the obvious route would be to run a debugger on hardware where the bug can be reproduced. Any suggestions on how to deal with this? -BenRI
bali-phy: version 3.4
Hi Andreas, I pushed a new version of bali-phy (version 3.4) to the salsa repo. Can you please upload it for me? Thanks! -BenRI
New version of bali-phy
Hi Andreas, I pushed a new version of bali-phy (version 3.3) to the salsa repo. The debian build process hasn't changed this round, but the package has some nice improvements. Can you please upload it for me? -BenRI
Re: Fwd: New bali-phy version
OK, I figured this out, now that I can debug the pbuilder fails. Thanks! On 05/05/2018 08:13 PM, Andreas Tille wrote: On Sat, May 05, 2018 at 04:41:59PM +0200, Andreas Tille wrote: FileNotFoundError: [Errno 2] No such file or directory: '/build/bali-phy-3.1+dfsg/tests/run-tests.py': '/build/bali-phy-3.1+dfsg/tests/run-tests.py' No idea why this error message was printed. What was really missing was /usr/bin/python. I've added this in my latest commit to the Build-Depends. Missing Build-Depends are usually causing issued between a build on the local machine compared to pbuilder. Yeah, that was a misleading error message from meson. It was actually failing to find python to run the script. I removed the Build-Depends on python 2, and added a quilt patch to change the interpreter to /usr/bin/python3. I might change this upstream, if this also work on homebrew, although on homebrew it is not necessary since /usr/bin/python recently changed to point to python3 So while this is solved now I get a set of other errors: ... 28/28 bali-phy testsuite FAIL63.29 s OK:27 FAIL: 1 SKIP: 0 TIMEOUT:0 The output from the failed tests: 28/28 bali-phy testsuite FAIL63.29 s --- command --- /build/bali-phy-3.1.1+dfsg/tests/run-tests.py /build/bali-phy-3.1.1+dfsg/obj-x86_64-linux-gnu/src/bali-phy --package-path=/build/bali-phy-3.1.1+dfsg/obj-x86_64-linux-gnu/src/builtins:/build/bali-phy-3.1.1+dfsg --- Listing only the last 100 lines from a long log. --- Running test: parse/partitions/link/5 ... FAIL! ['error'] Running test: parse/partitions/link/7 ... FAIL! ['error'] Running test: parse/partitions/link/1 ... ok Running test: parse/partitions/link/4 ... FAIL! ['error'] ... Running test: prob_prog/if-then-else/1 ... ok Running test: IO/errors/Codons/2 ... FAIL! ['error'] Running test: IO/errors/Codons/stop/2 ... FAIL! ['error'] Running test: IO/errors/Codons/stop/1 ... FAIL! ['error'] Running test: IO/errors/Codons/AUTGC ... FAIL! ['error'] Running test: IO/errors/Codons/3 ... FAIL! ['error'] Running test: IO/errors/Codons/1 ... FAIL! ['error'] Running test: IO/errors/Triplets/2 ... FAIL! ['error'] Running test: IO/errors/Triplets/AUTGC ... FAIL! ['error'] Running test: IO/errors/Triplets/1 ... FAIL! ['error'] Running test: IO/errors/DNA-RNA/2 ... FAIL! ['error'] Running test: IO/errors/DNA-RNA/3 ... FAIL! ['error'] Running test: IO/errors/DNA-RNA/1 ... FAIL! ['error'] FAIL! (41 unexpected failures, 2 expected failures, 91 tests total) --- Full log written to /build/bali-phy-3.1.1+dfsg/obj-x86_64-linux-gnu/meson-logs/testlog.txt FAILED: meson-test /usr/bin/python3 -u /usr/bin/meson test --no-rebuild --print-errorlogs ninja: build stopped: subcommand failed. If the build works on your local machine I'd recommend to seek for 1. Further missing Build-Depends 2. Attempts to access remote resources (which is not possible in pbuilder) The extra error indirectly resulted from the fact that pbuilder runs the tests with HOME=/nonexistant. This caused an extra error message. I changed the test script to stop requiring that the error messages are EXACTLY x, but that instead the error messages contain all lines in x. As a result, I can now build the package with gbp buildpackage @ pbuilder. The repo on salsa should be up-to-date now. Moreover I'd recommend to switch to Python3. The test script works in both python2 and python3. So the question is just whether /usr/bin/python3 is a usable name on other OSs where /usr/bin/python just works. I suspect it is. macosports wants /usr/bin/env python, since they don't want to run the python from /usr/bin, but that sounds like a security risk to me... Hope this helps Very much! thanks, -BenRI
Re: Fwd: New bali-phy version
Hi Andreas, On 05/05/2018 05:41 PM, Andreas Tille wrote: Hi Benjamin, On Sat, May 05, 2018 at 02:56:56PM +0200, Benjamin Redelings wrote: uscan --verbose --force-download gbp import-orig --pristine-tar bali-phy_3.1+dfsg.orig.tar.xz since the pristine-tar branch was not populated. Either you forgot the import-orig step or you did not pushed. 1. Hmm... yes I think I only pushed master. My workflow notes now look like this: % uscan --verbose --force-download % gbp import-orig --pristine-tar ../bali-phy_+dfsg.orig.tar.xz % gbp dch % git push origin --all % debuild -S % cd .. % sudo pdebuild --update % sudo pdebuild --build bali-phy_version.dsc Does this look right? This does not look wrong but it is not needed to force `git push --all`. I only use gbp clone ... git push This might depend on git config push.default . I think if the value is "simple", then you need --all to push the pristine-tar and upstream branches. which pushes branch master, upstream and pristine-tar. Moreover, I'd recommend to use gbp-buildpackage This is helpful. Currently, this is not calling the hook scripts, so I used cowbuilder to run the hook scripts, and then gbp-buildpackage to build a full package. I have modified /etc/pbuilder/buildd-config.sh to set HOOKDIR=/var/cache/pbuilder/hooks, and added a hookfile C10_something to /root/.pbuilder/hooks and /home/bredelings/.pbuilder/hooks and /var/cache/pbuilder/hooks but gbp-buildpackage is still not calling the hooks on failure. instead of sudo pdebuild --build in any case the sudo should not be needed here. May be you re-read Debian Med policy about how to use gbp. Please also let us know if this documentation is not really helpful - than we need to enhance it to make it better. Hmm... I somehow have a hard time using the debian-med policy as a guide, whereas other documentation like the new maintainer's guide is easier to follow. It feels like the debian-med policy is aimed at people who already understand debian packaging. For example, it says "set the devscripts variables DEBEMAIL and DEBFULLNAME", but does not say that this means editting ~/.devscripts to set environment variables. The "git tips" section also feels like it is full of lots of pieces of information that I have a hard time connecting. My apologies for being slow at this! In general, I think learning how to package for Debian is a confusing process, because there are so many different documents one needs to read, and they all have a different style for managing packages. As a result, I think being able to ask questions in person has been very helpful. 1. For the debian-med policy, would it be possible to generate the HTML version so that the section headings are numbered? I think this would make the structure more clear. 2. The git tips section has many little tips, but perhaps it could be organized into (a) an overview of setting up and updating package repos and (b) an FAQ-type section. I mostly need part (a). This could maybe be chronologically organized into (a.1) setting up config files (a.2) creating a new local git repo, and (a.3) updating the repo for a new version. 3. There is a nice sequence of commands for "To create a new local git repository" (a.2). Can we add a recommended sequence of commands for "Adding a new upstream release to the repo"? (a.3) Maybe it would look a little bit like this? % uscan --verbose --force-download % gbp import-orig --pristine-tar ../PKG_VERSION.orig.tar.xz % gbp dch % gbp-buildpackage // run pbuilder to build in a chroot % git push --all % git push --tags I think it is very helpful to have a basic working set of commands like this. People can then play around with these command, read the man pages, etc. Right now the policy doesn't say anything about uscan, and that is a big time-saver. However, it does seem like you have to set up a number of config files for gbp-buildpackage to actually work, and also probably run 'pbuilder --create --distribution sid' first, or something like that. 4. I suspect that some of this chould go upstream to the new maintainers guide. The workflow there probably works fine. But this stuff about using uscan and gbp is entirely missing from section 8.3 "New upstream release", which could more accurately be called "New upstream release (without git)". 5. It might be worth mentioning the pbuilder hook for debugging build problems. pbuilder has a large learning curve, and it wasn't immediately clear what the hooks were for. So, it could have taken me a very long time to figure this out. Anyway, I hope I am not causing trouble, and I hope these comments from a beginner are helpful. FileNotFoundError: [Errno 2] No such file or directory: '/build/bali-phy-3.1+dfsg/tests/run-tests.py': '/build/bali-phy-3.1+dfsg/tests/run-tests.py' FAILED: m
Re: Fwd: New bali-phy version
Hi Andreas, On 05/04/2018 09:14 AM, Andreas Tille wrote: Hi Benjamin, I've done uscan --verbose --force-download gbp import-orig --pristine-tar bali-phy_3.1+dfsg.orig.tar.xz since the pristine-tar branch was not populated. Either you forgot the import-orig step or you did not pushed. 1. Hmm... yes I think I only pushed master. My workflow notes now look like this: % uscan --verbose --force-download % gbp import-orig --pristine-tar ../bali-phy_+dfsg.orig.tar.xz % gbp dch % git push origin --all % debuild -S % cd .. % sudo pdebuild --update % sudo pdebuild --build bali-phy_version.dsc Does this look right? So there might be some difference to your local Git repository and there is a slight chance that this is causing the following build error (even if I doubt this reason for the issue): ... 25/28 trees-distances --help OK 0.01 s 26/28 alignment-thin --help OK 0.01 s 27/28 alignments-diff --help OK 0.01 s Traceback (most recent call last): File "/usr/bin/meson", line 26, in sys.exit(main()) File "/usr/bin/meson", line 23, in main return mesonmain.run(sys.argv[1:], launcher) File "/usr/share/meson/mesonbuild/mesonmain.py", line 278, in run return mtest.run(remaining_args) File "/usr/share/meson/mesonbuild/mtest.py", line 712, in run return th.doit() File "/usr/share/meson/mesonbuild/mtest.py", line 463, in doit self.run_tests(tests) File "/usr/share/meson/mesonbuild/mtest.py", line 621, in run_tests self.drain_futures(futures) File "/usr/share/meson/mesonbuild/mtest.py", line 637, in drain_futures self.process_test_result(result.result()) File "/usr/lib/python3.6/concurrent/futures/_base.py", line 425, in result return self.__get_result() File "/usr/lib/python3.6/concurrent/futures/_base.py", line 384, in __get_result raise self._exception File "/usr/lib/python3.6/concurrent/futures/thread.py", line 56, in run result = self.fn(*self.args, **self.kwargs) File "/usr/share/meson/mesonbuild/mtest.py", line 232, in run return self._run_cmd(wrap + cmd + self.test.cmd_args + self.options.test_args) File "/usr/share/meson/mesonbuild/mtest.py", line 276, in _run_cmd preexec_fn=preexec_fn if not is_windows() else None) File "/usr/lib/python3.6/subprocess.py", line 709, in __init__ restore_signals, start_new_session) File "/usr/lib/python3.6/subprocess.py", line 1344, in _execute_child raise child_exception_type(errno_num, err_msg, err_filename) FileNotFoundError: [Errno 2] No such file or directory: '/build/bali-phy-3.1+dfsg/tests/run-tests.py': '/build/bali-phy-3.1+dfsg/tests/run-tests.py' FAILED: meson-test /usr/bin/python3 -u /usr/bin/meson test --no-rebuild --print-errorlogs ninja: build stopped: subcommand failed. dh_auto_test: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 ninja test returned exit code 1 make: *** [debian/rules:12: build] Error 1 dpkg-buildpackage: error: debian/rules build gave error exit status 2 ... Can you please get a fresh clone and check the potential diff? 2. This is strange. I can reproduce the error, but I don't understand it. The file really should be there. Also, this does not happen if I just use debuild instead of using pbuilder. Um, pbuilder seems quite good at cleaning up after itself. Is it possible to log in with the build directory untouch and figure out where the errors are coming from? I haven't managed to figure this out yet... PS: The next days I'm not as active as usual - please excuse any delays from my side. No worries, thanks for any help! It still seems pretty quick. -BenRI
Fwd: New bali-phy version
Forgot to Cc list. Forwarded Message Subject:New bali-phy version Date: Thu, 3 May 2018 17:23:38 -0400 From: Benjamin Redelings <benjamin.redeli...@gmail.com> To: Andreas Tille <andr...@an3as.eu> Hi Andreas, I've updated the bali-phy repo on salsa for a new version (3.1). I added a single patch; I'll fix this upstream before the next version. I don't think I can upload, so if that's right, can you check the new version and upload for me? -BenRI
Fwd: Re: Help with new package version?
Forgot to Cc this to the list. Forwarded Message Subject:Re: Help with new package version? Date: Fri, 20 Apr 2018 08:44:23 -0400 From: Benjamin Redelings <benjamin.redeli...@gmail.com> To: Andreas Tille <andr...@an3as.eu> Hi Andreas, Sorry for the delay in responding. To clarify, I wasn't thinking of maintaining the /debian/ directory in upstream git, but more that I was trying to follow the directions here: https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.upstream-git.html If I understand you correctly, it is easier to simply import tarballs into the salsa repo than to somehow use git to pull upstream commits into the salsa repo. This has the downside that I have to actually make source tarballs solely for this purpose. But on the positive side it would establish a clear namespace separation between e.g. the upstream tags and the debian tags. Also it would be the standard workflow for debian-med. Am I understanding things correctly here? Pending answer to the above question, yes, can you please create a pure packaging-related repository? Once I understand how to perform the gbp magic on this new repository I can be more helpful in releasing new versions. I will probably ask more questions, but you seem to respond pretty quickly, so I guess I should just ask. thank you for your help! -BenRI On 04/20/2018 05:08 AM, Andreas Tille wrote: Hi Benjamin, was this hint helpful? I could volunteer to do the needed steps. However, it would help if you could draw a decision whether you might consider a separate packaging Git repository on salsa.debian.org or whether you intend to continue it beeing a clone of your upstream repository. If you draw a decision I would volunteer to recreate a pure packaging related repository of bali-phy. Kind regards Andreas. On Thu, Mar 29, 2018 at 08:16:54AM +0200, Andreas Tille wrote: Hi Benjamin, On Wed, Mar 28, 2018 at 09:37:05PM -0400, Benjamin Redelings wrote: I've released a new version 3.0.3 of bali-phy, and I realize that I don't understand how to manage the salsa repo using git. I've tried something like this (mostly locally), but I'm pretty sure there is a way of doing this with gbp that is recommended instead: git fetch upstream git fetch upstream --tags git checkout upstream git merge -X theirs 3.0.3 git tag upstream/3.0.3+dfsg git checkout master git merge upstream I assume the problem is that you most probably intend to maintain the Debian repository in your upstream repository. I know that this is somehow possible but I'm lacking experience with this and thus can not give any helpful hint for this approach. We actually had some clones of upstream directories created by other maintainers but I was always running into problems with this (most probably just me!) and since those Debian maintainers got busy with other stuff I turned the repositories in what we consider default repository layout in Debian Med policy[1]. So if qou want to avoid any hassle I'd recommend to do the following: gbp clone g...@salsa.debian.org:med-team/bali-phy.git (may be you rename the resulting dir to bali-phy_debian ??) change to this dir and do uscan --verbose gbp import-orig --pristine-tar This approach is well tested and if something unexpected might happen you can quickly get help here. BTW, I base my assumption that you are using your development Git on the fact that yesterday arrived lots of tags in the Salsa Git repository. I took the freedom to do for tag in `git tag | grep -v -e '^debian' -e '^upstream'` ; do git tag -d $tag git push origin :refs/tags/$tag done since these tags do not make any sense in the current repository on Salsa. I also tried gbp dch, but it tried to create version 3.0.2+dfsg-2 instead of 3.0.3+dfsg-1. Well, dch does not know what version bump you intend to do. Just use your editor to fix the version number. Would it be possible to give me the quick overview? My apologies for the basic nature of this question. Your question is perfectly valid and I'm happy to help. Just keep on with asking about any problem you might face. Hope this helps Andreas. [1] https://debian-med.alioth.debian.org/docs/policy.html#git-repository-structures -- http://fam-tille.de
Help with new package version?
Hi, I've released a new version 3.0.3 of bali-phy, and I realize that I don't understand how to manage the salsa repo using git. I've tried something like this (mostly locally), but I'm pretty sure there is a way of doing this with gbp that is recommended instead: git fetch upstream git fetch upstream --tags git checkout upstream git merge -X theirs 3.0.3 git tag upstream/3.0.3+dfsg git checkout master git merge upstream I also tried gbp dch, but it tried to create version 3.0.2+dfsg-2 instead of 3.0.3+dfsg-1. Would it be possible to give me the quick overview? My apologies for the basic nature of this question. -BenRI
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 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
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
Re: Using recent packages on stable systems (Was: Depends available in other PPA's)
Hi, On 03/08/2018 11:27 AM, Andreas Tille wrote: - a lot of people are going to show up running ubuntu. What might you all recommend? In theory ubuntu people could add debian testing to `apt/sources.list.d`. I do not think that it is a good idea to mix Debian testing with Ubuntu randomversion. IMHO the most sensible way to go would be to use the backporting system the NeuroDebian team has developed. They are doing automatic backports to Debian stable / oldstable and several Ubuntu versions. Its a real pitty that this nifty system is only used by NeuroDebian and nobody took the time to make this a bit more generic to make it useful for all Blends (NeuroDebian team are basically two very kind and helpful but totally overworked people who will not spent their time to port their scripting system for any other use - so we are on our own if we want to use it). Hmm... the 'Get NeuroDebian' section at neuro.debian.net does look nice. I don't suppose the code for the backporting system is hosted at a particular place that I could take a look at? Since I am new I probably couldn't/shouldn't do much, but I would be interested in taking a look. -BenRI
Re: Depends available in other PPA's
Hi, I'm Ben Redelings (http://ben-redelings.org) and I've recently joined debian-med on salsa. I've been thinking about uploading some new phylogenetics / bioinformatics software, partly so that I can tell students in workshops "just type sudo apt-get install if you are running debian or ubuntu". For this use case, I probably can't tell everyone to run debian testing - a lot of people are going to show up running ubuntu. What might you all recommend? In theory ubuntu people could add debian testing to `apt/sources.list.d`. I have no idea how much conflict that would cause - perhaps ubuntu users could set the priority of testing to something lower than ubuntu in apt/preferences. I could also try to make my own PPA called bredelings/bioinformatics or something like this, and only maintain packages that I am interested in... Thoughts? -BenRI On 03/08/2018 07:59 AM, Tony Travis wrote: On 08/03/18 11:37, Andreas Tille wrote: [...] I admit I personally consider maintaining that PPA a nightmare and I personally will not spent any time on it any more (since our the last Ubuntu instance of the users I need to care for was replaced by a pure Debian system). You really need to expect outdated, unmaintained and untested software in this PPA and I wonder whether we should really advertise it if nobody really cares. And sorry, no, I do not consider uploads of random packages at the latest sprint "real care" if there is no bugtracker support, no testing, etc. done. Hi, Andreas. OK, if everyone agrees that this PPA is now redundant I'll abandon any attempt to make use of it in Bio-Linux and, from my point of view, the PPA can be deleted. I'm tempted to remove all of my own uploads to a) make more space which is obviously needed and b) do not feel realiable for breaking any users system. At present, the Debian-Med Ubuntu PPA is not used in Bio-Linux 8.0.8. The only systems that will break if you remove your packages are mine and I'll fix them. Please go ahead and remove your packages and, if you think the PPA is now redundant/harmful I think it should be deleted. Bye, Tony.
Maybe sponsor package under debian-med umbrella?
Hi, I see that many bioinformatics programs such as muscle, mafft, and fsa (alignment) and mrbayes, beast-mcmc, and phyml (phylogenetics), etc. are maintained by the "Debian Med Packaging Team". I uploaded a package for bali-phy (which does simultaneous alignment) to mentors.debian.net. (Disclaimer: I am the author). I was originally planning to try to maintain this on my own, but (supposing people are interesting in this package) would the Debian Med team be a better structure? Many of the programs that I use (such as figtree) are available in Debian now, but a few (e.g. tracer: http://tree.bio.ed.ac.uk/software/tracer/, canu: https://github.com/marbl/canu) are not. I would probably be interested in packaging tracer. Like figtree, it is a java program, and it is by the same authors, so I presume I could use the figtree package as a template. Thoughts? -BenRI
