Re: [RFS] kineticstools 0.6.1+git20200729.e3723e0+dfsg-1
On Thu, Nov 26, 2020 at 12:10:42AM +0100, Étienne Mollier wrote: > ... > I'm conscious of three lintian warnings (the link may be worth > an override, but I'm not sure how to sort the two shared library > issue yet). The open bug will trigger package removal from > testing rather soon, so I have not further delayed. > > If you think the package is in appropriate shape, please either > consider uploading or granting me upload permissions. I think fixing an RC bug beats lintian warnings. Thus I've granted you upload permissions. Thanks a lot for your extensive work on this package Andreas. -- http://fam-tille.de
Re: [RFS] kineticstools 0.6.1+git20200729.e3723e0+dfsg-1
Hi Andreas, Andreas Tille, on 2020-11-26 09:59:03 +0100: > I think fixing an RC bug beats lintian warnings. Thus I've granted > you upload permissions. Thanks a lot for your extensive work on > this package You're welcome, I just uploaded the new version. Have a nice day, :) -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/tty1, please excuse my verbosity. signature.asc Description: PGP signature
Re: [RFS] tortoize
Hi Maarten, thanks a lot for your contribution. On Wed, Nov 25, 2020 at 11:34:55AM +0100, Maarten L. Hekkelman wrote: > I just checked in code for tortoize, an application to calculate > ramachandran z-scores. > > Tortoize validates protein structure models by checking the > Ramachandran plot and side-chain rotamer distributions. Quality > Z-scores are given at the residue level and at the model level > (ramachandran-z and torsions-z). Higher scores are better. To compare > models or to describe the reliability of the model Z-scores jackknife- > based standard deviations are also reported (ramachandran-jackknife-sd > and torsion-jackknife-sd). I changed the autopkgtest a bit. Please stick to the common name for the test script run-unit-test as its in the package template. The rationale is that we can do all package wide changes over the Debian Med packages. Moreover you were refering to the data file in debian/tests. While this is perfectly possible for the autopkgtest in debci it does not help the user who tries to run it on the local machine (as it is explained in the README.test file). So the date file needs to be provided as example *inside* the package - which I did. BTW, it seems to be the same example file in libcifpp. I'd consider it a good idea to have this file only once and set dependencies appropriately. Apropos dependencies: Either tortoize itself has a missing dependency or we need some Test-Depends. When I'm running the test script in my pbuilder chroot I get: + pkg=tortoize + '[' /tmp/autopkgtest.C15beQ/autopkgtest_tmp = '' ']' + cp -a /usr/share/doc/tortoize/examples/1cbs.cif /tmp/autopkgtest.C15beQ/autopkgtest_tmp + cd /tmp/autopkgtest.C15beQ/autopkgtest_tmp + mkdssp 1cbs.cif 1cbs-dssp.cif /tmp/autopkgtest.C15beQ/tree/debian/tests/run-unit-test: line 17: mkdssp: command not found Could you please `gbp pull` and check this situation? Kind regards Andreas. -- http://fam-tille.de
libsis-jhdf5-java hasn't migrated to testing since last 18 days
Hi Pierre and all others, It seems that libsis-jhdf5-java hasn't migrated to testing due to build failure on s390x, log attached[1] This is preventing a chain of other packages which are stalled to testing migration as well. Could you please have a look at this? [1]: https://buildd.debian.org/status/logs.php?arch=s390x&pkg=libsis-jhdf5-java&ver=19.04.0%2Bdfsg-4 Nilesh
Re: libsis-jhdf5-java hasn't migrated to testing since last 18 days
Hi Nilesh, On Thu, Nov 26, 2020 at 06:00:38PM +0530, Nilesh Patra wrote: > It seems that libsis-jhdf5-java hasn't migrated to testing due to build > failure on s390x, log attached[1] > This is preventing a chain of other packages which are stalled to testing > migration as well. > > Could you please have a look at this? Thanks for the heads up. IMHO we should not spent to much time into those architectures that are very uncommon in our field of work. I'm going to file a bug report to remove libsis-jhdf5-java for architecture s390x. May be we can address this later but the migration should not be blocked. Kind regards Andreas. > [1]: > https://buildd.debian.org/status/logs.php?arch=s390x&pkg=libsis-jhdf5-java&ver=19.04.0%2Bdfsg-4 -- http://fam-tille.de
Re: libsis-jhdf5-java hasn't migrated to testing since last 18 days
Hi Nilesh and Andreas, Le 26/11/2020 à 17:14, Andreas Tille a écrit : Hi Nilesh, On Thu, Nov 26, 2020 at 06:00:38PM +0530, Nilesh Patra wrote: It seems that libsis-jhdf5-java hasn't migrated to testing due to build failure on s390x, log attached[1] This is preventing a chain of other packages which are stalled to testing migration as well. Could you please have a look at this? Thanks for the heads up. IMHO we should not spent to much time into those architectures that are very uncommon in our field of work. I'm going to file a bug report to remove libsis-jhdf5-java for architecture s390x. May be we can address this later but the migration should not be blocked. > Thanks for raising the issue; actually it was on my before-bullseye-release todo but I did not have in mind the issue was blocking so many packages. Thus I guess the bug Andreas has filled is the best thing to do for now. Concerning the issue itself, it is raised by the unexpected behaviour of a function which is in the hdf5 source package. This appears while proceeding the tests, so could indicate an issue in hdf5 for s390x or something improperly done within the tests themselves... To be investigated. Kind regards Andreas. Bye, Pierre
Re: mrtrix3
Hi Yaroslav On Wed, Nov 25, 2020 at 08:38:10PM -0500, Yaroslav Halchenko wrote: > Could someone takes a look for final step to cross the line for mrtrix3. $ gbp build-package ... debian/rules override_dh_clean make[1]: Entering directory '/home/andreas/debian-maintain/salsa/med-team/build-area/mrtrix3-3.0.2' ./build clean /usr/bin/env: 'python': No such file or directory make[1]: *** [debian/rules:68: override_dh_clean] Error 127 make[1]: Leaving directory '/home/andreas/debian-maintain/salsa/med-team/build-area/mrtrix3-3.0.2' I think its just because I deinstalled python on my box. > I have pushed added new 3.0.2 release and completely disabled tests > since seems to require data now which is not shipped along AFAIK (but > may be I overreacted). Might just need tune up for python3 though Any reason why you do not upload if you are able to build at your side? What should be checked? You are the expert of this package - no idea what you expect me to do. Kind regards Andreas. > https://salsa.debian.org/med-team/mrtrix3.git > > Cheers and thanks in advance! > -- > Yaroslav O. Halchenko > Center for Open Neuroscience http://centerforopenneuroscience.org > Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 > WWW: http://www.linkedin.com/in/yarik > > -- http://fam-tille.de
Re: [RFS] tortoize
Hi Maarten, On Thu, Nov 26, 2020 at 08:03:18PM +0100, Maarten L. Hekkelman wrote: > Thanks for taking the time to look at tortoize. > > Op 26-11-2020 om 11:16 schreef Andreas Tille: > > I changed the autopkgtest a bit. Please stick to the common name for > > the test script run-unit-test as its in the package template. The > > rationale is that we can do all package wide changes over the Debian > > Med packages. > I copied this from another package, didn't know about this policy yet. > Noted. I recommend https://salsa.debian.org/med-team/community/package_template > > Moreover you were refering to the data file in debian/tests. While > > this is perfectly possible for the autopkgtest in debci it does not > > help the user who tries to run it on the local machine (as it is > > explained in the README.test file). So the date file needs to be > > provided as example *inside* the package - which I did. > Is that the examples file? Yes. > > BTW, it seems to be the same example file in libcifpp. I'd consider it > > a good idea to have this file only once and set dependencies > > appropriately. > This file is very common, I use it in all my PDB related packages. > > I agree that sticking to a single instance is way more convenient. But then > the question is, where do I put this. The libcifpp package contains a -dev > and -doc next to the library. Intuitively I'd say -doc makes sense and let the Test depend from this -doc package. > Perhaps the file should be packaged along with > the library. Since that library is a dependency for all my tools, the > example file would be there too. Fine for me as well. Its not extraordinarily large so that should be fine. > Besides, the autopkgtest of libcifpp uses it as well. Yes, that's what I have noticed. > OK, I'll wait until libcifpp passes the gates in New and will then provide > an update. For all packages. Fine. > > Apropos dependencies: Either tortoize itself has a > > missing dependency or we need some Test-Depends. When I'm running the > > test script in my pbuilder chroot I get: > > > > + pkg=tortoize > > + '[' /tmp/autopkgtest.C15beQ/autopkgtest_tmp = '' ']' > > + cp -a /usr/share/doc/tortoize/examples/1cbs.cif > > /tmp/autopkgtest.C15beQ/autopkgtest_tmp > > + cd /tmp/autopkgtest.C15beQ/autopkgtest_tmp > > + mkdssp 1cbs.cif 1cbs-dssp.cif > > /tmp/autopkgtest.C15beQ/tree/debian/tests/run-unit-test: line 17: mkdssp: > > command not found > > > > Could you please `gbp pull` and check this situation? > > Ooops... I really need to write that text-editor without copy/paste... I've > been burned way too often by that feature. The test should or course run > tortoize, not mkdssp. I updated the dssp package as well. :-) Kind regards Andreas. -- http://fam-tille.de
Packaging Jalview -- any general guidelines concerning privacy?
Hello, I'm currently on the packaging of Jalview. I would like to get some advice as Jalview upstream is collecting statistics on its use through the Internet. Basically this amounts to 4 things, I'm quoting/commenting their documentation: - HTTP logs on the Jalview website We record IP addresses of machines which access the web site, either via the browser when downloading the application, or when the Jalview Desktop user interface is launched. - Questionnaires, from time to time The questionnaire web service at www.jalview.org/cgi-bin/questionnaire.pl is checked and a unique cookie for the current questionnaire is stored in the Jalview properties file. - The Jalview web services stack is contacted to retrieve the currently available web services. All interactions with the public Jalview web services are logged, but we delete all job data (input data and results) after about two weeks. - Google Analytics, used if user explicitly consents Since Jalview 2.4.0b2, the Jalview Desktop records usage data with Google Analytics via the JGoogleAnalytics class. The Google Analytics logs for Jalview version 2.4 only record the fact that the application was started, but in the future, we will use this mechanism to improve the Desktop user interface, by tracking which parts of the user interface are being used most often. I would like to know if you have general practice or advice to give concerning this: can we package as is or do we need to take some special care about privacy? If you have some pointers to provide me with, I will also be very happy. Thanks a lot for reading, Pierre
Re: mrtrix3
On Thu, 26 Nov 2020, Andreas Tille wrote: > /usr/bin/env: 'python': No such file or directory > make[1]: *** [debian/rules:68: override_dh_clean] Error 127 > make[1]: Leaving directory > '/home/andreas/debian-maintain/salsa/med-team/build-area/mrtrix3-3.0.2' > I think its just because I deinstalled python on my box. > > I have pushed added new 3.0.2 release and completely disabled tests > > since seems to require data now which is not shipped along AFAIK (but > > may be I overreacted). Might just need tune up for python3 though > Any reason why you do not upload if you are able to build at your side? patches etc still need tune up, as you somewhat discovered as well. > What should be checked? You are the expert of this package - no idea > what you expect me to do. "expert" is a stretch ;) -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 WWW: http://www.linkedin.com/in/yarik
Re: libsis-jhdf5-java hasn't migrated to testing since last 18 days
On Thu, 2020-11-26 at 17:14 +0100, Andreas Tille wrote: > Hi Nilesh, > > On Thu, Nov 26, 2020 at 06:00:38PM +0530, Nilesh Patra wrote: > > It seems that libsis-jhdf5-java hasn't migrated to testing due to > > build > > failure on s390x, log attached[1] > > This is preventing a chain of other packages which are stalled to > > testing > > migration as well. > > > > Could you please have a look at this? > > Thanks for the heads up. IMHO we should not spent to much time into > those architectures that are very uncommon in our field of work. I'm > going to file a bug report to remove libsis-jhdf5-java for > architecture > s390x. May be we can address this later but the migration should not > be blocked. indeed, issue seems related to access to JNI library, which may be quite difficult to debug, and for sure is not a real target arch for our users. We should focus on not blocking lib and related packages Means we should patch d/control for libsis-jhdf5-jni to remove s390x support Olivier > > Kind regards > > Andreas. > > > [1]: > > https://buildd.debian.org/status/logs.php?arch=s390x&pkg=libsis-jhdf5-java&ver=19.04.0%2Bdfsg-4 > -- Olivier Sallou Univ Rennes, Inria, CNRS, IRISA Irisa, Campus de Beaulieu F-35042 RENNES - FRANCE Tel: 02.99.84.71.95 gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438
Re: libsis-jhdf5-java hasn't migrated to testing since last 18 days
Hi Olivier, On Fri, Nov 27, 2020 at 07:53:02AM +0100, olivier sallou wrote: > Means we should patch d/control for libsis-jhdf5-jni to remove s390x > support Every means that is not blocking progress is fine for me. Kind regards Andreas. -- http://fam-tille.de
