Re: RFS: PeptideBuilder
Hi On Sun, 29 Nov, 2020, 5:23 am Steffen Möller, wrote: > https://salsa.debian.org/med-team/peptidebuilder > > lintian-clean, builds in chroot - I guess you may have ideas how to > improve the testing. > Done. $git pull :-) Nilesh >
RFS: PeptideBuilder
https://salsa.debian.org/med-team/peptidebuilder lintian-clean, builds in chroot - I guess you may have ideas how to improve the testing. Many thanks! Steffen
Re: [RFS] quorum 1.1.1-4
Hi Étienne, On Sat, Nov 28, 2020 at 10:43:59PM +0100, Étienne Mollier wrote: > I brought a small update to quorum to address FTBFS (#975740). Cool. > Changes are available on Salsa for review: > > https://salsa.debian.org/med-team/quorum > > CI fails to build on i386, but that is merely due to missing > build dependency. I don't see and debian/tests dir. Are you sure you pushed? In cases where dependencies are missing I added something like Architecture: amd64 arm64 mips64el ppc64el riscv64 sh4 or something like this to debian/tests/control (this is from srst2). > Please consider upload or granting upload > permissions. Granted. Feel free to upload since I think I somehow misunderstood your statement. Kind regards Andreas. -- http://fam-tille.de
Re: New Jalview release -- hesitating on license
On 28.11.20 19:30, Pierre Gruet wrote: > Hi Andreas and Steffen, > > Le 28/11/2020 à 00:38, Steffen Möller a écrit : >> Hi Pierre, >> >> On 27.11.20 23:10, Andreas Tille wrote: >>> Hi Pierre, >>> >>> On Fri, Nov 27, 2020 at 10:48:13PM +0100, Pierre Gruet wrote: I'm stumbling upon the license terms of a part of the code (which is important enough so that the whole program really needs it) of the new release of Jalview I am packaging: that part has a license identical to BSD-3-clause except that clause 3 bas been changed to: 3. Redistributions must acknowledge that this software was originally developed by the UCSF Computer Graphics Laboratory under support by the NIH National Center for Research Resources, grant P41-RR01081. I'm really doubting this can be seen as DFSG-free: - "acknowledge" seems vague to me; - it looks like someone could be sued if he made a derived work without a sentence about the original developer and the grant number. >>> I agree it is vague but I personally assume that its just that you >>> mention the authors in your scientific results. >> I also think it is fine. Just paste it as such in d/copyright for the >> files this appears in. Maybe you have a definitive answer? Else should I write to debian-le...@lists.debian.org or to FTPmasters ? >>> Keeping upstream as well as debian-legal in CC makes sense. >> >> I do not see anything of concern here. A note that the creator of a file >> shall not be forgotten over time you find almost everywhere. And here >> they also ask to mention the grant number. Fine with me. Actually, as a >> tax payer I even somewhat appreciate this and it may be of historic >> interest to chase up how different folks came together in various grants >> over time or how different grants from different decades interact in >> larger workflows or how long it takes until a new development finds it >> ways into desktop machines. >> >> We should probably also find a way to model that in d/u/metadata I just checked https://wiki.debian.org/UpstreamMetadata . It is "Funding". But mentioning this there seems like stressing the NIH too much for what is developed in Glasgow, UK. The home page lists BBSRC and Wellcome Trust as its supporters. >> ... but >> days only have 24 hours ... maybe not. >> > > Thanks a lot for sharing your thoughts on this. After thinking again, > I agree with you and will go on packaging with this. Of course I will > put this in d/copyright :) :) Steffen
[RFS] quorum 1.1.1-4
Greetings, I brought a small update to quorum to address FTBFS (#975740). Changes are available on Salsa for review: https://salsa.debian.org/med-team/quorum CI fails to build on i386, but that is merely due to missing build dependency. Please consider upload or granting upload permissions. Kind Regards, -- Étienne Mollier Fingerprint: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da Sent from /dev/pts/0, please excuse my verbosity. signature.asc Description: PGP signature
Re: New Jalview release -- hesitating on license
Hi Andreas and Steffen, Le 28/11/2020 à 00:38, Steffen Möller a écrit : Hi Pierre, On 27.11.20 23:10, Andreas Tille wrote: Hi Pierre, On Fri, Nov 27, 2020 at 10:48:13PM +0100, Pierre Gruet wrote: I'm stumbling upon the license terms of a part of the code (which is important enough so that the whole program really needs it) of the new release of Jalview I am packaging: that part has a license identical to BSD-3-clause except that clause 3 bas been changed to: 3. Redistributions must acknowledge that this software was originally developed by the UCSF Computer Graphics Laboratory under support by the NIH National Center for Research Resources, grant P41-RR01081. I'm really doubting this can be seen as DFSG-free: - "acknowledge" seems vague to me; - it looks like someone could be sued if he made a derived work without a sentence about the original developer and the grant number. I agree it is vague but I personally assume that its just that you mention the authors in your scientific results. I also think it is fine. Just paste it as such in d/copyright for the files this appears in. Maybe you have a definitive answer? Else should I write to debian-le...@lists.debian.org or to FTPmasters ? Keeping upstream as well as debian-legal in CC makes sense. I do not see anything of concern here. A note that the creator of a file shall not be forgotten over time you find almost everywhere. And here they also ask to mention the grant number. Fine with me. Actually, as a tax payer I even somewhat appreciate this and it may be of historic interest to chase up how different folks came together in various grants over time or how different grants from different decades interact in larger workflows or how long it takes until a new development finds it ways into desktop machines. We should probably also find a way to model that in d/u/metadata ... but days only have 24 hours ... maybe not. Thanks a lot for sharing your thoughts on this. After thinking again, I agree with you and will go on packaging with this. Of course I will put this in d/copyright :) Best regards, Pierre
maude does not build on 32-bit architectures
Hi,
Maude(3.1) package in Debian fails to build on 32-bit arches with a common
error: "fileOutcomes.cc:87:37: error: conversion from ‘Int64’ {aka ‘long
long int’} to ‘const mpz_class’ is ambiguous"
The full logs can be found here for i386[1], armel[2], armhf[3] and mipsel[4]
[1]:
https://buildd.debian.org/status/fetch.php?pkg=maude=i386=3.1-1=1604156507=0
[2]:
https://buildd.debian.org/status/fetch.php?pkg=maude=armel=3.1-1=1604157359=0
[3]:
https://buildd.debian.org/status/fetch.php?pkg=maude=armhf=3.1-1=1604157360=0
[4]:
https://buildd.debian.org/status/fetch.php?pkg=maude=mipsel=3.1-1=1604161469=0
Please consider fixing this, or let us know if it is no longer
compatible to build on 32-bit arches.
Kind regards
Nilesh
