Leaving the Project
Dear all, It is time for me to follow a different path. Many thanks to Andreas for taking the time and for the MoM. Although rather short term interaction with you, I have been able to understand a bit more on why debian is so amazing. Thanks for your effort and for making the life of those who use debian so easy :) and I hope you all manage do go through such hard times in good spirits. Best Regards, AndreiR
Re: Packaging "AGAT - Another Gff Analysis Toolkit "
Hi Andreas, On 10/22/20 3:29 PM, Andreas Tille wrote: Hi again, Ok. got it. I tried to fix pristine-tar. You should *not* manually add complete tarballs there. Also the tarball is *without* the Debian revision - so the name should be agat_0.5.0.orig.tar.gz (and not agat_0.5.0-1.orig.tar.gz) Please re-read the recommendations from MoM and the Debian Med policy. Its finally important that you can successfully do `gbp buildpackage` - if it works for you to recreate the tarball it works for others as well. I have removed d/tests. Regarding the packaging: It contains the unchanged autopkgtest boilerplate. Please either provide a sensible autopkgtest or remove the boilerplate debian/tests. They dont have a formal (paper) citation, only https://zenodo.org/record/4044553. I have added agat to conda - metadata. So you know some citation about agat? This would be great. There is also the Conda ID "agat" which you could specify in debian/upstream/metadata (see template). should be done. You should also provide a lintian override for script-with-language-extension lintian warning (there exist a proper example to do so in the Debian Med template!) should be done. I still get lintian issues "bad-whatis-entry" that I am now running out of options on how to fix them. However, man displays a ok page (in my eyes). Please also fix the incorrect-path-for-interpreter - just check the rules file of package sspace or vcftools for example. There are also some manpage errors mentioned by lintian. Please try to fix these. Kind regards Andreas. On Thu, Oct 22, 2020 at 02:06:47PM +0200, Andrei Rozanski wrote: Hi Andreas, Thanks for the replying even in "real life mode" :D On 10/21/20 10:53 PM, Andreas Tille wrote: Hi, Thanks for pointing that out. I have pushed it. very short notice (I'm in real life mode this week): The pristine-tar branch is missing agat_0.5.0.orig.tar.gz. Kind regards Andreas. On Wed, Oct 21, 2020 at 06:44:54PM +0200, Andrei Rozanski wrote: Hello, I have worked on AGAT (https://salsa.debian.org/med-team/agat). For the moment, lintian seems fine. The build also looks promising. I would like to request some help for checking/guidance on what I have done so far. Many thanks. Best, AndreiR On Fri, Oct 16, 2020 at 7:41 AM Andrei Rozanski wrote: Hi Andreas, Thanks for the answer! I will work on it. On October 16, 2020 07:39:23 Andreas Tille wrote: Hi Andrei, On Fri, Oct 16, 2020 at 07:30:11AM +0200, Andrei Rozanski wrote: More recently I have tried AGAT - Another Gff Analysis Toolkit (https://github.com/NBISweden/AGAT) and found it quite useful in general. I have failed to find a debian package for it. Would it be ok for me to try to package it or should I prioritize the COVID list and do AGAT later? The general rule is: We package what we use. So yes, just go for it. (May be those who assembled the COVID list did not had this on the radar?) Feel free to keep on asking here in case of trouble. Thanks a lot for your contribution Andreas. -- http://fam-tille.de Best AndreiR -- Andrei R Many thanks ! Best AndreiR Thanks! Best AndreiR
Re: Packaging "AGAT - Another Gff Analysis Toolkit "
Hi Andreas, Thanks for the comments. I guess the problem is that I used pbuilder create and pdebuild (https://www.debian.org/doc/manuals/maint-guide/build.en.html#pbuilder) There I could not see the pointed errors. I will work now with gbp buildpackage and try to fix the problems. Thanks!! Best AndreiR On October 22, 2020 15:30:06 Andreas Tille wrote: Hi again, I tried to fix pristine-tar. You should *not* manually add complete tarballs there. Also the tarball is *without* the Debian revision - so the name should be agat_0.5.0.orig.tar.gz (and not agat_0.5.0-1.orig.tar.gz) Please re-read the recommendations from MoM and the Debian Med policy. Its finally important that you can successfully do `gbp buildpackage` - if it works for you to recreate the tarball it works for others as well. Regarding the packaging: It contains the unchanged autopkgtest boilerplate. Please either provide a sensible autopkgtest or remove the boilerplate debian/tests. So you know some citation about agat? This would be great. There is also the Conda ID "agat" which you could specify in debian/upstream/metadata (see template). You should also provide a lintian override for script-with-language-extension lintian warning (there exist a proper example to do so in the Debian Med template!) Please also fix the incorrect-path-for-interpreter - just check the rules file of package sspace or vcftools for example. There are also some manpage errors mentioned by lintian. Please try to fix these. Kind regards Andreas. On Thu, Oct 22, 2020 at 02:06:47PM +0200, Andrei Rozanski wrote: Hi Andreas, Thanks for the replying even in "real life mode" :D On 10/21/20 10:53 PM, Andreas Tille wrote: Hi, Thanks for pointing that out. I have pushed it. very short notice (I'm in real life mode this week): The pristine-tar branch is missing agat_0.5.0.orig.tar.gz. Kind regards Andreas. On Wed, Oct 21, 2020 at 06:44:54PM +0200, Andrei Rozanski wrote: Hello, I have worked on AGAT (https://salsa.debian.org/med-team/agat). For the moment, lintian seems fine. The build also looks promising. I would like to request some help for checking/guidance on what I have done so far. Many thanks. Best, AndreiR On Fri, Oct 16, 2020 at 7:41 AM Andrei Rozanski wrote: Hi Andreas, Thanks for the answer! I will work on it. On October 16, 2020 07:39:23 Andreas Tille wrote: Hi Andrei, On Fri, Oct 16, 2020 at 07:30:11AM +0200, Andrei Rozanski wrote: More recently I have tried AGAT - Another Gff Analysis Toolkit (https://github.com/NBISweden/AGAT) and found it quite useful in general. I have failed to find a debian package for it. Would it be ok for me to try to package it or should I prioritize the COVID list and do AGAT later? The general rule is: We package what we use. So yes, just go for it. (May be those who assembled the COVID list did not had this on the radar?) Feel free to keep on asking here in case of trouble. Thanks a lot for your contribution Andreas. -- http://fam-tille.de Best AndreiR -- Andrei R Many thanks ! Best AndreiR -- http://fam-tille.de
Re: Packaging "AGAT - Another Gff Analysis Toolkit "
Hi Andreas, Thanks for the replying even in "real life mode" :D On 10/21/20 10:53 PM, Andreas Tille wrote: Hi, Thanks for pointing that out. I have pushed it. very short notice (I'm in real life mode this week): The pristine-tar branch is missing agat_0.5.0.orig.tar.gz. Kind regards Andreas. On Wed, Oct 21, 2020 at 06:44:54PM +0200, Andrei Rozanski wrote: Hello, I have worked on AGAT (https://salsa.debian.org/med-team/agat). For the moment, lintian seems fine. The build also looks promising. I would like to request some help for checking/guidance on what I have done so far. Many thanks. Best, AndreiR On Fri, Oct 16, 2020 at 7:41 AM Andrei Rozanski wrote: Hi Andreas, Thanks for the answer! I will work on it. On October 16, 2020 07:39:23 Andreas Tille wrote: Hi Andrei, On Fri, Oct 16, 2020 at 07:30:11AM +0200, Andrei Rozanski wrote: More recently I have tried AGAT - Another Gff Analysis Toolkit (https://github.com/NBISweden/AGAT) and found it quite useful in general. I have failed to find a debian package for it. Would it be ok for me to try to package it or should I prioritize the COVID list and do AGAT later? The general rule is: We package what we use. So yes, just go for it. (May be those who assembled the COVID list did not had this on the radar?) Feel free to keep on asking here in case of trouble. Thanks a lot for your contribution Andreas. -- http://fam-tille.de Best AndreiR -- Andrei R Many thanks ! Best AndreiR
Re: Packaging "AGAT - Another Gff Analysis Toolkit "
Hello, I have worked on AGAT (https://salsa.debian.org/med-team/agat). For the moment, lintian seems fine. The build also looks promising. I would like to request some help for checking/guidance on what I have done so far. Many thanks. Best, AndreiR On Fri, Oct 16, 2020 at 7:41 AM Andrei Rozanski wrote: > Hi Andreas, > > Thanks for the answer! I will work on it. > > > > On October 16, 2020 07:39:23 Andreas Tille wrote: > > Hi Andrei, >> >> On Fri, Oct 16, 2020 at 07:30:11AM +0200, Andrei Rozanski wrote: >> >>> More recently I have tried AGAT - Another Gff Analysis Toolkit >>> (https://github.com/NBISweden/AGAT) and found it quite useful in >>> general. I >>> have failed to find a debian package for it. >>> >>> Would it be ok for me to try to package it or should I prioritize the >>> COVID >>> list and do AGAT later? >>> >> >> The general rule is: We package what we use. So yes, just go for it. >> (May be those who assembled the COVID list did not had this on the >> radar?) >> >> Feel free to keep on asking here in case of trouble. >> >> Thanks a lot for your contribution >> >> Andreas. >> >> -- >> http://fam-tille.de >> > > Best > AndreiR > -- Andrei R
Re: Packaging "AGAT - Another Gff Analysis Toolkit "
Hi Steffen, On 10/16/20 12:12 PM, Steffen Möller wrote: On 16.10.20 07:30, Andrei Rozanski wrote: Hi, More recently I have tried AGAT - Another Gff Analysis Toolkit (https://github.com/NBISweden/AGAT) <https://github.com/NBISweden/AGAT)> and found it quite useful in general. I have failed to find a debian package for it. Would it be ok for me to try to package it or should I prioritize the COVID list and do AGAT later? Thanks for adding it! Added it to https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit#gid=543782716 Best, Steffen Best AndreiR
Re: Packaging "AGAT - Another Gff Analysis Toolkit "
Hi Andreas, Thanks for the answer! I will work on it. On October 16, 2020 07:39:23 Andreas Tille wrote: Hi Andrei, On Fri, Oct 16, 2020 at 07:30:11AM +0200, Andrei Rozanski wrote: More recently I have tried AGAT - Another Gff Analysis Toolkit (https://github.com/NBISweden/AGAT) and found it quite useful in general. I have failed to find a debian package for it. Would it be ok for me to try to package it or should I prioritize the COVID list and do AGAT later? The general rule is: We package what we use. So yes, just go for it. (May be those who assembled the COVID list did not had this on the radar?) Feel free to keep on asking here in case of trouble. Thanks a lot for your contribution Andreas. -- http://fam-tille.de Best AndreiR
Packaging "AGAT - Another Gff Analysis Toolkit "
Hi, More recently I have tried AGAT - Another Gff Analysis Toolkit (https://github.com/NBISweden/AGAT) and found it quite useful in general. I have failed to find a debian package for it. Would it be ok for me to try to package it or should I prioritize the COVID list and do AGAT later? Thanks Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/15/20 4:18 PM, Andreas Tille wrote: Hi Andrei, On Thu, Oct 15, 2020 at 02:10:52PM +0200, Andrei Rozanski wrote: sorry, I've lost track. I assumed I would have written a response but obviously I missed that. Feel free to ping me earlier next time! Just created the ITP. Thanks for fixing it. You might like to inspect my last commits before I uploaded to new. Ok. Got it. Thanks for the links and detailed paths. You have now two packages in new and should be prepared to do some self-standing work (hopefully - if not you know where to ask). You can pick whatever task you might like to do which can be bug fixing, writing autopkgtests or other new packages. Regarding bug fixing you can seek for targets on the general BTS page of our team https://bugs.debian.org/cgi-bin/pkgreport.cgi?maint=debian-med-packag...@lists.alioth.debian.org or the Blends bugs pages https://blends.debian.org/med/bugs/ Packages in need for tests are listed here https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/debian-med-tests.txt For new packaging targets I'm currently recommending https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 Thanks for your nice work in the MoM project and have fun picking new targets in our team Andreas. Thanks for taking the time, for the patience and guidance. MoM was helpful and very important for me to understand, in a practical way, more about the routines. I will work on your suggestions and hopefully soon I will start contributing. Thanks! Best, AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/14/20 4:49 PM, Andreas Tille wrote: Hi Andrei, Ok. No problem! sorry, I've lost track. I assumed I would have written a response but obviously I missed that. Feel free to ping me earlier next time! Just created the ITP. I think that package should be ready except ITP bug - and if you are really good providing the missing manpage. Thank you for your patience Andreas. On Wed, Oct 14, 2020 at 04:38:51PM +0200, Andrei Rozanski wrote: Hi Andreas, Just to check with you if you had time to look into the updated tests. On 10/8/20 9:40 AM, Andrei Rozanski wrote: Hi Andreas, On 10/7/20 10:31 PM, Andreas Tille wrote: Hi Andrei, On Wed, Oct 07, 2020 at 07:23:24PM +0200, Andrei Rozanski wrote: Tried to port the tests script into it https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/run-unit-test and add python as dependency https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/control Sorry for that. I have updated the file and fixed the dependency. You need to replace *all* instances #PACKAGENAME# to make this work. Moreover python (== Python2) is not possible. It has to be python3. Please also test the script. Andreas. The build finishes like: I: gjh-asl-json: hardening-no-fortify-functions usr/bin/gjh_asl_json W: gjh-asl-json: new-package-should-close-itp-bug W: gjh-asl-json: manpage-has-useless-whatis-entry usr/share/man/man1/gjh-asl-json.1.gz W: gjh-asl-json: binary-without-manpage usr/bin/gjh_asl_json However I have add https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/gjh-asl-json.1 and https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/manpages .. not sure Thanks! I enhanced the manpage a bit. I should have pointed you to https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages which helps to call help2man in a more sensible way. Kind regards Andreas. Best, AndreiR Thanks! Best AndreiR Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, Just to check with you if you had time to look into the updated tests. On 10/8/20 9:40 AM, Andrei Rozanski wrote: Hi Andreas, On 10/7/20 10:31 PM, Andreas Tille wrote: Hi Andrei, On Wed, Oct 07, 2020 at 07:23:24PM +0200, Andrei Rozanski wrote: Tried to port the tests script into it https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/run-unit-test and add python as dependency https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/control Sorry for that. I have updated the file and fixed the dependency. You need to replace *all* instances #PACKAGENAME# to make this work. Moreover python (== Python2) is not possible. It has to be python3. Please also test the script. Andreas. The build finishes like: I: gjh-asl-json: hardening-no-fortify-functions usr/bin/gjh_asl_json W: gjh-asl-json: new-package-should-close-itp-bug W: gjh-asl-json: manpage-has-useless-whatis-entry usr/share/man/man1/gjh-asl-json.1.gz W: gjh-asl-json: binary-without-manpage usr/bin/gjh_asl_json However I have add https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/gjh-asl-json.1 and https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/manpages .. not sure Thanks! I enhanced the manpage a bit. I should have pointed you to https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages which helps to call help2man in a more sensible way. Kind regards Andreas. Best, AndreiR Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/7/20 10:31 PM, Andreas Tille wrote: Hi Andrei, On Wed, Oct 07, 2020 at 07:23:24PM +0200, Andrei Rozanski wrote: Tried to port the tests script into it https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/run-unit-test and add python as dependency https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/control Sorry for that. I have updated the file and fixed the dependency. You need to replace *all* instances #PACKAGENAME# to make this work. Moreover python (== Python2) is not possible. It has to be python3. Please also test the script. Andreas. The build finishes like: I: gjh-asl-json: hardening-no-fortify-functions usr/bin/gjh_asl_json W: gjh-asl-json: new-package-should-close-itp-bug W: gjh-asl-json: manpage-has-useless-whatis-entry usr/share/man/man1/gjh-asl-json.1.gz W: gjh-asl-json: binary-without-manpage usr/bin/gjh_asl_json However I have add https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/gjh-asl-json.1 and https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/manpages .. not sure Thanks! I enhanced the manpage a bit. I should have pointed you to https://salsa.debian.org/med-team/community/helper-scripts/-/blob/master/createmanpages which helps to call help2man in a more sensible way. Kind regards Andreas. Best, AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/7/20 3:40 PM, Andreas Tille wrote: Hi Andrei, On Tue, Oct 06, 2020 at 07:49:14PM +0200, Andrei Rozanski wrote: https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch#L27 Got it. Thanks! OK. I've seen these patches. Regarding the lintian warning remaining: Well, sometimes there are false positives. I think we can ignore these. However, I enhanced your patch. It is more flexible to rely on the variables rather than hardcoding (for instance for cross building or things like this). I have seen that gjh_asl_json has a tests directory https://github.com/ghackebeil/gjh_asl_json/tree/master/tests However, seeing the example of trf https://salsa.debian.org/med-team/trf/-/blob/master/debian/control I may need to install the tests files in a separate way as well? Ok. I got it. In trf the test data are way larger then in gjh-asl-json. I'd recommend to move these tests to /usr/share/doc/gjh-asl-json/examples (by creating a file debian/examples with the content Ok. I have pushed it https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/examples#L1 tests/* Tried to port the tests script into it https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/run-unit-test and add python as dependency https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/tests/control and adapt run-unit-test to let something sensible happen. Kind regards Andreas. The build finishes like: I: gjh-asl-json: hardening-no-fortify-functions usr/bin/gjh_asl_json W: gjh-asl-json: new-package-should-close-itp-bug W: gjh-asl-json: manpage-has-useless-whatis-entry usr/share/man/man1/gjh-asl-json.1.gz W: gjh-asl-json: binary-without-manpage usr/bin/gjh_asl_json However I have add https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/gjh-asl-json.1 and https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/manpages .. not sure Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/5/20 11:05 PM, Andreas Tille wrote: Hi Andrei, On Mon, Oct 05, 2020 at 10:01:05PM +0200, Andrei Rozanski wrote: Description: A gjh solver like solution. should be fixed. Yep. W: gjh-asl-json: initial-upload-closes-no-bugs That would be the ITP bug. Will work on it. OK. W: gjh-asl-json: no-manual-page usr/bin/gjh_asl_json You might consider using help2man to create a manpage. I would not require this for sponsoring - but it somehow would be considered a complete package if a manpage is included. Here I am a bit puzzled. I have made some changes: https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch#L25 https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch#L27 Got it. Thanks! I've seen these patches. Regarding the lintian warning remaining: Well, sometimes there are false positives. I think we can ignore these. However, I enhanced your patch. It is more flexible to rely on the variables rather than hardcoding (for instance for cross building or things like this). I have seen that gjh_asl_json has a tests directory https://github.com/ghackebeil/gjh_asl_json/tree/master/tests However, seeing the example of trf https://salsa.debian.org/med-team/trf/-/blob/master/debian/control I may need to install the tests files in a separate way as well? I forgot one issue: debian/tests contains just the non-working template. While it would be great if you could find a test if you don't we should remove that template. Kind regards Andreas. Thanks! Best, AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/5/20 3:01 PM, Andreas Tille wrote: Hi Andrei, On Mon, Oct 05, 2020 at 07:20:29AM +0200, Andrei Rozanski wrote: Thanks for the hint. Now the package builds successfully. Would it be possible for you to check it? Sure. :-) Thanks for revert and clarifying it. I reverted the targer distribution from "unstable" to "UNRELEASED". Please leave this untouched until a real upload will be done. This at least would require an ITP bug for this package. Here are some lintian issues that are worth fixing: $ lintian gjh-asl-json_0.0+git20180428.eb8720e-1_amd64.changes W: gjh-asl-json-dbgsym: debug-file-with-no-debug-symbols usr/lib/debug/.build-id/c8/74f359971427c935040188b2ea6b388213a9aa.debug This reminds me about the dh_dwz issue: Please patch the Makefile to respect CFLAGS set by debhelper. This includes '-g' which adds debug symbols and most probably dh_dwz will work afterwards. W: gjh-asl-json: description-synopsis-starts-with-article This corresponds to Description: A gjh solver like solution. should be fixed. Please read again about the description in the developers reference. It should be no complete sentence. W: gjh-asl-json: initial-upload-closes-no-bugs That would be the ITP bug. Will work on it. W: gjh-asl-json: no-manual-page usr/bin/gjh_asl_json You might consider using help2man to create a manpage. I would not require this for sponsoring - but it somehow would be considered a complete package if a manpage is included. Here I am a bit puzzled. I have made some changes: https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch#L25 https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch#L27 Then, blhc gjh-asl-json_0.0+git20180428.eb8720e-1_amd64.build returns empty but lintian still complains about hardening-no-bndnow and no-fortify-functions. I: gjh-asl-json: hardening-no-bindnow usr/bin/gjh_asl_json I: gjh-asl-json: hardening-no-fortify-functions usr/bin/gjh_asl_json Please uncomment the hardening option in d/rules. Besides the CFLAGS I recommended to propagate to the gcc-call you also need to pass LDFLAGS. Please feel free to ask if any hint was not helpful enough to solve the regarding issue. Kind regards Andreas. Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/4/20 10:32 PM, Andreas Tille wrote: On Sun, Oct 04, 2020 at 12:16:08PM +0200, Andrei Rozanski wrote: dh_dwz dh_dwz: dwz -q -- debian/gjh-asl-json/usr/bin/gjh_asl_json returned exit Thanks for the hint. Now the package builds successfully. Would it be possible for you to check it? I admit I'm usually doing override_dh_dwz: echo "dh_dwz fails - no idea how to fix" or something like this. Kind regards Andreas. Thanks! Best, AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/4/20 8:46 AM, Andreas Tille wrote: Hi Andrei, On Sat, Oct 03, 2020 at 04:11:58PM +0200, Andrei Rozanski wrote: I have created the ITP bug for libamplsolver. Thanks! :) I've seen this and uploaded libamplsolver. Congratulations to your first package in new. :-) Also, debuild for gjh-asl-json (https://salsa.debian.org/med-team/gjh-asl-json) finishes ok now. The binary gjh_asl_json still needs to be properly installed and for that I would like to ask for your help. Thanks for the fix. I have created an issue : https://github.com/ghackebeil/gjh_asl_json/issues I've fixed d/watch to feature git mode since upstream has not tagged any release. BTW, also in this case libsmithwaterman could serve as an example. Now the watch file gets automatically the latest upstream commit. Your "homework" might be to open an issue upstream to ask for release tags. (See comment in watch file of libsmithwaterman how to do this.) Done. Regarding the installation of gjh_asl_json you should just mention the binary in a debian/install file. I have tried to fix the issues. However, during build, there is one error that I dont know how to deal with: ``` dh_auto_test create-stamp debian/debhelper-build-stamp dh_testroot dh_prep dh_auto_install dh_install dh_installdocs dh_installchangelogs dh_perl dh_link dh_strip_nondeterminism dh_compress dh_fixperms dh_missing dh_dwz dh_dwz: dwz -q -- debian/gjh-asl-json/usr/bin/gjh_asl_json returned exit code 1 make: *** [debian/rules:21: binary] Error 1 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui failed ``` BTW, there are also remaining lintian issues about the description. Please try to fix these. Kind regards Andreas. Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, I have created the ITP bug for libamplsolver. Also, debuild for gjh-asl-json (https://salsa.debian.org/med-team/gjh-asl-json) finishes ok now. The binary gjh_asl_json still needs to be properly installed and for that I would like to ask for your help. Thanks! Best AndreiR On 10/2/20 7:55 PM, Andrei Rozanski wrote: Hi Andreas, On 10/2/20 6:43 PM, Andreas Tille wrote: Hi Andrei, On Fri, Oct 02, 2020 at 06:20:48PM +0200, Andrei Rozanski wrote: I have worked on gjh_asl_json link to ampl lib. For the sake of testing I have used the current lib name. Thanks! The lib name of the binary packages will not change. I have now moved the repository to https://salsa.debian.org/med-team/libamplsolver Please reset your git clone setting (or create new clone). I have updated d/control and d/copyright files for gjh-asl-json. https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/control Ok. Thanks for point this out. There is no need to Build-Depend: libamplsover since libamplsover-dev depends on it (please also mind that there is no such packaga libamplsover but only libamplsover0). Please also note that the long description has to be inserted by exactly one blank. For the formatting I recommend to run Ok. done. cme fix dpkg-control (after inserting the leading blank) https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/copyright Got it. Hopefully :) The formatting of the license paragraph is similar. The license text needs to have a leading blank and empty lines should have one blank and a '.' Since libamplsolver is not done yet, is there a way to "inject" the library (deb file) in the gjh-asl-json build so I can test it? Or do I need to wait for the library? I will try it. The easy way is to install the preliminary package of the library on your local machine and use debuild (from devscripts package). You can also configure pbuilder to respect a local repository. It is described here: https://wiki.debian.org/PbuilderTricks Yes, I need to fix it. BTW, the changelog file has the wrong version number. The repository is also lacking the upstream and the pristine-tar branch. Please read the Debian Med policy again about `gbp import-orig`. Since this command expects an upstream branch when the repository is not empty you need to create that branch manually before you can do the import-orig step. Just did it. Regarding libamplsolver the final step is missing. We need to create an ITP bug and upload. You can either call reportbug wnpp and fill in everything manually or you can simply call this script: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/itp_from_debian_dir which I wrote to fill in all the metadata we have assembled in the debian/ dir anyway. May be it makes sense to do the step manually at least once to know what you are doing. Kind regards Andreas. I will. PS: May be you might like to show up today in the video meeting. Thanks! Best, AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 10/2/20 6:43 PM, Andreas Tille wrote: Hi Andrei, On Fri, Oct 02, 2020 at 06:20:48PM +0200, Andrei Rozanski wrote: I have worked on gjh_asl_json link to ampl lib. For the sake of testing I have used the current lib name. Thanks! The lib name of the binary packages will not change. I have now moved the repository to https://salsa.debian.org/med-team/libamplsolver Please reset your git clone setting (or create new clone). I have updated d/control and d/copyright files for gjh-asl-json. https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/control Ok. Thanks for point this out. There is no need to Build-Depend: libamplsover since libamplsover-dev depends on it (please also mind that there is no such packaga libamplsover but only libamplsover0). Please also note that the long description has to be inserted by exactly one blank. For the formatting I recommend to run Ok. done. cme fix dpkg-control (after inserting the leading blank) https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/copyright Got it. Hopefully :) The formatting of the license paragraph is similar. The license text needs to have a leading blank and empty lines should have one blank and a '.' Since libamplsolver is not done yet, is there a way to "inject" the library (deb file) in the gjh-asl-json build so I can test it? Or do I need to wait for the library? I will try it. The easy way is to install the preliminary package of the library on your local machine and use debuild (from devscripts package). You can also configure pbuilder to respect a local repository. It is described here: https://wiki.debian.org/PbuilderTricks Yes, I need to fix it. BTW, the changelog file has the wrong version number. The repository is also lacking the upstream and the pristine-tar branch. Please read the Debian Med policy again about `gbp import-orig`. Since this command expects an upstream branch when the repository is not empty you need to create that branch manually before you can do the import-orig step. Just did it. Regarding libamplsolver the final step is missing. We need to create an ITP bug and upload. You can either call reportbug wnpp and fill in everything manually or you can simply call this script: https://salsa.debian.org/r-pkg-team/dh-r/-/blob/master/scripts/itp_from_debian_dir which I wrote to fill in all the metadata we have assembled in the debian/ dir anyway. May be it makes sense to do the step manually at least once to know what you are doing. Kind regards Andreas. I will. PS: May be you might like to show up today in the video meeting. Thanks! Best, AndreiR
Re: [MoM] ampl-netlib-solvers
Dear Andreas, On 9/30/20 10:22 PM, Andreas Tille wrote: Hi Andrei, On Wed, Sep 30, 2020 at 09:49:01PM +0200, Andrei Rozanski wrote: On 9/30/20 5:10 PM, Andreas Tille wrote: I have worked on gjh_asl_json link to ampl lib. For the sake of testing I have used the current lib name. Thanks! The lib name of the binary packages will not change. I have now moved the repository to https://salsa.debian.org/med-team/libamplsolver Please reset your git clone setting (or create new clone). I have updated d/control and d/copyright files for gjh-asl-json. https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/control https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/copyright Since libamplsolver is not done yet, is there a way to "inject" the library (deb file) in the gjh-asl-json build so I can test it? Or do I need to wait for the library? The Makefile patch is now at https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch . After patching the gjh_asl_json Makefile, the package compile without errors. I'll check tomorrow. However, I feel that the patched Makefile maybe need some more experienced review :) I can have a look. Kind regards Andreas. Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 9/30/20 5:10 PM, Andreas Tille wrote: Hi Andrei, On Wed, Sep 30, 2020 at 04:05:51PM +0200, Andrei Rozanski wrote: Many thanks for the commits. I will work on the reading suggestions. Thanks for doing the d-shlibs and all the info about it. You are welcome. I am totally fine with changing the name of the library. I also think that it will help with consistency. OK, so I'll move the repository later today and let you know. have some consistency here. This would also mean we should rename the git repository to libamplsolver. Finally its a matter of esthetics so I want to hear your opinion about this. Please note: Changing the source package **after** the package has been accepted is a real nuisance since it would require another round trip through the new queue. Cool. I will try to link it. I have worked on gjh_asl_json link to ampl lib. For the sake of testing I have used the current lib name. The Makefile patch is now at https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/debian/patches/fix-makefile-lib.patch . After patching the gjh_asl_json Makefile, the package compile without errors. However, I feel that the patched Makefile maybe need some more experienced review :) Good luck with this. Once we have decided about the name of the source package I consider this library as basically ready. What you can do is installing the resulting DEBs and try to link against your original target. It helped, a lot. Thanks! :-) Kind regards Andreas. Thanks! Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 9/30/20 3:25 PM, Andreas Tille wrote: Hi Andrei, On Wed, Sep 30, 2020 at 11:39:42AM +0200, Andrei Rozanski wrote: On Tue, Sep 29, 2020 at 03:31:21PM +0200, Andrei Rozanski wrote: I have worked on a few changes. Can you please check if it make sense? https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/patches/fix-makefile-shared-lib.patch Many thanks for the commits. I will work on the reading suggestions. Thanks for doing the d-shlibs and all the info about it. I am totally fine with changing the name of the library. I also think that it will help with consistency. As promised I have pushed changes to use d-shlibs. The good thing in d-shlibs is that you can't deliver a library package that is wrong - the bad thing is that you need to understand its principles. It expects the name of the binary package featuring the shared library to be named like the library name itself + SOVERSION (thus you have to set a soversion (which I did in the makefile patch with the -Wl,-soname option and it also expects that *.so is a symlink. The development package also needs to follow that naming scheme thus it is libraryname-dev. So the degrees of freedom in choosing the names were restricted when accepting that we decided the name of the static lib should be libamplsolver.a. I'm somehow considering to also name the source package libamplsolver to have some consistency here. This would also mean we should rename the git repository to libamplsolver. Finally its a matter of esthetics so I want to hear your opinion about this. Please note: Changing the source package **after** the package has been accepted is a real nuisance since it would require another round trip through the new queue. Cool. I will try to link it. Once we have decided about the name of the source package I consider this library as basically ready. What you can do is installing the resulting DEBs and try to link against your original target. It helped, a lot. Thanks! Hope this helps Andreas. Best AndreiR
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas, On 9/29/20 9:56 PM, Andreas Tille wrote: Dear Andrei, On Tue, Sep 29, 2020 at 03:31:21PM +0200, Andrei Rozanski wrote: I have worked on a few changes. Can you please check if it make sense? https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/patches/fix-makefile-shared-lib.patch Many thanks for the commits. I will work on the reading suggestions. Thanks Best, AndreiR I think this makes sense. I added two commits: 1. DEP3 header 2. Actually install the *.so file into the binary package The latter is not the final state. I volunteer to do some d-shlibs patch tomorrow which also involves creating two binary packages: One package libampl-netlib-solvers0 and one libampl-netlib-solvers-dev. But this will not be done today. Meanwhile you might like to read about multiple binary packages - also the libsmithwaterman control file will be a nice reading about this. Kind regards Andreas.
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Dear Andreas, On 9/28/20 10:00 PM, Andrei Rozanski wrote: Hi Andreas, On September 28, 2020 21:35:07 Andreas Tille wrote: Hi Andrei, On Mon, Sep 28, 2020 at 09:20:11PM +0200, Andrei Rozanski wrote: Its definitely OK. I do not think whether there is any "good practice" to work around broken upstream Makefiles. this will fail on all other build architectures than amd64 under Linux. May be its sensible to replace it simply by sys.*/ I will look into libsmithwaterman. Thanks! Unfortunately I cannot make it happen. I have been checking d-shlibmove, soname but I cannot put pieces together. I have worked on a few changes. Can you please check if it make sense? https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/patches/fix-makefile-shared-lib.patch Thanks! Best AndreiR Thanks. I will try it out. May be I was not clear enough. Please *ignore* d-shlibmove for the moment. What we need first is a shared library since this is mandatory. If you manage to tweak the build system in a way we can have *.so **and** *.a then (and only then) we might consider d-shlibmove since it requires both kind of libs. I was pointing to libsmithwaterman for binary package names as well as a potential way to create automake stuff in a patch (but that's not required). Sorry if I have dragged you into a to complex dead end street. Kind regards Andreas. -- http://fam-tille.de Best AndreiR
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas, On September 28, 2020 21:35:07 Andreas Tille wrote: Hi Andrei, On Mon, Sep 28, 2020 at 09:20:11PM +0200, Andrei Rozanski wrote: Its definitely OK. I do not think whether there is any "good practice" to work around broken upstream Makefiles. this will fail on all other build architectures than amd64 under Linux. May be its sensible to replace it simply by sys.*/ I will look into libsmithwaterman. Thanks! Unfortunately I cannot make it happen. I have been checking d-shlibmove, soname but I cannot put pieces together. Thanks. I will try it out. May be I was not clear enough. Please *ignore* d-shlibmove for the moment. What we need first is a shared library since this is mandatory. If you manage to tweak the build system in a way we can have *.so **and** *.a then (and only then) we might consider d-shlibmove since it requires both kind of libs. I was pointing to libsmithwaterman for binary package names as well as a potential way to create automake stuff in a patch (but that's not required). Sorry if I have dragged you into a to complex dead end street. Kind regards Andreas. -- http://fam-tille.de Best AndreiR
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas,
On 9/25/20 5:22 PM, Andreas Tille wrote:
Hi Andrei,
On Thu, Sep 24, 2020 at 03:55:52PM +0200, Andrei Rozanski wrote:
fb3ed2f5b9a313134a7abbffe23159b8f6fb4eb6)
Sorry for that. This time, it seems to finish without issues (commit
72f4e2a0bd44309a33c37f9ab9261d22cf52979c).
No need to sorry about this - I was just somehow communicating the fact
that if I've thought in the past that I did only a simple change that
will not break anything sometimes it was broken anyway. ;-) So just
rebuild before uploading. ;-)
debian/`dh_listpackages`/usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
where it was moved before. ;-)
I gave it a try using make variables -
https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/rules#L6
and
https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/rules#L33
However I am not sure if it is ok/good practice.
Its definitely OK. I do not think whether there is any "good practice" to
work around broken upstream Makefiles.
this will fail on all other build architectures than amd64 under Linux.
May be its sensible to replace it simply by
sys.*/
I will look into libsmithwaterman. Thanks!
Unfortunately I cannot make it happen. I have been checking d-shlibmove,
soname but I cannot put pieces together.
Good. Just let me know if something might remain unclear.
Its a simple package also featuring a rewrite of the build system
(which might or might not be appropriate here - just mentioning it)
and shows the two binary packages what files belong where. (For
the moment feel free to ignore d-shlibs - I'll explain later if needed.
It works only if shared *and* static library are provided.)
Thanks for the thorough message.
This is the idea of a MoM project: I try to be verbose and patiently
to guide newcomers. :-)
Kind regards
Andreas.
Best,
AndreiR
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas,
On 9/24/20 2:30 PM, Andreas Tille wrote:
Hi Andrei,
On Thu, Sep 24, 2020 at 11:31:56AM +0200, Andrei Rozanski wrote:
Thanks for the answer.
You are welcome. :-)
On 9/24/20 10:06 AM, Andreas Tille wrote:
The thing is that I was wondering why while the symlink is set inside
the resulting tarball the actual *.a lib was missing. The answer was
simple - the sequence in the debian/*links file was wrong.
Ok. I have removed the .links file and changed d/rules. (commit
fb3ed2f5b9a313134a7abbffe23159b8f6fb4eb6)
Sorry for that. This time, it seems to finish without issues (commit
72f4e2a0bd44309a33c37f9ab9261d22cf52979c).
Please always try to build before commiting. The build fails with
dh_install
mv usr/lib/x86_64-linux-gnu/amplsolver.a
usr/lib/x86_64-linux-gnu/libamplsolver.a
mv: cannot stat 'usr/lib/x86_64-linux-gnu/amplsolver.a': No such file or
directory
due to the fact that the source file you want to move can be actually
found in
debian/`dh_listpackages`/usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
where it was moved before. ;-)
I gave it a try using make variables -
https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/rules#L6
and
https://salsa.debian.org/med-team/ampl-netlib-solvers/-/blob/master/debian/rules#L33
However I am not sure if it is ok/good practice.
BTW, there are multiple ways to approach the renaming. Alternatively you
can also do
mv sys.*/amplsolver.a sys.*/libamplsolver.a
**before** dh_install. (See below why I'm writing sys.* !)
You could also patch a makefile (I really hate such self-invented
configure scripts - sometimes it is less work to simply add autoconf or
cmake code (depending from your preference for a build system) to create
a proper library name. See also in the end of this mail.
Please also note that Debian builds on several hardware architecture and
operating systems (also bsd and hurd). Since debian/*.install has
sys.x86_64.Linux/
done
this will fail on all other build architectures than amd64 under Linux.
May be its sensible to replace it simply by
sys.*/
I will look into libsmithwaterman. Thanks!
The package is finaly a library. I admit I would not have started
with the suggested package in the first place if I would have realised
this. However, its possibly not a bad example to learn step by step.
In Debian it is mandatory to provide a shared library - extra points if
a static library is provided in *addition*. So we do not only need to
adapt the binary package name but also we need to provide two binary
packages - one with the shared library and one with the header files +
optional static library. May be you want to have a look into
libsmithwaterman[1] which is an simply example for a library (feel free
to ignore the additional third binary package smithwaterman which just
provided a tool that uses the library).
Its a simple package also featuring a rewrite of the build system
(which might or might not be appropriate here - just mentioning it)
and shows the two binary packages what files belong where. (For
the moment feel free to ignore d-shlibs - I'll explain later if needed.
It works only if shared *and* static library are provided.)
Thanks for the thorough message.
Please do not hesitate to ask if something is not clear.
Kind regards
Andreas.
[1] https://salsa.debian.org/med-team/libsmithwaterman
Best
AndreiR
Re: Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas,
Thanks for the answer.
On 9/24/20 10:06 AM, Andreas Tille wrote:
Hi Andrei,
On Wed, Sep 23, 2020 at 08:30:56PM +0200, Andrei Rozanski wrote:
Just to check if you got my previous mail.
Thanks for checking. That's perfectly welcome and in this case very
sensible. I confirm I've got the mail, checked the result ... and got
distracted and forgot. :-(
The thing is that I was wondering why while the symlink is set inside
the resulting tarball the actual *.a lib was missing. The answer was
simple - the sequence in the debian/*links file was wrong.
Ok. I have removed the .links file and changed d/rules. (commit
fb3ed2f5b9a313134a7abbffe23159b8f6fb4eb6)
Thanks!
Best,
AndreiR
Unfortunately that did not seem to help. In my opinion we should really
rename that file and this can be done by
override_dh_install:
dh_install
mv ...
Once a user want to link against this library the option is -lamplsolver
and the file that the linker is seeking for is libamplsolver.a. So I
do not see any point in keeping the original name.
Kind regards and sorry for the delay
Andreas.
Thanks!
Best
AndreiR
--- Forwarded message ---
From: Andrei Rozanski rozansk...@gmail.com
Date: September 21, 2020 09:56:40
Subject: Re: [MoM] ampl-netlib-solvers
To: debian-med@lists.debian.org
Hi Andreas,
Many thanks for reaching out and sorry for the delay in getting back to you.
I was reading and trying to understand a bit more of the whole process.
I guess some of the steps on packaging are still not clear to me.
I have added d/ampl-netlib-solvers.links as Aaron has kindly suggested
(thanks Aaron!). (commit 1d6f7cabaf956738f7e6b7adafa24e9b53d66746)
Thanks,
Best
AndreiR
On 9/21/20 9:03 AM, Andreas Tille wrote:
Hi Andrei,
is the task to rename the *.a file to lib*.a clear? Do you have
any problem with this. (If its just spare time issue at your side
that's fine. I'm just checking whether you need more help.)
Kind regards
Andreas.
On Wed, Sep 16, 2020 at 06:10:50AM +0200, Andreas Tille wrote:
On Tue, Sep 15, 2020 at 03:51:50PM -0400, Aaron M. Ucko wrote:
Andreas Tille writes:
I: ampl-netlib-solvers: unstripped-static-library
usr/lib/x86_64-linux-gnu/amplsolver.a(asldate.o)
[...]
I have not seen this info before but considering the size of
usr/lib/x86_64-linux-gnu/amplsolver.a I suspect all needed libraries
are statically linked which is what we do not want.
Not necessarily; the library may in fact simply be unstripped. In
particular, it looks like dh_strip covers static (*.a) libraries only
when their names start with the usual "lib" prefix. If you specifically
need an unprefixed name, I suppose it would work to install the library
as libamplsolver.a so that dh_strip will see it, and direct dh_link to
establish an unprefixed symlink. If you're using Debhelper level 13 or
higher, you can do so without touching debian/rules by simply listing
usr/lib/${DEB_HOST_MULTIARCH}/libamplsolver.a
usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
in debian/ampl-netlib-solvers.links.
I admit that would have been my next suggestion to name the file lib*.a.
I did not expexted that this might solve the issue that the library
might be unstripped right now. Thanks a lot for the hint.
Making a shared version of this library might be a good idea regardless.
Definitely. It will be the next step.
Thanks a lot for your hints
Andreas.
--
http://fam-tille.de
Fwd: Re: [MoM] ampl-netlib-solvers
Hi Andreas,
Just to check if you got my previous mail.
Thanks!
Best
AndreiR
--- Forwarded message ---
From: Andrei Rozanski rozansk...@gmail.com
Date: September 21, 2020 09:56:40
Subject: Re: [MoM] ampl-netlib-solvers
To: debian-med@lists.debian.org
Hi Andreas,
Many thanks for reaching out and sorry for the delay in getting back to you.
I was reading and trying to understand a bit more of the whole process.
I guess some of the steps on packaging are still not clear to me.
I have added d/ampl-netlib-solvers.links as Aaron has kindly suggested
(thanks Aaron!). (commit 1d6f7cabaf956738f7e6b7adafa24e9b53d66746)
Thanks,
Best
AndreiR
On 9/21/20 9:03 AM, Andreas Tille wrote:
Hi Andrei,
is the task to rename the *.a file to lib*.a clear? Do you have
any problem with this. (If its just spare time issue at your side
that's fine. I'm just checking whether you need more help.)
Kind regards
Andreas.
On Wed, Sep 16, 2020 at 06:10:50AM +0200, Andreas Tille wrote:
On Tue, Sep 15, 2020 at 03:51:50PM -0400, Aaron M. Ucko wrote:
Andreas Tille writes:
I: ampl-netlib-solvers: unstripped-static-library
usr/lib/x86_64-linux-gnu/amplsolver.a(asldate.o)
[...]
I have not seen this info before but considering the size of
usr/lib/x86_64-linux-gnu/amplsolver.a I suspect all needed libraries
are statically linked which is what we do not want.
Not necessarily; the library may in fact simply be unstripped. In
particular, it looks like dh_strip covers static (*.a) libraries only
when their names start with the usual "lib" prefix. If you specifically
need an unprefixed name, I suppose it would work to install the library
as libamplsolver.a so that dh_strip will see it, and direct dh_link to
establish an unprefixed symlink. If you're using Debhelper level 13 or
higher, you can do so without touching debian/rules by simply listing
usr/lib/${DEB_HOST_MULTIARCH}/libamplsolver.a
usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
in debian/ampl-netlib-solvers.links.
I admit that would have been my next suggestion to name the file lib*.a.
I did not expexted that this might solve the issue that the library
might be unstripped right now. Thanks a lot for the hint.
Making a shared version of this library might be a good idea regardless.
Definitely. It will be the next step.
Thanks a lot for your hints
Andreas.
--
http://fam-tille.de
Re: [MoM] ampl-netlib-solvers
Hi Andreas,
Many thanks for reaching out and sorry for the delay in getting back to you.
I was reading and trying to understand a bit more of the whole process.
I guess some of the steps on packaging are still not clear to me.
I have added d/ampl-netlib-solvers.links as Aaron has kindly suggested
(thanks Aaron!). (commit 1d6f7cabaf956738f7e6b7adafa24e9b53d66746)
Thanks,
Best
AndreiR
On 9/21/20 9:03 AM, Andreas Tille wrote:
Hi Andrei,
is the task to rename the *.a file to lib*.a clear? Do you have
any problem with this. (If its just spare time issue at your side
that's fine. I'm just checking whether you need more help.)
Kind regards
Andreas.
On Wed, Sep 16, 2020 at 06:10:50AM +0200, Andreas Tille wrote:
On Tue, Sep 15, 2020 at 03:51:50PM -0400, Aaron M. Ucko wrote:
Andreas Tille writes:
I: ampl-netlib-solvers: unstripped-static-library
usr/lib/x86_64-linux-gnu/amplsolver.a(asldate.o)
[...]
I have not seen this info before but considering the size of
usr/lib/x86_64-linux-gnu/amplsolver.a I suspect all needed libraries
are statically linked which is what we do not want.
Not necessarily; the library may in fact simply be unstripped. In
particular, it looks like dh_strip covers static (*.a) libraries only
when their names start with the usual "lib" prefix. If you specifically
need an unprefixed name, I suppose it would work to install the library
as libamplsolver.a so that dh_strip will see it, and direct dh_link to
establish an unprefixed symlink. If you're using Debhelper level 13 or
higher, you can do so without touching debian/rules by simply listing
usr/lib/${DEB_HOST_MULTIARCH}/libamplsolver.a
usr/lib/${DEB_HOST_MULTIARCH}/amplsolver.a
in debian/ampl-netlib-solvers.links.
I admit that would have been my next suggestion to name the file lib*.a.
I did not expexted that this might solve the issue that the library
might be unstripped right now. Thanks a lot for the hint.
Making a shared version of this library might be a good idea regardless.
Definitely. It will be the next step.
Thanks a lot for your hints
Andreas.
--
http://fam-tille.de
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On Tue, Sep 15, 2020 at 2:54 PM Andreas Tille wrote: > Hi Andrei, > > On Mon, Sep 14, 2020 at 10:08:37PM +0200, Andrei Rozanski wrote: > > Copyright updated. > > Yeah.. I am quite paranoid about copyright :) Thanks for fixing it . > I'm sorry I seem to have dragged you into some extra work (like as a > school punishment). It was not intended that you split up all those > files into single copyright years. I summarised those two blocks of > files that were copyrighted by different copyright holders and simply > used the beginning and ending years for all. That should be sufficient > to give them according credit. So my self-imposed punishment was to > fix those edits. ;-) > The real missing was the license field that really belongs to every > Files paragraph. This is added as well. So this should be OK now. > Ok. I will check the commits. Thanks! > I also worked a bit on debian/control - please check my two commits. > One is fixing that the short description should be no sentence. > The other one fixes the lintian warning about a too long line in > the description. I simply fixed it by using > >cme fix dpkg-control > > Ok. > Please confirm that you have cme installed and can run this program > sucessfully. Its your friend when doing automatic changes to d/control. > > Please also confirm that you can run lintian - I strongly recommend to > install lintian from unstable no matter what system you are running - be > it stable, testing or even some Debian derivative. Since we are > developing for unstable we should use the latest policy checker. To > ensure this I have droped the following file on my system: > > $ cat /etc/apt/preferences.d/01-lintian.pref > Package: lintian > Pin: release a=unstable > Pin-Priority: 601 > > Package: lintian-brush > Pin: release a=unstable > Pin-Priority: 601 > > Ok. I will check. > > Lintian-brush is another nice package which I regularly use. It just > fixes lintian issues and commits these to your Git repository. > > So lintian tells you about the resulting package: > > I: ampl-netlib-solvers: unstripped-static-library > usr/lib/x86_64-linux-gnu/amplsolver.a(asldate.o) > I: ampl-netlib-solvers: unstripped-static-library > usr/lib/x86_64-linux-gnu/amplsolver.a(atof.o) > I: ampl-netlib-solvers: unstripped-static-library > usr/lib/x86_64-linux-gnu/amplsolver.a(auxinfo.o) > I: ampl-netlib-solvers: unstripped-static-library ... use > --no-tag-display-limit to see all (or pipe to a file/program) > > > (when running with --info severity which I ensure by droping the following > file: > > $ cat ~/.config/lintian/lintianrc > color=always > display-experimental=no > display-info=yes > > ) > > I will look into it. Thanks for all comments, directions and help. > I have not seen this info before but considering the size of > usr/lib/x86_64-linux-gnu/amplsolver.a I suspect all needed libraries > are statically linked which is what we do not want. So your task > is to find a quilt patch for the makefile to prevent static linking > and do dynamic linking instead. For sure you can keep on asking here > how to do this. > > Kind regards > >Andreas. > > > -- > http://fam-tille.de > > Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, Copyright updated. Thanks! Best AndreiR On 9/14/20 1:02 PM, Andreas Tille wrote: On Sun, Sep 13, 2020 at 07:01:33PM +0200, Andrei Rozanski wrote: Hi Andreas, I made the modifications that you have suggested. Not sure about the copyright warning on lintian. I have tried scan-copyrights and grepping README. No success. The simplest approach to learn about copyrights of different files is probably: grep -Ri copyright Please make sure you mention *all* copyright holders in an according Files: section. Many thanks! You are welcome Andreas.
Re: [MoM] ampl-netlib-solvers
Hi Andreas, I made the modifications that you have suggested. Not sure about the copyright warning on lintian. I have tried scan-copyrights and grepping README. No success. Many thanks! Best AndreiR On 9/12/20 10:49 PM, Andreas Tille wrote: Hi Andrei, On Sat, Sep 12, 2020 at 08:44:40PM +0200, Andrei Rozanski wrote: Thanks for that. You are welcome. I have compiled it in the past without issues making no changes in cflags. The only reason I did the patch was a sed line in https://github.com/ghackebeil/gjh_asl_json/blob/master/Thirdparty/get.ASL Probably those cflags would not make huge difference in the end. In Debian it is good to propagate CFLAGS (and other compiler flags into upstream Makefile. I fixed the patch to accomplish this and have standard build flags (which are generated from the hardening option for instance) as well as the recommended flags. The resulting package does not yet feature any build results which is as far as I see a development library. That means the package name should be probably libampl-netlib-solvers-dev Please make sure the *.a file that is build will be installed. I'd recomment to have a look for instance into https://salsa.debian.org/med-team/libvcflib/-/blob/master/debian/libvcflib-dev.install (well, there is a *.so file installed but the point is that it is installed in DEB_HOST_MULTIARCH). You also need to add dh-exec to Build-Depends. Usually also *.h files need to be installed. Regarding lintian warnings: I think you should simply remove the doc-base file. There is no relevant documentation to register and this template is not needed. Probably also the debian/tests dir can be removed. Kind regards Andreas.
Re: [MoM] ampl-netlib-solvers
Hi Andreas, On September 12, 2020 22:50:02 Andreas Tille wrote: Hi Andrei, On Sat, Sep 12, 2020 at 08:44:40PM +0200, Andrei Rozanski wrote: Thanks for that. You are welcome. I have compiled it in the past without issues making no changes in cflags. The only reason I did the patch was a sed line in https://github.com/ghackebeil/gjh_asl_json/blob/master/Thirdparty/get.ASL Probably those cflags would not make huge difference in the end. Ok. Got it. Thanks. In Debian it is good to propagate CFLAGS (and other compiler flags into upstream Makefile. I fixed the patch to accomplish this and have standard build flags (which are generated from the hardening option for instance) as well as the recommended flags. The resulting package does not yet feature any build results which is as far as I see a development library. That means the package name should be probably libampl-netlib-solvers-dev Please make sure the *.a file that is build will be installed. I'd recomment to have a look for instance into https://salsa.debian.org/med-team/libvcflib/-/blob/master/debian/libvcflib-dev.install (well, there is a *.so file installed but the point is that it is installed in DEB_HOST_MULTIARCH). You also need to add dh-exec to Build-Depends. Usually also *.h files need to be installed. Ok. Will do. Regarding lintian warnings: I think you should simply remove the doc-base file. There is no relevant documentation to register and this template is not needed. Probably also the debian/tests dir can be removed. Kind regards Andreas. -- http://fam-tille.de Thanks for the guidance. Best AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas, Thanks for that. I have compiled it in the past without issues making no changes in cflags. The only reason I did the patch was a sed line in https://github.com/ghackebeil/gjh_asl_json/blob/master/Thirdparty/get.ASL Probably those cflags would not make huge difference in the end. Thanks Best AndreiR On September 12, 2020 19:15:34 Andreas Tille wrote: On Sat, Sep 12, 2020 at 02:55:58PM +0200, Andrei Rozanski wrote: > If you reach that point and have no idea how to fix it - we can continue. I get the same error. I have been playing around with debian/rules - DEB_CFLAGS_STRIP However, not sure if in the right track. Your patch was wrong. I simply deactivated upstream CFLAGS and now it builds. I'd recommend to run lintian on the resulting package. Kind regards Andreas. -- http://fam-tille.de
Re: [MoM] ampl-netlib-solvers
Hi Andreas,
On 9/11/20 10:55 PM, Andreas Tille wrote:
Hi Andrei,
On Fri, Sep 11, 2020 at 09:48:33PM +0200, Andrei Rozanski wrote:
I have pushed ampl-netlib-solvers -
https://salsa.debian.org/med-team/ampl-netlib-solvers along with makefile.u
cflags patch.
Nice you started this effort.
Would it be possible to check that and guide me on how to proceed?
I pushed some commits with hopefully clear enough commit messages.
For the get-orig-source script I basically copied from
https://salsa.debian.org/med-team/phipack/-/blob/master/debian/get-orig-source
I think its better to have a full date in form MMDD as "version".
The script itself is helpful if others want to reproduce how the
orig.tar.xz tarball was created.
I also silenced uscan by using the template for a fake watch file.
The tarball was imported via
gbp import-orig --pristine-tar
../tarballs/ampl-netlib-solvers_0~20190702.orig.tar.xz
(in this case after a `git branch upstream` since gbp required this
branch - please see Debian Med policy [1])
I'd recommend you check my commits and if something remains unclear feel
free to ask here.
I'd recommend now that you have setup pbuilder (or sbuild at your
preference) as it is described in the Debian Med policy as well
and confirm that you can do
gbp buildpackage
to build the package. You will see that the build ends in
dh_auto_build
make -j4
make[1]: Entering directory '/build/ampl-netlib-solvers-0~20190702'
cd ${OBJDIR=sys.`uname -m`.`uname -s`}; make
make[2]: Entering directory
'/build/ampl-netlib-solvers-0~20190702/sys.x86_64.Linux'
make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
cc -c CFLAGS = -O3 -pipe -DNDEBUG -DASL_BUILD -fPIC -DPIC -O -DASL_NO_FPINITMT
fpinit.c
cc: error: CFLAGS: No such file or directory
cc: error: =: No such file or directory
make[2]: *** [makefile:234: arith.h] Error 1
If you reach that point and have no idea how to fix it - we can continue.
I get the same error. I have been playing around with debian/rules -
DEB_CFLAGS_STRIP
However, not sure if in the right track.
Thanks a lot for your work
Andreas.
[1]
https://med-team.pages.debian.net/policy/#to-create-a-new-local-git-repository
Thanks!
Best
AndreiR
Re: [MoM] ampl-netlib-solvers
Hi Andreas,
Many thanks for all the help and detailed commits. Also, thanks for
guiding me on next steps.
I will proceed as you suggested.
Best,
AndreiR
On 9/11/20 10:55 PM, Andreas Tille wrote:
Hi Andrei,
On Fri, Sep 11, 2020 at 09:48:33PM +0200, Andrei Rozanski wrote:
I have pushed ampl-netlib-solvers -
https://salsa.debian.org/med-team/ampl-netlib-solvers along with makefile.u
cflags patch.
Nice you started this effort.
Would it be possible to check that and guide me on how to proceed?
I pushed some commits with hopefully clear enough commit messages.
For the get-orig-source script I basically copied from
https://salsa.debian.org/med-team/phipack/-/blob/master/debian/get-orig-source
I think its better to have a full date in form MMDD as "version".
The script itself is helpful if others want to reproduce how the
orig.tar.xz tarball was created.
I also silenced uscan by using the template for a fake watch file.
The tarball was imported via
gbp import-orig --pristine-tar
../tarballs/ampl-netlib-solvers_0~20190702.orig.tar.xz
(in this case after a `git branch upstream` since gbp required this
branch - please see Debian Med policy [1])
I'd recommend you check my commits and if something remains unclear feel
free to ask here.
I'd recommend now that you have setup pbuilder (or sbuild at your
preference) as it is described in the Debian Med policy as well
and confirm that you can do
gbp buildpackage
to build the package. You will see that the build ends in
dh_auto_build
make -j4
make[1]: Entering directory '/build/ampl-netlib-solvers-0~20190702'
cd ${OBJDIR=sys.`uname -m`.`uname -s`}; make
make[2]: Entering directory
'/build/ampl-netlib-solvers-0~20190702/sys.x86_64.Linux'
make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
cc -c CFLAGS = -O3 -pipe -DNDEBUG -DASL_BUILD -fPIC -DPIC -O -DASL_NO_FPINITMT
fpinit.c
cc: error: CFLAGS: No such file or directory
cc: error: =: No such file or directory
make[2]: *** [makefile:234: arith.h] Error 1
If you reach that point and have no idea how to fix it - we can continue.
Thanks a lot for your work
Andreas.
[1]
https://med-team.pages.debian.net/policy/#to-create-a-new-local-git-repository
[MoM] ampl-netlib-solvers
Hi Andreas, I have pushed ampl-netlib-solvers - https://salsa.debian.org/med-team/ampl-netlib-solvers along with makefile.u cflags patch. Would it be possible to check that and guide me on how to proceed? Thanks! Best AndreiR
Re: [MoM] packaging gjh_asl_json (Was: Short Introduction)
Hi Andreas, On 9/8/20 11:56 AM, Andreas Tille wrote: Hi Andrei, Not a problem at all. Thanks for answering. sorry for the long delay which should remain untypical in a MoM project. My weekend was occupied by real life and yesterday was a busy day. On Fri, Sep 04, 2020 at 02:40:29PM +0200, Andrei Rozanski wrote: I'll leave it to your preference since I don't mind much. I guess it makes those rows shorter whan just having names without links and thus easier to edit - but as I said, I don't mind much. gjh_asl_json asks for as part of the setup. Not sure if the "dependency" should be a separate package... So there is need to fetch |http://www.ampl.com/netlib/ampl/solvers.tgz - |https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/Thirdparty/get.ASL#L6 Ahhh, I was hoping that we will start with something simple but that's for sure a new challenge. Inside the packaging process you are not allowed to download anything. Code that is needed needs to be packaged separately. Usually you are lucky with this kind of scientific software and so I tried to seek for it by apt-file search asl_pfg.h apt-file search avltree.h apt-file search jac2dim.h Seeking this way in packages usually reveals in what package the header files are available. I'm mentioning this to explain what I'm using - in the most cases successfully but it has no results so far. However, I've got something via apt-cache search netlib shows that this is somehow related to the Basic Linear Algebra system maintained in the Debian Science team. I admit I'm not very well educated about this. To be sure I'd recommend to ask for advise there. in order to be able to compile the program - https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/Makefile#L27 Not sure if its fine to fetch it and ship with that in place. Or to have a different package and add it as dependency. Ok. I have asked them. Yes, building a separate package netlib-ampl-solvers (or something like this) might be necessary - but I'd advise to ask for more opinions on Debian Science list. This is also sensible in the MoM project to enable you learning about those teams that might help you in your projects. Thanks Hope to be more responsive in the next couple of days. Kind regards Andreas. Thanks Best, AndreiR
Re: [MoM] packaging gjh_asl_json (Was: Short Introduction)
Hi Andreas, On 9/4/20 1:12 PM, Andreas Tille wrote: Hi Andrei On Fri, Sep 04, 2020 at 11:50:44AM +0200, Andrei Rozanski wrote: Thanks for the feedback. I see the point. Also with multiple selection was not that big the effort ;) Sure. :-) I am happy to change the links if you provide one or I can get rid of them. Fixed. I'll leave it to your preference since I don't mind much. I guess it makes those rows shorter whan just having names without links and thus easier to edit - but as I said, I don't mind much. I am reading the https://www.debian.org/doc/manuals/maint-guide/ in order to understand how to deal with the "ThirdParty" import that gjh_asl_json asks for as part of the setup. Not sure if the "dependency" should be a separate package... So there is need to fetch |http://www.ampl.com/netlib/ampl/solvers.tgz - |https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/Thirdparty/get.ASL#L6 in order to be able to compile the program - https://salsa.debian.org/med-team/gjh-asl-json/-/blob/master/Makefile#L27 Not sure if its fine to fetch it and ship with that in place. Or to have a different package and add it as dependency. Please simply ask here what might be your exactproblem and do not hesitate to push your reporitory soon. May be we can give sensible hints more quickly than if you read the whole maint-guide. ;-) Kind regards Andreas. Thanks Best AndreiR
Re: [MoM] packaging gjh_asl_json (Was: Short Introduction)
Hi Andreas, Thanks for the feedback. I see the point. Also with multiple selection was not that big the effort ;) I am happy to change the links if you provide one or I can get rid of them. On 9/4/20 11:41 AM, Andreas Tille wrote: On Thu, Sep 03, 2020 at 08:10:45PM +0200, Andrei Rozanski wrote: Thanks! It worked. Good. I've seen you've spent a lot of time just to link my name to wiki.d.o page. While that's nice of you it would really not have been worth that effort. Its definitely not the best representation of my work and not maintained at all. ;-) But I agree that it now is closer to the original page - thanks for it. I am reading the https://www.debian.org/doc/manuals/maint-guide/ in order to understand how to deal with the "ThirdParty" import that gjh_asl_json asks for as part of the setup. Not sure if the "dependency" should be a separate package... Do you have any questions regarding your actual work on the gjh_asl_json package? Kind regards Andreas. Thanks! Best, AndreiR
Re: Short Introduction
Hi Andreas, On 9/3/20 4:07 PM, Andreas Tille wrote: Hi Andrei, On Thu, Sep 03, 2020 at 02:49:41PM +0200, Andrei Rozanski wrote: I have done only a few changes. Is it possible to give me permissions to push the changes? ``` remote: You are not allowed to write to this project's wiki. fatal: unable to access 'https://salsa.debian.org/med-team/community/MoM.wiki.git/': The requested URL returned error: 403 ``` Thanks! It worked. I added rozanski to the Debian Med team which should be sufficient to gain push permissions. Thanks for your work on this Andreas. Best, AndreiR
Re: How to package human, mouse and viral genomes?
Hi Steffen, I am new to Debian Med :) Maybe could be easier to keep a registry of links, md5sum, taxonId, database, version, etc. Then, when needed one can fetch the genomes on the fly and check md5 using scripts that parse the registry. The genomes are not huge anyways (unless somebody wants to work with Axolotl :) ) so the download is quite fast (specially if using 2bit from ucsc - however 2bit will require twoBitToFasta). As the time passes the number of genomes and and versions grows so could be difficult to keep a copy of all genomes needed. Depending on the database, one could automatize the version check and find new genomes as they are released. Thanks Best, AndreiR On September 3, 2020 17:16:32 Steffen Möller wrote: Hello, We are closing in on the workflows. What is kind of missing are the mostly invariant inputs like the genomes of pathogens and very much so the reference genomes of the human, mouse, rat, worm, fly, you name them. Other than a few years ago, hard drives are now big enough to accommodate the one or other genome and derivative indexes. Just - I don't think we want to organize in our regular Debian infrastructure something as variant as public genome (yes, they are still regularly updated, very much so) and that is so very security-irrelevant (just some data). Also, different sites will vary a lot in where this data shall be organized and all those scripts should likely be executed/initiated as/by non-root. There are public sites for this from where this data can be downloaded. Any redundancy to these sites imho mostly hurts us. The other side is that to just get something up quickly and for reproducibility tests, our infrastructure is difficult to beat. Please kindly throw your ideas at me how you would like whole genomes to be presented by Debian to the average user and to professionals. Just reply to this thread and/or send me "+1"s a PM and I summarize this up in a document which I suggest we then talk about in a jitsi meeting. Best, Steffen
Re: Short Introduction
Hi Andreas, On 9/3/20 8:18 AM, Andreas Tille wrote: Hi Andrei, On Wed, Sep 02, 2020 at 05:53:06PM +0200, Andrei Rozanski wrote: Thanks for the help. You are welcome. I will check it. Thanks. Also, if needed, I could try to help migrating other pages. Ok, thanks. I do not think that anything will become structurally better if pages will be migrated. Admittedly our documentation is pretty poor but I do not think this will change just because it will be placed at some other Wiki (for sure I might be wrong here - its just my personal opinion). The rationale behind moving the MoM page is that its just bad to move newcomers into the situation in which you found yourself: Make a lot of effort to just add a single row to a table. Since you need to create a salsa.d.o login anyway if you want to join a MoM project I can now give the advise: "Please create a salsa login and add a row to the table on the wiki page hosted in Salsa." This makes way more sense than confronting people with wiki.d.o. BTW, there are good reasons to make the creating-login-process so cumbersome since we were bothered by spammers in the past. Kind regards Andreas. I have done only a few changes. Is it possible to give me permissions to push the changes? ``` remote: You are not allowed to write to this project's wiki. fatal: unable to access 'https://salsa.debian.org/med-team/community/MoM.wiki.git/': The requested URL returned error: 403 ``` Thanks! Best AndreiR
Re: Short Introduction
Hi Andreas, Thanks for the help. On September 2, 2020 17:11:36 Andreas Tille wrote: Hi Andrei, On Tue, Sep 01, 2020 at 09:49:42PM +0200, Andrei Rozanski wrote: I am not bored about wikis but maybe I will accept your help since when trying to create wiki account I get: ``` Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact w...@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online translation services.. ``` I will check it. Also, if needed, I could try to help migrating other pages. I admit that's a real nuisance. I'd like to stop this for ever now and moved the whole Wiki page to https://salsa.debian.org/med-team/community/MoM/-/wikis/home Since this has Markdown syntax and the old MoinMoin Wiki has some other syntax it needed a bit of manual tweaking. It would be really great help if you could please proof read what I did and compare the old page https://wiki.debian.org/DebianMed/MoM Please check whether my port was sensible and I have not forgot to change some syntax somewhere as your first contribution. Reading the text again might help you anyway. To do so simply create a Salsa account (which you need anyway) and add yourself to the table. Kind regards Andreas. -- http://fam-tille.de Best AndreiR
Re: Short Introduction
Hi Andreas, I am not bored about wikis but maybe I will accept your help since when trying to create wiki account I get: ``` Account creation failed: Automatic account creation disabled to stop spammers signing up. Please contact w...@debian.org and describe what you want to do in the wiki. Please contact us in English, otherwise we will have to pass your message to online translation services.. ``` On 9/1/20 9:13 PM, Andreas Tille wrote: Hi Andrei, you wrote in private mail that you are not sure what package to choose. But MoM is always about open questions and answers. ;-) So I try to clarify here. On Tue, Sep 01, 2020 at 09:24:47AM +0200, Andrei Rozanski wrote: Regarding machine learning we are in the process of packaging tensorflow which requires some predependency. On this front I lost track - but may be someone can enlighten here. On programming languages and environment, most of what I do involves bash scripting, GNU Make for pipelines, python and currently learning C++. I think its a great idea. My vote is on the spreadsheet. It would have been perfectly fine if you would have picked one. I had a very quick look into https://github.com/ghackebeil/gjh_asl_json mentioned in the table. I picked it since it is not even yet in Salsa so you get the training of injecting it there. From an extremely quick look it seems to be sufficiently easy to package (we'll see whether I'm correct here). Also, will check MoM link. Fine. Just add a row in the Wiki table (or simply ask me to do so if you are bored to create just another login on some "random" Wiki - there is no strong need for you to create a login there). You definitely need a login on Salsa (which makes me wonder whether I should move the Wiki from wiki.debian.org to a Wiki on Salsa sooner or later). Many thanks! You are welcome. If there are any questions that are not really private please simply post here and prefix the subject of your mail with [MoM]. Hope this helps Andreas. Thanks! AndreiR
Re: Short Introduction
Hi Andreas, Ok. Will do. On 9/1/20 9:13 PM, Andreas Tille wrote: Hi Andrei, you wrote in private mail that you are not sure what package to choose. But MoM is always about open questions and answers. ;-) So I try to clarify here. On Tue, Sep 01, 2020 at 09:24:47AM +0200, Andrei Rozanski wrote: Regarding machine learning we are in the process of packaging tensorflow which requires some predependency. On this front I lost track - but may be someone can enlighten here. On programming languages and environment, most of what I do involves bash scripting, GNU Make for pipelines, python and currently learning C++. I think its a great idea. My vote is on the spreadsheet. Great, will look into it. It would have been perfectly fine if you would have picked one. I had a very quick look into https://github.com/ghackebeil/gjh_asl_json mentioned in the table. I picked it since it is not even yet in Salsa so you get the training of injecting it there. From an extremely quick look it seems to be sufficiently easy to package (we'll see whether I'm correct here). Also, will check MoM link. Ok. Fine. Just add a row in the Wiki table (or simply ask me to do so if you are bored to create just another login on some "random" Wiki - there is no strong need for you to create a login there). You definitely need a login on Salsa (which makes me wonder whether I should move the Wiki from wiki.debian.org to a Wiki on Salsa sooner or later). Many thanks! Got it. You are welcome. If there are any questions that are not really private please simply post here and prefix the subject of your mail with [MoM]. Hope this helps Andreas. Thanks for clarifying. Best AndreiR
Re: Short Introduction
Hi Andreas, Thanks for the welcome! On 8/31/20 11:08 PM, Andreas Tille wrote: Hi Andrei, thanks a lot for your interest in Debian Med (again - since I also said so in private mail). On Mon, Aug 31, 2020 at 09:15:43PM +0200, Andrei Rozanski wrote: I am new to the project and I would like to introduce myself. My name is Andrei Rozanski, currently I am a researcher in computational biology/bioinformatics at MPI-BPC. I work with genomes and species comparison. Also, a little bit of machine learning and data analysis. Regarding machine learning we are in the process of packaging tensorflow which requires some predependency. On this front I lost track - but may be someone can enlighten here. On programming languages and environment, most of what I do involves bash scripting, GNU Make for pipelines, python and currently learning C++. I think its a great idea. My vote is on the spreadsheet. Also, will check MoM link. In the COVID-19 hackathons we developed a spreadsheet https://docs.google.com/spreadsheets/d/1tApLhVqxRZ2VOuMH_aPUgFENQJfbLlB_PFH_Ah_q7hM/edit?ts=5eb957ba#gid=543782716 which contains some todos and missings. I would suggest we try to package either some software you are using in your day to day work which is not yet packaged for Debian or we pick from the spreadsheet above to find a package where you can learn all things you need to know to work smoothly and efficient inside the Debian Med team. The formalisation of this is done here https://wiki.debian.org/DebianMed/MoM and this page contains a lot of links for newcomers you might like to read. Looking forward to contribute to the project! Thanks a lot and looking forward to work together with you Andreas. Many thanks! AndreiR
Short Introduction
Hello all, I am new to the project and I would like to introduce myself. My name is Andrei Rozanski, currently I am a researcher in computational biology/bioinformatics at MPI-BPC. I work with genomes and species comparison. Also, a little bit of machine learning and data analysis. On programming languages and environment, most of what I do involves bash scripting, GNU Make for pipelines, python and currently learning C++. Looking forward to contribute to the project! Thanks! Best Regards, AndreiR
