December 2020 bug squashing
Hi everybody, in order to carry on a tradition, I want to remind everybody of our combined efforts to take care of some poor souls. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 213 cases which are relevant to Debian Med[1] (this time 39 are serious or grave[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email1=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent-2020
libbio-db-ncbihelper-perl_1.7.4-1_amd64.changes REJECTED
Hi Michael, please mention the copyright holder of Bio-DB-NCBIHelper-1.7.4/bin/bp_biofetch_genbank_proxy in your debian/copyright. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
libbio-variation-perl_1.7.4-1_amd64.changes REJECTED
Hi Michael, please also mention Stan Nelson in your debian/copyright. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
libbio-db-refseq-perl_1.7.3-1_amd64.changes REJECTED
Hi Michael, please also mention Jason Stajich in your debian/copyright. Thanks! Thorsten === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns.
December 2019 bug squashing
Hi everybody, in order to carry on a tradition, I want to remind everybody of our combined efforts to take care of some poor souls. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 320 cases which are relevant to Debian Med[1] (this time 57 are serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-e xc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=gr ave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email1=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent-2019
December
Hi everybody, it is incredible but this time of the year has come again and in order to carry on a tradition, I want to remind everybody of our combined efforts to take care of some poor souls. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 240 cases which are relevant to Debian Med[1] (this time 50 are serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email1=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent-2018
Re: December
Hi everybody, advent is over and the calendar[1] has been filled with lots of entries. All in all 105 bugs have been closed, that is the second highest number after the all time record of 150 two years ago. So congratulations to all participants for a great job! Though some new bugs appeared during that bug squashing, the starting count of 180 bugs could be reduced to 113. The number of serious bugs could be reduced from 21 to 12. So, get some rest now for the next calendar in 2018 :-). I wish everybody a Happy New Year! Thorsten [1]http://debian-med.alteholz.de/advent
Re: Bugs closed in team help
Hi Andreas, On Fri, 1 Dec 2017, Andreas Tille wrote: I'm not sure whether you consider Debichem team bugs as valid targets for the advent calendar nope, not for the debian-med calendar. But a debian-science calendar might be possible next year ... Thorsten
Re: SVN to Git migration status
Hi everybody, On Fri, 1 Dec 2017, Andreas Tille wrote: * I never liked the split of one upstream source into lots of SVN checkouts in different source packages. Those who are working on that set of packages need to do stupid repeated work for no good reason and I really regret that I added myself as Uploader which seems to be a good reason for other Uploaders to leave with this kind of boring work they introduced in the first place when I did some work on these packages, only the released versions did have a tarball, whereas all the release candidates only existed as tags in the repositories. Meanwhile I only see a source tarball for 1.5.6, but there are release tags for 1.5.7 and 1.6.0 ... Well. It is not _that_ easy since in general our ftpmasters like to have this all separated. Erm, why? There is a *single* download tarball. Since when asks ftpmaster for separating its content? ftpmasters don't like a tarball of tarballs. Thorsten
Re: figtree autopkgtest
Hi Andreas, On Thu, 30 Nov 2017, Andreas Tille wrote: I'll open several bugs for missing tests soon which we can close in our advent bug squashing party (Thorsten?) yes, but don't forget the old poor souls :-). Thorsten
December
Hi everybody, this time of the year has come again and in order to carry on a tradition (it is the seventh time this year), I want to remind everybody of our combined efforts to take care of some poor souls. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 180 cases which are relevant to Debian Med[1] (this time 21 are serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lot s of good deeds. Maybe we can hide at least one number of a closed case behind every door. I would like to mention #225651 [5] here, as this seems to be the oldest one that needs some help (at least a proper closing). Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent-2017 [5]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=225651
Re: December
Hi everybody, advent is over and the calender[1] has been filled with lots of entries. All in all 95 bugs have been closed, that is the second highest number after the all time record of 150 last year. So congratulations to all participants for a great job! Though some new bugs appeared during that bug squashing, because new versions of packages FTBFS, the starting count of 150 bugs could be reduced to 134. The number of serious bugs could be reduced from 9 to 6. So, get some rest now for the next calendar in 2017 :-). I wish everybody a Happy New Year! Thorsten [1]http://debian-med.alteholz.de/advent
December
Hi everybody, how time flies! This time of the year has come again and in order to carry on a tradition, I want to remind everybody of our combined efforts to take care of some poor souls. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are only about 150 cases which are relevant to Debian Med[1] (only 9 being serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent
Re: December
Hi everybody, Christmas finally arrived and the Advent calendar has been filled with lots of closed bugs. I am really impressed with the achievement of all participants. After the rather small quantity last year, the incredible number of 150 bugs have been closed this year! Thanks alot! Now I wish everybody a Happy New Year! Thorsten
December
Hi everybody, the time has come and in order to carry on a tradition, I want to remind everybody of our combined efforts to take care of some poor souls at this time of the year. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 260 cases which are relevant to Debian Med[1] (28 being serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door and I am sure we will be much better than last year. Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent
Re: python-dendropy_4.0.3-1_amd64.changes REJECTED
Hi everybody, as Andreas seems to have problems with my emails, can someone else please tell him that his long awaiting answer can be found at [1]. Thorsten [1] http://lists.alioth.debian.org/pipermail/debian-med-packaging/2015-October/035277.html
Re: python-pbcore's rejection
Hi Afif, On Sat, 11 Jul 2015, Andreas Tille wrote: On Fri, Jul 10, 2015 at 06:42:35PM -0700, Afif Elghraoui wrote: Hi, Andreas, I believe I've corrected the copyright file. My only question is whether I can still call it a BSD-3-clause license if it's slightly modified: the three clauses are virtually identical, but the notice afterwards is different. in this case others choose a different name like BSD or BSD Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.150743290.12...@jupiter.server.alteholz.net
December is near
Hi, in order to carry on a tradition, I want to remind everybody of our combined efforts to take care of some poor souls at this time of the year. The days are closing in, the year is drawing to an end and we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 200 cases which are relevant to Debian Med[1] (9 being serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Maybe some of the "won't fix" can be resolved as well. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. As Debian is in freeze now, please also tell me of any RC bug that you close in other packages. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Have fun, Thorsten [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1411262303410.16...@jupiter.server.alteholz.net
Re: New package of GWAMA
Hi Dylan, On Sat, 22 Nov 2014, Dylan wrote: I use the Files-Excluded field in copyright file to remove the __MACOSX upstream folder with uscan but I don't know why it doesn't work. one empty line and one "/" too much. Files-Excluded: belongs to the header. commandLine.cpp says: cout << "| (C) 2008 Reedik Magi & Andrew P Morris |" << endl; cout << "| GNU General Public License, v2 |" << endl; This needs to be clarified with upstream. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1411221253210.20...@jupiter.server.alteholz.net
Re: aegean
Hi Sascha, On Thu, 20 Nov 2014, Sascha Steinbiss wrote: may I kindly ask if you could consider into sponsoring aegean as well, not yet, data/share/vendor/jquery.dataTables.js data/misc/amel-ogs-vs-ncbi-parseval-html/vendor/jquery.dataTables.js are under GPLv2 as well and missing in your debian/copyright. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1411202312470.9...@jupiter.server.alteholz.net
Re: kmc and fastaq - New upstream release
Hi Jorge, in fastaq you added the .pc directory to the repository. This doesn't look good. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1411202316290.9...@jupiter.server.alteholz.net
Re: kmc and fastaq - New upstream release
Hi Jorge, On Thu, 20 Nov 2014, Jorge Sebastião Soares wrote: It would be wonderful to get kmc in as soon as possible. I would be able to finish the IVA package (kmc and fastaq being a dependency) sooner. is there a reason why kmc depends on libboost1.54-all-dev whereas 1.55 is already available? Thorsten
Re: kmc and fastaq - New upstream release
Hi Jorge, On Wed, 19 Nov 2014, Jorge Sebastião Soares wrote: Does this mean that you'll sponsor the two packages? :) for kmc you need to take two hurdles: finding a sponsor and pass through the NEW queue. I can only help you with one of them (conflict of interest and stuff like that). So you may choose :-). Thorsten
Re: [KMC + asmlib] KMC Debian package progress
Hi Jorge, On Tue, 18 Nov 2014, Jorge Sebastião Soares wrote: KMC packaging is done. the Copright:-line in your debian/copyright needs some attention. Thorsten
Re: [fastaq_1.6.0] - New upstream release
Hi Jorge, On Tue, 18 Nov 2014, Jorge Sebastião Soares wrote: I have just finished packaging the new upstream version of fastaq. "UNRELEASED" in debian/changelog should be better "experimental". Thorsten
Re: Updating the fis-gtm package to V6.2-000
Hi Andreas, On Thu, 9 Oct 2014, Andreas Tille wrote: really sense - I'm no fis-gtm user. However, we agreed that for a low popcon package it is not possible to maintain several versions officially. Does this clarify my idea why fixing the licensing issue in fis-gtm-6.2-000 would be sufficient? aah, I think I forgot this part of the discussion. So, everything is fine. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410101946170.7...@jupiter.server.alteholz.net
Re: Updating the fis-gtm package to V6.2-000
Hi Andreas, On Thu, 9 Oct 2014, Andreas Tille wrote: No. We *could* have fixed 6.1-000 before (and it would have migrated to testing then) but since you immediately started working on 6.2 I considered it more sensible to fix it in 6.2 which can close the bug in the same manner. Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by uploading 6.2-000. I think the bug should not be assigned to package fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in fis-gtm-6.2-000 as well) Hmmm, the affected fis-gtm-6.1-000 will vanish from Debian mirror, after fis-gtm-6.2-000 will be accepted. fis-gtm in version 6.1-000 will vanish after upload of fis-gtm in version 6.2-000. But src:fis-gtm currently creates bin:fis-gtm-6.1-000 and will create bin:fis-gtm-6.2-000 after the upload. Wasn't the reason for creating the fis-gtm meta package to have different versions in the archive? Otherwise it wouldn't make sense to have the version within the package name. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410091215440.7...@jupiter.server.alteholz.net
Re: Updating the fis-gtm package to V6.2-000
On Thu, 9 Oct 2014, Andreas Tille wrote: Does it matter that the bug was submitted against 6.1-000 and we are working on V6.2-000? No. We *could* have fixed 6.1-000 before (and it would have migrated to testing then) but since you immediately started working on 6.2 I considered it more sensible to fix it in 6.2 which can close the bug in the same manner. Hmm, strictly speaking the bug is in 6.1-000 and won't be fixed by uploading 6.2-000. I think the bug should not be assigned to package fis-gtm but rather fis-gtm-6.1-000 (and of course be fixed in fis-gtm-6.2-000 as well) Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410090949170.28...@jupiter.server.alteholz.net
Re: Updating the fis-gtm package to V6.2-000
On Mon, 6 Oct 2014, Bhaskar, K.S wrote: [KSB2] Adding a license exception to the COPYING file would probably require me to go through Legal and that may add delays that increase the risk of pushing us past the deadline. Aah, ok. Would removing the claim of copyright to the reference implementation of the plugin solve the issue? Thanks. I am afraid not, you can not invalidate a license by only adding another layer. So as long as you use the plugin, the openssl license is still valid. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1410090858360.25...@jupiter.server.alteholz.net
Re: Updating the fis-gtm package to V6.2-000
Hi Bhaskar, On Thu, 2 Oct 2014, Bhaskar, K.S wrote: [KSB] Those *openssl* files are versions of the reference implementation of the plugin compiled with #include, #if, etc. configured to call call OpenSSL. They are not actually linked to OpenSSL or other libraries - linking happens dynamically. Oh, come on, why should it matter whether you are linking at compile time or at run time? In both cases the result is a combined binary. kbhaskar@bhaskark:~$ ls -l /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/lib*crypt* /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_AES256CFB.so -r-xr-xr-x 1 root root 40056 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_BLOWFISHCFB.so lrwxrwxrwx 1 root root 33 Sep 18 15:45 kbhaskar@bhaskark:~$ Yes and when you look with ldd at libgtmcrypt_openssl* you see that libssl is needed. Most of the discussion of license interaction between copyleft and non-copyleft licenses at en.wikipedia.org/wiki/GNU_General_Public_License pertain to software used under non-copyleft licenses requesting services from (I deliberately avoid the use of "linking to") software used under non-copyleft licenses. In this case, we have the reverse - a copyleft software (GT.M) requesting services from non-copyleft software (OpenSSL). Regardless, it appears that there are different schools of thought on this. Hmm, so why do you think that almost all GPL software that links to OpenSSL has a special OpenSSL exception? I am afraid such discussions have been made frequently ... * Include a statement in the README that says something like: As dynamic linking by the reference implementation of the plugin to software such as cryptographic libraries that are released under non-copyleft licenses is not considered to create a derivative work, there is no interaction between the license used for GT.M and those of cryptographic libraries. * Remove any claim of copyright from the reference implementation of the plugin (i.e., place the reference implementation in the public domain). * Remove the precompiled versions of the reference implementation of the plugin from the distribution and include only the source of the plugin (as I noted earlier, the GT.M binary distribution includes source code for the reference implementation of the plugin). Use the post-install script to compile the reference implementation of the plugin. Thorsten, please let me know what you think. I don't understand why you don't want to go the easy way? As you consider to remove the license in 2), why don't you just add the exception to your license text? Otherwise the last proposal would be fine. Thorsten
Re: Updating the fis-gtm package to V6.2-000
Hi Bhaskar, On Mon, 29 Sep 2014, Bhaskar, K.S wrote: GT.M does not require OpenSSL, does not statically link to it, and does not in a strict sense, depend on OpenSSL. But there is a looser relationship / dependency. hmm, while looking at the Debian package, I found the following comment: "The upstream V6.2-000 CMakeLists.txt file built only one of three possible encryption plugin libraries. This meant that the debian fis-gtm package was missing a core piece of the distributed binaries. Upstream will apply this change to the next release after internal review." Further the Debian package contains: libgtmcrypt_openssl_BLOWFISHCFB.so libgtmcrypt_gcrypt_AES256CFB.so libgtmcrypt_openssl_AES256CFB.so So at least the version in the Debian package is actually linked with OpenSSL. As the OpenSSL license contains (advertising) restrictions[1] that are not allowed by the AGPL, the AGPL must be extended by an exception clause. Thorsten [1]https://en.wikipedia.org/wiki/OpenSSL#Licensing -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1409300846530.7...@jupiter.server.alteholz.net
Re: Updating the fis-gtm package to V6.2-000
On Mon, 29 Sep 2014, Andreas Tille wrote: [amul:4] V6.2-000 is ready for upload! And so I did. Thanks for your work on this Hmm, AGPL code without exception linked with openssl doesn't look well .. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.02.1409292006420.29...@jupiter.server.alteholz.net
Re: Set of R preliminary packages towards (r-bioc-)BioSeqClass - 2Upload!2U
Hi Steffen, On Thu, 10 Jul 2014, "Steffen Möller" wrote: package, which is all much about machine learning on biological sequences. Those packages work, but are not nice, yet, in particular those are not necessarily DFSG clean at the very moment. It is mostly about PDFs shipping with the source tree. as long as there is a corresponding *.Rnw, this would be no problem. But please don't forget an entry for all *.rda in debian/README.source Thorsten
Re: force bowtie2 transition to testing
On Wed, 9 Apr 2014, Andreas Tille wrote: On Wed, Apr 09, 2014 at 05:42:22PM +0200, Alex Mestiashvili wrote: bowtie2 has stuck in unstable because of change in supported architectures. I've opened #742614, but haven't received any reaction so far. Is there anything else one can do to force the transition ? May be also pinging "our" ftpmaster assistant? ;-) Hmm, sorry, but I don't do rm's. They are far too exciting for my poor heart. But you might ask on #debian-ftp for a more robust person ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.lnx.4.64.1404092213150.21...@tor.gallien.in-chemnitz.de
Re: [MoM] incorporating phyutility into the packages
Hi Stephen, lintian tells me something about: W: phyutility: incompatible-java-bytecode-format Java7 version (Class format: 51 I am not a Java expert, but wouldn't this make the package unusable on standard Debian? Do you need src/jade/lib/libmatrixExp.so for anything? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.lnx.4.64.1404011451530.29...@tor.gallien.in-chemnitz.de
Re: [MoM] incorporating phyutility into the packages
Hi Stephen, On Thu, 20 Mar 2014, Stephen Smith wrote: Hopefully, yes! I have tracked down as best I can, all the authors of the original JEBL and the LGPL version that it was under. These have been added to the copyright. sorry for not being more verbose, the jebl directory was just one example. There are more files that need to be added to debian/copyright: src/phyutility/drb/WwdUtils.java <- Apache 2.0 src/jade/data/TransitionPenaltyTable.java -> LGPL (and maybe there are others) Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.lnx.4.64.1403231415590.24...@tor.gallien.in-chemnitz.de
Re: [MoM] incorporating phyutility into the packages
Hi Stephen, On Sun, 16 Mar 2014, Stephen Smith wrote: I would be happy to take a look at the copyright contents. However, I am a bit new to this so not exactly sure which bits are missing. In debian/copyright the maintainer must document the copyright holder and license of all files in the source tarball (wildcards are allowed). In your case I found files with license LGPL in the header, so those need to be added. On your website you say something about GPL2+ as license for phyutility, but in debian/copyright it is GPL3+. (http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/) to be dense, just not sure. Maybe Andreas or you could point me in the right direction and I can fix things. Aha, the copyright needs the jebl authors as well I am guessing? Yes, the authors and more important the license of their files. As for jebl being a separate package, it is a bit complicated. The original one is no longer maintained (http://sourceforge.net/projects/jebl/) though this older one is the one that is included in phyutility. Seems like those sources aren't even available anymore. There is an updated (https://code.google.com/p/jebl2/) one, but this is not the one used by phyutility. Oh, thats the answer I didn't expect. As there is a dependency on libjebl2-java in debian/control I thought that your version of jebl is just unused and could be removed from the source tarball (not the original one but the one included in Debian). So from phyutility's perspective, I am not sure it would be helpful to have jebl2 as a package. Again, new to this, so happy to do whatever is best. jebl2 is already available in Debian, so the question is whether you could use it in phyutility. If yes, you could repackage the sources and remove your copy of jebl. If not, you might create a libjebl1 package which might be useful for others (as there are no others sources available, you might create this from your package). Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.lnx.4.64.1403170931090.16...@tor.gallien.in-chemnitz.de
Re: [MoM] incorporating phyutility into the packages
Hi Stephen, thanks to Andreas I learned today that I need to write more emails and that phyutility is going to be uploaded soon. Before this upload, can you please have a closer look at the (yet) incomplete contents of debian/copyright. Would it make sense to create a separate package from the included jebl library? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.lnx.4.64.1403162158340.12...@tor.gallien.in-chemnitz.de
Re: readseq2 upstream unresponsive
On Wed, 19 Feb 2014, olivier sallou wrote:
after several mails to upstream to clarify some license issue, I think we
will have to put readseq2 in non-free.
I didn't follow the previous discussion. Is it the file that is
available at: http://iubio.bio.indiana.edu/soft/molbio/readseq/java/
This contains two jar files without sources -> non-free
src/flybase/FastVector.java -> non-free
* Permission to use, copy, modify, and distribute this software
* and its documentation for NON-COMMERCIAL purposes and without
rez/readseq.css -> not distributable
* This software is the confidential and proprietary information
* of Sun Microsystems, Inc. ("Confidential Information"). You
* shall not disclose such Confidential Information and shall use
* it only in accordance with the terms of the license agreement
* you entered into with Sun.
... and I didn't look very closely.
There is still however a big issue is they include some code from an other
source, with author indication but no license information about it. So we
do not know under which license is this part of code.
In this case the author could be asked.
This may be a definitive stop from being in Debian (even non-free), right ?
The software must be at least distributable. In case there is no license,
every author has to agree by other means.
Thorsten
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.lnx.4.64.1402201922001.15...@tor.gallien.in-chemnitz.de
Re: Updating fis-gtm package to 6.1
On Mon, 10 Feb 2014, Dominique Belhachemi wrote: There is no big difference to all the other packages in Debian. Transitions happen all the time. Compared to other transitions, a transition from 6.0 to 6.1 to 6.2 within one release cycle sounds really different to me. Besides, the older version shall not be deleted. Just let the latest stable release propagate into testing. Luis is setting up the git packaging infrastructure to make a transition from one release to another release as smooth as possible. We can deal with all the other issues when they arise. As version 6.1 is ready to go, isn't it time to at least discuss these issues now? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1402111016400.5...@tor.gallien.in-chemnitz.de
Re: Updating fis-gtm package to 6.1
On Tue, 11 Feb 2014, Bhaskar, K.S wrote: Dominique's suggestion makes sense. There's no issue changing the latest release and having fis-gtm reflect that, so that someone installing fis-gtm always gets the latest release. My concern is just to make sure that installing the latest release when fis-gtm is updated should not delete prior releases already on the system. So for testing the user needs to install the versionless package fis-gtm and such will get updates and informations about problems with the current versions. With respect to Thorsten's question about security and grave bugs: So far, we have been lucky and to date have never had a grave bug that caused us to withdraw a release. This is good to hear, but now we need to agree on the meaning of grave :-). According to https://www.debian.org/Bugs/Developer#severities a grave bug can cause data loss. So you never had such a bug? Everybody could use the version from oldstable forever and will just miss some new features? Anyways, if this would happen, would you (as upstream) provide patches for older versions? With respect to security issues, we have had two security issues in the last so many years (actually, one issue in 2007, followed by a second because the fix for the first issue was not complete). As the vulnerability was not in the GT.M core, we were able to distribute a fix that wrapped & isolated the vulnerable component and could be retrofitted to existing installations of older releases. Ok, in such a rare case you will provide the needed patches or workarounds for all versions in Debian? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1402111913380.21...@tor.gallien.in-chemnitz.de
Re: Updating fis-gtm package to 6.1
On Tue, 11 Feb 2014, Andreas Tille wrote: As far as I have read Dominique's (and more importantly Thorsten's mail who was perhaps partly wearing his ftpmaster hat, thanks Thorsten - I was hoping for input like this) the question was rather rhetorically. Oh, no, it was not meant to be rhetorically. The (implied) answer is that there is no really good way to support different versions from a security point of view. As Bhaskar wrote, all needed patches will be supplied by upstream and we just have to apply them. Maybe we should document everything on a Wiki page ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1402111958170.21...@tor.gallien.in-chemnitz.de
Re: Updating fis-gtm package to 6.1
Hi everybody, the whole project has the systemd-discussion and we discuss about the packaging of fis-gtm :-). So let me ask some questions and I hope they haven't been asked before ... More precisely we are talking about versions: fis-gtm-6.0 (currently in Debian) fis-gtm-6.1 (recently released upstream) fis-gtm-6.2 (to be released upstream by mid 2014) Assuming that these packages are in unstable and a security or grave bug will be found that affects all versions. As far as I understood only a new version fis-gtm-6.3 will be released. All other version remain unchanged. How are the Debian users informed that there is a new package with an important bugfix available? As the old package won't get an update, nobody will notice. Does the Debian Med team has to create backports of the bugfix? Or do the buggy packages need to disappear from the archive? The latter needs some action from the ftpmaster, who are surely not happy to be involved in maintaining packages. Now lets assume that these three versions are part of stable and versions 7.0, 7.1 and 7.2 are in unstable. How do we handle bugfixes in this case? Normally the packages in stable only get a minimal patch to fix the bug. Does the release team agree to put version 7.3 into stable? In case of a bug affecting all versions since 6.0 we have to deal with six packages now. This would be nine in case 6.0 moves to oldstable. Is this a task the Debian Med team can handle? I think we need to find a solution for all these problems before uploading the new version ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1402101905110.23...@tor.gallien.in-chemnitz.de
Re: MIRA 4.0 released at SourceForge
Hi, On Mon, 3 Feb 2014, Andreas Tille wrote: Thanks to Thorsten mira is no uploaded while I was sleeping my last night in Stonehaven. I was watching Super Bowl and due to the really boring game I had some spare time :-). Any clue how to adapt the watch file to fetch version 4.0? Today everything seems to be fine. After releasing a file at SF it needs to move to a European mirror (I guess in BE). Only then the Debian redirector works properly. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1402041939360.15...@tor.gallien.in-chemnitz.de
Re: [MoM] snp-sites (Was: I would like to submit a package to debian-med)
Hi Jorge, On Wed, 15 Jan 2014, Jorge Sebastião Soares wrote: GPL wise it's all done I think. It's all committed including the new pristine tar 1.3. wow, that was fast. Please let me know if you find any other weirdness. From my point of view everything is fine now. @Andreas: I am waiting for your upload :-). Thorsten
Re: [MoM] snp-sites (Was: I would like to submit a package to debian-med)
On Wed, 15 Jan 2014, Andreas Tille wrote: Uploaded ... waiting for acception by ftpmaster. So this is my moment to ask questions :-) debian/copyright says: Files: * License: GPL-2+ But the accompanying commentary says something about GPLv3+ (as do the headers of the src/* files). On the other side files in tests/* say they are GPLv2+ I am afraid there is room for improvement. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1401151440400.15...@tor.gallien.in-chemnitz.de
Re: Advent calendar
Hi everybody, thanks alot for closing so much bugs. After taking care of 64 bugs in 2011 and 27 bugs in 2012, we reached a new all time high of 73 bugs this year, BRAVO! The oldest bug that could be closed was #541207 [1] which was the RFP of fis-gtm dated from 2009 :-). Season's Greetings Thorsten [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541207 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1312251207140.6...@tor.gallien.in-chemnitz.de
Re: bedtools version 2.18.0
On Sat, 14 Dec 2013, Andreas Tille wrote: Personally, I have no problem with this. I also have the feeling that a couple of years ago, it would not have been a problem. However, I have the impression that now it is important for Debian that images are rebuild from their source. I do not think that this is a real problem for PNGs. At least I had never personally any problem with PNGs. DFSG 2 says that the source must be included. So if the PNG has been created, for example with gimp, there should be an XCF file available and part of the package ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1312141916250.11...@tor.gallien.in-chemnitz.de
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
On Thu, 28 Nov 2013, Yaroslav Halchenko wrote: in case an ftp trainee has checked the -1 version and now sees a new one, he would not be delighted by this, as his previous work would be just a waste of time. is that from personal experience? I just wanted to mention an argument from a different perspective. As with every team, there are different ways of working. So depending on the person really working on a package, uploading version -2 might be good or bad. debdiff between the two would quickly show what was changed/fixed thus possibly addressing already enlisted concerns which trainee would need to deal upon resubmission anyways, thus imho the situation would be a win-win Did you have a look at dak[1]? From my point of view debdiff is not part of the normal workflow. Anyway, you are right that debdiff between two packages of the same version is manageable. But if you also upload a new version, the diff might be too lengthy ... mne is so early in the queue that it is doubtful anyone is looking at it atm anyways According to [2] packages in new are handled bursty, so the queue might be empty soon :-). Thorsten [1]http://ftp-master.debian.org/git/dak.git [2]http://ftp-master.debian.org/stat.html -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1311290855190.7...@tor.gallien.in-chemnitz.de
Re: Bug#728797: ITP: python-mne -- Python modules for MEG and EEG data analysis
Hi Yaroslav, On Thu, 28 Nov 2013, Andreas Tille wrote: H, this information is new to me. If I have understood NEW queue correctly than it is better not to touch packages which are in the queue. Otherwise you might confuse ftpmaster or influence the position of your package to get handled later. Do you have any reference that I#m wrong in assuming this? sorry -- I would not even try to look up the reference atm (need to work on turkey) but just trust me on this one -- IIRC position would not change and ftpmasters will be just fine. in case an ftp trainee has checked the -1 version and now sees a new one, he would not be delighted by this, as his previous work would be just a waste of time. look e.g. at debmake in http://ftp-master.debian.org/new.html ;) This seems to be one of the oldest packages in the queue ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1311282223140.3...@tor.gallien.in-chemnitz.de
Advent calendar
Hi, in order to keep an old tradition, I want to remind everybody of our combined efforts to take care of some poor souls at this time of the year. As the years before we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 190 cases which are relevant to Debian Med[1] (17 being serious[2]). So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Last year we helped about 27 of them, I am sure this year we can do better. Furthermore I would like to mention another page[3] with lots of information about Debian Med packages. Besides the list of RC bugs you can also see packages that can not be built on a Debian architecture, packages that are not allowed to migrate from unstable to testing (and thus won't be included in the next release) and packages with a new upstream version. I think those packages need some care as well. As soon as I get the notice of a closed case I will record that in our Advent calendar[4]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Good hunting, Thorsten PS. The fun starts not until December 1st :-). [1]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&raw=yes&bug-rev=yes&pend-exc=fixed&pend-exc=done [2]http://bugs.debian.org/cgi-bin/pkgreport.cgi?which=maint&data=debian-med-packaging%40lists.alioth.debian.org&archive=no&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious [3]http://udd.debian.org/dmd.cgi?email=debian-med-packag...@lists.alioth.debian.org [4]http://debian-med.alteholz.de/advent -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1311252154450.17...@tor.gallien.in-chemnitz.de
Re: freemedforms & rpath
Hi Eric, On Wed, 10 Jul 2013, Eric Maeker wrote: I've commited the rpath issue correction. Please, if anyone can make a small test. Just compil, install, and run /usr/bin/freemedforms (or by the menu entry). doing a svn-buildpackage results in: cp -a global_resources/package_helpers/freemedforms-wrapper.sh /home/debian/debian-med/qa/packages/freemedforms-project/build-area/freemedforms-project-0.9.0~beta1/debian/tmp/usr/bin/freemedforms cp: cannot stat 'global_resources/package_helpers/freemedforms-wrapper.sh': No such file or directory make[1]: *** [override_dh_auto_install] Error 1 make[1]: Leaving directory `/home/debian/debian-med/qa/packages/freemedforms-project/build-area/freemedforms-project-0.9.0~beta1' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Command 'dpkg-buildpackage' failed in '/home/debian/debian-med/qa/packages/freemedforms-project/build-area/freemedforms-project-0.9.0~beta1', how to continue now? [Qri?]: Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1307102200040.15...@tor.gallien.in-chemnitz.de
Re: FreeMedForms new upstream
On Sun, 7 Jul 2013, Andreas Tille wrote: I have put Thorsten Alteholz explicitly in CC - perhaps he might be able to verify and upload before I can do. it builds here and I uploaded it. But according to lintinan this package still needs a lot of care ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1307082147310.24...@tor.gallien.in-chemnitz.de
Re: Hint for some imaging software from Fedora Medical SIG
Hi everybody, On Thu, 16 May 2013, Andreas Tille wrote: You might like to check this Wiki page for further interesting programs besides Seg3D[2] and msvtk[3]. I might consider creating a packaging skeleton if this helps. Any takers for packaging? shouldn't we begin with an entry in the task list and maybe a RFP-bug? And if someone/Andreas is doing this, aren't the other software packages from SCI (the Seg3D developers) interesting as well? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1305161706190.16...@tor.gallien.in-chemnitz.de
Re: Apache clinical Text Analysis and Knowledge Extraction System (cTAKES)
On Thu, 11 Apr 2013, Mathieu Malaterre wrote: Good luck with maven/java... See 693234#23 Hmm, and the ctakes-resources consist of 1GB of data ... Is there an upper limit of tolerated package size? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1304111933250.20...@tor.gallien.in-chemnitz.de
Re: end of the year
Hi everybody, as Christmas time is over now here are some statistics about this year's bug squashing. We started with about 100 bugs for debian-med and could resolve 15 bugs for debian-med packages. Additionally 12 release critical bugs have been resolved by our members. So we haven't been as successful as last year but did quite good. Happy New Year Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1212271939270.26...@tor.gallien.in-chemnitz.de
Re: end of the year
On Mon, 3 Dec 2012, Eric Maeker wrote: All dependencies are corrected. Ok We just need to patch the control file and add a bug close in the changelog. SVN files are actually for the 0.8.0, so we have to patch tagged 0.7.6 files. Hmm, as 0.8.0 is already in experimental, I don't think that it makes sense to change this old version. Can you manage this ? Or should I do something ?. Yes, I committed everything. As I need some sleep now, I will do the upload tomorrow. Btw. I got some lintian warning about missing hardening flags. W: freemedforms-emr: hardening-no-fortify-functions usr/lib/freemedforms/libCore.so W: freemedforms-emr: hardening-no-fortify-functions usr/lib/freemedforms/libDrugsBase.so W: freemedforms-emr: hardening-no-fortify-functions usr/lib/freemedforms/libPMH.so W: freemedforms-emr: hardening-no-fortify-functions usr/lib/freemedforms/libTemplates.so W: freediams: hardening-no-fortify-functions usr/lib/freediams/libCore.so W: freediams: hardening-no-fortify-functions usr/lib/freediams/libDrugsBase.so W: freediams: hardening-no-fortify-functions usr/lib/freediams/libTemplates.so Are these false positives or do they need to be fixed? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1212032159140.16...@tor.gallien.in-chemnitz.de
Re: end of the year
Hi Eric, On Fri, 30 Nov 2012, Eric Maeker wrote: Thanks for the bug list. I found one for the freemedforms project http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686677 It can be easily corrected, but I don't really know how to send the patch. I just had a short look at the bugreport. There were other bad dependencies mentioned!? Can you fix them too? Can someone help me? Do you want to commit everything (new changelog, control and whatever needs to be changed) to the repository? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1212012345450.3...@tor.gallien.in-chemnitz.de
Re: end of the year
On Fri, 30 Nov 2012, Andreas Tille wrote: If I understood you correctly that you are collecting the bugs manually (and not straight automatically from UDD which would set hard technical criterion) yes, it is still done manually. I would suggest the following extention of the rules: If a Debian Med team member might fix a Wheezy RC bug to help getting the release out more quickly I'd consider this even more brave than fixing some minor bug in our set of packages. Sure, but at least I need to know what bug has been resolved. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1212012336060.3...@tor.gallien.in-chemnitz.de
end of the year
Hi everybody, now it is the time again. The days are closing in, the year is drawing to an end and the Christmas season starts. As last year we should think of all those, that are not around with their own kind. Again, during the last few months, lots of volunteers all around the world tracked down those poor souls and put their cases in the database. We should take care of those needy. This year, there are about 100 cases which are relevant to Debian Med [1]. So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. Last year we helped about 60 of them, maybe this year we can do even better. As soon as I get the notice of a closed case I will record that in our Advent calendar[2]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Good hunting, Thorsten [1]http://tinyurl.com/caqkdsj [2]http://debian-med.alteholz.de/advent -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1211301934200.8...@tor.gallien.in-chemnitz.de
Re: Any progress with FIS GT.M?
On Sun, 1 Jul 2012, Luis Ibanez wrote: It turned out to be easier to remove the COPYING file as a final step in the installation: override_dh_auto_install: @echo "I: Fixing up permissions for setuid rights -- we aren't done yet!" chmod u+s $(CURDIR)/debian/$(BINPKG)/usr/$(GTM_INSTALL_DIR)/gtmsecshr seems to be wrong. You can a least set the bit for the buildd user, which makes no sense. I think this should be done in postinst. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1207012132330.25...@tor.gallien.in-chemnitz.de
meme
Hi, could somebody with more perl experience please have a look whether perl-include.patch of meme really is as desired? Or is there another way how things should be done in such a case? Further the meme documentation (to be exact: overview.html) talks about lots of small tools (-> $(MODULES) in debian/rules). Does anybody know whether all of them are really needed? Some of them have rather generic names ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1206272225340.13...@tor.gallien.in-chemnitz.de
Re: Please upload NEW r-cran-deal
On Wed, 4 Apr 2012, Charles Plessy wrote: this is a typical symptom of mergeWithUpstream not being set. *blush* you are right. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1204042202100.6...@tor.gallien.in-chemnitz.de
Re: Please upload NEW r-cran-deal
On Tue, 3 Apr 2012, Ivo Maintz wrote: I use sbuild. I tested it just in an absolutely fresh setup; it works. yes, sorry, my mistake :-(. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1204042203340.6...@tor.gallien.in-chemnitz.de
Re: libsbml5
On Tue, 3 Apr 2012, Ivo Maintz wrote: I fixed this. strip is now only called for this libs, if libsbml5 is build with matlab. Hmm, there seems to be a problem with dependencies (no swig found if swig2.0 is installed). The logs are at: https://buildd.debian.org/status/package.php?p=libsbml Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1204042206300.6...@tor.gallien.in-chemnitz.de
Re: Please upload NEW r-cran-deal
On Mon, 2 Apr 2012, Ivo Maintz wrote: r-cran-deal should be ready for upload... Hmm, got fresh version from svn, only installed packages from Depends: and got an error while building. Did you use pbuilder or something like that? Thorsten mkdir -p "." fakeroot debian/rules binary awk: cannot open DESCRIPTION (No such file or directory) awk: cannot open DESCRIPTION (No such file or directory) test -x debian/rules dh_testroot dh_prep dh_installdirs -A mkdir -p "." dh_installdirs usr/lib/R/site-library echo "R:Depends=r-base-core (>= 2.15.0-1)" >> debian/r-cran-.substvars if test -f /usr/bin/xvfb-run; then \ xvfb-run -a\ R CMD INSTALL -l /home/debian/debian-med/develop/trunk/packages/R/r-cran-deal/build-area/r-cran-deal-1.2.34/debian/r-cran-/usr/lib/R/site-library --clean \ . ;\ else\ R CMD INSTALL -l /home/debian/debian-med/develop/trunk/packages/R/r-cran-deal/build-area/r-cran-deal-1.2.34/debian/r-cran-/usr/lib/R/site-library \ --clean . ;\ fi Warning: invalid package '.' Error: ERROR: no packages specified make: *** [R_any_arch] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1204022001210.26...@tor.gallien.in-chemnitz.de
Re: libsbml5
On Mon, 2 Apr 2012, Ivo Maintz wrote: I think, it's ready... Hmm, without matlab on my computer: dh_strip --dbg-package=libsbml5-dbg strip --remove-section=.comment debian/libsbml5-matlab/usr/lib/*.mexa64 strip: 'debian/libsbml5-matlab/usr/lib/*.mexa64': No such file make: *** [binary-arch] Error 1 Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1204021942180.26...@tor.gallien.in-chemnitz.de
Re: libsbml5
Hi Ivo, On Thu, 29 Mar 2012, Ivo Maintz wrote: I: libsbml5-octave: binary-has-unneeded-section usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/OutputSBML.mex .comment I: libsbml5-octave: binary-has-unneeded-section usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/TranslateSBML.mex .comment I have no idea, how to fix this. But it's not critical, right? it is not critical, but somebody had so much concerns with it, that some output from lintian was born. So maybe it is worth an override stating that mex files do have such a section that contains the version of the used compiler ... I see, there is some more work to do. Up to now, also on amd64 the octave site packages were situated directly under /usr/lib; now it's usr/lib/x86-64-linux-gnu. I can only build for amd64 and i386; how to get infos about the right path for the octave site packages on other architectures? I have to admit that I am not really familiar with this multiarch stuff. The file in /usr/share/dpkg (<- used by dpkg-architecture) should give you some hints. So maybe you can use something like libsbml5-octave.install.in to create the real libsbml5-octave.install Yes. And no. dh_shlibdeps does not examine the *.mex and *.mexa64 files (octave and matlab bindings), but lintian gave an error: "missing-dependency-on-libc" So I hardcoded it, but now I added two lines in debian/rules: dpkg-shlibdeps \ debian/libsbml5-octave/usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/* -Tdebian/libsbml5-octave.substvars dpkg-shlibdeps debian/libsbml5-matlab/usr/lib/* -Tdebian/libsbml5-matlab.substvars Is this still the right way? Oh, I really don't know. But if lintian is calm and everything works as before, it might be correct. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1203291928380.3...@tor.gallien.in-chemnitz.de
Re: libsbml5
Hi Ivo, On Wed, 28 Mar 2012, Ivo Maintz wrote: But now it should be ready for upload (also to close bug #665837). after building the package, I got some I:-lines from lintian: I: libsbml5-dev: package-contains-empty-directory usr/lib/jni/ I: libsbml5-dev: package-contains-empty-directory usr/share/java/ I: libsbml5-dev: package-contains-empty-directory usr/share/man/ Did something strange happen during my build or are these empty dirs intentional? I: libsbml5-octave: binary-has-unneeded-section usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/OutputSBML.mex .comment I: libsbml5-octave: binary-has-unneeded-section usr/lib/x86_64-linux-gnu/octave/site/oct/x86_64-pc-linux-gnu/TranslateSBML.mex .comment In libsbml5-octave.install you added x86_64-linux-gnu to the path. Is this correct in case the package is built on some other architecture? Also there are some W:-lines: W: libsbml source: package-depends-on-hardcoded-libc libsbml5-matlab depends W: libsbml source: package-depends-on-hardcoded-libc libsbml5-octave depends Is there really any reason to depend on libc6? Thorsten PS. There are also lots of P:-lines :-). -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1203281941410.30...@tor.gallien.in-chemnitz.de
Re: Please review "Bits from Debian Med" proposal
On Tue, 13 Mar 2012, Andreas Tille wrote: Thanks in advance for any commitment I am mentioned at the beginning, so everything is perfect :-). Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1203131929060.9...@tor.gallien.in-chemnitz.de
package bagphenotype
Hi everybody, according to http://valdarlab.unc.edu/software.html bagphenotype is no longer maintained and shall be replaced by bagpipe. What shall we do? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1203131936300.9...@tor.gallien.in-chemnitz.de
Re: Build logs
Hi Eric, On Fri, 9 Mar 2012, Eric MAEKER wrote: May I suggest to add a startup date in the build logs available from sure, would it be sufficient to add a line at the beginning of the logfile? Just out of curiosity, at the end of the top page most of the time there is a line telling when the build starts and ends. Is there a special reason to know the exact time of one package build? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1203101626580.22...@tor.gallien.in-chemnitz.de
Re: [MoM] Packaging fis-get
On Sun, 29 Jan 2012, Andreas Tille wrote: I admit I also stumbled about this $HOME/.fis-gtm issue but was to tired yesterday and forgot to bring this up in my response. (...) The alternatives system has the purpose to handle different alternative packages. However, in the GT.M case there are no such alternatives currently available in Debian and I do not see a real "danger" that this wil come soonish. So for the moment I do not see any need for making things more complex for no current use. Wow, what a strange decision. I got a deja vu. Obviously we have a new expert here and my help is not needed anymore. Sorry Bhaskar, that your previous explanations will be simply ignored ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201291549200.1...@tor.gallien.in-chemnitz.de
Re: [MoM] Packaging fis-get
On Wed, 25 Jan 2012, Andreas Tille wrote: This is because Thorsten decided to move the complete tarball straight into the *.deb package which is a very untypical decision and I was reasoning about this several times in this thread. I hope I answered everything satisfactorily (I have to catch up some more emails). Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201272000470.18...@tor.gallien.in-chemnitz.de
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Wed, 25 Jan 2012, Bhaskar, K.S wrote: [KSB] Are there packages that are (for example) pure shell scripts so that there is no difference between a source package and a binary package? A VistA Debian package would be like that. No, the source package always contains information on how to build the binary package. These information are obviously not part of the binary package (so source and binary are not the same) and are also needed for packages containing only shell scripts. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201272008060.18...@tor.gallien.in-chemnitz.de
Re: [MoM] Packaging fis-get
On Tue, 24 Jan 2012, Luis Ibanez wrote: Then went into the directory: cd debian-med/trunk/packages/fis-gtm/ cd fis-gtm-initial/trunk and got the source code with the command: make -f debian/rules get-orig-source Ok, let me introduce my workflow here: After doing get-orig-source I just type 'svn-buildpackage' and everything is done automatically. The results are in ../build-area After I change something in debian/, I need to do 'svn-buildpackage --svn-ignore-new' until I commit my stuff. I don't need to take care about .svn and there is no need to copy files back and forth. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201271952170.18...@tor.gallien.in-chemnitz.de
Re: How Debian Packaging practices could apply to VistA maintenance and distribution
On Wed, 25 Jan 2012, Bhaskar, K.S wrote: A VistA Debian package is like a Linux installer ISO image. It's a tool that will let you create new VistA environments on your computer, So we only need one VistA Debian package, that contains just this 'installer' and everything else is done by KIDS. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201272005550.18...@tor.gallien.in-chemnitz.de
Re: [med-svn] r9384 - trunk/packages/fis-gtm/fis-gtm-initial/trunk/debian
On Mon, 23 Jan 2012, Andreas Tille wrote: Just explaining my motivation - not insisting that this was correct: We are currently talking about / working on the initial package to bootstrap a real fid-gtm package. Yes, but I assumed that we only wanted to have one -initial package. So it should contain both bootstrap tar files for amd64 and i386. Depending on the architecture of the buildd only one is really used. As the configure-script from fis-gtm needs to be run as root (this was explained by Bhaskar some time ago), this package can not be build like any "normal" source package. So everything has to be done in postinst. Up to now, this has nothing to do with multiarch but just has to be done due to the requirements of fis-gtm. The debconf stuff with user and group in postinst is a another nice feature of fis-gtm. You can restrict the usage of fis-gtm to a certain gid. This might be useful in an hospital where more strict security requirements needs to be fullfilled. Although Bhaskar told me that this feature is not used often, I left it in. It is defined with low priority, so everybody who wants to use it might use it and the majority will not be bothered by it. Anyway, most of the questions that come up now have been discussed some time ago when I started to work on the package. So it might be really helpful to browse the archive. IMHO there are no user decisions needed in this phase. Once we are talking about some kind like multiarch installations things will be different. See above, this is not multiarch as you might know from libs. However, I'd like to keep things as simple as possible in the beginning. So I also would recommend getting rid of the debconf stuff you injected into the initial package (again not questioning that it might be needed later). This package is already beyond the beginning. The debconf stuff is in, it is kind of useful, so why shall it be removed again? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201271931120.18...@tor.gallien.in-chemnitz.de
Re: [MoM] Regarding status of fis-gtm-initial package
On Sun, 22 Jan 2012, Andreas Tille wrote: IMHO that's pretty useless and thus I changed debian/rules to only install the tar which matches the architecture that matches the build system. There has been a discussion about this some time ago ... (in my case the amd64 binary) and a postinst file created by Thorsten that seems to implement some installation magic. I did not dived into this but it fails for me: Hmm, once upon a time it worked ... The -initial-package does contain some binary stuff. This is only used to compile the real sources from the -server-packages. So it is needed on the buildd in some kind of package. But as one of my goals for the future is to replace the -initial-package by some "real" mumps compiler, I created two packages and hope to let one disappear in the future (this would enable us to build fis-gtm on any architecture). Unfortunately I found no mumps compiler yet that was currently able to do the job. Further those packages are quite huge and if somebody just wants to have a look at the sources, he does not need to download all that binary stuff. As far as I understood the A-version of the initial package could also be used to build the B and any other following version. So there is no update needed for that package. Did I remember this right Bhaskar? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201231618050.27...@tor.gallien.in-chemnitz.de
Re: Looking for a Debian packager for FIS-GT.M : Change the History of Healthcare !!
Hi Luis, On Thu, 19 Jan 2012, Luis Ibanez wrote: I guess at some point we need to touch base with the Debian packagers who has been working in fis-gtm, to make sure that I'm not stepping in their toes..., no, just go on. Any help from somebody who knows better what to do is appreciated. I am happy that this package gains new momentum again. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201231553390.27...@tor.gallien.in-chemnitz.de
Re: [med-svn] r9384 - trunk/packages/fis-gtm/fis-gtm-initial/trunk/debian
On Sun, 22 Jan 2012, Andreas Tille wrote: +# obtain build architecture to detect the right binary for installation I guess that is not correct. Some times ago Bhaskar explained to me that there are reasons to let the user decide whether the 32bit or 64bit version shall be installed on amd64 ... + # Considering that there are two distinct tarballs in the original tarball copying both into the + # target binary deb is just wrong - wee need to grep for the right architecture as well + cp -a `ls -1 | grep -v debian | grep $(BUILDARCH)` debian/$(pkg)/$(FISGTM_ROOT)/distribution ... so I guess both tarballs are still needed on amd64. Of course on i386 only one should be available. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201231611070.27...@tor.gallien.in-chemnitz.de
Re: Debian Native Packages and README.Status
Hi Steve, On Sat, 14 Jan 2012, Steve M. Robbins wrote: The trouble with this is that "Source: unavailable" does not describe the situation. The source *is*, indeed, available. The distinction, rather, is that there is no upstream tarball. oops, I wasn't aware that the cmake file is all that is needed. So a line like "Source: debmedrepo" would be more appropriate, right? IMHO, the process would be more robust if, instead, the script uses the standard Debian method to describe whether the source package has an upstream tarball + patch, or not. Specifically, the absense of a "debian revision" in the Version string [2]. Ok, but can you really say that any native package has no tarball to download? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201231522001.27...@tor.gallien.in-chemnitz.de
Re: Droping med-doc?
On Sun, 8 Jan 2012, Andreas Tille wrote: I finally came to the conclusion that it makes no sense to pretend having a documentation package if it is not maintained at all. I guess the contentes should better go to some kind of Wiki. So up, up and away ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1201091947470.1...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
Hi Andreas, On Wed, 28 Dec 2011, Andreas Tille wrote: Seems we could do with only "one bug of the week" in 2012 to bring it down to zero. :-) ok, so let's go :-) BTW, the calendar does not seem to work any more. Ooops, sorry, fat finger alert. Now it should work again. I hope it even survives New Year now. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112281654010.15...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
Hi everybody, I am really impressed. As I started the Advent Calendar, I expected only one closed bug every day. But after 24 days of hard work 63 bugs are able to pass to the retirement community in the Archive. Unfortunately some new bugs have been detected but still the number of bugs assigned to Debian Med could be reduced from 70 to 35! Although he might not like to read this, but this considerable success could be only accomplished by the constant work of Andreas who cared about the major part of all bugs. So let's hear it for him! Of course as well thanks to everybody else who attended this fun. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112271253390.3...@tor.gallien.in-chemnitz.de
Re: MglTools packaging (Was: r8804 - trunk/packages/mgltools/pmv/trunk/debian)
On Mon, 19 Dec 2011, Andreas Tille wrote: I disagree. The build process is mostly automated and works. There are more important things to work on. Promised. My personal experience does not fit this statement. 1. Google: "site:bugs.debian.org mgltools 'depends on python (<< 2.6)'" 2. Google: "site:bugs.debian.org mgltools 'deprecation of dh_pycentral, please use dh_python2'" 3. Google: "site:bugs.debian.org mgltools 'python2.5-dev used as build-dependency, not python-dev or python2.6-dev'" 4. Google: "site:bugs.debian.org mgltools 'Please update depends/build-depends from glut3 to freeglut3'" Ok, but after a first glimpse these problems are not related to the build process. 5. Google: "site:bugs.debian.org mgltools 'Python string exceptions no more allowed in Python 2.6'" Another (short) series of still open bugs which are forcing us to fix one problem with several uploads. On one hand you have the build time of a huge package (which at least on my hardware is not neglectable). On the other hand you need some time to handle the debian/-stuff in several packages. In my oppinion it is easier to handle lots of small tasks. 6. In bug #651855 we failed to realise that the scenario tool was just replaced. Hmm, I seem to have missed something here. Was there any problem with the old scenario package? As far as I remember the package didn't have any bug!? 7. In bug #605315 somebody even asked for removal of one of the packages because it seemed unmaintained which was solved in NMU by aplying a long standing patch. So why did I spent time in assembling this history of bugs in mgltools? I wanted to prove that the current way to maintain this tool by not relying on the released upstream tarball creates a lot of work which is not only on the back of our shoulders but a lot of other DDs. Steffen already wrote some words about the python dependency. After releasing the first tarball and before doing the actual upload of all mgltools packages, lots of things have been committed to the upstream repository. In the worst case any commit might have resulted in a bug-report (okok, I exaggerate). I'm personally bored by working on one and the same problem several times and it is simply error prone to do so. Yeah, I agree, it is boring. Items 1.-5. above are showing that the mostly automated process you are claiming above does not work as expected. I am sorry, but I am not sure whether I understand the relation between those items and the build process itself. As you wrote in another mail Debian moves on. But this is as well true for Debian Med. If you look at the weekly build, nowadays almost all packages simply build with 'get-orig-source' and 'svn-buildpackage'. Two fail with a missing numpy dep (?) and two seem two fail due to an error in the build script itself (ok, I got something to fix until friday ...). I would say that 20 building packages are not an argument against the build process. Item 6. shows that it does not help in detecting outdated packages which should be removed. At least I became aware of that old package but did not realize that there is a problem keeping it in the archive. Finally item 7. shows that people become bored about our work which is simply bad. Yes, we definitely should care about bugs faster. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112201553130.13...@tor.gallien.in-chemnitz.de
Re: [med-svn] r8804 - trunk/packages/mgltools/pmv/trunk/debian
On Sun, 18 Dec 2011, Andreas Tille wrote: I actually very much in favour of building mgltools from plain upstream source as it is provided upstream in one source package and create different source packages. When doing this refactoring a package -common could be created which is needed by more than one binary package. Yes, but how do you know what files need to be part of such a package? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112201936520.19...@tor.gallien.in-chemnitz.de
Re: Some packages have no upstream tarball (attn: alteholz-guest)
Hi Steve, sorry for any inconvenience. On Sat, 10 Dec 2011, Steve M. Robbins wrote: I'd like to point out that some packages on debian-med have NO upstream tarball, and thus the "mergeWithUpstream" property is not needed. In fact, that's too mild. The property is *forbidden*, because setting it breaks "svn-buildpackage". for these cases we have the README.status (-> the schema file is available at: http://debian-med.alteholz.de/support/README.status.schema.yaml) If it contains a Source: line like "Source: unavailable" (or with any other yet to be defined value) the property will not be set automatically. You can find examples in .../trunk/packages/biomode/trunk/README.status or .../trunk/packages/fastdnaml/trunk/README.status If you like, I can create a README.status for wrapitk. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112121618570.17...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
Hi Andreas, On Mon, 12 Dec 2011, Andreas Tille wrote: and after there should be half the doors open I wonder if the open doors could not show at least the number of bugs closed on this day. A usual advent calendar changes its look evry day and the doors remain somehow opened. hmm, if you look at http://www.tu-chemnitz.de/advent/2011/ the doors are always closed as well. On your tree you need to click the doors over and over without any sign that they are opened before. Now you will see the resolved bugs if you move the mouse over the number. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112161508550@tor.gallien.in-chemnitz.de
Re: [med-svn] r8804 - trunk/packages/mgltools/pmv/trunk/debian
Hi Andreas, On Wed, 7 Dec 2011, Andreas Tille wrote: Resolved circular dependency by recommending autodocktools instead from depending from it. In case there *really* should be a strong dependency this is not the correct fix and we need further work to split up autodocktools in reasonable pieces to make sure we will reach the release goal. I just tried to install mgltools-pmv in sid and autodocktools was installed as well. So there should be no problem for the user but the cycle still seems to be present!? Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112121528520.17...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
On Sun, 27 Nov 2011, Thorsten Alteholz wrote: Maybe we can hide at least one number of a closed case behind every door. Wow, I am really impressed. After 8 days of hard work, 19 bugs could be closed :-). Keep it up! Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112082208470.15...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
On Thu, 1 Dec 2011, Andreas Tille wrote: As the star is part of the image, here is the link to the source: http://debian-med.alteholz.de/advent-2011-original.tar.gz which also contains the original original. 403: Forbidden ---> something is wrong with your server. Urgs, that was a faulty hdd and a non working RAID. Fortunately there were some good folks who could repair everything from the backup. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112022003280.17...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
On Thu, 1 Dec 2011, Andreas Tille wrote: Ahhh, OK. So I will see whether the upload to fix #648705 which I wanted to claim for 3.12. will count in here because it was a bit delayed when passing NEW (the package names have changed with this upload). The "marked as done"-email already arrived on the 1st .. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112022009281.17...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar (Was: Processed (with 1 errors): tagging as pending bugs that are closed by packages in NEW)
On Thu, 1 Dec 2011, Andreas Tille wrote: Sure. While I do not like to turn this into a competition I would love to loose it in case it would come to such a situation!!! oh, no, I didn't want to start a competition. I just wanted to encourage the others to follow your example! Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1112022003050.17...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar (Was: Processed (with 1 errors): tagging as pending bugs that are closed by packages in NEW)
On Tue, 29 Nov 2011, Andreas Tille wrote: while it is not yet clear to me how the Advent calendar might be filled by I would like to claim the next door (2.12.) for bug #639389. Ok, but it should be the Debian Med Advent calendar and not the Andreas Advent Calendar :-) Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.302217220.10...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
On Mon, 28 Nov 2011, Andreas Tille wrote: Even if I do not fully understand the calendar procedure If a bug is closed in december, this is noted behind the door of the calendar. So instead of getting something out, this calendar is filled with stuff. At Christmas I hope we have a well filled calendar :-). I would like to claim the 1.12.2011 for closing the bug #642697 which I realised because of this mail. Ok, sounds reasonable. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.302214120.10...@tor.gallien.in-chemnitz.de
Re: Debian Med Advent Calendar
Hi Charles, On Mon, 28 Nov 2011, Charles Plessy wrote: I like to start mornings reading emails like this ! ok, I try my best to repeat that at other times :-). I do not remember seing such and advent calendar before; I am sure it can inspire other teams as well. Out of curiosity, I tried to click on the first of December to see what happens. But December has not started yet ;) Nevertheless, even if it would allow cheaters to inspect the chocolates in advance, I would advocate putting a link to the source somewhere (on the star ?). That would be the cherry on the cake. Hmm, I like Black Forest cake :-). As the star is part of the image, here is the link to the source: http://debian-med.alteholz.de/advent-2011-original.tar.gz which also contains the original original. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.291559170.32...@tor.gallien.in-chemnitz.de
Debian Med Advent Calendar
Hi everybody, days are closing in, the year is drawing to an end and the Christmas season starts. Most of us will spend this time within the family circle. But we should also think of all those, that are not in such a fine situation. All around the world volunteers track down those poor souls and put their cases in a huge database. Some of them are merged together in a group, but most of them have a drab existence all alone. Although just some of us made the Hippocratic oath, we all should try to make the world better and take care of the needy. According to that database, there are about 70 cases which are relevant to Debian Med [1]. So please feel pity for them and allow the transition of as many as possible poor souls to their final destination, the retirement community in the Archive. As soon as I get the notice of a closed case I will record that in our Advent calendar[2]. In contrast to normal calendars, let us fill this special one with lots of good deeds. Maybe we can hide at least one number of a closed case behind every door. Good hunting, Thorsten [1]http://tinyurl.com/caqkdsj [2]http://debian-med.alteholz.de/advent -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.271856270.27...@tor.gallien.in-chemnitz.de
workflow for Debian Med packages
Hi, can everybody please have a look at: http://wiki.debian.org/DebianMedQA http://wiki.debian.org/DebianMedQAWorkflow and tell me your opinions. During my work on Debian Med packages I stumbled over one or another problem. With these documents I want to make things easier for everybody and introduce a consistent method for working on packages. Of course nobody shall be forced for example to use svn-buildpackage. But as its usage is even suggested in the Debian Med policy, some standardization might be helpful. Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1110311920580.4...@tor.gallien.in-chemnitz.de
Re: debian-med_1.9_amd64.changes is NEW
On Thu, 27 Oct 2011, Andreas Tille wrote: I wished we could make some progres in med-his (regarding fis-gtm Yes, next month I will continue with that project. Hopefully I will be able to upload the new package by myself by then ... Thorsten -- To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pine.lnx.4.64.1110271906520.14...@tor.gallien.in-chemnitz.de
