Re: python-pysam version lagging

2015-06-09 Thread Charles Plessy
Le Tue, Jun 09, 2015 at 12:38:31AM -0700, Afif Elghraoui a écrit :
 
 I was able to build it and clean it up a little more, but the package still
 has some lint:

Hi Afif, thanks a lot for all this work.

 W: python-pysam source: dep5-copyright-license-name-not-unique (paragraph at
 line 40)
 
 I'm actually not sure what to do about this one.

Try public-domain instead of PublicDomain.  public-domain is a special case
in the machine-readable specification, so if the Lintian warning stays, I would
consider it a false positive.

https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

 I: ...hardening-no-fortify-functions...
 
 I think these are false positives since the CPPFLAGS for fortification look
 like they're correctly set as I watch the package build.

I have seen such apparent false positives in other packages.  If you have time,
maybe it is worth asking for comments on the debian-mentors mailing list ?

 I: ...spelling-error-in-binary...
 
 This is maybe not worth fixing.

Maybe the easiest way to get rid of it is a pull request to upstream on GitHub ?

 I: python-pysam-tests: package-contains-timestamped-gzip
 usr/share/doc/python-pysam/tests/pysam_data/ex1.sam.gz
 
 I'm not sure what to do about this, either. Does it really affect
 ReproducibleBuilds if it's an upstream-provided compressed file?

This is a false positive: there is a timestamp, but it will not change
unless Upstream updates the file, hence the build of a given Debian package
for Pysam is reproductible for that file.

Please let us know when you need an upload.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20150609081450.gc16...@falafel.plessy.net



Re: [fis-gtm] FW: GT.M V6.2-002 available

2015-06-09 Thread Andreas Tille
Hi Amul,

On Tue, Jun 09, 2015 at 01:19:46PM +, Shah, Amul wrote:
 I uploaded the latest version of GT.M that we released yesterday.

Thanks for your work on this.

 I tagged the version as unstable. Let me know if that was the correct thing 
 to do.

Perfect.  Unfortunately I'm on vacation behind a quite slow connection
and thus can not upload any larger package.  If somebody else might take
this one it would be nice - otherwise please wait until end of June.

Thanks for your work on this

 Andreas.

-- 
http://fam-tille.de


-- 
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/20150609143610.gp27...@an3as.eu



Bug#788224: ITP: python-cobra -- constraint-based modeling of biological networks

2015-06-09 Thread Afif Elghraoui

Package: wnpp
Severity: wishlist
Owner: Debian Med Packaging Team debian-med@lists.debian.org
X-Debbugs-Cc: debian-de...@lists.debian.org, aebra...@ucsd.edu

* Package name: python-cobra
  Version : 0.3.2
  Upstream Author : Ali Ebrahim aebra...@ucsd.edu
* URL : http://opencobra.github.io/cobrapy/
* License : GPL3+
  Programming Lang: Python
  Description : constraint-based modeling of biological networks

COnstraint-Based Reconstruction and Analysis (COBRA) methods are widely
used for genome-scale modeling of metabolic networks in both prokaryotes
and eukaryotes. COBRApy is a constraint-based modeling package that is
designed to accommodate the biological complexity of the next generation
of COBRA models and provides access to commonly used COBRA methods, such
as flux balance analysis, flux variability analysis, and gene deletion
analyses.

This packaging will be maintained by the Debian Med team at
Vcs-Git: git://anonscm.debian.org/debian-med/python-cobra.git
Vcs-Browser: http://anonscm.debian.org/cgit/debian-med/python-cobra.git


--
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name


--
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/5576fc25.4090...@ghraoui.name



Re: [fis-gtm] FW: GT.M V6.2-002 available

2015-06-09 Thread Amul Shah

Hi Andreas,

On 06/09/15 10:36, Andreas Tille wrote:

Hi Amul,

On Tue, Jun 09, 2015 at 01:19:46PM +, Shah, Amul wrote:

I uploaded the latest version of GT.M that we released yesterday.

Thanks for your work on this.


I tagged the version as unstable. Let me know if that was the correct thing to 
do.

Perfect.  Unfortunately I'm on vacation behind a quite slow connection
and thus can not upload any larger package.  If somebody else might take
this one it would be nice - otherwise please wait until end of June.

Thanks for your work on this

[amul:2] Thank you for responding while on vacation! I'm fine with waiting if 
no one can do the upload.

Amul

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


--
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/55772fa1.3030...@fisglobal.com



Bug#788283: jessie-pu: package r-cran-rcurl/1.95-4.3-1+deb8u1

2015-06-09 Thread Charles Plessy
Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Dear Stable release team,

the r-cran-rcurl package provides curl functionalities for the R statistical
environment.  In Jessie (version 1.95-4.3-1), we built it against
libcurl4-nss-dev, but this creates errors that prevent R users to download and
install other R packages from GitHub (https://bugs.debian.org/786473).  I
wouldn't be surprised if there would be other problems not yet reported.  In
Unstable and Testing, we solved this in version 1.95-4.3-2 by building the
package against libcurl4-openssl-dev.  In the following proposed update
(1.95-4.3-1+deb8u1), we do the same, but the package was built against Jessie.

diff -Nru r-cran-rcurl-1.95-4.3/debian/changelog 
r-cran-rcurl-1.95-4.3/debian/changelog
--- r-cran-rcurl-1.95-4.3/debian/changelog  2014-09-17 20:10:59.0 
+0900
+++ r-cran-rcurl-1.95-4.3/debian/changelog  2015-06-09 21:54:48.0 
+0900
@@ -1,3 +1,10 @@
+r-cran-rcurl (1.95-4.3-1+deb8u1) jessie; urgency=medium
+
+  * Team upload.
+  * Build-Depend on libcurl4-openssl-dev only (Closes: #786473).
+
+ -- Charles Plessy ple...@debian.org  Tue, 09 Jun 2015 21:54:38 +0900
+
 r-cran-rcurl (1.95-4.3-1) unstable; urgency=medium
 
   * New upstream version
diff -Nru r-cran-rcurl-1.95-4.3/debian/control 
r-cran-rcurl-1.95-4.3/debian/control
--- r-cran-rcurl-1.95-4.3/debian/control2014-09-17 19:36:29.0 
+0900
+++ r-cran-rcurl-1.95-4.3/debian/control2015-05-31 09:15:18.0 
+0900
@@ -9,7 +9,7 @@
cdbs,
r-base-dev,
r-cran-bitops,
-   libcurl4-nss-dev | libcurl-dev
+   libcurl4-openssl-dev
 Standards-Version: 3.9.5
 Vcs-Browser: 
http://anonscm.debian.org/viewvc/debian-med/trunk/packages/R/r-cran-rcurl/trunk/
 Vcs-Svn: 
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-rcurl/trunk/

Have a nice day,

Charles

-- 
Charles Plessy
Debian Med packaging team
Tsurumi, Kanagawa, Japan


-- 
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/20150609215824.20002.44701.reportbug@aqwa.igloo



[fis-gtm] FW: GT.M V6.2-002 available

2015-06-09 Thread Shah, Amul
[sorry for the top post, Outlook doesn't do proper quoting]
Hi Andreas,
I uploaded the latest version of GT.M that we released yesterday. I tagged the 
version as unstable. Let me know if that was the correct thing to do.

As always, thanks for help.

Amul


From: Bhaskar, KS
Sent: Monday, June 08, 2015 1:48 PM
To: Omar Shboul; Khamis Siksek; Ahmad Sharaf; Mohammed Sharaf; Murat Khemesh; 
Wasim Naffar
Cc: FIS MLN GG GT.M Support
Subject: GT.M V6.2-002 available


V6.2-002 brings a number of modest enhancements to GT.M.

Improving performance:

  *   By reducing the number of dirty global buffers to be flushed in 
anticipation of an impending epoch, epoch tapers aim to ameliorate spikes in 
response time that can occur at epochs.

  *   $ORDER(gvn,-1) - reverse dollar order - of global variables is faster.

  *   Under conditions of high contention, processes holding locks exit faster, 
processes acquire database critical sections more efficiently when the mutex 
queue slots are all used, and lock acquisition is more efficient with 
substantially reduced impact on database throughput.

  *   Code size reduction that also improves performance.

Enhancements include:

  *   Intrinsic special variables: $ZUT provides a universal (across systems 
and across time zones) time stamp, and $ZHOROLOG extends $HOROLOG with 
additional pieces that provide microsecond resolution and time zone information.

  *   TLS for SOCKET devices benefits from enhancements to WRITE /TLS and 
$ZSOCKET().

  *   The environment variable gtm_autorelink_ctlmax provides a control to set 
the number of unique routine names in relink conrol files.

VIEW POOLLIMIT functionality introduced as field test grade functionality in 
the production release V6.2-001 is considered production grade functionality in 
V6.2-002.

As always, the release bring numerous smaller enhancements, including to the 
$ZQGBLMOD() function, better handling of split $PRINCIPAL, more helpful 
TPRESTART messages, and more. Robustness is improved, especially in the 
triggers, and security has been tightened by dropping support for dubious edge 
cases . These changes are described in the Release Notes 
(http://tinco.pair.com/bhaskar/gtm/doc/articles/GTM_V6.2-002_Release_Notes.html).

Please do upgrade to V6.2-002, and tell us how it works for you.  Thank you for 
using GT.M.

Regards
-- Bhaskar

--
GT.M - Rock solid. Lightning fast. Secure. Pick any three.

_
The information contained in this message is proprietary and/or confidential. 
If you are not the intended recipient, please: (i) delete the message and all 
copies; (ii) do not disclose, distribute or use the message in any manner; and 
(iii) notify the sender immediately. In addition, please be aware that any 
message addressed to our domain is subject to archiving and review by persons 
other than the intended recipient. Thank you.


Re: python-pysam version lagging

2015-06-09 Thread Ghislain Vaillant
Hi guys, just a few additional comments

2015-06-09 9:14 GMT+01:00 Charles Plessy ple...@debian.org:

 Le Tue, Jun 09, 2015 at 12:38:31AM -0700, Afif Elghraoui a écrit :
 
  I was able to build it and clean it up a little more, but the package
 still
  has some lint:

 Hi Afif, thanks a lot for all this work.

  W: python-pysam source: dep5-copyright-license-name-not-unique
 (paragraph at
  line 40)
 
  I'm actually not sure what to do about this one.

 Try public-domain instead of PublicDomain.  public-domain is a special
 case
 in the machine-readable specification, so if the Lintian warning stays, I
 would
 consider it a false positive.

 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/


This is one of these weird lintian warnings that popped up recently. Seems
that
you can no longer define a License twice in d/copyright. I believe bug
reports
have been sent about the rationales behind this.

 I: ...hardening-no-fortify-functions...
 
  I think these are false positives since the CPPFLAGS for fortification
 look
  like they're correctly set as I watch the package build.

 I have seen such apparent false positives in other packages.  If you have
 time,
 maybe it is worth asking for comments on the debian-mentors mailing list ?


+1


  I: ...spelling-error-in-binary...
 
  This is maybe not worth fixing.

 Maybe the easiest way to get rid of it is a pull request to upstream on
 GitHub ?


Happened to me a few times, each time I ended up sending a patch upstream.
It's up
to you to decide whether you want to carry on a patch downstream just to
fix such an
inoffensive bug. I personally did not care to do so.


Best regards,
Ghislain